Most teams meet AI agents through a prompt and a demo. An operation needs more than that. Before an agent touches a live queue, someone has to write down what it does first, what it is allowed to touch, when it gives a case to a person, and when it stops trying. That written-down shape is the agent workflow, and the quality of an agent in production depends on it more than on the wording of any instruction. The wider question of which work an agent should own at all is covered in AI agents for business.
What are the parts of an AI agent workflow?
Five parts recur in every agent workflow that holds up in production.
| Part | The question it answers | Example in an invoice-matching workflow |
|---|---|---|
| Steps | What happens, in what order? | Read the invoice, find the purchase order and the goods receipt, compare lines |
| Tools | What may the agent call, read or write? | Read access to the ERP, write access only to a "ready to post" status |
| Hand-offs | Who gets the case when the agent should not finish it? | Variances above tolerance go to the accounts payable clerk with a summary |
| Stop conditions | When does the run end? | Purchase order not found after two lookups; supplier on a hold list |
| Record | What is logged for audit and learning? | Every lookup, the comparison, the decision and who made it |
The steps and tools describe the work. The hand-offs and stop conditions describe its edges, and the edges are where operations get hurt when they are missing.
How does an agent workflow differ from a fixed workflow?
Anthropic draws the line clearly in its engineering guidance: workflows are "systems where LLMs and tools are orchestrated through predefined code paths," while agents are "systems where LLMs dynamically direct their own processes and tool usage." An agent workflow sits between the two. The skeleton is fixed by the designer, and the agent chooses its moves inside each step: which record to pull next, whether two supplier names refer to the same company, how to phrase the note to the clerk.
That mix is deliberate. Anthropic's same guidance notes it is common to include stopping conditions, "such as a maximum number of iterations," to keep control. OpenAI's practical guide to building agents makes the same point in its section on human intervention: "Set limits on agent retries or actions," and hand the case to a person when the agent exceeds them. Both are workflow design, written outside the model.
Where does a person fit in an agent workflow?
At the hand-offs. A well-designed workflow names the cases a person receives, what the person sees when the case arrives, and how quickly they need to act. That is the human-in-the-loop part of the design, and it decides whether the people on the team trust the agent or route around it. The limits that trigger those hand-offs are the agent's guardrails.
What goes wrong when the workflow is only a prompt?
The agent improvises its edges. It retries a lookup until it times out, posts an invoice it should have held, or escalates everything because nothing told it what "unusual" means. A prompt can ask for caution, but it cannot enforce a permission or keep an audit log. Put those in the system around the agent, test the workflow against last quarter's real exceptions, and change the prompt last.
An engineered AI workflow automation build starts from this level of definition, and intelligent workflow automation is the broader concept behind it. For an operations team, the practical test is simple to state: could a new hire read the workflow and know exactly which cases the agent finishes and which ones land on their desk? If not, the workflow is not done.