Multi-Agent Context Engineering: Isolation, Forking, and Handoffs

A multi-agent harness rarely breaks because a model was not smart enough. It breaks because context, the exact set of facts each agent holds at the moment it acts, arrives scattered, stale, or so bloated the model loses the thread.

You can wire up a lead agent and five capable subagents and still watch the system return a confident, wrong answer, because the lead never saw what a subagent found, or saw too much of it.

Anthropic reported that a lead model with parallel research subagents beat its single-agent baseline by 90.2% on one internal research evaluation. The same report says multi-agent systems fit highly parallel research tasks better than work with tightly dependent steps. Cognition, that same year, argued against multi-agent architectures for many coding tasks. Context discipline matters, but task parallelizability and coordination cost also determine whether multiple agents help.

The teams most likely to benefit are the ones that choose parallelizable work and decide, on purpose, what each subagent starts with, how much it may hold, and what it hands back.

This post is about that discipline: how subagent context flows, when to isolate or fork it, how to budget tokens, and how to keep context from rotting as you add agents.

TL;DR

• A multi-agent harness runs a lead agent and its subagents as one system. In common orchestrator-worker designs, each subagent receives a separate context assembled by the harness.
• Context moves in two directions, down from lead to subagent and up from subagent to lead, and most harness bugs live on one of those two edges.
• Start each subagent isolated with a clean window, forked from the parent transcript, or sharing a live common window, and pick the mode per subtask instead of defaulting to one.
• Anthropic observed roughly fifteen times the tokens of ordinary chat in one multi-agent research system, so measure usage and set budgets for your own workload rather than assuming a universal multiplier.
• Context rot takes four shapes, poisoning, distraction, confusion, and clash, and each one enters through a specific edge you can guard.
• Summarize a subagent’s run before handing it back to the lead, and instrument the harness so you can see subagent traces and score the handoffs.

What a Multi-Agent Harness Is

A multi-agent harness is the orchestration layer that runs a lead agent and its subagents as one system. The lead, sometimes called the orchestrator, reads the task, breaks it into parts, spawns a subagent for each part, and stitches the results back into a single answer. The subagents are often a smaller or cheaper model class than the lead, pointed at a narrower job with a narrower tool set.

This orchestrator-worker shape is the one most multi-agent frameworks converge on, because it maps cleanly onto work that fans out: research a topic from six angles, review a codebase across ten files, draft and critique in parallel.

The appeal is measurable in the right workload. Anthropic’s engineering team reported an orchestrator-worker system, Claude Opus as the lead with Claude Sonnet subagents, outperforming its single-agent baseline by 90.2% on an internal research eval. Anthropic also cautioned that tasks with many dependencies, including much coding work, are a weaker fit because they offer less independent work to parallelize.

On a separate browsing benchmark, the same team found token usage alone explained about 80% of the score variance, with tool-call count and model choice covering most of the rest. That is a blunt way of saying the systems that spent context well were the systems that won.

The skepticism is also earned. Cognition’s “Don’t Build Multi-Agents” argued the reverse: that spreading a task across parallel agents disperses decision-making, that subagents make conflicting choices when they cannot see each other’s full reasoning, and that a single-threaded agent is more reliable for most work.

The disagreement is not really about agent count. It is about whether you can move the right context to the right agent at the right time. Get that wrong and you get Cognition’s failure mode. Get it right and you get Anthropic’s number. Everything below is how you get it right.

How Context Moves Through Subagents

In many orchestrator-worker architectures, the lead and each subagent operate with separate context windows. Other frameworks may use shared state or a common message store, so the harness must define explicitly what each agent can see. In the isolated and forked patterns discussed here, the lead holds the task, plan, and returned results while each subagent receives context selected by the harness.

Information is not automatically shared across isolated windows. If the lead wants a subagent to know something, it has to pass it down; if a subagent learns something the lead needs, it has to return it explicitly.

A finding that stays in a subagent’s window and never makes the return trip is, for the rest of the system, a finding that never happened. This is the same structural reason subagent failures never roll up into the parent trace unless you deliberately propagate them.

So a single request produces two directions of context flow: down, from lead to subagent, and up, from subagent back to lead. What you pass down decides what the subagent can do. What comes back decides what the lead can conclude. Most harness bugs live on one of those two edges.

Isolated versus forked subagents

LangChain’s Deep Agents documentation describes isolated and forked context modes. The framework below extends that distinction to budgeting, handoff quality, context rot, and tool access. Common harness patterns include isolated context, forked context, and shared state.

An isolated subagent starts clean. It gets a fresh window with a task description and nothing else: no lead transcript, no sibling history. It is cheap in tokens and it cannot be poisoned by the parent’s mistakes, but it also knows nothing it was not explicitly told, so a badly written task brief leaves it guessing.

A forked subagent inherits the parent transcript. It starts with a copy of the lead’s window, so it has full continuity: the original request, the plan, and everything that already happened. That continuity costs tokens on the very first turn and carries a risk, because anything wrong in the parent window is now wrong in the child window too. Continuity and contamination arrive together.

Choosing a Context Mode

Once you can isolate or fork, the real decision is which mode fits which subtask, plus a third option, sharing, for agents that must react to each other live. There is no default that is right everywhere, and picking one mode for the whole harness is how most context problems start.

Isolate when the subtasks are genuinely independent. Six research angles that do not depend on each other should each start clean, because continuity buys nothing and every extra token is a chance for distraction.

Fork when continuity is the point: a subagent that refines the lead’s half-finished draft needs to see the draft and the reasoning behind it, so a clean start would just make it redo work.

Share when two agents are tightly coupled and have to see each other’s output as it lands, a debate between a proposer and a critic, for instance, where each turn depends on the last.

The trade-offs run along three axes: token cost, contamination risk, and how much the subagent needs to know. Sharing is the most expensive and the most fragile, because a shared window grows with every participant and every write is a chance for two agents to contradict each other.

The practical rule: default to isolated, fork when a subtask provably needs history, and reserve sharing for the rare pair that cannot work without a live view of each other.

The Token Budget Problem

Multi-agent systems can use substantially more tokens than ordinary chat. In Anthropic’s research-agent data, multi-agent runs used about fifteen times the tokens of chat interactions. This was a workload-specific observation, not a universal multiplier: actual cost depends on agent count, model choice, tool use, context passed to each agent, and the amount of independent work available.

Token growth is both a cost and quality concern. Model quality can degrade before a context window reaches its advertised limit, especially when the window contains irrelevant or conflicting material. A window that is 90% full is not necessarily operating at 90% effectiveness.

So every agent needs a hard token budget, enforced before each model call, not a hope that windows stay small. Measuring and context window management as a first-class concern is what keeps the multiplier from turning into truncation. LangChain’s trim_messages gives you the enforcement primitive: keep the most recent turns under a ceiling while always retaining the system prompt.

# Code 1 - per-subagent token budget with LangChain's trim_messages
from langchain_core.messages import (
    trim_messages, SystemMessage, HumanMessage, AIMessage,
)

def budget_context(messages, max_tokens: int, token_counter):
    # keep the most recent turns under a hard budget, always retain the system prompt
    return trim_messages(
        messages,
        max_tokens=max_tokens,
        strategy="last",
        token_counter=token_counter,
        include_system=True,
        start_on="human",
    )

def _demo():
    msgs = [SystemMessage("role"), HumanMessage("a"), AIMessage("b"), HumanMessage("c")]
    kept = budget_context(msgs, max_tokens=3, token_counter=len)
    assert isinstance(kept, list) and kept[0].content == "role"

if __name__ == "__main__":
    _demo()

The strategy="last" keeps the newest turns, which is what you want for a subagent mid-task; include_system=True protects the instructions from being trimmed away; start_on="human" keeps the trimmed window starting on a clean turn boundary instead of a dangling tool result. Set the budget per subagent, not globally, so a research worker that needs history gets more room than a formatter that needs almost none.

How Context Rot Breaks Multi-Agent Systems

Context rot is what happens when a window fills with content that actively hurts the next decision. Drew Breunig catalogued four common shapes it takes, and each one enters a multi-agent system through a specific edge.

Poisoning is when a wrong fact gets treated as ground truth and cited again and again; in a harness it enters when a subagent invents a detail and the lead forks it, inheriting the lie. Distraction is when the model fixates on a long history and stops reasoning about the current step; it enters through windows that grow unbounded across many turns.

Confusion is when irrelevant content pulls the answer off course; it enters when the lead passes a subagent everything instead of only what the subtask needs. Clash is when two pieces of context contradict each other and the model picks wrong; it enters when parallel subagents return conflicting findings into the same lead window.

The pattern across all four: rot is a context-placement failure, not a model failure. The fix is always about what you let into a window and when, which is why the next section matters.

Summarization and Handoff Between Agents

One of the highest-leverage moves in a multi-agent harness is also one of the most overlooked: summarize a subagent’s run before handing it back to the lead. A subagent that ran twenty tool calls has a long, noisy transcript. The lead does not need the twenty steps. It needs the decisions and the results.

Passing the raw transcript up is how you get distraction and clash, because the lead now has to re-read reasoning it did not do and reconcile detail it does not need. Passing a tight summary up is how you keep the lead’s window clean enough to actually conclude.

This is the one point where the multi-agent skeptics and advocates agree. Cognition’s argument against parallel agents still ends with a recommendation to compress history with a dedicated model for long tasks, which is exactly the handoff move, applied to a single thread. Evaluating agent handoffs is how you know the summary kept what mattered.

# Code 2 - summarize a subagent run before handing context back to the lead
# Requires ANTHROPIC_API_KEY in the environment.
import anthropic

client = anthropic.Anthropic()

def summarize_for_handoff(subagent_transcript: str, max_tokens: int = 256) -> str:
    resp = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=max_tokens,  # hard ceiling; the prompt targets a tighter ~200
        messages=[{
            "role": "user",
            "content": (
                "Summarize this subagent run for the lead agent in about 200 tokens. "
                "Keep decisions and results, drop the step-by-step reasoning:\n\n"
                f"{subagent_transcript}"
            ),
        }],
    )
    if resp.stop_reason == "max_tokens":
        raise ValueError("handoff summary hit the token ceiling and was truncated")
    return resp.content[0].text

The contrast is the whole point. Hand back the raw transcript and the lead’s window grows by the full length of every subagent run, so ten workers can blow the budget by themselves. Hand back a capped summary and each subagent contributes a fixed, small amount no matter how long it worked. Summarization is what makes the token math survive more than two or three agents.

Where Future AGI Fits for Multi-Agent Context

Context discipline needs two things you cannot eyeball: visibility into what each subagent actually held, and a score for whether the handoffs were any good.

Observability and evaluation tools can trace runs and score outputs. For multi-agent context, the additional question is whether the stack also lets you restrict which tools each agent identity may access. Because competitor capabilities change frequently, verify current vendor documentation against those three requirements rather than relying on a static feature table.

Future AGI combines trace inspection, custom evaluation, and per-key MCP tool access control in the same stack.

Future AGI’s observability captures every subagent run as spans nested under the lead, so a subagent that failed quietly shows up in the tree instead of vanishing into a green parent.

You can open a run and read exactly what each window contained, which is the only reliable way to catch context that was passed down wrong or never sent back. The applied guide to trace and debug multi-agent systems walks through reading those traces span by span.

To measure the parts this post is about, Future AGI’s evaluation lets you write custom evals that score exactly what a handoff should preserve and whether a subagent’s window stayed in budget, then run them as a CI gate so a regression in summarization or budgeting is caught before it ships, not after.

Built-in agent evals like task completion and loop detection cover the failure modes that surface once subagents start calling tools.

The Agent Command Center supports per-key MCP tool access control: API keys can carry allowed and denied tool lists, and those restrictions are enforced at the MCP layer. Give different subagents different keys to make tool access a gateway policy instead of scattered prompt logic. The core is open-source and self-hostable via Docker Compose, so the harness you instrument in development can also run inside your own environment.

Keeping Context Clean as You Scale Agents

The multi-agent harness that returned a confident, wrong answer at the top of this post did not need a smarter model. It needed the lead to see what its subagents found, and it needed each subagent to start with the right context and hold no more than it could use.

That is the whole job: budget tokens so no window bloats, pick isolated or forked per subtask instead of defaulting to one, summarize a subagent’s run before it hands back, and reconcile conflicts at the lead instead of hoping they cancel out.

None of it holds unless you can see it. Context discipline is invisible in a green dashboard and obvious in a trace, so the practical next step is to instrument the harness: trace every subagent as a span, score the handoffs and the context-window use as evals, and gate the next change on those scores.

Do that and adding the sixth agent makes the system better instead of noisier. Skip it and every new agent is one more window you cannot account for.