Most AI agents are workflows in disguise. Five patterns cover 90% of real tasks. Genuine autonomy is for the other 10%.
Most things marketed as AI agents are not agents. They are workflows: fixed sequences of LLM calls with predefined branching logic and deterministic execution paths. The distinction matters, not because "workflow" is a demotion, but because calling a workflow an agent tends to make you engineer it wrong. You add complexity it doesn't need, remove predictability you were counting on, and then wonder why the system that was supposed to be intelligent keeps doing unexpected things.
Anthropic's own engineering team puts it plainly: find the simplest solution possible, and only increase complexity when a simpler workflow genuinely can't do the job. The most common production mistake isn't under-engineering AI systems. It's reaching for autonomous loops when a fixed workflow would have been cheaper, faster, and far more debuggable.
A workflow executes LLM calls and tool calls through code paths you define in advance. You decide the structure; the model fills in the content. It is predictable, testable, and cheaper because every call has a known place in a known sequence.
An agent is a system where the LLM dynamically decides its own sequence of actions based on what it observes — rather than following a control flow you wrote in advance. You own the goal and the guardrails; the model decides what to do next. Flexible. Harder to predict. More expensive. And errors can compound across steps in ways they can't in a fixed workflow.
The practical test: can you enumerate the steps this task requires before running it? If yes, you're building a workflow and should. If no — if the right next step genuinely depends on what the previous step returned, and you can't anticipate that in advance — that's when an agent earns its complexity.
These are Anthropic's own taxonomy. Five compositional patterns that are all technically workflows — predefined code paths — but that together cover nearly every real production use case. If your task fits any of these, you don't need a full autonomous agent.
Each LLM call processes the output of the previous one, in a fixed sequence. The model at step 3 doesn't decide to go to step 3. Your code does. Use when the task decomposes cleanly into ordered stages whose structure you can write down in advance.
An LLM classifies the input and directs it to a specialised follow-up path. The model decides which branch, but not what the branches are. Use when different input types need genuinely different handling that's too varied to cover with one general prompt.
Multiple LLM calls run simultaneously, results aggregated at the end. Two sub-variants: sectioning (divide the problem, run each part independently) and voting (run the same task multiple ways, pick the consensus or best answer). Use when subtasks have no dependencies on each other.
A central LLM dynamically breaks a task into pieces and delegates to worker LLMs. The orchestrator decides the subtasks; the workers execute them. Closer to agentic than the previous patterns: the orchestrator has real decision-making power. Still a workflow if the worker execution paths are predefined.
One LLM generates a response; a second evaluates it against criteria; loop until it passes or you hit a ceiling. The classic 'generate and critique' pattern. Works when you can state what 'good' looks like precisely enough that an LLM can score it reliably. If you can't, the loop runs without improving anything.
Once a task does need genuine autonomy, two loop shapes handle the majority of production cases. The choice between them is less about which is "better" and more about which failure mode you're most worried about.
The foundational loop. The model alternates: Thought (what do I know, what do I need next) → Action (call a tool) → Observation (what came back) → loop or terminate.
Strengths: transparent, auditable, adapts immediately to unexpected results. If a search returns nothing, it reformulates. If an API errors, it tries a fallback. The loop recalibrates after every single step.
Weakness: prone to getting stuck on tasks that need strict execution order, since it recalibrates at every step rather than committing to a plan.
Use for:
Exploratory, open-ended tasks — debugging, research, anything where the right next step can't be known until the previous step returns.
Splits thinking into two phases. A planner LLM writes the full multi-step plan up front, then an executor runs each step in sequence — or in parallel where steps don't depend on each other.
Strengths: locks in a coherent strategy before any irreversible action is taken. Reduces step-count on long-horizon tasks. Lets a cheaper model do plain execution once a stronger model has done the planning.
Weakness: less adaptive — if an early step produces an unexpected result, the plan doesn't automatically recalibrate the way ReAct does.
Use for:
Long, structured tasks where you need a guaranteed sequence and mid-stream drift — the agent executing well but in the wrong order — is the failure mode you're most worried about.
The simplest quality loop: generate output, evaluate it, accept or revise. The agent becomes its own reviewer. Identical in shape to evaluator-optimizer, but run as a loop within a single agent rather than as two separate calls.
A coordinator LLM breaks a large task into pieces and dispatches to specialised sub-agents. For high-stakes factual decisions: spawn multiple agents with different stances and have them argue; a judge synthesises the result. Measurably reduces hallucination because no single confident wrong answer goes unchallenged.
Retrieval embedded inside the reasoning loop rather than run once upfront. The agent decides mid-loop when it needs to retrieve and what to retrieve, based on what it's discovered so far. Different from standard RAG — retrieval itself becomes an available action at every step, not a fixed preprocessing stage.
For long-running tasks: periodically checkpoint progress to a durable store — a doc, a file, a task list — and restart the loop with compressed context rather than letting the context window grow unbounded. The emerging standard for multi-session or multi-day tasks.
These are what production teams actually learn, usually after deploying something that seemed to work fine in testing. Design against all of them before you build, not after.
ReAct-style agents can cycle without making progress if the termination condition is poorly specified. The fix: define an explicit "done" condition, and add a hard step-count ceiling as a backstop. Both. Not one or the other.
Each autonomous step is a chance to drift further from the goal. The longer the loop, the more this matters. Grounding in real environment feedback at each step — tool output, execution results — is what keeps this in check. Not just model reasoning.
The evaluator-optimizer pattern breaks down when the evaluator can't reliably distinguish good output from bad. If you can't clearly state what "good" looks like, this pattern will loop without actually improving anything. State the quality bar before you build the loop.
Reaching for multi-agent orchestration or full autonomy on tasks that are actually fixed-sequence or simple classification problems. Reported as the single most common production mistake — not the reverse. The same note applies to agent frameworks: they simplify getting started, but hide what's actually happening, making debugging harder.
These steps are sequenced deliberately. Skipping ahead is the failure mode.
Before writing any code or prompt. If you can't state what success looks like, you're not ready to build the loop yet — you're still scoping the problem. A vague goal produces a loop that can never terminate correctly.
Usually prompt chaining or routing. Only move up the table toward orchestrator-workers or full autonomy if the simpler pattern demonstrably can't handle the task's actual complexity. Most don't need to move up.
Step-count ceilings, explicit termination conditions, human-in-the-loop checkpoints at points where an irreversible or high-stakes action would otherwise happen unsupervised. These come first.
Tool call results, execution output, retrieved documents. Not just model reasoning. This is what lets an agent self-correct instead of drifting. A model that only reasons from its own prior output will compound its own errors.
To a durable external store rather than letting them run unbounded inside one context window. Compress and restart rather than accumulate indefinitely. Long context windows don't fix this — they delay it.
Measure whether the loop actually improves outcomes over the simpler workflow before committing to it in production. Same discipline as RAG: 'it looks like it's working' is not evaluation. The gain from autonomy should be measurable, not just felt.
Which pattern fits which task.
Fixed, ordered sub-steps
Prompt chaining
Different input types need different handling
Routing
Independent subtasks, or want consensus across attempts
Parallelisation
Subtasks unknown until main task is examined
Orchestrator-workers
Clear quality bar exists and iteration helps
Evaluator-optimiser
Exploratory, open-ended, uncertain next step
ReAct
Long, structured, guaranteed sequence required
Plan-and-Execute
High-stakes factual decision
Debate pattern (multi-agent)
Retrieval need only becomes clear mid-task
Agentic RAG
Task spans multiple sessions or days
Loop engineering + checkpointing
Yao et al. · arXiv 2022
The paper that established the Reason + Act loop as a viable LLM architecture — the conceptual foundation for every agent framework built since.
Daniel Kahneman · Farrar, Straus and Giroux
The cognitive science behind when to trust fast intuitive outputs versus slow deliberate reasoning — maps directly onto when to use single-shot LLM calls versus multi-step agent loops.
Lilian Weng · lilianweng.github.io
The most widely cited technical overview of LLM agent architectures — planning, memory, tool use, and multi-agent coordination explained with both diagrams and implementation detail.
Continue the conversation
If this changed how you think about it — or you think I'm wrong — I want to know.
Corrections, disagreements, and applications all welcome. Replies go directly to Chris.
Get in touch →STOP BUILDING AGENTS
~6-8 min1× · Two speakers · tap to play