Workflows vs agents: the patterns

The big idea

"Agent" has become a word for almost any system with a language model in it. A more useful split, popularised by Anthropic's engineering team, is between two kinds of agentic systemAny system in which language models and tools work together over several steps, whether the steps are fixed in code or chosen by the model.:

• A workflowA system in which language model calls and tools are arranged along code paths you defined in advance. runs model calls and tools along paths you wrote in code. You decide the steps; the model does each step.
• An agent lets the model decide its own steps and tool use, in a loop, until it judges the task is done.

Workflows are predictable, cheaper and easier to test. Agents are flexible, but cost more, take longer and can compound errors. So the rule of thumb is to start with the simplest thing that works, often a single well-prompted call with retrieval, and add steps only when measurements show they help.

Think of a restaurant kitchen. Most dishes follow a recipe card: prep, cook, plate, check. A few situations, like a customer with three allergies and an odd request, need a chef who improvises. You would not run the whole kitchen by improvisation.

How it works

All six build on one block: an "augmented" model call that can use retrieval, tools and memory ( Why RAG? , Function calling and tool use ). The patterns differ in who decides the next step: your code, or the model.

1. Prompt chaining

Split a task into fixed steps, each call working on the previous call's output: write an outline, check it, then write the document. Between steps, add gatesA programmatic check between steps of a chain, such as a length, schema or keyword test, that stops or reroutes the workflow when an intermediate result looks wrong., plain code checks that stop the chain early when an intermediate result looks wrong. You trade latency (more calls) for accuracy, because each call has an easier job.

2. Routing

Classify the input once, then send it to a prompt, model or tool set built for that category: refund requests, technical questions and general queries each get their own handling. Routing keeps each prompt focused, so tuning one category does not break another. It also saves money: easy questions go to a small model and hard ones to a large one ( Routing, cascades and cost optimization ). It works when classification itself is accurate.

3. Parallelization

Run calls at the same time and combine the results in code. Two flavours:

• Sectioning: independent subtasks in parallel, such as one call answering the user while another screens the request for policy violations, or one call per evaluation criterion.
• Voting: the same task several times, then a vote or threshold, such as several reviewers flagging security problems in a piece of code. This is self-consistency ( Reasoning models and test-time compute ) used as a pattern.

Separate calls give each consideration the model's full attention, and the latency is that of the slowest call, not the sum.

4. Orchestrator-workers

A lead model reads the task and decides the subtasks at run time, sends each to a worker call, then merges the results. It looks like parallelization, but the subtasks are not fixed in advance. That fits coding changes, where the files to edit depend on the request, and research across many sources. It is the bridge to multi-agent systems ( Multi-agent systems ).

5. Evaluator-optimizer

One call drafts; another evaluates the draft against clear criteria and returns specific feedback; the draft is revised and checked again. Use it when you can state what "good" means and when feedback measurably improves the output: a translation that misses nuance, a summary that must include every key number. Always cap the rounds.

6. Autonomous agents

The model plans and acts on its own in a loop, getting "ground truth" from the environment at each step, such as tool results or test outcomes, and stopping when done, when it needs a human, or when a limit is hit ( The agent loop (ReAct) ). Use agents for open-ended problems where you cannot predict the number of steps or hard-code a path, and where you trust the model's decisions enough. Their autonomy brings higher cost and compounding errors, so test them in sandboxes and add guardrails.

When simple beats complex

Climb the ladder one rung at a time, and only when an evaluation shows the extra rung helps:

1. One well-prompted call with good context and examples.
2. Add retrieval or a tool.
3. A workflow pattern with fixed steps.
4. An agent, for the parts that truly need open-ended decisions.

Frameworks can hide the actual prompts and responses behind layers of abstraction. Many patterns are a few lines of ordinary code, so start there, and if you adopt a framework, make sure you know what it sends to the model.

Try it

Try this:

1. Sort all eight. For each one you put in "Agent", could a fixed workflow handle 90 percent of cases, with an agent only as a fallback?
2. Find the two routing and parallelization items. What in the task description told you the steps were fixed?

Each pattern really is a few lines of ordinary code. Here they are with a canned stand-in for the model:

# Workflow patterns are ordinary code around LLM calls. `llm` is a stand-in that returns canned text.
from concurrent.futures import ThreadPoolExecutor
def llm(task, text=""):
    canned = {"classify": "refund" if "money back" in text else "tech",
              "outline": "1. Problem 2. Fix 3. Result", "draft": f"Post following: {text}",
              "review": "PASS" if "with numbers" in text else "FAIL: add numbers",
              "revise": text + " with numbers"}
    return canned.get(task, f"[{task} answer for: {text[:30]}]")
def chain(topic):                       # prompt chaining with a gate between steps
    outline = llm("outline", topic)
    if outline.count(".") < 3:          # programmatic gate: stop early if step 1 looks wrong
        return "gate failed"
    return llm("draft", outline)
def route(ticket):                      # routing: classify once, then a specialised prompt
    handlers = {"refund": "refund_policy_prompt", "tech": "troubleshooting_prompt"}
    return handlers[llm("classify", ticket)]
def parallel(code):                     # parallelization (sectioning): independent checks at once
    checks = ["security review", "style review", "test coverage review"]
    with ThreadPoolExecutor() as pool:
        return list(pool.map(lambda c: llm(c, code), checks))
def evaluate_optimize(draft, rounds=3): # evaluator-optimizer, with a round limit
    for i in range(rounds):
        verdict = llm("review", draft)
        print(f"  round {i + 1}: {verdict}")
        if verdict == "PASS":
            return draft
        draft = llm("revise", draft)
    return draft
print("chain:   ", chain("cache stampede"))
print("route:   ", route("I want my money back"), "|", route("app crashes on start"))
print("parallel:", parallel("def f(): pass"))
print("evaluator-optimizer:")
print("  final:", evaluate_optimize("Launch post draft"))

chain:    Post following: 1. Problem 2. Fix 3. Result
route:    refund_policy_prompt | troubleshooting_prompt
parallel: ['[security review answer for: def f(): pass]', '[style review answer for: def f(): pass]', '[test coverage review answer for: def f(): pass]']
evaluator-optimizer:
  round 1: FAIL: add numbers
  round 2: PASS
  final: Launch post draft with numbers

Going deeper

Combining patterns

Real systems mix patterns. A support assistant might route each message, run a guardrail check in parallel with the main answer, and hand only the "complex account problem" route to an agent with account tools. The production RAG system in Production RAG architecture is a workflow: rewrite, retrieve, rerank, generate, check.

Tools are the agent's interface

Anthropic's post argues you should invest as much in the agent-computer interface, meaning tool names, descriptions and parameters, as you would in a human interface, and make tools hard to misuse. In its coding agent work, the team reports spending more time optimizing tools than the overall prompt; switching a tool to require absolute file paths fixed mistakes the model made with relative ones. More on this in Making agents reliable .

Trade-offs

Common mistakes

• Building an agent first, when a single call or a fixed workflow would do.
• Adding steps without measuring whether they improve results.
• Using a framework without knowing what prompts it actually sends.
• An evaluator-optimizer loop without clear criteria or a round limit.
• Routing on an inaccurate classifier, so every downstream specialisation receives the wrong inputs.

In the wild

Check yourself

Recap