System Model
cmdop’s system model is a three-layer separation: a client layer of heterogeneous operators (CLI, GUI, API, AI agents, automation), a transport layer of interchangeable carriers (SSH, WebSocket, HTTP, local socket), and an execution layer — the cmdop core — that owns the persistent, network-addressable, single-homed execution-state objects. Operators are distributed; the execution state is not. Clients never touch the runtime directly; they attach through transports to the execution layer, which holds the one live execution.
Layered diagram
Separation of concerns
- Client layer — where operators live. Every operator attaches to the same live execution; none is a privileged controller, though authority is asymmetric and transferable (a human can take control). The layer is type-agnostic: a CLI and an AI agent are structurally identical participants attaching to the execution layer, as established in operator execution identity.
- Transport layer — interchangeable carriers. No carrier owns state; carriers are bound and released by the attach/detach surface. The session is addressed by its own identity, not by the connection carrying it, which is what enables transport-independent sessions.
- Execution layer — the cmdop core. It owns execution-state objects and holds the one live, single-homed execution. The runtime is the durable thing; operators on any transport attach to it.
Mapping to known systems
The split generalizes the client-and-runtime separation familiar from interactive notebook and terminal-multiplexer systems — one durable runtime, many front-ends that come and go — and promotes it to a continuity layer: cmdop has a coordinator managing many persistent objects, each a single-homed live execution, reachable from any client over any transport. The access is distributed even though each execution is single-homed. Isolation primitives (Firecracker microVM, gVisor) sit underneath the execution layer as the tenancy boundary, not as the model itself.
Cmdop