The Agent Architecture Decision: Workflow, Single Agent, or Multi-Agent

Every time you design an LLM system, the same question nags at you: should this be one agent, or a whole team of them? Two instincts pull in opposite directions. One says hard problems are best attacked by a team of specialized agents working in parallel, the way an organization splits work across people. The other says that most of the time a single capable agent with good context will beat a committee, and the committee will cost more and fail in stranger ways. Both are right, just for different tasks. The goal of this guide is to make the boundary between them precise, with the architectures drawn out so the decision is concrete rather than guesswork. And one thread runs through every recommendation that follows: the architecture that wins is almost always the one that keeps each decision-maker best informed. The real discipline underneath the single-versus-multi question isn’t agent count, it’s context engineering.

Three words worth pinning down

An agent is an LLM running tools in a loop: it receives a goal, decides on an action, calls a tool, observes the result, and repeats until it judges the task done. The defining property is that the control flow is decided by the model at runtime, not hard-coded by you.

A workflow is the opposite: LLM calls wired together along paths you defined in code. The model fills in the cells, but the structure is fixed. Workflows are predictable, cheap, and easy to debug.

A multi-agent system is several agents (each its own tools-in-a-loop process, usually with its own context window) coordinating toward a shared goal through some orchestration layer.

Most features that ship reliably are workflows, not agents, and certainly not multi-agent systems. The most common architecture mistake is reaching for autonomy when determinism would do. Before asking how many agents, ask whether you need an agent at all. If the path is knowable, encode it. Agents earn their complexity only when the path can’t be known in advance.

Figure 1: The fundamental split. A workflow runs a path you defined; an agent decides its own path at runtime.

The core trade-off: parallelism versus coherence

Here is the one mental model to keep. Multi-agent systems trade coherence for parallelism and context capacity.

Splitting a task across agents gives each its own context window and lets them work simultaneously, a real advantage when the problem is too big or too broad for one context. But the moment you split, you fracture the shared understanding of the task. Each sub-agent now holds a partial, possibly conflicting picture, and they generally can’t see each other’s intermediate reasoning. Decisions made in parallel on conflicting assumptions are how multi-agent systems quietly produce confident nonsense.

So the real question for any task is: does this work decompose into independent pieces, or does every piece depend on every other piece? That maps cleanly onto a read/write axis:

• Read-heavy, parallelizable tasks

(research, search, retrieval, broad information gathering) decompose beautifully. Many sub-agents can investigate many facets at once, and merging their findings rarely produces contradictions. The pieces are loosely coupled.

• Write-heavy, coherence-critical tasks

(writing a codebase, drafting one document, producing a single artifact with internal consistency) decompose terribly. If two agents independently write two halves, the halves won’t fit. The pieces are tightly coupled, and someone has to hold the whole thing in their head.

This is exactly why the two instincts disagree. A research tool is a read task, and an orchestrator spawning parallel sub-agents substantially outperforms a single agent on open-ended, breadth-first questions. A coding agent is a write task, and fanning work out to parallel agents produces incoherent results because the sub-agents can’t share enough context to stay aligned. Both observations are correct about their own domain.

Where multiple agents genuinely earn their keep

Multi-agent architectures pay off when one or more of these hold:

1. The task exceeds a single context window.

The most concrete reason. Research over hundreds of sources, or analysis across a large corpus, benefits from giving each sub-agent its own window. The canonical structure is the orchestrator-worker pattern: a lead agent plans, persists that plan to external memory so it survives context truncation, then delegates scoped sub-questions to sub-agents that each explore with a fresh budget. Context isolation is the feature, not a side effect.

2. The task is embarrassingly parallel.

When subtasks are genuinely independent, parallelism is near-free speedup. Breadth-first exploration (“find everything relevant about X across twenty angles”) is the textbook case.

3. You need strong separation of concerns or specialized tooling.

A sub-agent that only ever talks to your data warehouse, with a tight prompt and tool set, beats one generalist juggling fifteen tools and a bloated system prompt. Here context isolation is about focus.

4. The value per task justifies the cost, measured honestly.

A multi-agent run can burn an order of magnitude more tokens than a single chat turn. But the naive comparison flatters multi-agent, because it pits a swarm against a cheap single agent. The honest comparison is at an equal compute budget: given the same number of thinking tokens, does coordinating several agents beat letting one agent reason longer? Compute-matched studies on reasoning tasks repeatedly find that single agents match or beat multi-agent setups once the budget is held constant. Intuitively, passing information through extra agents can’t create signal that wasn’t already extractable, but it can lose some. So the test isn’t “is this worth 10×?” It’s “would I get more from a second agent, or from giving the first agent that same budget to think harder?”

Figure 2: Orchestrator-worker. A lead agent plans, delegates to context-isolated sub-agents in parallel, then synthesizes and verifies. The pattern behind most deep-research systems.

A useful summary: multi-agent shines on high-value, parallelizable, read-heavy tasks that overflow a single context. That is a real and important category, but it is narrower than the hype implies. And it narrows further as base models get stronger: much of what once looked like a multi-agent advantage was a workaround for model limitations that newer models no longer have. The stronger your base model, the higher the bar for adding agents.

Where multiple agents are unnecessary, or actively harmful

Reach for a single agent (or a workflow, or a plain call) when:

• The task demands a single coherent artifact.

Code, a contract, a long document with one consistent voice. Coherence is the deliverable, and coherence is exactly what fragmentation destroys. Actions carry implicit decisions; when agents act in parallel without sharing full traces, you get a telephone game whose small miscommunications compound into failure at scale.

• The subtasks are tightly coupled.

If every piece needs to know what every other piece decided, you don’t have parallelizable work; you have one sequential problem wearing a multi-agent costume. A single-threaded agent with one continuous context is the more sophisticated choice, not the lazy one.

• The path is predictable.

If you can draw the flowchart, build the flowchart. A deterministic workflow is cheaper, faster, and more reliable than agents improvising a path you already knew.

• You can’t afford the cost, latency, or non-determinism.

Each added agent multiplies token spend, adds coordination latency, and widens the space of possible behaviors.

• You can’t observe and debug it.

Multi-agent behavior is non-deterministic, failures emerge from interactions rather than any single component, and a small early error cascades. Without tracing and evaluation, such a system fails in ways you can’t even diagnose.

The reliability reality

It’s tempting to treat multi-agent as obviously more powerful: more agents, more intelligence. The empirical record says otherwise. Systematic analyses of large numbers of multi-agent execution traces find failure rates that are often high, and the failures cluster into three families: specification and system-design issues, inter-agent misalignment, and missing task verification.

The finding to sit with: most failures are design problems, not model problems. They aren’t fixed by swapping in a smarter LLM. They come from poor task decomposition, agents acting on assumptions never established up front, brittle handoffs, and absent termination or verification logic. The failure mode of multi-agent systems is the coordination itself. Adding agents adds capability, but it also adds surface area for failures that single agents simply don’t have.

Topology decides how bad this gets. Independent parallel agents that don’t communicate amplify errors dramatically, because each duplicates the same mistakes with no one to catch them. A centralized orchestrator that inspects and verifies sub-agent output before synthesizing contains that amplification by a large factor. The lesson: if you go parallel, the orchestrator’s real job is verification, not just dispatch. A lead agent that fans work out but isn’t a quality gate is the worst of both worlds: full coordination cost, minimal error correction. And the verifier doesn’t have to be another model. For high-stakes or irreversible actions, the most reliable gate is a human in the loop: a checkpoint where a person approves the plan, or signs off on the output, before the system commits. Designing those checkpoints well, surfacing exactly the context a reviewer needs to judge quickly, is itself part of the same discipline.

Figure 3: The same parallel work, two topologies. Without a verification gate, errors compound; with one, the orchestrator catches them before they reach the output.

Underneath it all: context engineering

Strip away the framework wars and both camps say the same thing: agent failures are context failures. Either an agent is missing context it needed, or it holds context that conflicts with another agent’s. Everything else is downstream.

That reframes the decision. It isn’t “single or multi” in the abstract; it’s “can I keep every decision-maker in this system adequately informed?” A single-threaded agent solves this trivially: the context is continuous and shared by construction. A multi-agent system solves it only with deliberate effort: sharing full agent traces rather than just final messages, persisting plans to external memory, scoping responsibilities so agents don’t collide, and giving downstream agents visibility into what upstream agents actually did and decided.

Notably, the multi-agent pattern that survives contact with production is a disciplined one: a single root agent that delegates isolated sub-tasks to clones of itself in separate sandboxes, never sharing machines, never collaborating interactively. It works precisely because the sub-tasks are independent by design, so the context-fragmentation problem never gets a chance to bite. That is the shape to aim for: parallelism where the work is truly independent, single-threaded coherence everywhere else.

A decision path you can actually use

Walk down this before building :

• Does this need an agent at all?

If the path is knowable, build a workflow and stop here.

• Does the task fit in one context, and are the subtasks interdependent or coherence-critical?

If yes to either, use a single agent. A continuous context is a feature.

• Is the work read-heavy and genuinely parallelizable, and high-value enough to beat a single agent at equal budget?

If not, collapse back to a single agent.

• Can you trace, evaluate, and debug agent interactions?

If not, you aren’t ready to run a multi-agent system in production; build the observability first.

• Do any actions carry consequences you can’t undo?

If a misstep is expensive or irreversible, don’t let autonomy run unattended. Put a human in the loop at the decision points that matter, and give that reviewer the context to judge fast.

• Can you guarantee each agent has the context it needs and none that conflicts?

If you can’t answer concretely, the system will fail in the coordination layer, and no model upgrade will save it.

A blunt heuristic to tape to your monitor: parallel reading, single-threaded writing. Fan out to gather; keep one head for anything that has to be coherent.

Architectures at a glance

A handful of coordination patterns cover almost everything in practice. Most real systems use one of these directly or combine two or three.

Closing thought

The multi-agent excitement is, at bottom, a bet that more autonomous components add up to more intelligence. Sometimes they do, when the task is broad, parallel, context-hungry, and valuable. But intelligence in these systems doesn’t come from the number of agents. It comes from how well-informed each decision-maker is at the moment it acts. A single agent with excellent context beats a swarm with fractured context almost every time.

So the right default is humility about complexity. Start with the simplest thing that could work: a prompt, then a workflow, then one agent. Add agents only when you hit a wall that a second context window genuinely knocks down, and only when you’ve built the coordination and verification to keep them aligned, with a human in the loop wherever the stakes demand it. Whatever shape you land on, the work that decides whether it succeeds is the same underneath: engineering the context so every decision-maker, model or human, knows what it needs to at the moment it acts. Multiplicity is a tool, not a trophy. Use it where the task is shaped for it, and nowhere else.