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. Input from multiple operators is applied in a single serialized order and attributed to its source, so every client sees a consistent, ordered view of the same session.
How do attached clients stay coherent?
Coherence comes from there being one live execution state that all clients attach to, rather than each client holding its own copy. 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.
Input from operators is not applied simultaneously. It is taken in a serialized order and attributed to the client that sent it, so the session has a single, well-defined sequence of what happened and who an action came from. 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 serialized, attributed input behavior and the operator/observer split are documented at user-facing altitude in multi-client sessions; the session transports that carry it are 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 its input is taken in the same serialized order — 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 arbitration 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 multi-actor write conflict is serialized and attributed.
TAGS: multi-actor, multi-client, operator, coherence DEPENDS_ON: [architecture/protocols, concepts/multi-client, concepts/ai-operators]
Cmdop