Subagent Design Boundaries: Context Isolation, Not an Org Chart

A team we worked with last quarter had six subagents in their code review pipeline: a security reviewer, a style reviewer, a test-coverage reviewer, a performance reviewer, a documentation reviewer, and a lead agent to synthesize the findings. It looked like a well-run engineering org. It cost about eleven dollars per pull request and took four minutes. When we collapsed five of those six into a single loop with a checklist in the system prompt, quality on their eval set went up by a few points, cost dropped to under two dollars, and latency fell to fifty seconds.

The security reviewer stayed separate. Not because security deserves its own seat at the table, but because it was the only one that needed to pull down dependency manifests, query a CVE database, and read three years of commit history. That reading burned 60,000 tokens to produce a nine-line finding. Everything else was reading the same diff the parent already had in context.

That is the whole distinction. A subagent is a memory management primitive that happens to look like a person. Once you stop treating it as a person, the design questions get much easier.

What a subagent actually buys you

Strip away the anthropomorphism and a subagent is a function call that runs a model loop in a fresh context window, does an unbounded amount of reading and tool use, and returns a bounded result to the caller. The parent never sees the intermediate mess. That is the product.

This matters because context is not a neutral container. Chroma's context rot study tested 18 models and found that performance degrades non-uniformly as input length grows, even on tasks well within the advertised window. Adding tokens to a prompt is not free capacity. It is a slow tax on every subsequent decision the model makes. A parent agent that has read forty files to answer one question is measurably worse at the next question than one that received a nine-line summary.

Production harnesses converged on this independently. Anthropic's writeup of their multi-agent research system is explicit about the mechanism: subagents "operate in parallel with their own context windows, exploring different aspects of the question simultaneously," and the lead agent receives condensed findings. Their internal breadth-first research eval showed the multi-agent configuration outperforming a single agent by a wide margin. They also reported the bill: agents use roughly 4x the tokens of a chat interaction, and multi-agent systems around 15x. They were candid that this only pencils out for high-value tasks where the work is genuinely parallelizable.

Fifteen times. That is the number to hold in your head when someone proposes adding a critic agent.

The org chart fallacy

The dominant failure pattern in 2026 is what I'd call role casting: taking a job description you understand from human teams and instantiating it as an agent. Researcher, critic, writer, project manager. Jumpcap's analysis of agent org structures traces why this is so seductive - the org chart is the only mental model most buyers have for coordinating specialized work, so it gets imported wholesale.

The problem is that human org charts solve constraints models do not have. We separate roles because a person cannot hold a codebase in working memory, cannot be an expert in six domains, and cannot work on two things at once. We add a critic because the author has ego investment in their draft. None of these transfer. A model has no ego about its first draft, and asking it to critique its own output in the same context is often better than shipping the draft to a fresh instance that has to reconstruct why the choices were made.

Cognition made the sharpest version of this argument in Don't Build Multi-Agents. Their two principles are worth memorizing: share context, and remember that actions carry implicit decisions. When you split work across agents, each one makes decisions the others cannot see. The writer agent picks a framing. The critic agent, lacking the reasoning behind that framing, critiques it as if it were arbitrary. You get conflict that looks like rigor and is actually just information loss at the boundary.

Here is the antipattern table we use in design reviews:

Two of those six survive contact with the question "what constraint does this boundary relieve?" That ratio matches what we see in most client codebases.

The three gates

Here is the test we apply before any subagent ships. A step earns its own context window if it passes at least one gate. If it passes none, inline it.

Gate 1: Context budget. Will this step read far more than it reports? The heuristic we use is a 10:1 compression ratio. If a step consumes 50,000 tokens of file contents, search results, or logs to produce a 2,000-token finding, isolation pays for itself immediately. If it consumes 3,000 and returns 2,500, you have added a network round trip and a system prompt for nothing. Anthropic found that token usage alone explained around 80% of performance variance on their browsing benchmark, which cuts both ways: spend tokens where they buy reading, not where they buy handoffs.

Gate 2: Permission scope. Does this step need credentials or tools the parent should not hold? This is the gate most teams underweight, and it is the one with real security value. A subagent that queries production Postgres with a read-only role, or one that fetches untrusted web content with no write tools attached, is a containment boundary in the security sense. It keeps you from assembling the full set of capabilities - private data access, untrusted input, and an exfiltration path - inside a single loop. Google's ADK multi-agent documentation treats scoped tool assignment per agent as a first-class design concern rather than an afterthought, which is the right framing.

Gate 3: Failure containment. Can this step loop, hallucinate, or blow a time budget in a way you want to bound? A subagent gives you a natural retry unit. If a web research subagent spins for twelve turns without converging, you kill it, log the failure, and either retry with a tighter brief or proceed with partial results. The parent's state is untouched. Try that with an inline step and you have a poisoned context that you now need to compact or truncate, which is its own engineering problem (we wrote about the mechanics in our post on context compaction for long-horizon sessions over on the OpenNash blog).

The gates are deliberately not about task semantics. Nothing in that list says "different kind of thinking" or "specialized expertise." Those are the criteria that produce org charts.

Boundaries need contracts, not vibes

Passing a gate tells you where to cut. It does not tell you what crosses the cut. This is where most multi-agent systems actually break.

The Berkeley study on why multi-agent LLM systems fail analyzed traces across seven popular frameworks and built a taxonomy of 14 failure modes. The finding that should change your architecture: the majority of failures were not model capability problems. They clustered into specification and system design issues, and inter-agent misalignment - agents ignoring input from peers, dropping requirements during handoff, or terminating before verification. These are interface bugs. They are the multi-agent equivalent of passing untyped JSON between microservices and hoping.

So every subagent boundary in our systems carries three things:

1. A typed return schema. Not "return your findings." A JSON schema with required fields, enums where the answer space is closed, and a confidence or coverage field the parent can act on. If the subagent cannot fill a required field, that is an explicit failure, not a paragraph of hedging.
2. A complete brief. The subagent gets everything it needs to make the same decisions the parent would. Anthropic's team noted that vague subagent instructions produce duplicated work, because two subagents given fuzzy briefs will converge on the same obvious search. Specify the scope, the output format, the tools to use, and the boundaries of what is out of scope.
3. A budget. Maximum turns, maximum tokens, maximum wall clock. Enforced in code, not requested in a prompt.

The contract is what makes the boundary a boundary. Without it, you have not isolated context, you have just added a lossy translation layer.

When to use a workflow instead of any of this

There is a third option that gets skipped: do not use dynamic delegation at all. LangChain's workflows versus agents documentation draws the line cleanly. A workflow orchestrates LLM calls through predetermined code paths. An agent lets the model decide the path. Most of what teams build as "multi-agent systems" are workflows wearing a costume - the sequence is fixed, the steps are known, and the only reason a model is deciding anything is that someone wired it that way.

If you know the step order in advance, write the step order in code. You get determinism, cheap debugging, real error handling, and a system your on-call engineer can reason about at 2am. Parallelization across a known set of inputs is a Promise.all, not a swarm.

Reserve model-driven delegation for the case where the number and shape of subtasks genuinely depends on what the model discovers. Open-ended research is the canonical example: you do not know before you start whether the question decomposes into three threads or eleven. That uncertainty is what buys the orchestrator its keep.

The design space analysis of current agent systems makes a related point about where the field is heading: the interesting axis is not how many agents you run but how tightly the coordination substrate constrains them. Loose coordination with many agents is the worst quadrant. It is also the most common.

How OpenNash Can Help

Most of our agent engagements start with an architecture that already exists and already costs too much. The audit phase maps every subagent boundary against the three gates and produces a list of which ones survive. In practice, somewhere between a third and half of them collapse into the parent loop with no quality loss, and the surviving boundaries usually need output contracts they never had.

The design phase is where we write those contracts: return schemas, tool scoping per agent, turn and token budgets, and the human approval points where a subagent's output crosses into anything with side effects. Build and deploy follow the same pattern as the rest of our work - eval sets before refactors so you can prove the collapse did not cost you quality, CI integration, and full handoff so your team owns the system.

On the platform question, be honest about your situation. If your workflow maps cleanly onto an off-the-shelf agent platform and you do not need custom tool permissions or audit trails, use the platform. If your agents touch regulated data, need per-step credential scoping, or run inside processes where you have to explain every decision to a compliance reviewer, custom implementation is the path. If you have not yet defined what a correct output looks like, wait and build the eval set first. That is not a sales answer, it is the sequence that works.

Book a call if you want the three-gate review run against your current architecture.

The test to run this week

Take your agent system and, for every subagent, answer one question: what breaks if I inline this? If the answer is "the parent's context gets crowded with things it does not need later," keep it. If the answer is "it would have write access to something it should not," keep it. If the answer is "a bad loop would poison the whole run," keep it.

If the answer is "nothing, it would just be one big prompt," you found your savings. Delete the boundary, move the instruction into a checklist, and spend the tokens you recovered on a longer eval run.