What Is a Subagent?
A subagent is a second agent invoked by a first to carry one scoped part of a task. It receives a brief rather than the caller's transcript, runs its own loop under its own instructions and its own tool grant, and returns a result. What makes it a subagent rather than a peer is that control comes back: the caller still holds the task while the subagent runs, and still holds it afterwards.
The boundary, and what crosses it in each direction
Everything that separates delegation from simply continuing sits at a boundary crossed exactly twice. Outbound goes a brief — the task as the caller chose to state it — with whatever instructions, tool grant and material the caller decided to include. Inbound comes a result in the shape the brief asked for. Nothing else passes by default. The subagent's intermediate steps, its tool outputs, its wrong turns and its retries stay on its side of the boundary and are discarded when it returns.
That asymmetry is the reason to delegate. The caller's context grows by the size of the result, not by the size of the work: a search that read forty documents to find one paragraph costs the caller one paragraph. It follows that delegation pays on tasks whose output is far smaller than their working material — reading, searching, sifting a long file, checking a claim — and buys nothing at all on a task whose output is most of what it read, where the same material crosses the boundary anyway and a run has been added to move it.
The cost is on the outbound side and it is structural rather than occasional. A brief is a lossy restatement of intent, written by a step that holds context the subagent will not have and cannot ask for. A qualification the caller knew and did not write down is a qualification the subagent never learns, and the characteristic result is not a wrong answer but a confident answer to a slightly different question. The subagent is in no position to notice: it was never given the original, so it has nothing to compare its brief against.
| Direction | What passes |
|---|---|
| Caller to subagent | A brief stating the scoped task, in the caller’s words. |
| Caller to subagent | Instructions and a tool grant, ordinarily narrower than the caller’s own. |
| Caller to subagent | Whatever material the caller chose to attach, which is the only material available. |
| Subagent to caller | A result, in the shape the brief specified. |
| Neither direction | The subagent’s steps, retries and tool outputs. They end with its run. |
| Neither direction | What the caller knew and did not write into the brief, including why the task was being done. |
The last row is where delegated work goes wrong, and it does not look like failure from either side: the caller receives a well-formed result, and the subagent answered the question it was handed. The mismatch is visible only by reading the brief against what was meant, which is a step nobody performs on a run that appeared to succeed.
A returned result is an input
The result arrives in the caller's context and is read by the step that decides what happens next, which makes it input with the same standing as anything else reaching a context from outside. And the subagent that wrote it has spent its whole run reading fetched pages, tool output and documents. Content written to be read as instruction can therefore leave in the summary the subagent returns, and it is then in the caller's context under the caller's own subagent's name — the mechanism this registry's page on prompt injection sets out, with one boundary added and one attribution laundered.
Permission crosses the boundary too, and it crosses by grant rather than by possession. A subagent holding a narrower grant than its caller is the ordinary and correct arrangement. The reverse — a delegate that can reach what its caller could not, because the grant was attached to the delegate rather than derived from the request — is the shape this registry's page on the confused deputy problem describes, and delegation is where it is easiest to build by accident, since the child's permissions are configured once and the callers arrive later.
Two accounting points, both frequently reversed. Delegation does not divide the work: a subagent is a full run that resubmits its own accumulated transcript at each of its own steps, so the total spent goes up, and what is saved is room in the caller's context. Those are different currencies and the trade only pays where context is the binding constraint. And a delegated failure is harder to attribute afterwards, because the evidence that would explain it — the steps between the brief and the result — is precisely what the boundary discards, unless the runtime recorded the child's run separately, which is a decision taken before it started and unavailable after.
How the Registry classifies a delegated subtask
Delegating a scoped research subtask to a second agent and returning only its finished result is filed as information retrieval in this registry's classification. The classification reads the operation rather than the arrangement: material that already exists is located and compressed, and the delegation decides whose context it is compressed into rather than what kind of task it is.
The Registry's canonical brief for this entry is filed as:
Delegate a scoped research subtask to a second agent with its own instructions and return only its finished result.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
78128945f20b4db9…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about subagent
How a brief is written, what a subagent is permitted to reach, and whether its result answers what the caller meant are properties of a particular system, and the canonical brief above encodes none of them. This registry invokes nothing on an operator's behalf, delegates no part of an assessment, and has never read a result returned across such a boundary.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about subagent
- What is a subagent?
- A subagent is a second agent invoked by a first to carry one scoped part of a task, with its own instructions, its own tool grant and its own context. It receives a brief, runs to completion, and returns a result to a caller that held the task throughout and holds it still.
- What is the difference between a subagent and a multi-agent system?
- A subagent names one relationship — caller, brief, result, control returning. A multi-agent system names a whole arrangement of components and the protocol governing them. A system built entirely out of subagent calls is a multi-agent system with one particular topology, and a system built out of handoffs contains no subagents at all, because after a handoff nothing is waiting for a result.
- Why delegate instead of continuing in the same run?
- For three reasons that are usually stated as one. To keep a large volume of working material out of the caller’s context. To run part of a task under a narrower tool grant than the caller holds. And to obtain a check that does not share the context of the thing it is checking, which a later step in the same run cannot be.
- What does a subagent not know?
- Anything not written into its brief: the caller’s earlier steps, the original request, the reason the task is being done, and any qualification the caller was holding implicitly. It also has no route to ask, which is why an ambiguous brief returns a confident answer rather than a question.
- Should a subagent’s result be trusted?
- It should be handled as input. The subagent has been reading external material all run, and its summary is where that material arrives in the caller’s context. Whatever validation would be applied to a document fetched from outside applies here, with the added difficulty that the result carries an internal name.
- Does delegation reduce cost?
- Not in general. It adds a run, and that run resubmits its own transcript at each of its steps. What it reduces is the caller’s context, which is a different constraint. Where context is what is binding, the trade is worth making; where cost is what is binding, delegating more of the work makes it worse.
Related entries
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.