Problem it solves
Orchestrators spawn subagents during execution without surfacing this to the user. The user consented to the orchestrator but not to the specific new agent being created.
When to use
Every time an orchestrator spawns a new subagent during a live run that was not part of the originally disclosed topology.
When not to use
For subagents that were part of the pre-run disclosed topology and already consented to.
Governing principle
Spawning a new agent is a consent event, not an implementation detail. The human's original consent does not extend to agents that weren't in the original disclosure.
Required Components
Interaction Flow
Orchestrator requests subagent spawn
During execution, the orchestrator determines it needs to create a new agent not in the original topology.
Execution paused
The orchestrator halts at the spawn point. The new agent is not created yet.
Spawn-Time Consent Gate appears
The gate shows what new agent is being proposed, what it will be authorized to do, what data it will access, and how it relates to the current run.
User reviews and decides
The user approves the spawn (with or without scope modification), declines and allows the run to continue without that agent, or aborts the run entirely.
Decision logged
The spawn request, the gate contents, and the user's decision are all logged.
Run continues
If approved, the new agent is spawned with the consented scope and joins the network.
Governance requirements
Every spawn event must be logged, regardless of whether the user approves. Approved spawns must record the consented scope. Declined spawns must record what agent was blocked.
Accessibility notes
Spawn-time gates must use role="dialog" with aria-modal="true". The gate must receive focus on open and trap focus until closed with a deliberate decision.