Architecture: The Execution-State Continuity Layer
An AI-native system has three concerns: memory (what was learned), orchestration (what to do next), and the live execution (what is running right now). The first two are mature; the third has no layer of its own — the running process tree, PTY, file descriptors, and local sockets are almost always an implementation detail of whichever client spawned them, and they die when that connection drops. cmdop is the reference implementation of the layer that fills that gap: it makes the live runtime a first-class, single-homed, ownerless object that humans, AI agents, devices, and services attach to as operators — detaching and reattaching across client, transport, and device. This page is the architectural spine; it states the category, then hands off to the concrete shape, the primitives, and the category essays below.
The missing layer
Every serious agent system has converged on two layers, and built them well.
Memory is the durable record of what happened — transcripts, embeddings, rolling summaries, retrieval over episodic and semantic stores. It serializes to disk, replicates trivially, and is designed to outlive any session.
Orchestration is the logic that decides what happens next — the agent loop, the planner, the task graph, the durable-workflow engine that drives a multi-step process to completion across restarts.
Between them they cover a remarkable amount of ground. And yet a closed laptop lid, a dropped socket, or an app restart still annihilates the work in progress. Memory remembered the plan. Orchestration would happily re-issue the next step. Neither one kept the live execution alive — the running process tree, the pseudo-terminal with its scrollback, the open file descriptors, the bound socket, the live variables resident in the process. In almost every system shipping today, that object has no independent existence: it is parented to the client that spawned it and is reaped silently when the transport drops.
That is the missing layer, and it is the layer cmdop is.
The category
cmdop is the reference implementation of the command-operator execution layer — descriptively, the execution-state continuity layer. The shape of that layer is defined by four load-bearing properties, all stated at capability altitude:
- Single-homed. The live execution state lives on one host. It is not replicated or sharded; what is many is the set of operators attaching to it, not the execution itself.
- Ownerless. No privileged occupant — not even the client that spawned the runtime — whose departure ends it. Every operator is a replaceable attached reference; authority is asymmetric but transferable.
- First-class and addressable. The live runtime is an object with its own identity and lifetime, reachable independently of any one connection. Transport handoff does not reset it.
- Operator model, not controller model. Humans, AI agents, devices, and services attach to one running execution as operators — they observe and steer the same live state — rather than each holding a private runtime, and rather than dispatching commands at it from the outside. AI is one kind of operator, not a controller bolted on top.
The shift this names is from a controller model, where whichever client holds the connection is the holder of the runtime, to an operator model, where the runtime is the durable thing and every client is a replaceable attached reference that can detach, switch device, and reattach without the execution noticing.
How cmdop realizes it
This page stays at capability altitude on purpose. The concrete shape lives one layer down:
- The system shape — one Go core, the daemon, the relay, Connect, the permission gate, and where state lives — is the block-diagram view in Intro · Architecture. That is the implementation of everything stated above; this spine defers to it, not the reverse.
- The prompt’s journey end to end — daemon → relay → permission gate → agent loop — is in Intro · How it works.
The primitives
Each property above is realized by a primitive documented under Concepts. The concept pages are the operational nouns you manipulate; this section is the formal model behind them.
The formal model
The architecture pages below give the formal, per-property model. They defer to the primitives in Concepts and the shape in Intro · Architecture; they do not re-derive the implementation.
The category, in depth
The “why this shape exists” argument — why memory and orchestration got built first, why this third layer was skipped, and where the boundary of the category honestly falls — is the seven-part essay series. The docs describe the shipped product; the series stakes the category.
Conceptual deep dive: why this is steered live state, not deterministic replay, is argued at length in Steered, Not Replayed — and where the category honestly ends in The Boundary.
TAGS: execution-state, single-homed-execution, ownerless, operator-model, architecture DEPENDS_ON: [concepts/sessions, concepts/multi-client, intro/architecture]
Cmdop