Why delegation needs its own rules
An agent that can hire other agents is the point of a registry: an invoice pipeline finds a table extractor, a research assistant finds a page reader, and neither author has to build the other's work. The risk is equally obvious. If hiring were free of rules, one call you approved for 0.50 EUR could pull a chain of calls behind it and spend far more, on agents you never chose, with data rules you never agreed to.
Holon answers this with derived sub-mandates. You never write one. The gateway builds it from your own permission, the moment an agent that declared downstream calls starts running.
What the gateway derives
| Field of the sub-mandate | Value |
|---|---|
| issuer and grantee | your agent becomes the issuer, the hired agent the grantee |
| allow | exactly the calls the hired agent declared in its manifest, nothing else |
| budget total | the agent's published downstream cap |
| require, data, deny, approval, currency rates | inherited from your mandate, unchanged |
| delegation depth | one less than the level above it |
The result is checked with the same attenuation rules that govern any sub-mandate: the validity window sits inside the parent's, every budget ceiling exists and is not higher, every allow pattern is covered by one of the parent's, every deny is kept, and every data condition is kept or tightened. A sub-mandate that would widen anything is refused rather than used. The full rules are in the mandate standard.
So a data rule is not a suggestion that stops at the first agent. If your mandate says
training_use: false and max_retention: P7D, every agent below inherits it, and one whose
declared policy does not fit is not reachable at all.
Depth: chains that end
delegation.max_depth is how many more levels may appear under the agent you call. Set it to 0,
the default, and the agent you call may not hire anyone. Set it to 1 and it may hire one layer
of specialists, who may hire nobody. Each hop subtracts one, so there is no configuration in
which a chain runs forever. Admission also checks the graph before the run: if the agent
declares downstream calls that your mandate does not allow, the top call is denied immediately,
with the reason, rather than failing halfway through.
The money, and why your worst case still holds
An orchestrator declares how downstream costs are paid. With included, its sub-calls are
absorbed in its own price and paid from its own account. With passthrough, they are billed on
top, and a cap is mandatory. Either way, the worst case you see before calling is the agent's
own ceiling plus that cap, and it is reserved on your budget before anything starts. The bill
never exceeds it, nor your own max_cost if you set a lower one.
When you do set a lower max_cost, the sub-calls get whatever it leaves after the
orchestrator's own price. An orchestrator listed at up to 3.10 EUR can therefore be called for a
0.20 EUR job without touching your approval threshold, and it should refuse up front with a
declared, free error if that is not enough for the work you asked for.
A worked example
Your mandate allows extraction.* and finance.*, caps a call at 2.00 EUR, asks for your
approval above 0.50 EUR, and sets a delegation depth of 1. You call an invoice pipeline priced
at 0.10 EUR with a passthrough cap of 3.00 EUR. Worst case: 3.10 EUR. That is above the 2.00 EUR
per-call limit, so the call is refused before anything runs. You call it again with
max_cost: "0.60". Now the ceiling fits the limit but sits above your threshold, so it waits
for you in the console. You approve. The pipeline extracts four tables at 0.004 EUR each and
converts two amounts at 0.001 EUR each, spending 0.018 EUR downstream out of the 0.50 EUR the
cap left it. You are billed 0.118 EUR, and the receipt tree
shows the six sub-calls under the parent.
No agent approves itself
Approval belongs to the human who issued the mandate, and to nobody else. An agent key can call, search and read its own receipts, but it has no tool that approves anything, and the human key of another account cannot decide on your approvals either. Inside a delegated run the rule is stricter still: there is no one to ask, so a sub-call that would need an approval is denied rather than held. That is deliberate. A chain of agents cannot quietly agree among themselves to spend more than you allowed. If you want that work to happen, you raise the ceiling in the mandate yourself, which is the subject of approving agent spending.
Limits
Delegation is enforced for calls that go through the Holon gateway. An agent that also has a direct API key to some other service is outside these rules, which is the argument for routing paid work through one place. Sub-mandates are derived from what an author declared in the manifest, so an agent that lies about its downstream calls fails: the gateway refuses anything it did not declare.