What a Sub-Agent Actually Inherits

Five things can be inherited. Your config file covers two.

When a parent spawns a child, the following cross the boundary — or fail to — and each is an independent decision that most stacks bundle or ignore.

• Transcript. The conversation so far: the user's original request, intermediate tool results, the parent's reasoning. Configurable nearly everywhere.
• Instructions. The system prompt, policies, style rules, refusal boundaries. Usually bundled with the transcript decision, which is a mistake — the constraint "never email a customer without approval" belongs to the child regardless of whether the transcript does.
• Authority. The tool set, the credentials behind those tools, and everything reachable from the process without an explicit credential at all. Almost never configurable; almost always total.
• Budget and deadline. Remaining tokens, remaining wall-clock, remaining step count, remaining spend. Typically not inherited, which means not enforced.
• Provenance. The trust labels on the material that produced the child's task. Essentially never carried, and its absence is load-bearing in a way we get to in STEP 4.

Read that list against the sub-agent patterns your framework offers and the asymmetry is stark: the two cheapest things to get wrong are richly configurable, and the three expensive ones are defaults nobody chose.

Transcript inheritance: the switch that exists, and the real trade behind it.

LangChain's deepagents makes the choice explicit and is a good model to reason from. A sub-agent defaults to mode: "isolated", where it sees only the task description it was handed and carries no memory of the conversation that led to the delegation. Switch it to mode: "fork" and it inherits the parent's full conversation history and its exact system prompt. Skills are separate again: custom sub-agents do not inherit them by default, and where they are present, skill state is isolated in both directions — the parent's are invisible to the child and the child's do not propagate back. LangGraph's subgraphs express the same axis structurally: a shared state schema means the child reads the parent's keys, while private state keeps its working memory out of the parent's.

Both settings fail, in opposite and predictable ways.

• Fork fails on cost and attention. You have duplicated a large context window N times, paid for it N times, and handed each child a window in which the relevant instruction is buried among thousands of irrelevant tokens. This is context budgeting at its least forgiving, because the duplication is multiplicative rather than additive.
• Isolated fails on the constraint stated in turn three. The user said "keep it under two pages" eight messages ago; the parent's task description did not repeat it; the child cannot know. Every isolated hand-off makes the parent's brief the entire specification, and briefs written by a model under token pressure drop qualifiers.

The practical resolution is neither switch: it is a typed hand-off. Give each sub-agent role a small structured schema — the task, the accumulated constraints, the definition of done, the artefacts it may read — and have the parent fill it. That converts "how much history" into a question with a testable answer, because a missing field is visible in a trace and a missing sentence in a paragraph is not. It also makes the supervisor's decomposition reviewable, which is where most of these failures actually live.

Authority inheritance: the switch that does not exist.

Here is the asymmetry that matters. Tool access is bound at the process, not at the conversation. A sub-agent spawned inside the same runtime shares the same MCP client connections, the same environment variables, the same OAuth tokens on disk, the same network namespace, the same database session. Setting mode: "isolated" isolates the transcript and changes none of it.

So the sentence to say out loud in a design review: context isolation is configurable, authority isolation is architectural. An isolated sub-agent is not a sandboxed one. It is a fresh context window with identical reach, and if it is persuaded by the document it was asked to summarise, it can do everything the parent could — through connections the parent opened, with no approval step and typically with no supervisor inspection of its individual tool calls.

Fan-out then multiplies the exposure in a direction the topology diagrams do not show:

• Concurrency at constant authority. Five parallel workers are five actors that can each write, not five fifths of a writer. Any rate limit, approval queue or human checkpoint tuned for one agent's call pattern is now facing five.
• The audit trail loses its subject. If children call tools over the parent's credential, every action in the log is attributed to one identity, and afterwards you cannot say which worker sent the email. That is the attribution half of agent identity, and it is lost at spawn time rather than at logging time.
• Recursion is usually unguarded. A sub-agent that can spawn sub-agents, with no inherited depth counter, is a fork bomb whose cost is denominated in tokens. Frameworks rarely bound it by default.

What actually helps is unglamorous and mostly predates agents: give each sub-agent role its own declared tool allowlist, mint per-child credentials scoped to that allowlist rather than sharing the parent's, and put the write-capable roles in a separate process or sandbox so that "isolated" means something at the operating-system level too. Readers get read tools and no credentials worth stealing; the one role that writes gets a narrow, short-lived grant and a checkpoint. That is scoped credentials applied one level further down than most teams apply it, and it is the only control in this essay that changes the worst case rather than the average one.

Provenance: isolation is a laundering channel.

This is the counter-intuitive consequence, and it inverts the safety intuition behind the isolated default.

Trace a hand-off backwards. The parent fetched a web page. The page contained a line addressed to the agent. The parent, following it, wrote a task description and spawned a child. The child receives that description in its instruction position — a clean, short, authoritative-looking brief with no history attached — and executes it. The untrusted origin was real, knowable at the moment it happened, and destroyed by the delegation. A dispatcher enforcing taint rules at the parent would have refused the write; the same dispatcher at the child sees a privileged instruction from its own orchestrator and allows it.

The split-context construction in the taint literature works precisely because it runs the opposite way: the untrusted content goes into the quarantined child, which holds no credentials, and only a narrow structured value comes back out. The pattern that launders provenance is the mirror image — untrusted content shapes the brief, and the capable child is the one that acts on it. Both are called "using a sub-agent for isolation", and only one of them isolates anything.

Two rules make the hand-off honest, and neither needs a framework change:

• Taint flows down. The hand-off payload carries the maximum trust level of everything that contributed to it. A brief derived from a fetched page is tainted, the child inherits the label, and the child's dispatcher applies the same argument-level checks the parent's would have. Without this, every delegation is a trust-level reset.
• Returns flow up as untrusted. A child's return value is a tool result, not a colleague's report. It was produced by a model that read arbitrary content, and the parent must treat it exactly as it treats any other untrusted string — which in particular means a child cannot authorise the parent to do something, however confidently it phrases the recommendation.

Budget and termination are inherited by nobody.

The remaining two inheritance channels are cheaper to fix and produce most of the operational pain.

• A parent step limit does not bound a tree. "Maximum 30 steps" on the orchestrator means thirty of its own turns, each of which may spawn a child that runs forty. The bound you need is on the whole tree, enforced by a counter passed down and decremented, not by a per-agent constant.
• Spend has to be a shared, debited budget. Give the run one token and cost allowance, pass a handle to it, and have each child debit it — so an unexpected fan-out degrades into "children ran out of budget" rather than into an invoice. Per-child limits multiply; a shared ledger does not, which is the distinction cost control in the loop turns on.
• Deadlines must be absolute, not relative. Pass a wall-clock instant, never a duration, or each level restarts the clock and a three-level tree takes three times as long as the timeout you set. This is the same defect deadline budgets describes in RPC chains, and agent trees are deeper than RPC chains.
• Cancellation has to propagate. When a user aborts or a kill switch fires, in-flight children must stop. If they hold the credentials, an orphaned child is an unsupervised actor still making writes — the worst possible combination of the previous two steps.
• Failure semantics need declaring per role. Does a dead child fail the run, or return a partial result the parent must detect? Silent partial results are how error propagation gets into a final answer with full confidence attached.

Write the delegation contract down, once, per role.

The fix is not a better framework setting; it is a short declaration per sub-agent role, reviewed like an API. Six fields cover it, and the exercise of filling them in is where the design errors surface.

# one of these per sub-agent ROLE, reviewed like an API
role: document_reader
context:     task_schema        # not "fork", not "none" — a typed brief
instructions: [policy.core]     # inherited explicitly, listed
tools:       [fetch, extract]   # allowlist; no writer in this role
credentials: none               # nothing worth stealing
budget:      shared_ledger      # debits the run's allowance
trust_out:   untrusted          # parent must treat returns as tool results

• Put every writer in its own role with its own credential. Most systems need exactly one, and discovering that is usually the largest single reduction in blast radius available.
• Log the contract with the spawn event. Role, budget remaining, trust label in, tool allowlist. Without it, credit assignment has nothing to work with, because you cannot reconstruct what a child was allowed to do after the fact.
• Test the contract, not just the behaviour. An assertion that the reader role cannot reach a write tool is a unit test that keeps passing as prompts change; a hope that it will not is not.