[FEATURE]: No control over what enters or leaves a Task dispatch

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

A Task dispatch has no levers over its own context economy. Four gaps, all measurable on a long orchestration session:

Returns are prose. A subagent's result comes back as free text, so a parent that wants a structured answer has to parse it out of the model's writing. There is no place to put a machine-readable result.

Completion frames rewrite the cache tail. A background child's full output is injected into the parent as a user message. Because that lands at the end of the context, it invalidates the cached prefix — so every completion costs a re-upload proportional to how verbose the child was. Measured across two sessions: 80–173 cache-bust events of ≥1K tokens each, dominated by multi-KB completion frames. The child session is durable and readable by id, so the full text in the frame is redundant for a parent that only needs the verdict.

Every dispatch carries the full instruction set. A scoped execution subagent receives the global instruction files, the skills catalog, and the MCP tool docs — thousands of tokens it will never use on a one-file edit. Worse than the cost is the dilution: the actual task instructions compete with guidance for work the subagent cannot do.

An idle child cannot be reached. Once a subagent goes idle it stays idle until the parent explicitly resumes it, so any message that arrives in between waits. For coordinator patterns this forces a poll loop or a parent-mediated relay.

Suggested behaviour

Four opt-in controls, each defaulting to today's behaviour:

• a way for a subagent to set a structured result on its own session, surfaced in the completion frame and event
• a terse completion mode: digest plus a pointer to the child session, instead of the full body
• a sparse context mode that drops the global instruction/skills/MCP blocks — and skips assembling them rather than building and discarding
• an opt-in wake for an idle child when a message lands, budgeted so it cannot spin

Terse and sparse are session/agent properties as much as per-call ones, so they want a config precedence chain rather than being dispatch-only.

Version

v1.18.5

Additional context

PR #35400 implements these. Wake-on-message depends on the messaging primitives in #38963/#38964; the other three are self-contained.