Subagents as Working Memory Protection, Not Speed

Multi-agent workflows are usually justified by wall-clock savings, but in a long-running session the more important property of a subagent is what it keeps out of the orchestrator's context, not how fast it executes. Every token that lands in the orchestrator's context competes for attention on every subsequent turn. Treating subagents as disposable workers for offloading reasoning the orchestrator doesn't need to hold is the real design goal, and it requires explicit ground rules for when and how to delegate.

What Actually Happened in the Session

During a refactor of a response pipeline in a .NET codebase, four subagents were running in parallel with results arriving out of order. Three had clear runtimes (approximately twelve minutes, five and a half minutes, and seven minutes) and a fourth was still running. Concurrent execution kept the wall-clock time near twelve minutes instead of the roughly twenty-five serialization would have required. That looked like a straightforward win for parallelism.

The unexpected cost surfaced when the orchestrator suggested checking on the running agents. A lightweight-looking prompt ("check on the agents") caused the tool to pull back full raw transcripts of a background agent — tens of thousands of tokens of JSONL, intermediate reasoning, and tool output — imported wholesale into the main thread. A second status check repeated the mistake.

A caveat applies: the orchestrator itself ranked this polling cost above the duplication tax of running four agents. Per-call token accounting wasn't available, so that ranking is the orchestrator's account, not a measured fact. What is verifiable is that the transcript dumps occurred and that the status-check path introduced large, avoidable cost. Whether it was the single largest cost remains a hypothesis until tooling can instrument it.

The Costs Were Not All the Same

Looking at the session as one lumped "subagent cost" obscured a more important breakdown. Three distinct problems emerged:

  • Two of the four subagents were working in the same area of the response pipeline. Different tasks and files, but each had to independently reconstruct an understanding of the same architecture, testing conventions, and surrounding code.
  • One agent executed git stash and git stash pop asynchronously with sibling agents writing elsewhere in the same tree. Nothing broke, but repository-wide git operations carry structural risk with multiple concurrent writers.
  • Status polling imported entire transcripts in response to lightweight questions.

Ranking these costs by size turned out to be the wrong question. A one-time token bill is a single expense; what the transcript dumps did was different.

Context Is Not Just a Token Bill

The raw transcript stayed in the orchestrator's context after the tool call completed, so every following turn carried it forward whether or not it was still useful. Two distinct problems were at play: pollution taxing every later turn, and attention dilution — the more sits in context competing for notice, the harder it is for a model to focus on what matters at the moment. A larger context window simply gives the noise more room to accumulate before it becomes obvious.

The orchestrator is the only component that accumulates understanding across a session. It remembers design decisions, carries architectural constraints, and tracks which trade-offs are settled. Subagents are designed to be disposable, holding exploration, repeated file reads, failed approaches, and noisy reasoning in their own contexts, never returning that material to the main thread. That isolation only holds if the orchestrator respects it.

Cognitive Locality

The overlapping orientation work wasn't two agents reading the same files — it was two agents independently rebuilding the same mental model because the work had been partitioned by task rather than by knowledge required. Cognitive locality is the useful distinction: tasks that need the same mental model should stay together. Splitting them forces redundant reconstruction.

Parallelism becomes the byproduct, not the goal. Running waves of subagents is useful largely because they keep noisy reasoning out of the main thread. The orchestrator's responsibility is to return to context only what it still needs and nothing more.

Four Standing Rules

The lessons from the session compressed into four rules added to CLAUDE.md. The constraint was to keep the file small — every added line costs something on every future session — and each rule is really asking the same question: does this information or work split earn a place in the orchestrator's context?

  1. Prefer two to four agents in one wave. If five or more are desired, first ask whether tasks sharing files or conventions should be merged.
  2. Do not poll background agents for status when the answer can be inferred from existing knowledge. Do not fetch a full transcript to answer a lightweight question.
  3. Do not allow repository-wide git operations inside concurrent agent prompts.
  4. Treat overlapping file ownership as a signal to consolidate, not a cue to spawn more agents.

Each rule gives the orchestrator a check to perform before acting rather than a script to run. None is individually profound. Taken together they protect the property that matters: keeping disposable reasoning disposable and reserving the orchestrator's context for what later turns will need. The tangible evidence for this view is the cost of getting isolation wrong, not a measured benefit of getting it right. That side of the equation awaits proper instrumentation.

Skills Don’t Automatically Follow the Spawn

A different flaw surfaced in a later session. The orchestrator had been started with explicit skills—coding guidance in one case, design guidance in another—and I assumed those would carry over to any subagents it spawned. They don't. Unless the orchestrator explicitly hands them over, a subagent inherits none of the parent session's active skills.

My first draft of a fix was a universal confirm-before-spawn gate: the orchestrator would stop, list the agents it wanted to launch, name the skill file each should load, and wait for approval. Keeping that version would have been a mistake. It solved the wrong problem. There was no evidence bad spawn plans were slipping through for want of a confirmation step; I had merely discovered a missing fact about skill propagation. A universal gate would have inserted a round-trip into every similar session, and before long those approvals would have been on autopilot. That isn't improved governance—it's an added ritual. And it still wouldn't have caught the earlier, real problem of the orchestrator polluting its own context.

The narrower fix held up better. Before spawning, the orchestrator states which active skills are relevant to each agent's task and points the subagent at the skill file to load, rather than pasting the entire skill inline. Confirmation is required only above the existing batch-size threshold, or when file ownership is ambiguous.

That left me with a useful heuristic: before adding a line to a standing instruction file, ask whether a reasonably competent orchestrator would make the right decision once it knew the one missing fact. If so, state the fact and stop. If the fix starts specifying a decision procedure—approvals, checkpoints, mandatory steps—that's a sign process is being encoded where a small clarification would suffice. I can't say yet whether the heuristic survives harder cases, but it currently keeps every interesting incident from turning into a miniature bureaucracy.

Calibration, Not Prescription

I don't have a settled view on how much governance is enough, and this piece doesn't earn one. What it offers is a flywheel with a human still firmly in the middle. A session exposes a gap; someone has to notice it felt wrong, stop the work to inspect it, decide whether it's real or noise, and judge what deserves to become a standing rule. The orchestrator can grade its own session and surface clues, as it did here, but it can't make that judgment itself. The choice of what to codify, what to leave alone, and what might be an overreaction remains mine. The next session reveals whether that judgment improved the work or created a different kind of waste.

The artifact of this round is the current version of my CLAUDE.md. It isn't a finished prescription, but the state of calibration after this iteration. The thresholds in it—two to four agents per wave, five as a consolidation signal—fit the work I was doing when I wrote them, and I'd be suspicious of any write-up presenting them as universal constants. They were also calibrated against Claude Sonnet 5; I haven't tested them on other models, which might reasonably need a different balance. More rules have accumulated in the file since. Treat it as a sample, not a template. What matters is the habit behind it: noticing a failure, asking what it actually cost, and writing the rule that would have caught it.

For years we optimized systems around CPU, memory, and throughput; the first wave of LLM tooling taught us to watch tokens. This session suggests a third metric for long-running agent workflows: the quality of the orchestrator's own working memory. It's the one resource that, once polluted, keeps charging rent for the rest of the session. I don't believe that's settled law yet—just a pattern that held up in the sessions I've examined.

The tax I went looking for was never on the subagents. It was on the orchestrator, in what it chose to carry forward. That reframes the central design question from how many agents to run to what earns a place in the orchestrator's context. The genuinely open questions remain:

  • How do I measure this properly, instead of relying on the orchestrator's own account of its mistakes?
  • When should a missing fact go into the instructions, and when does that become too much process?
  • What is the next orchestration mistake I'm not seeing yet?

I expect I'll revise the file again. That feels less like a failure of foresight and more like the ordinary cost of working with a system opaque enough that doubt itself becomes part of the method.

This piece is a narrower follow-up to my earlier Context Anchoring, which argues that decision context should be externalized into a living document because conversations forget their own reasoning and nothing survives the session boundary. That work addresses context surviving across sessions; this one is about keeping context clean within a single session while multiple agents write to the same working memory.

The move to turn this incident into a standing rule owes something to Birgitta Böckeler's Harness Engineering, which names the loop I was running without a word for it. A feedforward guide (the CLAUDE.md rule) meets a feedback signal (the orchestrator's self-critique and my review), with a human steering the update. That article defines three kinds of harness—maintainability, architecture fitness, and behavior—while what this piece describes, using subagents deliberately to protect the orchestrator's context, belongs to a fourth: the orchestration process itself. Thanks to Martin Fowler for guidance and feedback, and to ChatGPT and Claude for serving as pair editors on grammar and structure.