Feature hasn't been suggested before.
Describe the enhancement you want to request
A subagent that hits a decision its dispatch prompt does not resolve has two options: guess, or fail. It cannot ask the agent that spawned it.
The question tool goes to the human, which is wrong for most of these — the parent has the context, and interrupting a person for something the orchestrator already decided is worse than useless during unattended runs.
This shows up constantly in practice: a subagent finds the target file already modified, or two valid approaches with no stated preference, or a blocked operation with an obvious workaround it is not sure it is allowed to take. All of those are cheap for the parent to answer and expensive to get wrong.
The same gap exists in the other direction — a parent watching a subagent drift has no way to correct it, though that is arguably a separate concern.
Suggested behaviour
A message tool for parent↔child communication, distinct from the human-facing question tool: a child can ask and block for an answer, or send a fire-and-forget status update; the parent replies with the same tool.
Two things make this harder than it looks:
- During a foreground dispatch the parent's turn is parked waiting on the Task tool result, so there is no live parent turn to answer from. If the child also blocks waiting for the parent, they deadlock.
- A blocked child must be bounded — a reply that never comes has to time out into "proceed without an answer" rather than hanging the dispatch.
Authorization matters too: a reply should only resolve for the parent recorded at send time, and resuming a subagent by id should verify the target actually is the caller's child.
Version
v1.18.5
Additional context
PR #38942 implements this (behind an experimental flag). #38943 extends it to sibling↔sibling messaging.
Feature hasn't been suggested before.
Describe the enhancement you want to request
A subagent that hits a decision its dispatch prompt does not resolve has two options: guess, or fail. It cannot ask the agent that spawned it.
The
questiontool goes to the human, which is wrong for most of these — the parent has the context, and interrupting a person for something the orchestrator already decided is worse than useless during unattended runs.This shows up constantly in practice: a subagent finds the target file already modified, or two valid approaches with no stated preference, or a blocked operation with an obvious workaround it is not sure it is allowed to take. All of those are cheap for the parent to answer and expensive to get wrong.
The same gap exists in the other direction — a parent watching a subagent drift has no way to correct it, though that is arguably a separate concern.
Suggested behaviour
A
messagetool for parent↔child communication, distinct from the human-facingquestiontool: a child can ask and block for an answer, or send a fire-and-forget status update; the parent replies with the same tool.Two things make this harder than it looks:
Authorization matters too: a reply should only resolve for the parent recorded at send time, and resuming a subagent by id should verify the target actually is the caller's child.
Version
v1.18.5
Additional context
PR #38942 implements this (behind an experimental flag). #38943 extends it to sibling↔sibling messaging.