Agent Architecture Patterns

There are perhaps six shapes worth knowing, and the industry has spent a great deal of energy on the most complicated one. The pattern conversation usually starts at multi-agent — a planner, a researcher, a critic, a writer, each with a persona and a system prompt — because that is the diagram that looks like progress. It is almost always the wrong starting point, and the reason is not aesthetic. It is that multi-agent systems reintroduce, inside your process, precisely the coordination problem that makes large delivery organisations slow.

The patterns below are ordered by how much structure they impose and how little they cost to operate. The correct approach is to start at the top and escalate only when you have evidence — a measured failure mode, not a suspicion — that the simpler shape cannot do the job. Almost every team that started at the bottom has spent the following quarter walking back up.

Nothing here is exotic. These are the same composition primitives you already use for services: a function, a pipeline, a switch, a coordinator with workers, a scatter-gather, and a set of independent processes exchanging messages. The difference is that one participant is non-deterministic, which changes the economics of each choice rather than the choices themselves.

Single loop

One model, one tool set, one context, iterating until it concludes or hits a cap. ReAct-style in its simplest form: observe, choose a tool, observe the result, choose again.

This is the default and it is underrated. It has one context, so nothing has to be summarised and handed between parties. It has one trajectory, so debugging is reading a transcript in order. It has one cost line and one place to enforce a step budget. When people report that a complicated multi-agent system was replaced by "just a loop with better tools" and got faster, cheaper and more accurate, this is the thing they replaced it with.

What it is genuinely for: tasks with an open sequence but a single coherent objective, where all the relevant work can be done with one set of tools and the context stays manageable. Investigation, research within one domain, debugging, most coding tasks, most support resolution.

Where it breaks: when context grows past the point where the model reliably attends to the earlier parts of it, or when the task genuinely decomposes into independent pieces that would be faster in parallel. Those are the two legitimate reasons to escalate, and they are measurable.

Prompt chain

A fixed sequence of model calls, each transforming the output of the last. Extract, then classify, then draft, then check. Control flow is in your code; the model does not choose anything except content.

This is not an agent and that is the point. It is the highest-reliability shape available, because every step is individually testable, individually replaceable and individually observable. Each step gets a small focused prompt rather than one prompt carrying five responsibilities, which measurably improves quality on each.

Use it whenever the procedure is known. If you can draw the flowchart, draw the flowchart. The most common architectural mistake in this field is paying a model to rediscover a process you have already documented.

The chain also gives you a natural place to put deterministic work. Validation, lookups, formatting, arithmetic and anything with a correct answer should be code between the model steps, not instructions inside them.

Router

One model call classifies the input and dispatches to one of a fixed set of handlers. Each handler can itself be a chain, a loop, or plain code.

The router is the cheapest way to get adaptability without giving up enumerability. Every path is known, so every path can be tested and costed. The only non-determinism is which branch you take, and misrouting is a single, measurable, improvable failure mode with a confusion matrix behind it.

Most systems described as agents would be better as a router over three chains. It is worth building the router first even when you expect to need a loop, because the routing distribution tells you where the real work is concentrated, and it frequently reveals that eighty per cent of traffic is three well-understood cases with a long, quiet tail.

Keep the branch set small and give the router a default that escalates rather than guesses. A router with fifteen branches is a router that will misroute, and a router that cannot say "none of these" will pick the nearest wrong one.

Orchestrator-worker

A coordinating model decomposes a task into subtasks, dispatches each to a worker with its own fresh context, and assembles the results. The workers do not talk to each other. All coordination flows through the orchestrator.

This is the first genuinely useful multi-model shape, and the reason it works is context isolation rather than specialisation. Each worker starts clean, does one bounded thing, and returns a compact result. The orchestrator never holds the full detail of any subtask, only the summaries, which is how a long task stays inside a workable context. That mechanism is the subject of context engineering and agent memory, and it is the real argument for this pattern.

It works when subtasks are genuinely separable and the result of one does not change how another should be done. Research across several sources, checking a change against several independent criteria, gathering evidence from several systems before a judgement.

It fails when the decomposition is wrong, which you will not find out until the results come back incoherent. The orchestrator is making a plan with less information than it will have later, which is the same reason up-front project plans fail. Give it a way to revise: dispatch, read results, dispatch again, rather than planning the whole tree in one go.

Parallel fan-out with a reducer

The same work, or independent slices of it, run concurrently, with a deterministic or model-based step that combines the outputs.

Two distinct uses, and it is worth not confusing them. The first is throughput: ten documents, ten concurrent calls, one aggregation. That is plain parallelism and it needs no cleverness. The second is quality through sampling: run the same judgement several times and take the consensus, or run several different checks over one artefact and combine the findings. This buys real reliability on tasks where errors are uncorrelated, at a direct multiple of the cost.

Make the reducer deterministic wherever you can. A voting rule, a union of findings, a schema merge. A model-based reducer is another place to be wrong, and it is the place where a subtle failure is hardest to see because the individual workers all looked fine.

Watch the cost multiplier honestly. Fan-out of five is five times the tokens for a reliability gain you should be able to measure. If you cannot measure it, you are buying a feeling.

Multi-agent, and the coordination cost nobody budgets

The full shape: several agents, each with its own goal, context and tools, exchanging messages, potentially running concurrently, potentially long-lived.

Before building this, notice what you have just done. You have created independent actors with partial information, each making decisions the others cannot see, connected by a lossy communication channel. That is the exact structure of a multi-team delivery organisation, and the arithmetic of why those get slow is well established: the number of pairwise channels grows as the square of the participant count, and each channel is not a line on a diagram but a queue with latency and loss. Three agents have three channels; six have fifteen. Every message is a summarisation, and every summarisation drops the detail the receiver turns out to need.

Agents suffer this worse than teams do, for three reasons. Humans repair misunderstanding opportunistically — they ask, they notice a confused expression, they check. Agents accept the message as given and proceed confidently. Humans share an organisational context that is never written down; agents share only what is in the message. And a human who realises a plan is wrong can escalate outside the process, while an agent will usually keep going.

So the honest position is this. Multi-agent systems are frequently worse than one good loop, they are always more expensive, and the failure modes they add — deadlock, ping-pong between two agents each waiting for the other to decide, confidently-passed misunderstandings, cost that grows with conversation length rather than with task size — are harder to diagnose than anything a single loop produces. They are justified in a narrow set of cases: genuinely concurrent long-lived work, hard trust boundaries where one component must not have another's authority, or organisational reality where different teams own different agents and you are modelling Conway's law rather than fighting it.

If you build one, apply the same medicine you would apply to a slow organisation. Reduce the number of participants. Make the interfaces explicit and typed rather than conversational. Remove dependencies rather than coordinating them. Prefer a hierarchy with one coordinator over a mesh of peers, because a mesh has no place to put the cap, the budget or the stop button.

Selecting between them

Pattern	Use when	Coordination cost	Debuggability	Escalate to it when
Prompt chain	The procedure is known	None	Highest	Never; this is the floor
Router	Inputs fall into known classes	Negligible	High	Branch behaviour genuinely differs
Single loop	Open sequence, one objective	None	High	A fixed chain cannot cover the tail
Orchestrator-worker	Separable subtasks, context pressure	Moderate	Medium	One context stops being enough
Parallel fan-out	Independent slices or sampled reliability	Low	Medium	Latency or uncorrelated-error gains are measured
Multi-agent	Concurrent long-lived work, trust boundaries	High and superlinear	Low	You have exhausted the rest and can prove it

The column that decides most arguments is the last one. Each escalation should be triggered by an observation, not an intuition: a measured context overflow, a measured latency requirement, a measured accuracy ceiling that a better tool did not move. Write the trigger down before you build, because after you build, the system will always seem to have been necessary.

What to do on Monday

Draw your current system as one of the six shapes. If it does not fit cleanly, it is probably two shapes stacked, which is fine — label both. The exercise takes twenty minutes and usually reveals at least one component doing coordination nobody designed.

Then try the demotion. Take the most complicated part and write down what it would look like one level simpler: the multi-agent mesh as an orchestrator with workers, the orchestrator as a single loop with more tools, the loop as a router over chains. You do not have to build it. You have to be able to say precisely which failure the simpler version would have, backed by something you have measured. If you cannot, build the simpler version, because you are currently paying for complexity you cannot justify.

Finally, instrument the escalation triggers so that the next decision is evidential. Log context size at the end of every run, step count, wall-clock time and cost per run. When any of those approaches a limit you have set, you will have the argument for the next pattern ready, with numbers in it. Getting those numbers systematically is the subject of evaluating agents.