Multi-Actor Runtime
The multi-actor runtime is the property that many heterogeneous clients — CLI sessions, desktop and mobile clients, SDK/API callers, and AI operators — can attach to a single live execution-state object at the same time. All attached clients observe the same execution as it happens; clients that may send input act as operators, others attach read-only as observers. Several operators can be attached at once and take turns steering the one live session, and each operator’s actions are recorded in the audit log, so every client shares the same live view and the session has a clear record of who did what.
How do attached clients stay coherent?
Coherence comes from there being one live execution state that all clients attach to, so all clients see the same live state. A client that attaches sees the same output stream as everyone else, and a client that joins late receives the current state on attach — so a desktop client that connects after a CLI has been working sees the accumulated, coherent result rather than an empty environment. Because every attached client is looking at the same live execution, there is no divergence to reconcile.
The user-facing behavior, including the operator/observer capability split, is documented in multi-client sessions.
Heterogeneous client types
A shell command from a CLI, a file edit from a desktop client, a job submitted by an SDK/API caller, and a command issued by an AI operator are all input to the same live execution state, reaching it through the same session. This is the architectural meaning of “multi-client” — not screen-sharing one client, but many dissimilar clients attaching to one execution-state object, some as operators and some as observers.
Operators take turns steering the one live session rather than acting on private copies. Each operator’s input lands and is reflected in the shared live state that every attached client is watching, and each operator’s actions are recorded in the audit log — so the behavior is auditable per operator. For stateful operations, the result is last-write-wins: there is no merge of competing input.
Why not a single-client model?
A single-client runtime binds the execution state to one client: when that client disconnects, the work is gone, and no second client can attach to observe or assist. cmdop’s model is the opposite — the execution state is single-homed on one host but ownerless with respect to clients, so it survives any individual client disconnecting and other clients (human or AI) can attach to the same live session to observe or, as operators, to act. The disqualifying case is a runtime whose state lifetime is bound to one client; that is a terminal multiplexer or a sandbox, not a multi-actor runtime.
The turn-taking and the operator/observer split are documented at user-facing altitude in multi-client sessions; the attach/detach/reattach surface that carries it is described in process-control protocols.
AI participates here as an operator, not a controller. An AI operator attaches to the live execution state through the same interface as human clients and takes its turn steering the one live session — it does not dispatch commands from a privileged layer above the session. Authority is asymmetric but transferable: a human can take control at any time, and operators act within the session’s permission floor. Full transferable-authority handoff across operators is on the roadmap, not yet shipped — see execution identity and AI operators.
Background reading: AI as Operator, Not Controller — the multi-actor execution model; and Failure Modes of a Continuity Layer — how a continuity layer behaves when operators contend for the same live state.
Cmdop