Build an operating system
for agent work.

An agentic operating system gives agents a lasting environment in which to work. Applications can assign responsibilities and make shared resources available under explicit authority. Work can continue as individual workers stop, models change, and new specialists join. The operating system keeps the responsibilities and records that connect those contributions.

Chio supplies the Rust kernel around which that environment is built. The application owns the workflow and its completion criteria. Workers choose how to pursue their assignments. The host arranges durable state, credentials, isolation, and worker lifecycle. The kernel evaluates each mediated request under the authority and controls that govern access to its tools.

A research report makes these responsibilities concrete. Workers gather sources and check claims; the application assembles the result and decides whether it is ready to publish. Each contribution has inputs, effects, and a completion condition. The job needs to retain them when one worker is interrupted.

Each owner keeps its own record. The application records progress in a checkpoint: small process-owned JSON under a compare-and-swap revision, which refuses a stale writer instead of silently replacing another worker’s progress. The kernel separately retains admitted tool operations and their receipts. A stable operation key, chosen from the application task and never from a timestamp or a worker attempt, joins the two histories.

Keeping these responsibilities visible makes the system easier to change. A team can replace a model or revise its workflow while retaining an explicit execution boundary, and it can see what infrastructure is missing: a reviewer interface, a persistent store, or a defined recovery procedure.

The interruption experiment stops the worker after the first report source is retained. The process’s identity and checkpoint stay with the host. A replacement inspects the saved progress and continues the application’s work, and the first source is not collected again merely because one worker disappeared.

The logical process is not the worker that runs it. Under supervision, the runner keeps operating-system attempts separate from logical tool operations: worker attempt two can recover the receipt of a call made in attempt one. Run the same plan with the same state after an interruption and the runner reuses recorded completions, attempts, and dependencies. A changed plan cannot reset an exhausted attempt budget.

A checkpoint retains application progress. It cannot establish whether a provider performed an external operation. To recover a call, the host saves the request before sending it: every new logical call freezes its process identity, key, target, arguments, and authorization extensions before kernel invocation. A checkpoint that says only “publishing” cannot reconstruct which report or recovery policy was submitted.

The lost-response experiment publishes the completed report and withholds the response. The tool has performed an effect, but the requester has no confirmation, and its local timeout cannot establish that nothing happened.

Saved progress, recorded execution, and an accepted outcome answer different questions. The checkpoint says what the application last recorded. The kernel’s retained operation says whether the call ran and what it returned. Acceptance belongs to the application: after recovering the existing publication, the reader opens both sources, runs the named citation and calculation checks, and only then decides whether to accept the report. A tool’s successful return is evidence; the completion criteria decide whether the job is finished.

Sending the publication with a fresh operation key creates a new intent and can repeat the effect. Recover the original operation through the call and recovery contract, using the state the kernel retained before the response went missing.

Where the response was lost decides the answer. Before dispatch, the saved request is submitted under its original key. A refused call is fixed and becomes a new intent. Once the kernel retains the outcome, the worker replays the original key and verifies the original receipt. In between, after dispatch and before a retained outcome, the effect may have happened, so the kernel refuses a second dispatch and the worker reconciles with the effect owner. Only a tool declared free of side effects, under authority with no request-bound, constrained, or budget state, earns a bounded fresh attempt, and known_outcome_only withdraws even that.

A software factory turns an issue into a tested candidate and a separately authorized publication. A research swarm divides an investigation into contributions. An incident system connects a diagnosis to a provider-owned repair and a subsequent health check.

• Research / report 42Retains source material while a worker changes.
• Engineering / candidate 17Waits for its owner’s publication decision.
• Operations / incident 08Reconciles a provider’s operation record.

These jobs have different lifetimes and different completion criteria. A host can arrange their scheduling, durable storage, and shared services. Each application owns its workflow. What they share is the shape of the operating environment: named participants, bounded authority, resource access, durable records, and a path through failure.

A shared kernel lets these applications enforce authority through the same execution contract while choosing different models, languages, and orchestration. The configured host retains each process’s work. Agents can participate in an operating environment that holds responsibilities and records beyond any one application run.

The first useful system may have one worker and one tool. As it grows, add responsibilities deliberately: a new specialist with a smaller mandate, a shared resource with a named owner, a review path for a consequential decision.

The process host already draws those lines. An adaptive worker can start a child through a host-defined spawn tool; the host selects the executable and signing material, and the child receives narrowed authority. A waiting parent checkpoints, yields its worker slot, and resumes under the same process identity and attempt budget. Plans bind once, so attempt ceilings, deadlines, and failure policy cannot be changed to give a stopped run another chance.

These retained identities and authority records let a job continue across worker changes. Its results remain available for the application to inspect after any individual run ends.

Chio decides mediated calls and retains their operations and receipts. It does not decide whether a report is good, whether a candidate should ship, or when a job is complete; those criteria stay with the application. A checkpoint cannot reconstruct unrecorded reasoning or prove an external side effect. A worker’s exit code of zero proves that its program completed, not that a report was published or a patch applied. After a lost response, a resource’s own idempotency can help reconcile the uncertain window, but it cannot manufacture the kernel’s missing receipt. known_outcome_only governs Chio’s dispatch, not retries inside a model provider or tool. Direct Linux workers share the operator’s account unless an isolation profile is configured; confinement decides what a worker can reach outside mediated tools.