Give agents responsibility
and room to act.

Autonomy lets an operator assign a responsibility without prescribing every action needed to fulfill it. An agent can investigate, choose an approach, and request help within a defined mandate. Chio separates those planning choices from the authority to act, so an application can give agents useful responsibilities while keeping resource decisions enforceable outside their reasoning.

The grant bounds which choices may become effects. It names the subject, the tools and operations, the lifetime, and the supported constraints. The receiving system evaluates each request against that authority and its configured controls. A task tells an agent what to pursue. A grant establishes what it may do. The agent chooses its approach within that grant.

The retry-patch example requires two contributions: a risk review and passing checks at the delay cap. The analysis worker can read the candidate; the test worker can run its tests. Neither grant includes publication, so the owner can accept useful work from both without handing either worker the right to release it.

Delegation lets work branch without copying every privilege of the parent. A coordinator can remove tools, reduce allowed invocations, shorten expiry, and tighten supported constraints. Each child carries the scope its own contribution needs.

The child also carries its lineage. Each link in a delegated grant’s chain records the ancestor’s capability id, the delegating and receiving keys, how the scope narrowed at that step, and when, and the delegator signs it. Before it admits a delegated grant, the kernel also requires a stored snapshot of every ancestor and refuses a chain whose ancestors it cannot find or whose recorded depth or parent disagrees. That lineage is what later lets a branch of the team be ended as a unit.

The receiving evaluator must establish the narrowing under the selected delegation model. The complete delegated-worker application uses one-hop child credentials, records an attempted scope expansion, and shows a worker refused another worker’s tool. Recursive teams need a fuller account: Chio’s swarm authority model checks a signed graph with the required scope witnesses, routes, budgets, and revocation evidence. The one-hop illustration does not implement that recursive verifier.

An engineering team can assemble a tested candidate while publication remains a separate decision. In the local specimen, the candidate becomes ready for owner review only when the analysis and the passing edge assertions are both present. The test computes the supplied function over explicit inputs; it does not execute a repository or deploy a patch. A reviewer should see the actual target and parameters being authorized. If the action changes, the application needs authorization for the changed action.

That leaves an agent three useful responses: proceed within the mandate, present a specific decision to its owner, or choose another permitted approach. A refusal can improve the plan. Retrying the same request does not create permission.

Autonomy is useful when an agent can act on a clear mandate and recognize when it needs a different one.

Resource use belongs in that mandate too. A per-call ceiling limits a request; it does not reserve shared money across sibling workers. A team that consumes a common allowance also needs its selected budget authority and accounting state.

A system can change its team while retaining the work each member contributed. Revoking the analysis grant refuses its next read. The test worker continues under its own grant, and both earlier contributions stay visible. A worker’s current authority and the work it already did are separate records, and revocation changes only the first.

The kernel draws the same line. Revoking a grant writes one id to the revocation store; nothing is sent to the grant’s descendants and nothing about them is edited. The branch closes at admission. The kernel checks the presented grant’s own id, then walks its delegation chain and asks the store about each ancestor. The revoked grant is refused with CapabilityRevoked; a descendant is refused with DelegationChainRevoked, naming the ancestor where the walk stopped. Its parent and siblings carry no revoked id and keep working.

Revoking the coordinator stops new calls from the whole team. Revoking the reader stops only that branch. Calls admitted before revocation remain in the record.

Revocation does not undo an earlier effect. A published report stays published until a separate authorized action changes it. The store has no operation that reverses a revocation either, so a closed branch resumes only through a new grant from a live ancestor. Keep the earlier records, reconcile unfinished work, and issue the replacement with its own scope. The replacement is a new decision with a new history.

A revocation takes effect at each verifier that has observed it; it is not a message that reaches every disconnected recipient at once. A verifier’s revocation state is therefore part of its authority, and it needs the trust and freshness the deployment requires. In the captured federation run, a kernel with no trusted snapshot denies the call, a fresh verified snapshot that does not list the capability admits it, an incomplete subject list is refused before installation, and a rollback or stale root is refused. Expiry, missing evidence, and unavailable revocation state each need an explicit admission response of the same kind.