Workflows vs Agents: The 6 AI Agent Orchestration Patterns (and When to Go Multi-Agent)
"Agent orchestration" sounds exotic, but the question underneath it is plain: how do you arrange one or more LLM calls into a system that solves a real task, reliably? The answer most teams who have shipped agents converge on is also plain. As Anthropic put it in its December 2024 guide Building effective agents: "the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns."
Workflows versus agents
Anthropic draws a line that's worth adopting:
- Workflows are systems where LLMs and tools are orchestrated through predefined code paths. You write the control flow.
- Agents are systems where the LLM dynamically directs its own process and tool use. The model decides the control flow at runtime.
Workflows give predictability and consistency for well-defined tasks. Agents are the better option when the path genuinely can't be predicted in advance. For many applications, a single well-prompted LLM call with retrieval and good examples is enough.
The six patterns
Each one maps onto something you already know from distributed systems.
| Pattern | What it does | Familiar analogy | Use it when |
|---|---|---|---|
| Prompt chaining | A fixed sequence; each call's output feeds the next, with optional checks between steps | A Unix pipe or ETL pipeline | The task splits into clean, fixed subtasks (outline → draft → revise) |
| Routing | A classifier sends each input to a specialised handler | An API gateway routing by path | Different request types need different prompts, tools or models |
| Parallelization | Run subtasks concurrently and merge, by sectioning or by voting | Scatter-gather / MapReduce | Parts are independent, or you want confidence from repeated runs |
| Orchestrator–workers | A lead LLM decides the subtasks at runtime and delegates them | A coordinator fanning jobs out to a worker pool | You can't know the subtasks up front, such as code changes across an unknown number of files |
| Evaluator–optimizer | One LLM generates, another critiques against criteria, repeat | A CI suite gating a build | You have clear quality criteria and iteration measurably helps |
| Autonomous agent | The model runs a reason–act–observe loop freely until done | — | Maximum flexibility is worth maximum cost and unpredictability |
The patterns compose: a router often feeds a prompt chain, and an orchestrator's workers often run an evaluator–optimizer loop. But each added layer adds a failure mode. Every extra LLM call adds latency, cost and a compounding error rate, so add calls deliberately, at decision points you chose.
Routing: the most underrated pattern
Routing deserves a closer look because it's cheap and it pays twice. A support inbox with billing, tech and general questions sends each message through a small classifier first:
input -> [ Router LLM ] classifies intent | +--------+---------+ v v v billing tech-support general (prompt+ (prompt+ (cheap tools) tools) model) The router does one narrow job: output a category. Keeping it tool-free and single-purpose makes it fast, cheap, and easy to test with a plain classification eval. And it lets you send easy questions to a cheap model and hard ones to a capable one.
The agent loop, and why it needs a budget
Underneath every autonomous agent is the ReAct loop (Yao et al., 2022): the model writes a thought, takes an action, observes the result, and repeats. To a backend engineer, it's a while loop around a stateless handler:
for step in range(MAX_STEPS): # a budget cap prevents infinite loops response = llm.chat(messages, tools=tool_schemas) if response.tool_call: result = tools[response.tool_call.name](**response.tool_call.args) messages.append(response.raw) messages.append({"role": "tool", "content": str(result)}) continue print(response.content) # no tool call -> final answer break That step budget isn't decoration. An unbounded agent loop is the agent equivalent of runaway recursion.
Single agent or multi-agent?
This was the field's biggest architecture debate of 2025, and the evidence is worth knowing before you build a team of agents.
- Against: in June 2025, Cognition (the makers of Devin) published Don't Build Multi-Agents. Their argument: parallel subagents that don't share full context make conflicting implicit decisions, and "actions carry implicit decisions, and conflicting decisions carry bad results."
- For, with a price: a day later, Anthropic described its multi-agent research system, a Claude Opus 4 lead with Claude Sonnet 4 subagents. It beat a single Claude Opus 4 agent by 90.2% on their internal research eval. It also used about 15 times more tokens than a chat interaction, against roughly 4x for a single agent.
- The failure data: the MAST study (Cemri et al., NeurIPS 2025) annotated 1,642 execution traces across seven multi-agent frameworks and found failure rates from 41% to 86.7%. About 42% of failures came from specification and system design, 37% from misalignment between agents, and 21% from weak task verification.
The consensus that emerged by 2026: multi-agent helps for genuinely parallel, breadth-first work such as research. The reliable shape is one stateful orchestrator that holds the full context, with narrow, stateless subagents that return summaries, not a chatty peer-to-peer mesh. Even Cognition's author later acknowledged that setups following exactly this shape "actually work."
How agents talk to each other
When you do need more than one agent, there are three coordination mechanisms, from tightest to loosest coupling:
- Shared state: every agent reads and writes one common state object. Best for agents inside one process.
- Handoffs: one agent transfers control, usually with the conversation history, to another. A triage agent handing a billing issue to a billing specialist means the user never repeats themselves.
- Agent-to-agent protocols: for agents across processes or organisations. A2A (Agent2Agent), announced by Google in April 2025 and donated to the Linux Foundation that June, has each agent publish an Agent Card describing its skills and endpoints.
The tidy distinction: MCP is vertical (agent to tools) and A2A is horizontal (agent to agent). Production systems often use both: A2A routes a task to the right specialist, and MCP gives that specialist its tools.
The rule to remember
Start at the lowest rung that works: a single call, then a workflow, then an agent, and only then a team of agents. Climb only when the simpler design demonstrably fails.
Originally published on TechBrosEbooks.
This article is adapted from the ebook The AI Agent Field Manual, which goes on to memory and RAG, checkpointing, durable execution, queues and retries, observability and evals, security, and a complete support-ticket triage system built end to end.