A Subagent’s Blast Radius Is a Design Decision

Every time an agent delegates a task, it creates a second actor with its own context, its own tools, and its own capacity to do the wrong thing. How much of the system that second actor can see, touch, and break is its blast radius, and the mistake most people make is treating that radius as a side effect of the task rather than the first thing they design. They write down what the subagent should do, spawn it, and inherit whatever reach that implies. The result is a subagent that works in the demo and misbehaves in ways nobody can trace, because its actual authority, its actual view of the system, and its actual failure behavior were never decided on purpose. They fell out of defaults.

The discipline that makes delegation safe is to invert that. Before deciding what a subagent does, decide what it is allowed to see, what it is allowed to do, what it is responsible for, and how its result comes back. Those four boundaries are the blast radius, and each one is a lever you set deliberately or forfeit by inattention. A subagent whose boundaries are tight is predictable, testable, and cheap to reason about. A subagent whose boundaries are loose is a liability that happens to be producing correct output for now.

A subagent starts with nothing, and that is the point

The single most consequential fact about a delegated agent is that it begins empty. Nothing crosses over from the parent unless the parent puts it there: not the running conversation, not whatever the sibling tasks are doing, not the overarching plan the work belongs to. What sits in front of the subagent at the moment of assignment is the entirety of its world, and everything the parent knew but did not pass simply does not exist for it. This emptiness is not a condition to engineer around. It is the property that fixes the first dimension of blast radius, which is how much of the system the subagent can see.

Treating that emptiness as the design default pays off in several directions at once. A subagent that receives only what its task requires cannot accumulate the drift and noise of a long parent session, so its attention stays on the work. It cannot leak sensitive material into an unrelated task, because material it was never handed cannot travel. It costs less, since every token the parent loads into that context draws on the same budget of spend and delay, and a focused context is a small one. And it can be exercised on its own, with nothing but its declared inputs, which is the only way to know what it actually does before it runs inside a live pipeline.

The instinct that undoes all of this is generosity. The parent holds a rich context and it feels safe, even thorough, to pass a generous slice of it down so the subagent has everything it might conceivably want. That instinct is backwards. More context is not more capability when the extra material is irrelevant to the task, because the irrelevant part does not sit inertly. It competes for the model’s attention with the part that matters, and it widens the set of things the subagent might latch onto and act on. The question that governs what to include is deliberately strict. Admit what the task in front of the subagent genuinely depends on, and refuse anything whose only justification is that it could conceivably come in handy. Withhold the rest by default. Starting minimal and adding a needed piece deliberately is a controlled operation. Starting broad and trimming is guesswork, because you can no longer tell which of the things you passed the subagent is quietly depending on.

Authority extends only as far as it is granted

The second dimension of blast radius is what the subagent can do, and the principle that governs it is least privilege. A subagent should hold exactly the tools and the access its task requires, and not one capability more. A component whose job is to condense text has no business holding the authority to delete records. A component that reads from an internal datastore has no reason to reach the open internet. These are not hypothetical tidiness concerns. Every tool a subagent can call is an action it can take when something goes wrong, and an authority you grant without needing is a failure mode you signed up for at no benefit.

Bounding authority has two parts, and the tooling is only the first. The other is stating the boundary in the subagent’s own instructions, in plain terms: here is what is in scope, here is what is out of scope, do not act beyond it. A model that is told where its edges are is far less likely to improvise past them than one left to infer its role from the shape of the task. The two mechanisms reinforce each other. The permission set makes certain actions impossible, and the instruction makes the remaining ambiguous ones unlikely.

The failure this prevents is the side effect the parent never sees. A subagent that modifies shared state, or takes an action outside its assigned lane, changes the world in ways the parent is not tracking and cannot account for. The parent reasons about the system as though each subagent did only its declared job, and every undeclared side effect is a gap between that model and reality. Side effects are where multi-agent systems become unpredictable, and the defense is to make them structurally scarce: no write authority a task does not need, no reach into shared state that the design did not sanction, no actions beyond the assignment. A subagent that cannot touch what it was not sent to touch has a blast radius you can actually draw.

Scope is the boundary that makes the other two enforceable

The third dimension is what the subagent is responsible for, and it is the one people define most vaguely. Scope is the definition of the task itself: precisely what the work is, precisely what it is not, and precisely what finished looks like. It is easy to underrate because a loosely scoped task still runs and still returns something. But scope is what makes the other boundaries meaningful. You cannot grant least privilege to a task whose extent is fuzzy, because you cannot tell which privileges it needs. You cannot pass a minimal context to a task whose requirements are open-ended, because you cannot tell what is relevant. Loose scope forces loose authority and loose context, and the blast radius swells to match.

A well-scoped instruction settles what a bare task statement leaves dangling. It bounds the work tightly enough that the subagent can tell what belongs to the assignment and what falls outside it. It fixes the form of the output, so the result returns as something the parent can act on. And it states the condition for done, so the subagent knows when to stop instead of guessing at it. Let any of these go missing or soft and output quality drops, and worse, it drops differently each run. Behavior that wobbles from one run to the next is among the hardest defects to chase in a multi-agent system, because the failure wears a fresh face every time and never sits where its symptom surfaces.

There is a clean test for whether scope is right, and it doubles as a test for the whole design. Two properties tell you the boundary was drawn well. The first is that the subagent can be exercised on its own: hand it the declared inputs, with no parent and no peers running alongside, and its result can be checked on the spot. The second is that one build of it can stand in for another with nothing else in the system noticing, so long as the shape of what goes in and what comes back is preserved. Both properties trace to a single condition, which is that the subagent leans on nothing it was not handed. When it quietly depends on state the parent never passed, it can neither be checked alone nor exchanged cleanly, and that very inability to run it in isolation is the tell that its remit reaches too far or its dependencies have grown tangled. A subagent you cannot exercise by itself is one whose blast radius you are accepting on faith rather than knowing.

The return trip is a contract, not a summary

The fourth dimension is how the result re-enters the system, and it decides whether the parent can treat the subagent as a part it plugs in or as an opaque thing it has to interpret. The parent does not read a subagent’s output the way a person reads a report. It consumes that output in code, to decide what happens next. So the result has to arrive in a form built for that: a fixed shape, with named fields or sections a program can pick apart. A prose summary reads well to a human and does the parent no good, because decisions cannot be lifted out of it reliably, and a form that shifts from one run to the next pours ambiguity into the exact place the system can least afford it.

This is a requirement to fix before the subagent runs, not a preference to discover after. Leave the output shape unstated and the subagent will default to whatever prose reads most fluently to it, which is nearly always a paragraph of explanation, and the parent ends up interpreting where it should be processing. The remedy is to pin the return shape in the assignment from the start, down to the fields the parent will read, so the result composes by construction. Part of that shape is a status the parent can branch on. The return should state outright whether the task succeeded rather than shipping the payload alone, so success and failure stay distinguishable without the parent having to read intent out of the content.

A silent failure is the worst thing a subagent can return

Error reporting deserves the same deliberate design as the success path, and it usually gets none. When a subagent runs into something it cannot handle, how it reports that matters as much as anything it does on a good run. The safe behavior is to hand back a signal that names the failure and carries enough detail for the parent to work out what broke and choose a response. The dangerous behavior is to come back empty and mute about the reason. Silence is the worst thing it can do, because a task that failed and produced nothing looks exactly like a task that ran fine and legitimately found nothing. A lookup that came up empty and a lookup that crashed are the same shape to the parent, which has no way to tell whether to accept the answer, run the task again, or escalate. More often than not it accepts it, and the failure vanishes into the final result with nothing to mark where it slipped in.

Designing the failure path means settling, before the subagent ever runs, two things: the exact form its output takes when the work cannot be finished, and the detail the parent will need to tell what went wrong or to mount a second attempt. That answer belongs in the output shape as a first-class part of it, alongside the success fields, not bolted on as an afterthought. A subagent that fails loudly, with a clear signal and actionable detail, keeps its failure contained to the step that produced it, where the parent can still respond. A subagent that fails silently lets the failure ride along unnoticed, and a failure you cannot see is one you cannot bound. The blast radius of a silent failure is every step that runs after it.

Delegation has a price, and sometimes it is not worth paying

Every boundary above is work, and that work is the argument for not delegating reflexively. Spawning a subagent is not free. It carries the cost of loading a fresh context, coordinating the handoff, waiting on the result, and processing what comes back. For a task that is small and that the parent could simply do in line, that overhead exceeds anything delegation buys, and the reflex to give every subtask its own agent produces a system that spends more effort on the machinery of delegation than on the work. Each spawn adds latency, each one adds a component to manage, and a pipeline full of trivial delegations is slower and more fragile than the straight-line version would have been.

Delegation earns its cost under a few specific conditions. One is when a task stands genuinely apart, running in parallel with others and needing none of their in-progress results to do its own work, so bounding it off takes nothing away. Another is when a task calls for capabilities the parent should not itself hold, and handing it to a subagent lets those capabilities live behind a narrower permission set. A third is when keeping one task’s material from bleeding into another’s is the entire point, which is exactly what a fresh, sealed context delivers. The common thread is that a real reason can be named. When no such reason comes to mind, that silence is the verdict: keep the work in line, and save the delegation machinery for the tasks that pay it back.

The handoff is the design, and it comes before the spawn

Pulling this together, the artifact that matters most in delegation is the specification you write before anything runs: the task defined narrowly, the context pared to what that task requires, the authority granted only where it is needed, and the return shaped so the parent can act on it, failures included. That specification is the blast radius. Get it right and the subagent is a component you can test alone, swap freely, and reason about with confidence, because everything it can see, do, and break was chosen rather than inherited. Get it wrong and you have spawned something whose reach you will learn about the first time it does damage, in production, where the cost of discovery is highest.

The recurring anti-patterns are all the same failure viewed from different sides. A scope drawn too broadly makes the task ambiguous and its output impossible to validate. A context passed too thin leaves the subagent guessing, and its guesses will not match the parent’s intent. Criteria for done left unstated leave the subagent unable to know when to stop. An output format left implicit forces the parent to interpret prose. A failure path left undesigned lets errors travel silently. Each one is the consequence of designing the task and letting a boundary set itself. The remedy is not more sophisticated agents. It is the deliberate act of drawing all four boundaries first, so that the reach of every delegated task is a decision you made, not a discovery you are waiting to make.