Multi-Agent Orchestration

## The claim, stated precisely When an orchestrator delegates to several subagents, the improvement you measure does not come from having "more minds on the problem." The workers are usually instances of the same model, with the same weights and the same reasoning ability. Nothing about spawning a second copy makes either copy smarter. What multi-agent buys is a *context* property: work that would have piled up in one window is partitioned across several, and only condensed results cross the boundaries. This distinction is the single most testable thing about the topic, and it is where weak answers collapse. "Five agents means five perspectives" sounds right and is mostly wrong — five identical models given the same brief produce five correlated outputs, not five independent perspectives. ## Why context size degrades quality Attention is finite and roughly competitive: every token in the window competes for the model's attention against every other. Three consequences follow, and they have standard names in the field. **Context rot** — as a window fills, accuracy on the material it contains declines, even well below the nominal limit. A model that answers reliably at 10k tokens of context is measurably shakier at 150k, on the same question. **Lost in the middle** — retrieval of a specific fact is best when it sits near the beginning or the end of the window and worst when it is buried in the middle. Long transcripts bury things by construction. **Context poisoning / distraction** — a wrong intermediate conclusion, a failed tool call, or a page of irrelevant scraped text does not sit inertly. It conditions everything that follows. An agent that guessed wrong at step four will keep referring to that guess at step forty. A long single-agent run accumulates all three. Every dead-end search, every oversized tool result, every abandoned hypothesis stays in the record. ## What isolation actually does about it Give the same work to an orchestrator and three workers and the arithmetic changes. Each worker starts clean, holds only its brief and its own findings, and finishes before it has time to bloat. The orchestrator never sees the twenty documents — it sees three paragraphs. Its window stays small, so the reasoning that matters most (what does all this mean for the user's actual question?) happens under the best conditions available, not at the end of a 150k-token slog. A concrete shape: a scientific-literature-review orchestrator splits a question across five workers, each assigned a disjoint set of papers. Each reads its set — call it 40–60k tokens of full text and search results — and returns a 300-word finding with citations. The orchestrator ends up with roughly 2k tokens of high-signal input covering material that would have overflowed a single window entirely. The workers' dead ends, retracted PDFs and irrelevant hits never touch it. ## Isolation is one tool among several Context isolation sits in the same family as the other context-engineering techniques, and interviewers like to hear you place it: - **Compaction** — summarize the conversation so far and restart from the summary. Same idea applied to time rather than to workers, and lossy in ways you do not control. - **Context editing** — clear stale tool results or old reasoning out of the window rather than summarizing them. - **Just-in-time retrieval** — hold identifiers or file paths instead of contents, and fetch at the moment of use. - **Structured note-taking** — write findings to durable storage and re-read the notes rather than re-reading the transcript. Subagent isolation is the most expensive of these, because it duplicates system prompts, tool definitions and task context per worker. Reach for the cheaper ones first: if compaction or offloading tool output by reference solves your context pressure, you do not need a multi-agent system at all. ## The diagnostic that follows If isolation is the mechanism, then the payoff scales with how much noise the subtask generates. That gives a usable test before you split anything: *how many tokens does this subtask consume relative to what it needs to report back?* A worker that reads a hundred pages to answer one question has a compression ratio of maybe 50:1 and is an excellent candidate. A worker that makes one API call and returns the response verbatim compresses nothing — you have paid for an extra model round-trip and a coordination step to achieve exactly nothing. This is also why multi-agent shines on breadth-first search and exploration, and disappoints on tightly coupled work. Exploration is noise-generating by nature; a sequential refactor where each step depends on the last is not, and splitting it merely means every worker lacks the context the previous step produced. ## Two honest caveats First, isolation costs information. Anything a worker saw but did not report is unrecoverable to the orchestrator, and workers are poor judges of what will matter later. Second, isolated workers cannot coordinate mid-flight — two of them can independently reach incompatible conclusions, and no amount of summary quality lets the orchestrator tell which one was right.