Workflow or agent
This block explains the first design choice for any feature built on a language model: who decides the next step, your code or the model. It also goes through the five workflow patterns from Anthropic's guide, which people often mistake for five kinds of agent.
Northwind's support inbox gets about 3,000 messages a day. "Where is my order?" is 60% of them, and it always takes the same moves: find the order, get the delivery status, write the reply. Then a customer writes: "Order 4417 came broken, it was a gift, the replacement was late and I paid with a coupon." Nobody can list the moves for that one in advance.
A train and a taxi
A train runs on tracks laid before anyone bought a ticket. The crew can do skilled work at each stop, but the route is fixed. Where the line branches, a signal sends the train down one of the tracks that already exist.
A taxi driver gets a destination and picks the streets, and picks new ones when a road is closed. The driver can reach places no track goes to. The driver can also get lost while the meter runs.
In Anthropic's terms, a workflow is the train: models and tools are connected by code paths written in advance. An agent is the taxi: the model directs its own process and its use of tools. Anthropic calls both "agentic systems" and notes that the word "agent" has several definitions, so ask what a person means by it.
The phone colleague from the first block is a taxi driver: after each answer, they tell you what to do next. In a workflow you hold the script, and you ring them for one narrow job at a time. "Pull the order number out of this email." "Write a reply from these facts."
One workflow, slowly
Your code sends the customer's message to the model and asks for the fields as JSON.
The model returns them:
{
"order_id": "4417",
"intent": "where_is_my_order",
"language": "en"
}Your code checks the result with ordinary if statements. Anthropic's guide calls such a check a gate.
Your code fetches the order and the delivery status. No model is involved.
Your code sends the facts to the model, which writes the reply.
def where_is_my_order(message, session):
fields = extract_fields(message) # model call
if not fields.get("order_id"): # gate
return ASK_FOR_ORDER_NUMBER
order = orders.get(fields["order_id"], session.customer_id)
if order is None: # gate
return NO_SUCH_ORDER
status = shipping.status(order.tracking_id)
return write_reply(fields, status) # model callThis function makes at most two model calls. Replace those two with stubs and the if statements test like any other code.
The price of each choice
| Workflow | Agent |
|---|---|---|
Who picks the next step | Your code | The model |
Model calls per request | Usually known from the code | Varies, up to your budget |
Unforeseen cases | Only the paths you wrote | Can change course |
Testing | Paths test like normal code | Anthropic advises extensive testing in a sandbox |
Anthropic's guide names higher cost and the potential for compounding errors as the price of an agent's autonomy. Some arithmetic shows why the length of a run matters. Suppose each step is right 95% of the time, steps are independent, and one wrong step spoils the run. Ten steps then come out right about 60% of the time.
Real steps are not independent, and an agent can notice a mistake and repair it, so read the curve as a rough picture. A gate in a workflow pushes against the same curve, because it stops the bad output it catches at the step that produced it.
Anthropic's advice is to find the simplest solution and add complexity only when it demonstrably improves outcomes. That can mean no agentic system at all, just one model call with retrieved context and examples. Northwind sorts its messages that way:
Message | Design | Why |
|---|---|---|
"Do you ship to Norway?" | One model call with the shipping policy retrieved | Nothing to decide between steps |
"Where is my order?" | Workflow | The steps are known |
The broken gift with the coupon | Agent | Each move depends on what the last lookup found |
The designs combine. A router at the front sends known categories to their workflows and everything else to the agent. Anthropic lists customer support as a good fit for open-ended agents, so the agent stays, on the messages that need it.
Five workflow patterns
Anthropic's guide describes five patterns under workflows and describes agents in a separate section. So "five types of agents" is a misquote. Other authors use other names for the same shapes, and the picture gives the common ones in grey.
Pattern | What happens | At Northwind |
|---|---|---|
Prompt chaining | Each call reads the previous output, with gates between | Extract fields, check them, write the reply |
Routing | A classifier sends the input to a specialized follow-up | Refunds, delivery and account questions get separate prompts |
Parallelization | Independent subtasks at once (sectioning), or one task several times (voting) | One call answers while another screens for abuse |
Orchestrator-workers | A central model splits the task at run time, delegates, combines the results | Check whichever services a bug report turns out to involve |
Evaluator-optimizer | One call generates, another gives feedback, in a loop | Redraft an apology until it meets the tone guide |
Orchestrator-workers is the closest to an agent, since the model decides the subtasks. Anthropic still files it under workflows. Later blocks return to the last two.
Conclusion
- In a workflow your code sets the path. In an agent the model does, until it finishes or a stop condition fires.
- Start with the simplest design that works: one call, then a workflow, then an agent, and mix them by message type.
- A workflow buys predictability and normal tests. An agent buys flexibility and pays in cost, latency and errors that can add up.