01 / The operating case
What changes in a real workflow?
A parent may approve $25,000 of invoice releases. Two children each attempt $20,000 at the same time.
- 01Origin grant
- 02Parent agent
- 03Narrow child grant
- 04Action boundary
02 / Decision contract
What the executor must check
Reserve value atomically against the same budget identifier before execution; settle or reconcile reservations after uncertain outcomes.
Architecture review / negative test
Make the boundary testable.
A shared budget must be consumed atomically or reserved before the protected effect. Define units, currency, scope, parent identifier and reconciliation after unknown outcomes. Merely placing the same numeric limit on each child does not create a shared ceiling. Consider whether an approved amount is per transaction or aggregate.
03 / Failure and evidence
What goes wrong, and what can be proven?
Giving each child an independent $25,000 limit converts one authorization into $50,000 of effective spending.
Record reservation, decision, executor result, reconciliation and remaining balance.
04 / Canonical scope
Why this reference stands alone
Sub-agent permissions covers per-child scope; this page owns aggregate concurrency and accounting.
Technical deep dive
Concurrency is the budget test.
A per-child ceiling is not an aggregate ceiling. The budget owner must decide whether a reservation, an atomic decrement, or a preallocated partition protects the parent limit. The decision cannot be separated from the effect by an unlimited queue: a committed action must consume capacity, while an uncertain downstream outcome must hold its reservation until reconciliation. Give every budget a unit, scope, ancestor and expiry so unrelated workflows cannot share or double-count it.
Parent ceiling: USD 25,000 Child A requests: USD 20,000 → reserve 20,000 Child B requests: USD 20,000 → DENY (5,000 remain) A times out after submit → reservation stays held Reconcile provider result before release or retry
Run the negative test
Run the two requests simultaneously against the same budget identifier and inject a timeout between provider commit and response. The sum of committed and unresolved reservations must never exceed the parent ceiling. A retry must reuse the original operation identity rather than creating new capacity.
Continue to Idempotent retries for the adjacent boundary.
Architecture field test
Shared limits need atomic reservation
Can parallel children exceed one origin grant?
- 01Define origin-wide budget
- 02Intersect child scopes
- 03Reserve at common authority point
- 04Reconcile before release
Work the boundary
An origin grants up to $25,000 of invoice releases. Child A requests $20,000 and child B requests $20,000 simultaneously. A successful atomic reservation for A leaves $5,000; B must be denied despite its individual ceiling.
| Required facts | Origin grant, shared budget ID, child action ID, amount, reservation state and provider outcome. |
|---|---|
| Allow only when | An atomic reservation fits the remaining budget and the individual child grant also permits the action. |
| Deny when | Two children independently read the same balance and both spend it. |
Break the assumption
Race both requests, then lose A’s provider response. Hold A’s reservation until reconciliation shows whether the payment committed. Releasing it on timeout could allow an unintended second payment.
Design tradeoff
A central reservation point costs coordination and may reduce availability. Partitioned budgets are possible only when aggregate ceilings remain provable across partitions.
For shared limits need atomic reservation, consult NIST NCCoE agent identity and authorization concept. This worked decision and negative test are ProofGrid analysis.
Continue with Multi-agent authorization.
Primary references