Multi-agent systems

A multi-agent system splits work across several model-directed loops, usually an orchestrator that plans and sub-agents that execute slices of the task with their own tools and context. The bet is that isolation and parallelism beat one giant transcript: each worker stays focused, contexts stay smaller, and independent research can run at the same time.

The bet is often wrong. Coordination has a tax: duplicated work, conflicting edits, lost information at merge time, and token bills that are many times a single-agent run. Use multiple agents when the problem structure demands it, not because the diagram looks impressive.

Many systems that look like "five agents talking" are better as one orchestrator calling parallel functions (retrieve, summarize, score) without giving each function its own open-ended tool loop. Promote a function to a sub-agent only when it needs multi-step tool use and a private context that would otherwise pollute the parent.

Concepts in this section

Read them in order. Each one builds on the one before.

Step	Concept	What it answers
1	Orchestrator and workers	Who plans, who executes, and what does a task spec look like?
2	Context isolation	What does each agent see, and what must a handoff keep?
3	Coordination and cost	What does fan-out cost, and how do workers collide?
4	Evaluating multi-agent systems	How do you tell a bad plan from a bad merge?

When it helps, and a safe rollout

It helps for parallelizable research, noisy context that should not sit in the planner's window, specialized tool sets, and hard wall-clock limits where you can afford parallel spend.

It hurts when steps are tightly coupled, when several agents edit the same artifact without ownership, when the task fits in one context, or when you cannot yet evaluate a single agent reliably.

Trade-off

Default to one agent or a workflow. Split only when you can name the isolation or parallelism benefit in one sentence. Token cost shows up immediately.

A rollout that usually works:

One agent, with better tools and context compaction.
An orchestrator that calls functions in parallel, not full agents.
Promote heavy functions to sub-agents when their transcripts get large.
Add budgets, dedupe caches and merge evals before you increase fan-out.

Prefer process-level concurrency (async tasks) over distributed drama until you need durable execution. If wall-clock is the only pain, a faster model or parallel retrieval inside one loop sometimes beats four full agents.

Common mistakes

Starting with five agents. Ship one reliable agent first.
Free-form chat between workers. You cannot debug causality.
Ignoring the token multiplier. Four workers can cost several times a single run for a smaller wall-clock win.
Evaluating only fluency. A pretty merge can drop a caveat.

Key takeaways

Multi-agent pays for isolation and parallelism, not for architectural fashion.
Orchestrator writes sharp task specs. Workers run in clean contexts. Merges take condensed structured results.
Expect large token multipliers. Budget workers and model tiers on purpose.
Watch duplication, conflicting edits and lossy handoffs.
Evaluate the final artifact and the boundary summaries, with full traces.