Multi-Agent Systems · Agentic Engineering

Multi-agent systems split work across several model loops, each with its own context window. The legitimate reasons to split are exactly three: context isolation (a subagent does verbose work in a fresh window and returns only the distillate), parallelism (independent subtasks run at once), and specialization (different instructions or models per role). The standard topology is orchestrator–worker; the failure surface is the handoff, because a subagent starts cold and knows only what its brief says. Write briefs like contracts for a contractor: goal, constraints, what is already known, and the exact shape of what to return. And default to one agent — go multi only when a single agent measurably hits the context wall, because coordination multiplies cost, failure modes, and debugging surface.

Prerequisites: Context Engineering, Evals — you’ll need the eval to prove the split helped. Feeds problems: Coordination across agents, The context bottleneck.

Practitioner

Multi-agent is the most seductive architecture in the field — a team of specialists, like a little company! — and most teams that reach for it are solving a problem they don’t have. Start from the null hypothesis: one agent, better context engineering. Then check whether you have one of the three real reasons to split:

Context isolation. The strongest reason. Some work is intrinsically verbose — searching twenty files, reading long documents, trawling logs. Done in the main agent, that verbosity pollutes the window for everything after it. A subagent does the messy exploration in its own fresh window and returns two paragraphs; the parent pays two paragraphs. The subagent is a context firewall — this reason alone justifies most production multi-agent systems.
Parallelism. Genuinely independent subtasks — research five competitors, process thirty documents — run concurrently in separate windows, turning serial hours into parallel minutes. The load-bearing word is independent: if the subtasks need to share discoveries mid-flight, the coordination erases the win.
Specialization. Different roles want different system prompts, tools, or models — a cheap fast model for extraction workers, a strong model for the orchestrator, a review agent whose instructions are pure skepticism. Real, but the weakest of the three on its own; often a single agent with better tools does as well.

If none of the three applies, stop. The costs are not subtle: total tokens go up (every subagent re-reads its own briefing and context), failure modes multiply (per-agent errors compound across the team), and debugging goes from reading one trajectory to reconstructing a conversation between several.

The topology that works: orchestrator–worker. One agent owns the task, decomposes it, delegates scoped pieces, and integrates the results. Workers don’t talk to each other — results flow through the orchestrator. It’s not fashionable — no society of equals negotiating — but it keeps one place where the whole task is understood, which is exactly what free-form agent societies lose. Peer-to-peer designs demo well and debug terribly.

The handoff is the product. A subagent starts with nothing: no memory of the planning, no sense of what the user actually wants, no knowledge of what’s been tried. It knows its brief. So write briefs the way you’d write a contract for a competent contractor you’ll never meet: the goal and why (purpose lets it handle surprises sensibly), hard constraints, what’s already known or ruled out (or it will re-derive it at your expense), and the exact shape of the deliverable — “return: files changed, one-line rationale each, anything you couldn’t resolve.” Vague briefs are the leading cause of multi-agent failure, and the failure is quiet: the subagent succeeds diligently at the wrong task. If you did the Agent Loop Apply-it, you’ve already felt this — the model could only act on what the transcript showed it. A subagent’s brief is that lesson with the stakes raised.

Return distillates, not transcripts. The subagent’s raw trajectory would re-pollute the window the split was protecting. Findings, decisions, unresolved questions — in the requested format, a page at most. If the parent might need detail later, have the subagent write the full version to a file and return the path: the parent buys detail only when needed.

Prove it with the eval. Run your eval suite on both architectures. Multi-agent should win clearly on quality or wall-clock time to justify its token overhead and debugging tax. “It feels more sophisticated” loses to a 40% cost increase every time someone looks at the bill.

Expert pointers

Published practitioner reports are unusually candid here — orchestrator-worker systems showing large quality gains on parallelizable research at a large token premium, alongside prominent “don’t build multi-agent” arguments claiming context isolation is better solved inside one agent. Read both sides; the disagreement is the state of the art. Open threads: agent-to-agent protocol standardization, whether specialization survives each frontier-model improvement (the six-months-from-now model, applied to org charts), and evaluation of multi-agent traces, which is still mostly artisanal.

Misconceptions

“More agents, more intelligence.” More agents means more context windows, not more understanding. Intelligence gains come only through isolation, parallelism, or specialization — if none applies, you’ve bought overhead.
“The agents share what they learn.” Each has its own window and knows only what’s explicitly passed. Multi-agent memory is plumbing you build, not a property you get.
“Subagents make tasks reliable through redundancy.” Independent errors compound across a team just as steps compound in a loop. Reliability comes from verification at the seams, not from headcount.

Check yourself

An agent researching “acquisition target risks” fills its window with SEC-filing excerpts and quality collapses. Redesign with one subagent — what exactly goes in the brief, and what comes back?
Which of the three reasons to split justifies parallel per-document extraction across 500 contracts? What extra machinery does the merge step need that the split didn’t?
Your multi-agent system underperforms the single agent on the eval. List three seams to inspect, in the order you’d check them.
Why does orchestrator–worker beat peer-to-peer for debuggability, specifically?

Apply it

Add one subagent to your Agent Loop agent: when the task needs broad code exploration, spawn a fresh loop with a search brief (“find every place X is handled; return file:line plus one sentence each; flag anything ambiguous”) and feed only its distillate to the parent. Run a task both ways and compare: parent’s final context size, total tokens across all agents, and answer quality. You’ll meet the tradeoff this whole topic is about, in numbers.