Implementation: ENABLED (work runtime) · DESIGN (Agency API server) · Exposure: INTERNAL · PUBLIC PREVIEW (Agency API contract). See status labels. The kernel is the system that runs agent work: it compiles a goal into typed contracts, carries the resulting Run durably across time, checks every action against policy, closes work only from verification evidence, and writes receipts. The Agency API is the public HTTP surface over the kernel; it is not the kernel itself. See Kernel and Agency API. A Run is one durable execution of a goal. It is the unit the work runtime carries across time, and it is the object the Agency API returns.

​
Architecture contract

​
What makes a run durable

  • The run is persisted before the create call returns. It does not depend on the process that accepted it.
  • Run state survives model eviction, cache loss, executor death and process restart.
  • Resume works from durable state and receipts, never from a transcript.
  • A node that was interrupted in the middle of an effect is not blindly re-run. It resumes only if the effect carries an idempotency key and a receipt. Otherwise the run raises an attention request with reason unsafe_resume.
  • Every material transition is observable as a typed event or a receipt.

​
The work-node lifecycle

A run is a graph of work nodes. Each node moves through one lifecycle:
No executor moves a node from running to done on its own. Closing a node is a system transition backed by completion evidence. VAULT and LEARN happen after the terminal state and are not shown as a run status.

​
Run status

Run.status is the aggregate of the node lifecycle and the run receipt’s completion status. There are ten statuses. partial is never a synonym for failed or unfinished. It means the caller allowed a partial result in advance and the run reports exactly which criteria passed. When nodes are in different states, the run reports the highest-precedence one:

​
Control operations

Pause, resume and cancel are asynchronous and idempotent. Effects in flight at cancel time are never silently abandoned. Each outcome is receipted and listed in Run.cancellation.effects_in_flight until it settles.

​
Attention and approvals

Agents request attention. They never notify people directly. An attention controller owns delivery, quiet hours, deduplication, quotas and escalation. A run raises an attention request and moves to needs_attention when: Each request has a kind:
  • approval is a policy ASK. If it expires, it resolves as a rejection. This is fail closed.
  • informational asks for input without gating an action. If it expires, it becomes expired with no rejection implied.
The first valid answer wins. An answer is written as a receipt before it takes effect. A hard policy deny never becomes an attention request, and an approval can never override one.

​
Budgets

A budget sets at least one of a time limit (max_seconds) or a cost limit (max_cost_usd), and may also cap executed work nodes (max_steps) and attention requests (max_attention_requests). On exhaustion the order of operations is fixed:
  1. The platform hard-stops all further billable and effectful execution. budget_usage.spend_halted becomes true.
  2. Only then does the run ask. With on_exhaustion: request_attention (the default) the run moves to needs_attention with reason budget_exhausted. With on_exhaustion: stop the run ends failed.
No spend happens while the run waits. Only a human answer can raise the budget. A model can never raise its own budget.

​
Resolved defaults

A caller may supply only a goal. Whatever is omitted (workspace, authority, budget, completion) is resolved from the agent’s and profile’s versioned defaults. The resolved values are recorded on the run before execution and returned to the caller, along with which defaults filled them. There are no hidden permissive defaults. If a safe value cannot be resolved, the request fails and no run executes.

​
Current implementation

The work runtime underneath the run model is in the Allternit Factory engine on main today: first-class node outputs, manual and timer wait gates, leases with heartbeat and reclaim, campaigns, and the attention gate. Agents request attention through that gate; they do not notify people directly. The run statuses, budgets and resolved defaults above are specified in the kernel contracts and the Agency API v0.3 contract. Scheduled autonomous waking of campaigns through the Agency API stays off until an explicit go-live.

​
Availability

​
Developer relevance

If you integrate through the Agency API, the run status table and control operations are what your client state machine handles; treat partial as a distinct terminal outcome, and treat needs_attention as the signal to answer an attention request. If you build a component that runs inside the kernel (a tool, a verifier, an executor), you never move a node to done yourself: you produce outputs and evidence, and the system closes the node.