Skip to main content

Agent Runtime

The Agent Runtime executes agent work. Its defining property is that execution is durable, signed, and externally replayable: state survives a process death, a peer cell can resume a dead coordinator's work, and an outside auditor can re-execute a run from its recorded inputs and verify the result. Most agent frameworks lose their state when the process dies and cannot prove afterwards what happened.

This page covers the durable journal, resumption, external replay, the sandbox an agent runs inside, autonomy controls, placement, and the on-device runtime that mirrors all of it at the edge.

Durable execution​

Every workflow node writes journal entries through a write-ahead log:

  • intent → executing → completed / failed entries, each carrying an input hash, an output hash, the executing cell, and a cell-identity signature;
  • an audit chain over the journal, plus a lineage context, index, and query;
  • budget leases and a budget bridge, so spend is reserved against the run;
  • a permission gate on the run, run recovery, and a run purger.

Because the journal is persisted and replicates rather than living in the conversation, a run keeps a durable plan, a run that restarts, or is picked up by another cell, reconstructs its plan instead of starting over. Runs can be cancelled and resumed.

Resumption​

A lease with compare-and-swap renewal governs which cell owns a run. If the coordinator dies, a peer cell acquires the lease and resumes from the last completed journal entry rather than replaying the whole workflow. Cross-cell handoffs travel as signed envelopes through an envelope chain store, so a run that moves between cells carries its authority with it.

External replay​

The recorded inputs, output hashes, and signatures are not only for recovery, they make a run verifiable by a third party:

An external auditor with read-only access can re-execute a workflow from its recorded inputs and verify every output hash and cell-identity signature.

This is verification against the record itself, not a claim in a log. The same discipline runs through the platform's other chains. See Security → Cryptography.

The execution sandbox​

An agent's attenuated resource budget is turned into an enforceable sandbox specification and a per-platform launch command:

PlatformSandbox mechanism
Linuxbubblewrap
macOSSeatbelt
WindowsJob Object + AppContainer

The sandbox is the boundary a leased sub-agent runs inside, carrying that agent's cryptographic allowed-tools ceiling, so two agents in the same run can hold genuinely different powers. The governed tool surface is what the agent reaches through that boundary.

Memory, reasoning, and self-knowledge​

The runtime gives an agent more than a context window:

  • Memory typed as episodic, semantic, procedural, and working, with an embedding pipeline, retrieval, consolidation, time-based decay, contradiction detection, and a trust scorer that weights by source reliability.
  • A working-set manager with an explicit compaction policy, so long-running work has a managed context rather than an overflowing one.
  • Reasoning: goal decomposition into dependency-ordered subgoals, strategy selection and learning from outcomes, plan execution with checkpoint/resume and rollback, and post-execution reflection.
  • Self-introspection: an agent can inspect its own state and query a model of the platform it runs on, so it can answer what am I, what may I do, what have I spent, and what mode am I in.

Autonomy controls​

The runtime bounds how much rope an agent has, and who holds it:

  • Loop and goal control. A governed loop controller drives a step function until a done-predicate holds, bounded by a maximum iteration count and a budget guard. The caps are governed quantities derived from the capacity model, not arbitrary constants.
  • Triggers. Data-arrival and metric triggers let an agent start itself, but an automatic start is still a gated act.
  • Human approval is a first-class node type, with quorum-based authorization and two-person confirmation where the action warrants it.
Permission modes are an advisory UX layer

The allow / deny / ask rules in the chat cockpit decide whether to auto-run a tool, ask the user, or refuse, but state this honestly: it is an advisory UX gate. The hard gates, the net-potential-gain gate, the per-agent tool allowlist, and role-based access control, are unchanged and still decide every consequential call. The convenience layer cannot weaken the security layer.

Placement​

Where a run executes is a governed decision. Placement scores candidate cells on topology and clearance as hard constraints, a workflow cannot execute on a cell below the required clearance, before it scores GPU availability, model availability, data locality, and cost, penalised by load.

The runtime at the edge​

The Edge Agent carries a behavioural mirror of this runtime on the device:

  • an agentic operator loop that turns the agent from a telemetry daemon into something that can be given an objective;
  • a governed execution sandbox mirroring the core's tier model, so local work still runs under policy;
  • a four-layer permission gate every tool call passes, with execution through one runaway-guarded primitive, argv, never a shell, so there is no injection surface, carrying an inherited timeout, an output cap, and a scrubbed environment; and
  • a formally-grounded policy engine that evaluates authorization on the device with no network round-trip, so an offline device still enforces policy. Customer policies can restrict but never loosen platform defaults.
How the edge runtime is validated

The on-device runtime is validated in-crate, and the two-runtime parity fixtures assert that the edge and the core make the same decision for the same input. That is what keeps the contract honest across both implementations.

See also​