Multi-Agent Context: What Each Agent Should See

The obvious way to give a sub-agent context is to hand it the conversation so far. It is also the way that multiplies your bill by the number of agents and imports every irrelevant instruction the parent was carrying.

The default that does not scale

A parent agent decides to spawn three workers. The framework passes the current message array to each, because that is the easiest thing to pass and because it feels safest — surely more context cannot hurt. Both halves of that intuition are wrong, and they are wrong for independent reasons, which is why isolation is worth designing rather than defaulting.

Whether you should have multiple agents at all is a separate question with a frequently negative answer. This page assumes you have already decided you need them, and asks only what each one is allowed to see.

The fan-out arithmetic

Context sharing is multiplicative and it compounds with depth. Let H be the parent’s accumulated context in tokens, k the number of sub-agents, and t the number of turns each sub-agent takes.

shared transcript : input billed ≈ k * t * (H + own_growth)
isolated brief    : input billed ≈ k * t * (B + own_growth),  B << H

With H = 60,000, B = 1,200, k = 3, t = 8 (all ASSUMPTIONS):
  shared   ≈ 3 * 8 * 60,000  = 1,440,000 tokens of history re-sent
  isolated ≈ 3 * 8 *  1,200  =    28,800
  ratio    ≈ 50x on the history term alone

And it recurses: a sub-agent that spawns its own sub-agents while carrying the parent’s transcript passes the whole thing down another level. Two levels of fan-out at k = 3 is nine leaf agents each re-sending 60,000 tokens on every one of their turns. This is the mechanism behind agent runs that cost a hundred times what the task appeared to be worth, and it is invisible in the code — the expensive line is the one that passes messages along.

The parent’s own context is not free either. Every sub-agent result comes back and is appended, so a parent that fans out to three workers and receives three full reports has grown by the sum of them. Sub-agent returns want the same treatment as tool results: a bounded summary plus a handle, not the worker’s transcript.

The correctness half

Cost would be enough of an argument on its own, but isolation is also the thing that makes sub-agents behave predictably.

• Instruction bleed. The parent’s system prompt says “always answer in the user’s language and never reveal internal reasoning.” The sub-agent’s job is to emit a JSON plan. Passing the parent’s instructions makes the worker follow rules written for a different task, and the failures are subtle — a worker that hedges because the parent was told to hedge.
• Stale world-state. The transcript contains the file as it was before the parent edited it. A worker told to “update the config” now has two versions and no ordering information beyond message position — the same superseded-state problem that drives long-session decay, now transplanted into a fresh agent that has no way to know which is current.
• Anchoring. If the point of the second agent is an independent check, giving it the first agent’s reasoning destroys the independence you spawned it for. A verifier that sees the answer being verified is not a verifier.
• Undebuggable failures. When a worker misbehaves and its context is 60,000 tokens of inherited transcript, the cause is somewhere in there. When its context is a 1,200-token brief you can read the whole input in under a minute.

The brief

Replace inheritance with an explicit, constructed hand-down. The parent must state what the worker needs; anything it cannot state is something the worker probably should not be conditioning on.

type Brief = {
  objective: string;        // one task, phrased so success is checkable
  inputs: Ref[];            // by handle: file paths, result ids, urls
  constraints: string[];    // only those that bind THIS task
  outputContract: string;   // exact shape the parent will parse
  budget: { tokens: number; steps: number; usd?: number };
  notWanted?: string[];     // "do not modify files", "do not call the api"
};

Four properties make this worth the extra code. The brief is serialisable, so it can be logged, diffed and replayed — a failed worker run is reproducible from one small object. Inputs are handles rather than contents, so passing a large document costs a path. Budgets are per-worker, which is what makes a per-task spend cap enforceable at all under fan-out. And the output contract is stated by the caller, which is what lets the parent parse the result deterministically instead of re-reading prose.

The discipline it imposes on the parent is the real benefit. Writing a brief forces the parent to know what it wants before spawning, and a parent that cannot write the objective in one checkable sentence usually should not be delegating that step.

What may legitimately be shared

Full isolation is not the goal either — agents that share nothing duplicate work and produce contradictory results. Three things are safe to share, and they are safe for the same reason: they are small, structured and current.

The shared store deserves one warning. A scratchpad that every agent appends to and every agent reads in full is a shared transcript with extra steps, and it grows fastest exactly when fan-out is widest. Shared stores want addressable reads — named files, read on demand — not a common log that is pasted into every worker’s window.

There is one class of exception worth naming, because a rule with no exceptions invites people to break it quietly. When the sub-agent exists to continue rather than to assist — a specialist taking over a task outright rather than answering a question inside it — what it needs is not a brief but a handoff document, which is a richer object with decisions, rejected options and open questions. The distinction is whether the parent stays responsible for the outcome. If it does, send a brief and expect a result back. If it does not, send a handoff and let go.

Finally, budget the fan-out itself and not just its children. The arithmetic above showed that the multiplier is k × t, and both of those are decisions the parent makes at run time. An agent that can spawn workers without a cap on k, and workers that can spawn their own without a depth limit, is a system whose maximum cost is unbounded no matter how carefully each individual brief is trimmed. Cap the width, cap the depth, and make both visible in the trace — they are the two numbers that turn a well-designed brief into a well-bounded run.