Choosing inherited or fresh context for concurrent subagents

Goal

Status as of 25 October 2026. Choose what a concurrent child receives and what its parent accepts back. Re-check the runtime's inheritance behavior, permission boundaries and negotiated protocol before applying this proposed procedure. It addresses the decision to copy context, rather than the general structure of a handoff brief.

Prerequisites

Identify a bounded deliverable, its acceptance condition, the current task revision and the parent responsible for integration. Establish whether starting a child copies conversation text, shares mutable files, inherits credentials or does some combination. Inspect these separately; the label “fork” is insufficient evidence of isolation. Provide an authorized location for evidence too large for a return message.

Steps

1. Check whether delegation helps. Keep tightly dependent work with the parent when the child would need continuous updates to make progress. Delegate a question whose result the parent can evaluate independently, with an explicit boundary on writes and external actions.
2. Choose inherited context for dependent reasoning. Use it when the child needs the sequence of decisions and exceptions already established. Record the snapshot's task revision and restate the current objective, superseded assumptions and permitted actions. If the runtime cannot exclude sensitive history, choose a fresh conversation with selected material instead.
3. Choose fresh context for independent work. Supply the question, authoritative inputs, constraints and acceptance condition without the parent's proposed answer when seeking an independent review. For an illustration, a parser review needs the format contract and relevant code; a continuation of a difficult diagnosis may also need the reasoning that ruled out earlier explanations. Neither choice should silently expand permissions.
4. Separate conversation, task and trace identifiers. The A2A specification uses context identifiers to group interactions and task identifiers for units of work. Its historyLength parameter bounds returned message history; it does not define a local conversation-fork mechanism. Record the parent's revision separately. OpenTelemetry context propagation correlates telemetry across execution boundaries; use that correlation alongside application task identifiers, without treating it as a copy of the conversation.
5. Bound the result before starting. Request a disposition, concise findings, evidence references, artifact revision, checks performed and unresolved questions. Set a response budget appropriate to the parent's remaining context. Keep detailed output in the authorized evidence location, with enough information to retrieve the relevant passage.
6. Reconcile before accepting. Compare the returned task revision with the current objective. Inspect decisive evidence and validate the artifact. If the objective changed, classify the result as still applicable, needing revision or superseded. Retain a useful partial result without presenting it as completed work.

Expected result

The parent receives a result it can evaluate without replaying a transcript. Each child has an explicit context choice, authority boundary and evidence trail. A late response remains attributable to the instructions under which it was produced.

Limits and test basis

This is an untested operational proposal. Neither a fresh conversation nor inherited context guarantees independent judgment or correct execution. Exercise both paths with a harmless fixture: change the parent's requirement while a child runs, and verify that the old result is identified before integration. No measured context savings are claimed.