Anthropic’s Multi-Agent Blueprint: What Production Constraints Add

Anthropic’s engineering team published one of the cleanest write-ups available on how a multi-agent system actually works in practice. The post is about Claude Research, an orchestrator-subagent pattern built for breadth-first research. The architecture is optimized for a particular task class, and the price of admission is a roughly fifteenfold token cost compared to a chat conversation. That cost is the tradeoff the system makes on purpose.

Most production systems make different tradeoffs. They run under cost ceilings, accuracy SLAs, speed budgets, and error rates that the research context does not impose. The blueprint’s patterns travel — orchestrator delegation, parallel subagents, condensed-return artifacts, end-state evaluation — but the architecture that emerges from applying them under production pressure is rarely the architecture in the post. The choices look the same up close and different at the system level.

The blueprint is for breadth-first research, and the cost multiplier travels with it

Anthropic’s system is built for a specific kind of work: research where the question is large, the directions are independent, and the answer is worth a lot of tokens. The lead agent plans an approach, spins up subagents to explore in parallel, and reconciles their findings against citations. On Anthropic’s internal evaluation, a multi-agent setup with Claude Opus 4 as lead and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%.

The number that matters more: multi-agent systems use about 15x more tokens than chat interactions. The cost multiplier is the price of admission to the architecture. If the task does not decompose into parallel directions, you pay it without earning it.

Anthropic is direct about the limit: “domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.” That is the boundary of where the architecture earns its keep. Tasks with tightly-coupled state, sequential dependencies, or shared mutable context will hit coordination overhead faster than they hit parallelism gains.

The first decision is whether the task is in the right shape for the pattern. If it is a research-style problem with independent directions, parallel subagents are doing real work. If it is a workflow with chained dependencies, a single agent or a deterministic pipeline with smaller agents inside it usually wins on cost and reliability.

Token budget, not prompt cleverness, is the dominant performance lever

Anthropic’s variance analysis is the more useful diagnostic. In their BrowseComp evaluation, token usage by itself explained 80% of performance variance. Tool-call count and model choice were the other two factors. Prompt phrasing, instruction style, and the things teams typically iterate on did not show up as primary drivers.

The implication is practical. When a single-agent system plateaus on a complex task, the first question is whether it is context-bound, not whether the prompt needs more polish. A polished prompt cannot exceed the model’s working context. A multi-agent system, with separate context windows for each subagent, can. That is the mechanism, more than better instruction-following or any cleverness in the orchestrator.

Multi-agent’s main contribution to performance is parallel reasoning across more aggregate context than a single agent can hold. If the task fits inside one agent’s effective working window, the multiplier is rarely worth it. If the task genuinely needs more context than one agent can hold and the directions are independent, parallelism earns the cost.

Orchestrator delegation is a four-part contract that prevents agentic drift

The orchestrator-subagent split looks simple from a diagram and gets complicated in practice. Anthropic’s contract for each subagent: an objective, an output format, guidance on which tools and sources to use, and clear task boundaries. Miss any of the four and the subagent drifts — not because the model is poorly behaved, but because the orchestrator did not specify enough for it to know what done looks like.

Effort-scaling is part of that contract. Anthropic’s prompts embed concrete rules: 1 agent for simple fact-finding, 2 to 4 subagents for direct comparisons, and more than 10 subagents for complex research. Without rules like these, the lead agent over-scales — spinning up subagents for problems a single call could answer — and the cost multiplier compounds against you.

Tool ergonomics is the other load-bearing piece. The contract is only as good as the tool surface it points to. Anthropic ran a tool-testing agent that exercised flawed MCP tool descriptions, identified the failure patterns, and rewrote the descriptions; future agents using the rewritten tools cut task completion time by 40%. The orchestrator’s instructions assume the tools they describe behave the way the descriptions claim. When tool descriptions are vague or misleading, every downstream agent pays the tax.

Order of operations: get the four-part contract right, embed effort-scaling rules in the orchestrator prompt, then audit your tool descriptions before iterating on anything else. The contract and the tools are upstream of every other lever.

Context handling is external-memory-first, not bigger-context-first

The instinct on context limits is usually to ask for a larger window. Anthropic’s architecture does the opposite. The lead researcher saves its plan to memory before context fills, because past 200,000 tokens the context window can be truncated and the plan needs to survive. The architectural choice is to externalize early, not to chase larger windows.

The artifact pattern earns its place here. Instead of subagents reporting findings back through chat-style returns — long, lossy, expensive on lead-agent tokens — they write to a shared filesystem and return a lightweight reference. The lead agent does not re-read every detail; it gets a pointer and pulls what it needs. The pattern is not unique to Anthropic, but their post implies it through the memory system; practitioners across the industry have been naming it the artifact pattern because it solves a specific failure mode: the game of telephone, where information loses fidelity each time it passes from subagent to lead.

Fresh-context resets between sub-tasks are a deliberate design choice. If state lives outside the agents, the agents do not need to carry it in their context windows. “Bigger context” also stops being the answer to most context problems; the right move when an agent struggles with a long task is usually to externalize state and reset.

Evaluation grades outcomes, not the path the agent took

Evaluation is where multi-agent systems get the strangest. The path the agent takes through a complex task is rarely the path you would have prescribed in advance. Anthropic’s guidance: “judge whether agents achieved the right outcomes while also following a reasonable process.” Outcomes are graded; paths are observed but not required to match a template.

The mechanism most teams reach for is LLM-as-judge with a structured rubric — factual accuracy, citation accuracy, tool efficiency — producing a 0.0 to 1.0 score per output. The score does not substitute for human review; it scales review across thousands of runs without reading every trace by hand.

For state-mutating agents, end-state evaluation is the cleaner framing. Ignore the path entirely. Compare the final environment state to the goal state. Did the document get written, the ticket get closed, the file get moved? If yes, the agent succeeded — even if the trace looks meandering. Letting the agent iterate over its own process tends to produce better runs than prescribing the process up front, because the right path is often not knowable in advance.

Scoring is necessary but not sufficient. Production agents need traces, audit trails, and the ability to investigate a failure that scored well on the rubric but cost too much or used the wrong tool. The governance layer for production agents sits underneath evaluation, supplying the visibility scoring alone cannot provide.

Production constraints reshape the decisions the blueprint leaves to defaults

The blueprint and production part company here. Anthropic’s research context has no fixed daily cost ceiling, no hard accuracy SLA, no sub-second response budget, no error-rate threshold tied to revenue. Most production systems have at least one, often all four. The architecture decisions a team makes under those pressures are not the decisions the blueprint defaults to.

A few of the gaps the blueprint leaves to the reader:

• Long-running state across sessions. The Claude Research system is session-bounded. A research run starts and finishes. Production agents often need to operate across days or weeks: a content pipeline that watches for new briefs, an operations agent that monitors a system continuously, an integration agent that processes events as they arrive. State across sessions is a different problem than state within one.
• Failure cascades when a subagent fails mid-orchestration. The blueprint describes the happy path. Production has to handle a subagent that times out, returns malformed output, hits a rate limit, or fails its tool call. The lead agent needs to know whether to retry, fail over, partial-result, or abort the whole run, and that logic is not in the blueprint.
• Multi-model pinning. Anthropic uses one model family throughout. Production teams often need a specific model version pinned for a specific job — partly for accuracy stability across runs, partly for cost control, partly because behavior changes between model versions can break workflows that depended on the old behavior.
• Runaway-spend protection. The 15x cost multiplier compounds quickly when something misbehaves. A subagent that recursively spawns or a tool that returns oversized results can burn through a daily budget in minutes. The blueprint does not address circuit breakers, budget caps, or per-run cost ceilings.
• Stateful resumption. When a long-running agent fails, restarting from scratch is wasteful. Checkpointing so the agent can resume from its last decision point, not its first, changes the cost economics of long jobs significantly. The blueprint mentions resumption in passing but does not treat it as a first-class architectural concern.

One example of how production pressures push toward different choices: in a content pipeline that runs autonomous agents end-to-end, fixed downstream crons were replaced with completion-triggered orchestration so that downstream stages fire the moment the previous stage finishes, instead of waiting for a scheduled tick. That is not a choice the blueprint suggests, because the blueprint is not session-spanning; production constraints make it obvious. Different pressures, different decisions.

The general pattern across these gaps: the blueprint optimizes for a single bounded run with a research outcome as the deliverable, while production systems usually optimize for repeated runs with reliability, predictable cost, and operational containment as the deliverables. Those are not opposing goals, but they push the architecture toward different shapes. A research system can afford to retry an entire run when something goes wrong; a production system that does that on every failure burns its budget and its SLA. A research system can afford to use the strongest available model throughout; a production system often pins a smaller model for the subagent tier because the cost difference compounds across thousands of calls per week.

Read the blueprint as a high-quality reference architecture for the task class it targets. Treat the patterns as primitives (orchestrator delegation, parallel subagents, condensed-return artifacts, end-state evaluation) and let the production constraints you are actually operating under decide how those primitives compose. The architecture lives in the composition, with each pattern earning its place in context.

When not to go multi-agent, and the question that comes first

Before “should I use a multi-agent architecture?” comes a different question: what job am I trying to remove from human supervision?

Multi-agent systems earn their keep when they reduce work; they fail when they multiply things to manage. A team running a single agent that already does its job well does not need a multi-agent architecture; it needs a clearer success metric and maybe a better tool surface. A team that has identified a research-shaped problem with independent directions and budget headroom for the cost multiplier is in the right place for the pattern.

A few heuristics for when single-agent or deterministic-workflow architectures are usually the right call:

• Tightly-coupled context. If every agent needs the same shared state and changes propagate across the system, the coordination cost will exceed the parallelism gain.
• Sequential dependencies. If step B requires step A’s output and step C requires step B’s output, you have a pipeline, not a parallel workload. A pipeline of small agents is usually simpler and cheaper than an orchestrator-subagent decomposition for the same work.
• Deterministic workflow surface. If the steps are knowable in advance and the failure modes are predictable, a deterministic workflow with self-improvement scoped to skill optimization will be more reliable than a general-purpose agent picking between dozens of tools.
• Insufficient budget for the cost multiplier. If the daily or per-run budget cannot absorb the token overhead, the architecture is the wrong tool for the budget.

For mid-market teams, complexity is its own failure mode. Every additional agent is another component to manage, debug, monitor, and pay for. Lower-order simple agents nested inside larger loops often produce better outcomes than a general-purpose multi-agent system trying to do everything. The mistake to avoid is adding agents because the architecture diagram looks impressive; the goal is to remove jobs from human supervision, never to create more agents for a human to supervise.

Sharper than “single or multi”: if I did not need to supervise this work, and the agent did it as well as or better than a person doing it today, what would that unlock? When the answer is concrete — a person freed up for higher-value work, a process that runs overnight, a backlog that clears without intervention — the architecture that earns its keep is the one that delivers that outcome with the fewest moving parts. The shape of the answer often points at where you are on the autonomy spectrum and what the next step is.

Anthropic’s blueprint documents one such point well. For any team adopting it, the work is to know which pressure the system is being built under, and to let that pressure shape the architecture that emerges. Same patterns, different production constraints, different decisions.

Frequently asked questions

What is Anthropic’s multi-agent research system?

Anthropic’s multi-agent research system, used in their Claude Research product, is an orchestrator-subagent architecture for breadth-first research. A lead agent plans the research approach and saves its plan to memory; it then spins up parallel subagents to explore independent directions, each with its own context window and tool access. Subagents return condensed findings, often via a shared memory store rather than long chat-style returns, and the lead agent reconciles them into a final answer with citations. On Anthropic’s internal evaluation, this setup outperformed a single Claude Opus 4 agent by 90.2% on their research eval.

What is the orchestrator-subagent (orchestrator-worker) pattern?

The orchestrator-subagent pattern, sometimes called orchestrator-worker, is a multi-agent design where one agent decomposes a task and delegates pieces of it to other agents. The orchestrator does not do the work itself; it plans, dispatches, and integrates results. Each subagent receives an objective, an output format, guidance on which tools and sources to use, and clear task boundaries. The pattern fits tasks that decompose naturally into independent directions and where parallel exploration is faster than sequential execution. It does not fit tasks with tightly-coupled context or heavy dependencies between subagents.

When should I use a multi-agent architecture vs. a single agent?

Use multi-agent when the task is breadth-first, the directions are independent, the aggregate context exceeds what a single agent can hold, and the budget can absorb the cost multiplier. Use single-agent when the task fits inside one context window, when steps are sequential, when the workflow is deterministic enough to specify, or when the budget is tight. The blueprint itself flags shared-context and high-dependency domains as poor fits for multi-agent. Most production tasks land closer to single-agent or deterministic-pipeline shapes than to research-style multi-agent shapes.

How does Anthropic’s multi-agent system handle context limits?

Anthropic’s system handles context limits by externalizing state to memory rather than chasing larger context windows. The lead researcher saves its plan to memory before context fills, because the context window can be truncated past a certain length. Subagents write findings to a shared filesystem and return lightweight references — the artifact pattern — so the lead agent does not re-read every detail through chat-style returns. Fresh-context resets between sub-tasks are part of the same strategy: state lives outside the agents, so agents can reset without losing it.

How much more expensive is a multi-agent system than a single agent?

Anthropic reports that multi-agent systems use roughly 15x more tokens than a chat conversation on the same surface task. The multiplier is the cost of running parallel subagents with their own context windows and tool calls. If the task is breadth-first and decomposes into independent directions, the multiplier buys parallelism that exceeds a single context window. If the task does not decompose, you pay the multiplier without earning it. Production teams often add cost circuit breakers and per-run budget caps because the multiplier compounds quickly when something misbehaves.

What does Anthropic’s blueprint not cover about production agent systems?

The blueprint focuses on session-bounded research and leaves several production concerns to the reader: long-running state across days or weeks, failure cascades when a subagent fails mid-orchestration, multi-model pinning for accuracy stability and cost control, runaway-spend protection through circuit breakers and budget caps, and stateful resumption from a checkpoint instead of a full restart. These are not flaws in the blueprint; they are concerns that emerge when the same patterns are applied under production constraints — cost ceilings, accuracy SLAs, speed budgets, error rates — that the research context does not impose.

Building autonomous agent systems under production constraints is the work we do every day. If you’re evaluating multi-agent architecture for a real job and want a practitioner’s view on where the patterns earn their keep, our managed autonomous AI agents service is the closest place to start.