(2/3) Three Agentic Loop Architectures, and What Each One Actually Costs
Ask five vendors what their "multi-agent system" does, and four of them are describing a single loop with better branding.
That's not a knock on the marketing — it's a symptom of a real gap in how this stuff gets discussed. Part one of this series argued that a loop only qualifies as agentic once it has a trigger and a goal something outside the model can verify. That's the floor. It says nothing about how many models are doing the reasoning, whether they run in sequence or in parallel, or whether a supervisor is reading their work before it ships. Those are architecture decisions, and the common assumption — more agents, more advanced, strictly better — is wrong in a specific, measurable way: architecture is a cost curve, not a maturity ladder. Picking the wrong one either burns a multiple of your token budget for no capability gain, or leaves real capability on the table to save a few cents.
The single loop: one model, one thread, no coordination tax
The simplest architecture is exactly what part one described: one model, cycling through perceive-reason-plan-act-observe against a single goal, with nothing else running alongside it. This is what Yao et al.'s ReAct pattern formalizes, and it's the right default for anything narrow enough that one continuous thread of reasoning can hold the whole task in view — fixing a specific failing test, answering a question that requires a couple of lookups, working through a bounded migration file by file. There's no coordination overhead because there's nothing to coordinate. The failure mode isn't cost; it's scope. Past a certain task size, a single thread starts losing track of earlier decisions, re-deriving things it already figured out, or missing that two steps it took several turns apart now contradict each other.
Plan-and-execute: separate deciding what to do from doing it
The next architecture breaks the single loop's core assumption — that reasoning and acting have to interleave one step at a time — by front-loading the reasoning into an explicit plan, then executing the steps of that plan, in parallel where they don't depend on each other. Kim et al.'s LLMCompiler (ICML 2024) is the clearest published case for why this is worth the added complexity: by planning tool calls as a dependency graph up front and executing the independent branches concurrently instead of waiting on each one before deciding the next, they report latency improvements of up to 3.7x and cost reductions of up to 6.7x over a sequential ReAct-style baseline on their benchmark suite — with an accuracy gain on top, not a trade-off against it, because a step no longer has to guess what an earlier step will return before it can start. The mechanism is specific: parallelizable work doesn't need sequential reasoning between each piece of it, and a single interleaved loop pays a reasoning cost for serialization it didn't need.
The cost of this architecture is upfront planning quality. If the plan is wrong — a dependency the planner missed, a step that actually needed the output of another — you're now debugging a DAG instead of a linear trace, which is a harder failure mode to read than a single loop's, even though it's rarer to hit.
Multi-agent orchestration: specialization bought with a real token bill
The architecture furthest from the single loop hands different pieces of a task to different agents — typically a lead agent that plans and delegates, and subagents that each run their own perceive-reason-plan-act-observe cycle on a slice of the problem, in parallel, reporting back to the lead. Anthropic published exact numbers on the cost of this pattern in their June 2025 engineering post on the multi-agent research system behind Claude's research capability: "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats." That's not a rounding difference — it's an order of magnitude, and it comes from a legible mechanism: every subagent re-derives its own context and writes its own reasoning trace, and the lead agent then has to read and reconcile all of it, so the same ground gets covered multiple times instead of once.
The same post reports the other side of the trade: an orchestrator-worker system running Claude Opus 4 as the lead with Claude Sonnet 4 subagents outperformed a single-agent Opus 4 baseline by 90.2% on their internal research evaluation — and, in a detail worth sitting with, token usage alone explained 80% of the variance in how well a given run performed, more than model choice or which tools were available. Parallel exploration of a wide problem space is a genuine capability multi-agent orchestration buys that a single loop structurally can't, because a single thread can only pursue one line of reasoning at a time. It's priced at 15x, and the 80% figure is the tell: the capability gain is mostly bought with tokens, not with cleverness.
A fourth axis, orthogonal to all three: how hard a single pass tries before answering
Architecture answers "how many agents, arranged how." A separate question is how much a single agent second-guesses its own output before calling a step done, and that's what Shinn et al.'s Reflexion (NeurIPS 2023) formalized: instead of updating model weights, the agent writes a verbal self-reflection on why an attempt failed, stores it in an episodic memory buffer, and retries with that reflection in context. On HumanEval, this pushed pass@1 from an 80% GPT-4 zero-shot baseline to 91% — without touching the model itself. This layer is orthogonal to the three architectures above: you can bolt a self-reflection pass onto a single loop, onto each worker in a multi-agent system, or onto the executor stage of a plan-and-execute pipeline. It buys accuracy at the cost of more iterations per task, which is a different bill than the coordination tax of adding agents.
The 90.2% is real; so is the 15x — and only one task shape earns both
The pitch decks skip this concession: multi-agent orchestration's win is real, but it's conditional on the work actually being parallel. A supervisor coordinating three subagents that could only ever run in sequence anyway pays the full 15x token multiplier and the coordination overhead — the reconciliation, the context re-derivation — for zero benefit, because there was never a wide problem space to explore concurrently in the first place. The 90.2% figure came from a research task purpose-built for breadth: many independent lines of inquiry, explored in parallel, reconciled at the end. A narrow, sequential task — the kind a single loop handles fine — doesn't have that structure to exploit, so multi-agent orchestration on it multiplies cost without multiplying anything else.
How I'd choose, in order
- Can one continuous thread of reasoning hold the whole task? If yes, start with a single loop. It's the cheapest architecture and the easiest to debug, and most tasks that get "multi-agent" treatment didn't need it.
- Is the work a set of steps with a clear, largely independent dependency structure? If yes, plan-and-execute is the next reach — you get the parallelism without the full coordination tax, at the cost of getting the plan right upfront.
- Does the task require exploring a wide, disjoint problem space that no single thread could hold at once? Only then does the 15x multiplier buy something a cheaper architecture structurally can't. If you can't name the parallel exploration, you're not paying for capability — you're paying for the coordination tax alone.
- Separately: does correctness matter more than latency on this task? If yes, layer a self-critique pass like Reflexion's on top of whichever architecture you land on, and budget for the extra iterations it costs.
None of this survives contact with production without guardrails
A well-chosen architecture still runs out of control if nothing caps how far it goes, how much it spends, or what it's allowed to do without a human looking first — which is where part three of this series picks up.
If you're weighing which of these fits a system you're building, get in touch.
