Topics
Agent-to-agent delegation: keeping authority inside the chain
Agent-to-agent delegation is the pattern where one AI agent invokes another to carry out part of its task. An orchestrating agent breaks a goal into subtasks and hands each to a specialist agent, which may in turn spawn others. The chain can be several hops deep, and the agents at the bottom of it may have been created seconds ago and will be gone when the task completes.
This pattern is how agent systems scale, and it is also where authority is most likely to drift beyond what any human intended.
The tracing problem and the bounds problem
There are two distinct problems here, and most discussion covers only the first.
The tracing problem is knowing that Agent A was authorized by a human, that A invoked B, and that B invoked C. When the relationships are known and mapped, the chain can be traced back to the original human. Inventory and mapping tools work on this problem.
The bounds problem is different. Knowing that C's authority derives from A's does not prove that everything C is capable of doing falls within what the human originally granted. Every delegation is an opportunity for authority to expand, combine, or drift. Two agents each holding a narrow authority can, between them, accomplish something neither was authorized to do alone. A subtask agent given its parent's full grant holds far more than the subtask requires.
Tracing tells you how the chain is connected. It does not tell you whether the authority exercised at each hop is still inside the bounds that were set.
Attenuation: authority may narrow, never widen
Our position is that a sound delegation model has one non-negotiable rule: each hop may narrow authority and may never widen it. The orchestrator holds a slice of the human's authority. The specialist it invokes holds a slice of the orchestrator's. The agent at the bottom of the chain holds exactly what its subtask needs and nothing that was accumulated on the way down.
This is possible in principle in most systems. It is not what happens by default, and it is not what inherited-permission models deliver. Under inheritance, the tenth agent in the chain holds exactly what the first one holds.
Check against the policy, not against the parent
A second rule follows. The check at the point of action should evaluate against the governing policy, not merely against whatever the parent agent happened to hold. If the check is "does C hold less than B," then a chain that started too wide stays too wide all the way down. If the check is "is this action within the refund policy the support director owns," then the chain's history is context, and the policy is the boundary.
The chain still matters. It is recorded, it is visible to the check, and constraints can be applied to it: no more than this many hops, no delegation to agents outside this set, cumulative ceilings shared across the whole chain rather than reset at each hop. But the authority itself lives in the policy.
Cumulative ceilings across a chain
One specific failure is worth naming. If a daily refund ceiling is enforced per agent, and the orchestrator spawns ten refund agents, the effective ceiling is ten times what the policy said. Cumulative constraints have to be ledgered at the level of the delegation, so that every agent operating under the same grant draws down the same ceiling.
Accountability in a chain
When the agent at the bottom of a chain makes a bad decision, who answers for it? Under the inheritance model, the record says the human at the top did, even though they never saw the chain. Under a policy model, the record says the decision was made under the refund policy, which the support director owns, by an agent four hops from the workflow the human started, with the full chain attached. The director is accountable for the policy. That is a defensible thing to hold them to.
Where BotAris fits
BotAris records and evaluates the delegation chain as part of every authority check. Constraints can apply to the chain itself, cumulative ceilings are ledgered at the delegation level rather than per agent, and every decision in the ledger carries the chain that led to it. The authority checked against is always the human-owned policy in the Authority Model.
Frequently asked questions
If I can trace an agent chain back to a human, is the chain governed?
Traceability answers who is connected to whom. It does not answer whether the authority exercised at each hop stayed inside the original grant. Governance requires the second.
Should a spawned agent inherit its parent's permissions?
Our position is no. It should receive the narrowest slice of authority its subtask requires, and the check should be against the governing policy rather than against the parent's grant.
How do you stop agents from splitting one large action into many small ones across a chain?
With cumulative ceilings ledgered at the delegation level, so every agent operating under the same policy draws down the same total, regardless of how the work is split.
