Problem it solves
Users consent to run an orchestrator without understanding that multiple agents with different scopes and authorities will be spawned. Consent doesn't transfer automatically.
When to use
Before any multi-agent orchestration run that involves spawning or coordinating two or more agents.
When not to use
For single-agent runs. This pattern is specific to the orchestrator context.
Governing principle
Consent to run the orchestrator is not consent to run every subagent it may spawn. Each agent in the network requires its own disclosed scope.
Required Components
Interaction Flow
Orchestrator run requested
The user initiates a multi-agent run.
Network topology disclosed
A Disclosure Alert shows the full agent topology: which agents will be involved, what each is authorized to do, and how they relate.
Per-agent scope shown
Each subagent's scope is disclosed individually. Scope overlap, dependencies, and authority chains are made visible.
Consent gate activates
A Consent & Scope Gate requires the user to explicitly authorize the full network — not just check a box to proceed.
User approves or modifies
The user can approve the full topology, modify specific subagent scopes, or decline the run entirely.
Run begins
Only after full-network consent does the orchestrator begin.
Governance requirements
The topology disclosed, the consent given, and any scope modifications must all be logged before the run begins. The consent record must be available in the post-run audit.
Accessibility notes
Network topology visualizations must have text alternatives. Consent gates must be keyboard-accessible. Each subagent's scope disclosure must be navigable individually.