Delegation that narrows as agents collaborate.
Coordinate parent agents, child agents and tools without allowing authority to widen through handoffs.
Can the child explain which part of the parent grant it received?
Problem → control → outcome- 01OriginOperations team
One $25K aggregate change budget
- 02ParentPlanning agent
Can partition or reserve the shared limit
- 03Child AResearch agent
Read and recommend only
- 04Child BExecution agent
Named change under remaining budget
A request outside the child grant requires a separate authorized path.
Fan-out partitions work; it does not duplicate the parent budget.
Delegation graph
A team of agents is an authority graph
A planner may distribute tasks to researchers, validators and executors. Each child needs an identity, a purpose, a bounded grant and an expiry. The relationship to its parent should be explicit. Otherwise a child with a powerful tool may operate outside the original task even while every API call is technically authenticated.
Authority propagation should be monotonic: child scope is equal to or narrower than the parent’s. A parent lacking payment authority cannot delegate payments; a child granted document review cannot sub-delegate account changes.
- Parent and child principal
- Parent grant reference
- Task-specific purpose
- Narrower scope and duration
- Sub-delegation permission
Shared limits
Fan-out does not multiply privilege
Delegating one task to several workers should not create several independent copies of a broad credential that survive after the parent task ends. Child grants should be revocable with the parent, and the system should account for concurrent actions against shared limits.
An invoice workflow may assign data extraction to one child and fraud review to another. Neither needs authority to release the payment. An executor can be given a separate grant only after the required checks and approvals are complete.
Expiry
Expiration and cancellation
A child grant should expire when its task, deadline or parent authority ends. Revocation must reach active workers, not merely prevent new ones from starting. A workflow that resumes after a pause should reassess its grants rather than reuse stale authorization.
The architecture also needs evidence of handoff: who created the child task, what was delegated, what result returned and whether any consequential action was executed.
Budget authority across concurrent agents
If a parent grant permits ten changes or $25,000 of activity, concurrent children must share that limit rather than each receiving a fresh full allowance. A design should specify whether limits are per action, per child, per workflow or across an organization. The wrong choice can multiply privilege simply because the planner parallelized work.
The graph should also survive retries and reassignment. A failed child can be replaced, but the replacement should receive only the remaining task authority and not revive a cancelled grant. Evidence of those handoffs helps explain why several agents touched the same operation.
Review the last actor and the first origin
An execution system should know which child made the final request, while an operator should be able to trace it back to the authorized human or organizational origin. Losing either end makes the decision hard to defend. A parent’s broad role name is not a substitute for a task-specific child grant.
The risk created by fan-out
A team may use a planner agent to distribute invoice review, network changes or incident response among children. Parallelism should increase throughput, not privilege. If the parent has total transaction authority of $25,000, spawning five children cannot give each a fresh $25,000. The delegated scope must remain within the parent, and shared value or operation limits must be enforced across the entire fan-out.
Possible conceptual designs include a shared remaining budget, a reservation before execution or an explicit partition assigned to each child. The correct choice depends on concurrency, retries and failure recovery. None is presented here as a shipped ProofGrid budget engine. The integration design should say which system owns the budget and how it avoids double consumption after a timeout.
A chain that can be revoked
Each child needs a trustworthy identity, parent reference, purpose, action, target, expiry and delegation depth. A child may sub-delegate only if the parent allowed it, and never beyond the remaining depth or scope. Cancellation or revocation of the parent must invalidate dependent grants at the next consequential action, even if child credentials remain technically valid.
Some operations require converging approvals from different owners, such as a business authorization and an infrastructure change window. Effective authority should be the intersection of those approvals. Crossing runtimes or tool servers must preserve the origin and limits without accepting a child’s self-reported authority. A buyer can evaluate the design by tracing one child action back to the first accountable origin and forward to its observed result.
Solutions / Next Step