Multi-agent architectures established practitioner

Orchestrator and workers

A lead agent breaks a task into bounded sub-tasks, hands each to a worker with its own context, and synthesises what comes back.

Established: described the same way by several independent primary sources and in wide production use. Named and recommended by Anthropic (orchestrator-workers workflow; the multi-agent research system), by OpenAI (the manager pattern), and implemented as subagents in Claude Code and as Send fan-out in LangGraph. Contested only at the edges: Cognition argues most tasks are better served by one agent with compressed context.

Input Should we move our job queue from Redis to Postgres? Cover the public trade-offs, what our own docs say, and how our code uses the queue. Three workers in parallel, each with its own context, joined by the orchestrator. Five model calls, three of them concurrent.

ready

Every step in words

The question has three natural parts that need three different tools. That shape is the signal for this pattern.
The orchestrator decides the split dynamically: one worker per information source, each with a brief, an output schema and a 15k-token budget. The number three was not fixed in advance; a narrower question would get one worker.
The plan is visible before any worker spends budget. The researcher adds one constraint: prefer sources from the last two years. Cheap to change now, expensive after the workers run.
Each worker receives only its brief and the shared constraint. It does not see the other briefs or the researcher’s full history. Separate contexts are what let the work run in parallel and keep each window small.
Retrieval over internal documents returns the three most relevant items with dates. The worker reads them and drafts findings in the required schema.
A deterministic grep, then reading the handful of files that matter. The worker reports counts and paths, not opinions.
The web worker searches, reads, and extracts claims with URLs and publication dates. Everything it read is untrusted; it returns findings as structured data, never as instructions to the orchestrator.
The merge point holds three structured results, each tagged with its worker, sources and confidence. The orchestrator can now compare them without re-reading any source.
ADR-14 chose Redis for latency; the web worker found that latency is a non-issue at our volume; the code worker found one module that bypasses the client. The orchestrator writes the answer with each claim attributed and the bypass flagged as migration work.
Five model calls, three of them in parallel, about 30k tokens across four context windows. One agent doing all three parts in sequence would have needed one window holding everything.

The interactive simulation needs JavaScript. The diagram above is the same picture; every step of the baseline run is written out under "How it works".

The problem it solves

A task is too wide for one context window: researching five sources, reviewing a large change, answering a question that spans several systems. One agent doing it all in sequence loses the thread or runs out of room.

What the human needs: A researcher wants a thorough answer in minutes, wants to see which sources each part came from, and does not want five windows of chat to read.
What the agent does: The orchestrator reads the request, writes a plan of sub-tasks with explicit boundaries, starts a worker per sub-task with only the context that sub-task needs, waits, and synthesises the workers’ structured results into one answer.
What the human sees: The researcher sees the plan before the workers start, a progress roster of workers, and a final answer with each claim attributed to the worker and source that produced it.

After this page you can

Explain why a worker gets its own context window and what that costs.
Tell dynamic decomposition (the orchestrator decides the sub-tasks) from a fixed fan-out.
Predict what goes wrong when workers do not share what they decided.
Place the trust boundary between a worker that reads the web and the orchestrator that acts.

How it works

The request enters. The orchestrator decides how to split it; the number of workers is not fixed in advance.
The orchestrator writes a sub-task brief for each worker: objective, allowed sources, output format, and a token budget.
Workers run in parallel, each in its own context window with its own tools. A worker never sees another worker’s context.
Each worker returns a structured result: findings, sources, confidence, open questions.
The results join at a merge point. The orchestrator reads them side by side, resolves conflicts, and writes the answer.
If a worker fails or returns thin results, the orchestrator may re-brief it, start another, or note the gap in the answer.

The baseline scenario in the stage above plays these steps with a worked example. Open "Every step in words" under the stage for the full trace, including why each step happened.

When to use it

The task splits into parts that do not depend on each other’s decisions.
The parts need different tools or different trust levels.
One context window cannot hold all the material.

When not to

The parts share decisions (naming, structure, style): one agent in sequence with compaction keeps them consistent.
The task is narrow: the orchestrator is pure overhead.
Cost per task matters more than wall-clock time.

Trade-offs

Reliability	middling	Each worker is simpler and more focused; reconciliation at the merge is a new place to be wrong.
Latency	strong	Parallel workers cut wall-clock time for wide tasks.
Cost	weak	Several context windows and a planning call; Anthropic reports multi-agent runs use many times the tokens of a chat.
Complexity	middling	Briefs, schemas, budgets and a merge step to design and test.
Observability	middling	Good per worker; the overall story needs the plan and the roster to read.
Maintainability	middling	Adding a worker type is contained; changing the result schema touches everything.
Security	middling	Strong when workers are capability-sandboxed and results validated; a worker with a send tool undoes it.
Human control	middling	The plan is a natural review point; inside the workers the human sees only the roster.

Three bars mean strong (or cheap); one bar means weak (or costly). Ratings are editorial and relative to the other patterns in this library, not measurements.

Security posture

Turn on Trust boundaries in the stage to see the zones on the diagram. The controls below sit on the nodes named; the "Break" scenarios show an attack and the control working.

Control	Threat	Where
Workers are sandboxed by capabilityEach worker type has a fixed tool set; the web worker can read but not write, send or reach internal systems.	A worker with broad tools becomes an exfiltration path.	w1 · w2 · w3[simonwillison.net]
Structured results with provenanceResults are validated against a schema; findings without a source are dropped and flagged.	Free-text results carry planted instructions into the orchestrator.	merge[Anthropic]
No external communication in the orchestratorThe orchestrator’s only outputs are the plan and the answer, delivered to the researcher.	The orchestrator is talked into sending data out.	lead · answer[simonwillison.net]
Per-worker budgetsToken and time limits per worker and in total, enforced outside the models.	One worker consumes the run.	budget[Anthropic]

Failure scenarios

Failure	Trigger and effect	Recovery
Injected workerscenario: worker-injected	A worker reads content that instructs it. The worker’s result carries an instruction.	Schema and provenance validation at the merge; no external-communication tool anywhere in the system.
Thin or failed workerscenario: worker-thin	A worker exhausts its budget or errors. A gap in the answer.	The orchestrator re-briefs narrowly or notes the gap explicitly.
Divergent decisions	Two workers make incompatible implicit choices (naming, scope, format). The synthesis has to reconcile or discard work.	Briefs carry the shared decisions; the output schema forces comparable results; prefer sequential work when parts depend on each other.
Over-decompositionscenario: simple-question	The orchestrator splits a simple task. Cost and reconciliation effort with no gain.	Let the orchestrator choose zero or one worker; measure.

Architecture and implementation

Inputs

request string: The question or task.
workerTypes WorkerSpec[]: The kinds of worker available, each with its tools and trust level.
budgets { perWorker, total }: Token and time limits.
resultSchema JSON schema: What every worker must return; validated at the merge point.

Outputs

answer string: The synthesis, with attribution.
results WorkerResult[]: Every worker’s raw structured result, for audit and evals.
plan Brief[]: The decomposition that was run.

State schema

plan Brief[]: The sub-tasks the orchestrator wrote: objective, sources, schema, budget.
workers { id, status: 'running' | 'done' | 'failed', tokens }[]: The roster the researcher watches.
results WorkerResult[]: Structured findings with worker id, sources, confidence and open questions.
budgetUsed number: Tokens across all contexts, against the run total.
status 'planning' | 'plan approved' | 'workers running' | 'synthesising' | 'done': Where the run is.

Framework-neutral pseudocode

plan = orchestrator.plan(request)             # dynamic: 0..n briefs
show_plan_to_researcher(plan)                   # optional redirect
results = parallel(
    for brief in plan: run_worker(brief, tools_for(brief.kind), budget.perWorker)
)
for r in results:
    r = validate(r, resultSchema)               # drop unsourced findings, flag
    if r.failed or r.thin:
        r = run_worker(orchestrator.rebrief(brief, r.report), ...)
answer = orchestrator.synthesise(request, results)   # attribution required
return answer, results, plan

In the frameworks

Anthropic research system A lead agent plans and spawns parallel subagents with separate context windows; results are structured; token use explains most of the quality variance. [Anthropic]
Claude Code subagents A subagent runs with its own context and tool set and returns a summary to the main session. [Anthropic]
LangGraph Send() fans out one node to many dynamically; a reducer on the state merges results; the Graph API documents the map-reduce shape. [LangChain]
OpenAI Agents SDK The manager pattern: a central agent calls specialised agents as tools and keeps the conversation. [OpenAI]

Testing

Unit-test the plan step: for fixed requests, assert the number and kind of workers.
Validate every worker result against the schema; assert unsourced findings are dropped.
Replay recorded worker results into the synthesis step and diff the answer.

Evaluation

Grade the final answer with a rubric that includes attribution; grade workers separately on source quality.
Track tokens per answer and wall-clock; compare against the sequential single-agent baseline for the same tasks.

Deployment

Separate worker identities and credentials per worker type; the web worker has no internal access.
Run workers as durable tasks so a crash loses one worker, not the run.
Log the plan, every brief and every result; the roster is the researcher’s progress view.

Where it helps in software delivery

1 Discover and define central to this stage
Research across several sources is the canonical use: Anthropic’s own research system is this pattern.

Example A discovery brief that pulls from interviews, support tickets and competitor docs, each by a worker, with attribution.
3 Architecture and system design strong fit
Option analysis benefits from independent workers investigating each option without anchoring on the others.

Example Three workers evaluate three storage options against the same rubric; the orchestrator compares.
4 Development and implementation strong fit
Large changes split by module; coding assistants use subagents for verification so the main context stays clean.

Example A migration across six modules, one worker per module, each returning a diff and test results.
5 Testing and validation strong fit
Test generation per module or per requirement parallelises cleanly and the results are naturally structured.

Example One worker per acceptance criterion writes and runs tests; the orchestrator reports coverage.
8 Operations and monitoring useful here
Incident investigation across logs, metrics and deploy history can fan out, though a single read-only loop is often enough.

Example Workers check logs, recent deploys and alerts in parallel during the first five minutes of an incident.

Open the SDLC explorer to start from a stage instead.

What the human sees

The interaction patterns a person meets when this architecture runs. The run waits for a person at: Researcher.

References and provenance

The orchestrator-workers workflow: a central model dynamically breaks down tasks, delegates to workers and synthesises; suited to tasks where the subtasks cannot be predicted.

evidence Building effective agents, Anthropic, Erik Schluntz and Barry Zhang, published 2024-12-19. Verified 2026-10-18.
Separate context windows per subagent enable parallelism and compress findings; token usage is the strongest predictor of quality; structured results and careful briefs matter.

evidence How we built our multi-agent research system, Anthropic, published 2025-06-13. Verified 2026-10-18.
Parallel subagents without shared context make conflicting implicit decisions; a single-threaded agent with compression is often better.

practitioner Don’t build multi-agents, Cognition, Walden Yan, published 2025-06-12. Verified 2026-10-18.
The manager pattern keeps one agent in charge and calls others as tools.

convention A practical guide to building agents (PDF), OpenAI, undated. Verified 2026-10-18.
Send enables dynamic map-reduce fan-out with a reducer merging results.

framework LangGraph graph API, LangChain, undated. Verified 2026-10-18.
Removing external communication from agents that read untrusted content blocks exfiltration.

practitioner The lethal trifecta for AI agents: private data, untrusted content, and external communication, simonwillison.net, Simon Willison, published 2025-06-16. Verified 2026-10-18.

Published 2026-10-18 · observed 2026-10-18 · last verified 2026-10-18 · updated 2026-10-18 · v1 · review status: draft

Evidence kinds: evidence: evidence-backed recommendation from a primary source; convention: established industry convention; several sources agree; framework: how one framework implements it. version-specific; practitioner: a practitioner’s observation, not independently verified; emerging: an emerging technique with thin evidence; editorial: our interpretation.

Share: https://agentsandhumans.ai/agentic/patterns/orchestrator-worker · the stage's Share button links to a scenario and step; Export downloads the trace as JSON, labelled as a learning simulation.