Agent processes

A replacement worker resumes the process its predecessor ran

When a worker exits, its OS PID and local memory go with it. The process identity, checkpoint, and operation keys stay with the host.

Worker a connects with a credential that selects process p, checkpoints revision 4, and calls publish-report-42, which the kernel admits, dispatches once, and retains. After a exits, the host issues a new credential for the same process. Worker a′ reads revision 4 and resolves publish-report-42 by its original identity, receiving the retained outcome instead of a second dispatch.

Reusing that key after a crash resolves the original call; reusing it with changed arguments conflicts. The host binds each credential to one process and reconstructs the request from its persisted capability, and the kernel still decides admission, dispatch, guard evaluation, and the signed receipt.

Read more in Calls & Recovery.

A process sits between the node that hosts it and the swarm that delegates to it

A node owns listeners, the kernel service, and operator state. An agent process owns worker identity, parentage, its checkpoint, logical-call keys, and the application's attempt plan. A swarm owns a delegation graph and the coordination across its actors. One node hosts many processes, a swarm can span nodes and operators, and a process can belong to a swarm without a swarm becoming an OS process tree.

A model turn or a graph task defines no new process by itself. Keep one identity for work that shares authority, call history, and recovery, and create children when delegation and an independent lifecycle belong to the application. Children run in a tree under one root grant, and cancel and revoke cascade through it.

Each retained record answers one question the replacement asks

The records are separate on purpose. A saved checkpoint does not prove that an external effect occurred, and a worker exit does not prove that an application result is correct.

• Identity and signed ancestors, restored by the host: use the delivered connection and mint no replacement identity.
• Logical calls and receipts, held by the host and kernel: resolve the original key with the exact request.
• Checkpoint and immutable blobs, in the process store: compare-and-swap revisions hold progress, and process-owned blobs hold larger data.
• Pending mailbox messages and claim history, in the native mailbox: resume polling and claims with the retained identities.
• Attempts, joins, and dependencies, in the runner journal: respect remaining attempts and recorded waits.
• Model planning and graph state, in the adapter or application store: keep original messages, turn ids, and provider settings.
• External document or service state, with the effect's owner: verify the current assignment and reconcile unknown outcomes.

An operator reads retained state without starting a worker

chio process state authenticates as no worker and starts no tool server, so the process keeps its revision and its call count.

chio process state --state .chio --process a

{
  "schema": "chio.process.application-state.v1",
  "process": "a",
  "data": {
    "checkpoint": {
      "revision": "1",
      "value": {
        "report.v1": {
          "completed": [
            "one"
          ]
        }
      }
    }
  }
}

Process a belongs directly to root and retains revision 1. In the same exercise its inspect response reports thirteen of the tree's 32 shared logical calls used and five blobs holding 28,517 logical bytes under a 64 MiB limit, which lets an operator tell progress from remaining capacity. Its running state describes durable admission, not a live OS worker.

Inspect restores no Python locals, JavaScript promise, open database transaction, or provider stream. The replacement rebuilds its next step from retained application state, which keeps the failure path readable and testable.

Read more in Checkpoints & State.

Choose a process when the work itself must own recovery

A report handed from Python to Node, an agent that publishes after several model turns, and a coding session that must keep a selected source commit all need a persistent actor. A one-shot MCP client that owns its session may need only mediated tool access, and a graph application can keep its control flow and checkpointer while its tools move to a process-backed node. Choose an agent integration compares the routes by who owns recovery.

Workers can be Rust, TypeScript, or the mixed Python and Node starter, under the same identity, permission, and recovery rules. Security stays the reference for admission, verified launch, and OS confinement.

Every Agent Processes page, in the order you build

1. Start and Connect. Run Your First Process stops a worker and keeps the handoff, Rust & TypeScript Workers rebuilds the workers, Identity & Authority gives each worker a durable name and only the authority its part needs, and Host & Worker Protocol connects a worker to its own process.
2. Run Durable Work. Supervise an Application declares order, attempts, and failure policy, Calls & Recovery keys each tool call, Checkpoints & State saves progress under a revision, Mailboxes & Shared Work hands work between processes, and Shared Resource Ownership refuses a write from a reassigned worker.
3. Operate. Operate & Move a Host inspects, cancels, rotates, and relocates a host, and Embed a Rust Host runs the kernel and process runtime inside your binary.

Next: build a report that survives interruption