There’s a moment in almost every agent project where someone draws a second box on the whiteboard. A router. A “planner agent.” A billing agent, a shipping agent, a compliance agent. It looks like good architecture because it looks like a microservices diagram — and we all spent a decade learning that small focused services beat a big ball of mud.
For agents, that intuition is often wrong. Not always, but often enough to slow down before drawing the second box.
Over 2026 Anthropic published a run of practical articles on this question, and together they tell a consistent story. The latest, Building agents: when to fold subagents into your main agent loop (October 2026), goes furthest: it describes enterprise teams getting better results by removing routers, planners, and domain subagents. This post is my synthesis: when multiple agents help, which coordination patterns fit which problems, why the pendulum is swinging back to one loop, where advisor/executor fits, and a decision framework. The trade-offs come from how context windows work, not from any one framework, so they apply whether you use the Claude Agent SDK, LangGraph, or a hand-rolled loop.
The real cost of a second agent
Start with the bill. Anthropic’s January 2026 article puts typical multi-agent overhead at 3–10x more tokens than a single agent for an equivalent task. The causes are mundane: duplicated context across windows, coordination messages that produce nothing for the user, and summarization at every handoff.
The last one hurts most, and not because of tokens. Every handoff is lossy: details that seemed irrelevant at hop one matter at hop three, and by then they’re gone. The same article describes an experiment with planner, implementer, tester, and reviewer agents where the subagents spent more tokens coordinating than working.
Latency is the other surprise. Parallelism speeds up individual subtasks, but total computation goes up, so the system is often slower overall. The October article cites one customer whose single-agent loop ran roughly twice as fast as the multi-agent harness it replaced — one data point, not a law, but the direction I’d expect.
The most underrated cost is organizational. When each team builds its own agent and a platform team bolts an orchestrator on top, you get what the October article lists: overlapping subagents with no owners, a system prompt stitched together from conflicting team rules, and evals each team optimizes locally while nobody owns end-to-end quality. The architecture mirrors the org chart. Conway’s law didn’t stop applying when the components became LLMs.
When multiple agents genuinely help
None of this means “never use subagents.” The January article names three situations where splitting consistently wins, and almost every legitimate multi-agent design reduces to one of them:
- Context protection. A subtask produces lots of output irrelevant to the main task (the article suggests roughly 1,000+ tokens as the point where isolation pays). A subagent digests it and returns a compact summary; the main window stays clean.
- Parallelization. Genuinely independent facets — unrelated research directions, separate review dimensions — run in separate windows at once. The source frames the benefit as thoroughness, not speed.
- Specialization. Too many tools to choose between reliably, conflicting tool domains, or personas that pull in opposite directions. As we’ll see, there are now cheaper ways to get most of this.
Plus one cross-cutting use: verification. An agent that gets the artifact and success criteria but not the build history is a genuinely independent check.
Decompose by context, not by job title
The most useful idea in the whole series: split along context boundaries, not problem types. Good boundaries are where little context needs to cross — independent research paths, clean interfaces, black-box verification. Bad boundaries are sequential phases of the same work, tightly coupled components, anything needing shared state. The article’s example: the agent that builds a feature should also write its tests, because it already holds the context. A separate “tester agent” is a tidy role split that costs fidelity. If you’ve done domain-driven design, it’s bounded contexts again — except what you’re bounding is literally a context window.
Five coordination patterns, and what each one costs
Once you’ve decided you really need more than one agent, the April 2026 coordination-patterns article lays out five shapes. Here’s my condensed read, with the failure mode I’d watch for in each.
| Pattern | Shape | Use it when | Watch out for |
|---|---|---|---|
| Generator–verifier | One agent produces, another checks against criteria, loop until accepted or capped | Quality matters and criteria can be stated explicitly | A verifier without concrete criteria rubber-stamps everything; loops that oscillate |
| Orchestrator–subagent | Lead agent plans, delegates bounded subtasks, synthesizes results | Clear decomposition, low interdependence | The lead becomes an information bottleneck; sequential subagents cost multi-agent tokens with no speedup |
| Agent teams | Persistent workers pull from a shared queue and accumulate context | Independent, long-running partitions (e.g. one service per worker in a migration) | Conflicting edits on shared resources; uneven completion times |
| Message bus | Agents publish/subscribe to events via a router | Event-driven workflows, a growing ecosystem of independently deployed agents | Silent failures from misrouted events; hard-to-trace cascades |
| Shared state | Agents read and write a common store, no central coordinator | Collaborative research where findings should flow between agents as they go | Duplicate work, reactive loops that never converge without explicit termination |
Three things stand out side by side.
Orchestrator–subagent is the default if you need multiple agents at all. The others are what you evolve toward when a specific pain appears: routing logic piling up in the orchestrator suggests a bus; workers that must remember across cycles suggest teams; agents needing each other’s intermediate findings suggest shared state.
Every loop needs a stopping rule written before it starts — a max iteration count plus a fallback for generator–verifier; a time budget or “no new findings for N cycles” for shared state. Locking solves concurrent writes; it doesn’t stop two agents politely asking each other follow-ups forever.
Verification is only as good as its criteria. The January article describes an early-victory failure: the verifier runs two tests, sees green, declares success. The fix is boring: require the full suite, negative tests, and edge cases explicitly.
The March workflow-patterns article (sequential, parallel, evaluator-optimizer pipelines with a path fixed in code) adds the advice that underpins everything here: try a single call first, and add structure only where it demonstrably falls short.
The pendulum swings back: one loop, progressive disclosure
Here’s where the October guidance gets interesting. Many enterprise deployments improved by folding routers, planners, and domain subagents into a single loop; a single agent with skills often beat both single-prompt and subagent designs on quality, frequently at lower cost and latency. Part of the reason is capability: newer models handle far more decision-making themselves, so logic can move from the harness into the model.
The target architecture:
- One model, one context window, one open-ended tool loop, with turn budgets, cost budgets, and write gates in the harness. Tool calls come in batches and run in parallel.
- Planning happens inside the loop. The model plans on turn one and revises as results arrive — planner and executor are the same model, so nothing is lost in a handoff.
- Domain procedure moves into skills; hard limits and live lookups move into tools. Deterministic code still handles cheap, always-needed work like entity resolution.
What makes this scale is progressive disclosure: the agent sees short descriptions of each skill and tool, and loads full content only when a task needs it. The article notes Anthropic cut Claude Code’s system prompt by over 80% for more advanced models, partly this way. The April harness-design article argues the same from the other side: every preloaded token competes for the model’s attention.
Tools get the same treatment. The January piece suggests tool selection gets harder around 15–20 tools; the October piece observes degradation beyond roughly 30–50 definitions. Both recommend tool search with deferred loading before adding agents, plus tools grouped by user intent rather than one per endpoint, with per-user permissions enforced inside each tool.
Notice what this does to the specialization argument. Most of what a specialist subagent offered — focused instructions, a curated tool set — progressive disclosure now delivers inside one window, without the lossy handoff. That’s the real shift.
How to fold without breaking things
The October migration path is careful in a way I appreciate:
- Build end-to-end evals first — ten golden examples is enough to start. Track routing accuracy now; after folding, track whether the agent loaded the right skill or tool.
- Merge tightly coupled specialists — ones that chain on each other’s output or are usually called together.
- Call remaining subagents as tools, so the main agent owns the conversation and you get a baseline.
- Fold in one at a time. Prompts become skills, API calls become tools. Look at which tasks changed, not just the aggregate score.
The article’s cautionary example: folding one subagent into a support agent lowered latency but broke a process — the main agent answered a delivery-date question itself instead of consulting the shipping specialist, and only in one of two runs. Run each task several times; as the evals post argues, agent behavior is a distribution.
Ownership changes too: teams stop owning agents and start owning skills and tools, while a small central team owns the system prompt and end-to-end quality. And subagents still earn their place when context bloat degrades the loop, parallel tasks need fresh windows, or tool selection and conflicting instructions defeat a single agent.
The advisor/executor pattern: intelligence on demand
There’s a third shape that doesn’t fit neatly into “one agent vs. many,” and it’s worth knowing. Anthropic’s April 2026 article on the advisor strategy describes pairing a smaller executor model that runs the whole task end-to-end with a larger advisor model that it consults only at hard decision points. The advisor reads the shared context and returns a plan, a correction, or a stop signal. It never calls tools and never talks to the user.
It inverts the orchestrator pattern: instead of a big model decomposing work for small workers, the small model drives and escalates upward. No decomposition, no worker pool, and frontier reasoning is paid for only when needed.
Anthropic’s reported numbers (internal evals, with caveats about differing thinking settings and prompts between runs): on SWE-bench Multilingual, Sonnet with an Opus advisor scored 2.7 points higher than Sonnet alone at 11.9% lower cost per task; on BrowseComp, Haiku with an Opus advisor reached 41.2% versus 19.7% solo. Their advice is the right one: eval three configurations — small solo, small plus advisor, large solo — and let the numbers decide.
Conceptually, I like that it keeps one context and one owner of the task — exactly what the fold-in guidance protects — while adding a second opinion where it matters. Tempted to build a planner agent? Try an advisor first. (More on the cost side in token economics.)
A decision framework
Here’s the table I’d tape next to the whiteboard before anyone draws the second box.
| Task shape | Recommended architecture |
|---|---|
| Single task, fits comfortably in one window | One agent, one call. No orchestration. |
| Broad domain, many procedures, many tools | One agent loop with skills + tool search (progressive disclosure) |
| Mostly routine work with occasional hard judgment calls | Smaller executor + larger advisor |
| A subtask produces large, mostly irrelevant output | Main loop + a context-protection subagent that returns a summary |
| Genuinely independent research or review facets | Orchestrator–subagent, explicitly parallelized |
| Output must meet explicit, checkable criteria | Generator–verifier with a max-iteration cap and fallback |
| Independent, long-running partitions (one per service) | Agent teams with partitioned resources |
| Event-driven pipeline with independently deployed agents | Message bus with correlation IDs and routing evals |
| Agents must build on each other’s findings in near real time | Shared state with an explicit termination condition |
Before adopting anything below the third row, ask three questions adapted from the January checklist: Is there a real constraint (context, parallelism, or specialization that skills and tool search can’t solve)? Does the split follow context, not job titles? Is there a clear verification point? If any answer is no, you have a single-agent problem. “It’s cleaner” is not a constraint.
Where I’d be careful
- These are vendor articles. Written by Anthropic, about Claude, with numbers from internal evals or individual customers. The patterns are portable; the figures are not a forecast for your workload.
- “Often” isn’t “always.” The October article says single loops frequently win. Yours might be the exception — only an end-to-end eval suite, run several times per configuration, will tell you.
- The thresholds will move. Tool-count limits and context thresholds shift as models improve; the harness-design article shows scaffolding that one model generation needed and the next didn’t. Re-test on every upgrade.
- Folding moves complexity, it doesn’t delete it. A single loop needs a disciplined system prompt, sharp skill and tool descriptions, and deliberate memory management. That’s context engineering, and it’s real work.
- One loop is one process that can crash. Checkpointing and idempotent tools matter more without an orchestrator to retry subtasks — see durable execution for agents.
How I’d approach an existing multi-agent system
If you have a router plus a dozen specialists today, don’t rewrite it:
- Build the end-to-end eval set first, owned by one person. Nothing else is safe without it.
- Instrument handoffs — log what each agent receives and returns. Lossy boundaries show up fast.
- Merge the pair that’s always called together. Lowest risk, clearest signal.
- Convert specialists to skills and tools (MCP is a sensible standard for the tool side), one at a time, re-running evals each step.
- Keep what earns its place — and document which of the three constraints justifies each surviving subagent.
The career angle
Wiring five agents together with a framework is easy now, which is partly the problem. The valuable skill is knowing when not to and proving it with evals. That means fluency in things that outlive any model: designing context boundaries, writing skills and tool descriptions a model selects reliably, building evals that catch process regressions, and reasoning about token and latency budgets. The engineer who can look at a twelve-box diagram and say “this is three boxes, and here’s the eval” will be in demand for a long time. Coming from enterprise backend work? See from C# to Claude agents.
Going deeper
Claude Agent SDK covers the agent loop, subagents, skills, and tool design hands-on. Building LLM-Powered Apps: RAG & Agents covers the patterns framework-agnostically. Claude API covers the building blocks — tool use, caching, cost control. MCP Servers is about turning domain APIs into intent-grouped tools. And Claude Code Mastery shows a production single-loop agent with progressive disclosure from the user’s side.
Sources: Anthropic, Building agents: When to fold subagents into your main agent loop (October 2026); Multi-agent coordination patterns: Five approaches and when to use them (April 2026); Building multi-agent systems: When and how to use them (January 2026); Common workflow patterns for AI agents and when to use them (March 2026); The advisor strategy (April 2026); Harnessing Claude’s intelligence (April 2026). This post is independent commentary; figures are as reported by the sources. Related in this series: context engineering, evals, token economics, durable execution, the AI-native SDLC.
