Delegation Succeeds or Fails in the Prompt, Not the Subagent

Handing verbose investigation to a child agent is usually sold as a clean architectural win. The parent frames a question, a subagent does the messy work in a separate context of its own, and only a focused answer crosses back. The parent’s working memory stays uncluttered while someone else wades through the noise. That is the promise, and it is real. But it is not automatic. The isolation delegation offers is entirely contingent on how the delegation is specified, and a child agent handed a loose question returns a loose, bloated answer that pollutes the caller exactly as badly as doing the work inline would have. When delegation disappoints, the subagent is almost never the reason. The prompt is.

This is the part of the pattern that separates a diagram from a dependable property of a running system. Four mechanics decide the outcome: the prompt that frames the work, the contract that shapes what comes back, the authority the child is granted, and the posture the parent takes toward the result. Get them right and delegation reliably buys you a clean caller and a bounded cost. Get them wrong and you pay the latency and the tokens for a second agent while receiving none of the isolation you delegated for.

The prompt is the whole bet

The single most common way delegation quietly fails is an open-ended prompt. Ask a child to “map how refunds move through the system and write up what you find” and you have licensed it to wander, trail every lead, and report the journey. What returns is a wall of prose assembled from everything the child happened to look at. The parent’s context absorbs all of it, and the boundary that was supposed to protect the caller has done nothing. The child faithfully did what it was told. It was told to produce an essay.

A precise prompt is a different instrument. It names one concrete thing to find, bounds where to look for it, and says what to ignore. The outcome quality tracks the prompt quality almost one for one, because a child agent cannot return an answer sharper than the question that produced it. This holds well beyond coding. A delegated agent reconciling a discrepancy across service logs, pulling a specific clause out of a long contract corpus, or isolating which upstream field went stale in a data pipeline will each return something usable or something useless depending almost entirely on how tightly the ask was drawn. Vague questions produce vague answers, and vagueness is expensive when a second agent is metabolizing it into tokens.

A delegation prompt names four things

Four things, specified together, make an ask tight enough to hand off: what to find, how far the search may range, the form the answer takes, and when to stop looking. Each closes off a distinct way the interaction goes wrong.

The question is a single concrete ask rather than a broad directive. “Which component enforces the spending limit” is answerable and bounded. “Understand the billing system” is not a question, it is an invitation to read everything. The scope names where to look and, just as importantly, where not to: which services, stores, directories, or document sets are in bounds, and which are off the table. Scope is what keeps a child from wandering into an adjacent subsystem and dragging its contents back. The return shape describes the exact format the answer should take, which is the seed of the return contract discussed below. The stop condition tells the child when to return what it has instead of continuing to search.

The stop condition is the element most often left implicit, and it is the one that turns a hard lookup into a runaway. A child with no instruction to stop will keep going when the answer is buried, spending budget and latency on a search that may not converge, and returning late with more material than the parent asked for. A stop condition can be a limit on how many sources to examine, a directive to return the best partial answer if no definitive one appears, or a rule to surface ambiguity rather than resolve it by guessing. Its purpose is to bound the worst case, not the typical one. Delegation is attractive precisely because it caps the parent’s exposure to messy work, and a missing stop condition removes that cap on the child’s side.

Fix the answer’s shape before the search starts

A return contract is the parent’s up-front declaration of the form the answer must arrive in, and it is what holds the caller’s context clean however widely the child had to range to produce it. Hand back a record, not a recounting. The workable default carries just enough to act on and nothing past it: an identifier, where it lives, and one line of context. For a served system that might be the offending record’s id and the field that is inconsistent; for an incident diagnosis it might be the failing dependency and the first timestamp it degraded; for a code investigation it might be the file path, the function, and one sentence of context. The particulars vary. The discipline does not. The parent decides the shape of the answer before the child goes looking, so that the answer arrives pre-compressed.

The contract should also state a maximum length explicitly. Absent a stated ceiling, a child that turned up something it deems worth relaying has nothing to weigh its verbosity against, and it will err toward telling the parent more. Left to its own judgment, an agent that did real work tends to report real work, and the report is the pollution. A length cap removes that discretion. It is worth being blunt about the asymmetry here: the child ranged widely on its own budget, and none of that cost the parent anything, right up until the moment the child decides to summarize it generously. The contract is what stops a well-intentioned summary from re-importing the very verbosity delegation was meant to leave behind.

Grant only the authority the work requires

The third mechanical decision is the authority the child is given, expressed concretely as its available tools. A subagent whose job is to find something needs to read and to search. It does not need to write, to delete, or to call endpoints that mutate state. The default palette for an investigation should be read-only, and everything beyond that should be added deliberately, for a stated reason, and not by inheritance from whatever the parent happened to have.

The reasoning is operational rather than aesthetic. A narrow palette makes the child’s behavior predictable and auditable: given only the ability to observe, the range of things it can do to the rest of the system collapses to nothing, and a discovery step that goes sideways stays contained as a wasted read rather than a side effect. Hand that same discovery agent the ability to write records or call a mutating service and a low-risk lookup has quietly become an action with consequences, one that can now fail in ways that outlive its own run. The cost of scoping the palette down is close to zero, because a child that only needed to find something loses nothing by being unable to change anything. The cost of not scoping it is a class of failure that has no reason to exist. When in doubt, the investigation gets to look and nothing else.

What returns is a claim to weigh, not a fact to bank

The last mechanic is not something the child does, it is the stance the parent takes toward what returns. What the child sends up is a claim to be weighed, not a fact to be banked. A child errs the way any bounded investigator errs. It can settle on an authority a later source supersedes, transpose a value it read correctly moments earlier, or report confidently from a snapshot the system has already moved past. The boundary between parent and child is exactly the place to decide how much of that risk to absorb, and the decision should be calibrated to what is at stake rather than applied as a blanket rule.

When little rides on the answer, taking it at face value is ordinarily correct, and demanding proof of every finding would surrender the speed delegation was bought for. For a decision on the critical path, the calculus inverts. If the parent is about to modify the component the child identified, or reconfigure the service the child named, or act irreversibly on a value the child reported, a spot-check before acting is cheap insurance against propagating a single wrong answer into everything downstream of it. Blanket distrust destroys the efficiency that made delegation worth doing; blanket trust turns the child’s occasional error into the parent’s committed mistake. Sizing the check to the stakes, and no larger, is the whole of what this fourth mechanic asks.

The failure modes share a root

Three failures recur, and seeing them as a family is more useful than memorizing them separately. One is the narrative dump: the return shape is ignored and an essay comes back, seating in the parent the exact volume the boundary existed to keep out. Another is overshoot, where the child ranges past its stated bounds and delivers findings nobody requested, buying the parent latency and noise for material it will discard. The third is unquestioned acceptance, where a critical finding is acted on without a check and an error rides into work built on the assumption it was sound.

The first two trace back to the same origin: a prompt that did not specify tightly enough. The narrative dump is what an unbounded return shape and a missing length cap produce. The overshoot is what an unstated or vague scope produces. Both are specification failures wearing different clothes, and both are fixed on the parent’s side before the child ever runs, by drawing the prompt tighter rather than by hoping the child exercises restraint. The third failure is different in kind. Acting on an unchecked finding is not an under-specified prompt, it is a posture failure at the boundary, and it is fixed by calibrating verification to stakes rather than by writing a better question. Naming which category a given failure belongs to tells you where the fix lives. Most of the time it lives in the prompt. Sometimes it lives in the parent’s willingness to check.

Four decisions the parent makes before the child starts

Trustworthy delegation reduces to four commitments, and none of them are about the subagent’s cleverness. Draw the ask narrow, with one concrete question, an explicit scope of what is in and out of bounds, a named return shape, and a stop condition that caps the worst case. Bind the return to a structured finding with an explicit length limit, decided before the child looks rather than after it reports. Hold the authority down, read-only by default, with anything more added on purpose. Match the scrutiny to the stakes, treating the answer as a claim to weigh and verifying in proportion to what acting on it would cost. Do those four things and the boundary between parent and child does the work it was drawn to do, keeping the caller focused while a separate context absorbs the mess. Skip them and delegation becomes an expensive way to move noise from one context window into another. The pattern was never a guarantee. It is a set of decisions the parent makes before the child ever starts, and the parent is where it succeeds or fails.