Let independent systems
work together.

Agentic operating systems can cooperate across companies. One organization can contribute knowledge or services to another’s work while retaining its own models, infrastructure, and resource decisions. A shared job becomes a relationship between independently controlled systems, with explicit terms for what crosses each boundary.

Chio supplies the authority and evidence contracts for those exchanges. Each company chooses which peers and issuers it trusts, exposes selected work, and admits requests under its own controls. Delegated authority and signed records give the participants something precise to enforce and inspect at each handoff.

A shared incident illustrates the relationship. The customer supplies evidence of a failure; a specialist receives selected diagnostics and proposes a repair. It never acquires a provider deployment grant. The provider evaluates the repair under its own controls, and the customer checks whether the service recovered. Each decision stays with the organization that owns the resource.

The trace, proposal, and operation evidence cross different organizational boundaries. Each exchange names a sender, a receiver, and a bounded payload; the remaining information stays with its owner. The customer can disclose a diagnostic bundle without exposing every customer record. The provider can accept a proposal without giving away its production credentials.

A useful handoff also names the requested operation, the authority it requires, an acceptable result, and the evidence of completion. For a metered service, it names who owns accounting and which settlement profile applies. An authenticated connection and a cost ceiling do not supply cross-company escrow, so a handoff that needs escrow has to arrange it separately.

Write these responsibilities into the downloaded handoff worksheet in terms both operators can inspect, then map them to the protocol and records the application uses. The worksheet is a design note for that mapping; it defines no wire format.

The first proposal raises both the invoice and the export timeouts. The disclosed trace concerns only invoices, so the provider asks for a narrower change. The revision raises the invoice timeout from 1,000 to 5,000 ms and leaves exports alone. The provider’s refusal narrowed the proposal before approval.

The customer then compares its 3,600 ms request with the applied limit. A second observation at 6,200 ms can still fail, even though the provider applied the repair successfully. Disagreement and incomplete recovery are ordinary states of the undertaking: each participant knows which work can proceed independently and which step waits on someone else’s decision. A revised proposal returns to that decision boundary instead of inheriting the old authorization.

A shared application can combine contributions from several companies while each company authorizes its own part. Signed task and governance artifacts can name those contributions and their required commitments. Where bilateral co-signatures are required, both kernels sign the same canonical bytes, and one participant’s signature cannot replace the other’s.

A contribution can cross an organizational boundary while authority over the underlying resource stays put.

For each request, the receiver applies the current trusted state required by its admission rules. Past cooperation does not satisfy those checks. Ending participation means attending separately to outstanding grants, existing sessions, unfinished work, and retained records.

Revocation shows what current trusted state has to mean. In the federation guide’s captured run, an authority signs epoch roots over the capabilities it has revoked, and a bounded receiver installs a root into the kernel’s revocation view only when four conditions hold. The signature verifies. The root is at most 5,000 ms old. The key set delivered with it rebuilds exactly the signed root. Its epoch is strictly greater than the installed one. Each condition closes a specific gap: without the rebuild, a receiver could install a subject list the authority never signed, and without the epoch order, a replayed older root could restore a revoked capability.

Before any root arrives, the kernel denies: its view holds only an empty sentinel issued at time zero, and the kernel will not consult a snapshot that old, so silence from the authority never reads as permission. Revocation does not reverse earlier execution. The call admitted under the first snapshot ran once; after the second snapshot, the same call is denied and the handler count stays at one.

A requester’s timeout leaves acceptance, authorization, execution, and result retention unresolved. Each requires evidence from the peer.

Use the operation’s supported status, reconciliation, or recovery path before submitting equivalent work again, and preserve the uncertainty until evidence resolves it. Local independence remains valuable during an interruption, but it does not make another participant’s unknown result disappear.

Revocation refuses new admissions. It does not undo an effect that already happened, recall information already disclosed, or settle work already in flight. The captured receiver rebuilds the full accumulator from the supplied key set and uses capability IDs as its explicit subject namespace; large or persistent deployments need their own durable authority history, authenticated delivery, and restart recovery.

None of these mechanisms supplies cross-company escrow or resolves a disputed result, and the local captures do not qualify an arbitrary multi-company deployment. Agreements, accounting, and each operator’s own controls remain work every company does for itself.