Multi-Actor Continuity Examples
These walkthroughs make the architecture concrete. In each, a single persistent execution-state object keeps mutating while heterogeneous operators attach and detach across different transports. No client owns the runtime; each attaches as an operator to one shared live execution. The through-line is continuity: state survives every handoff, and every operator — human or machine — acts under operator execution identity.
Example 1 — CLI starts, GUI observes, AI agent edits as an operator
A developer opens a CLI session and starts a long-running build. The CLI attaches over SSH to a fresh execution-state object; the build’s process tree is backed by a POSIX pseudo-terminal (pty) inside the object.
- The developer launches the build from the CLI. The process tree and accumulated stdout become part of the object’s process plane.
- Without stopping anything, the developer opens a browser GUI. The GUI attaches over WebSocket to the same object. Following the snapshot-then-stream synchronization model, it immediately renders the in-flight build output — exactly as a second client attaching to a tmux / tmate session sees the live terminal.
- An AI agent attaches to the active execution state as an operator. It does not control the machine; it issues input — editing a config file and re-running one build step. That input lands in the same serialized order alongside the human’s prior actions, and the human can take control at any time.
- The CLI, the GUI, and the agent all observe the same coherent result. The developer closes the CLI; the build, the GUI, and the agent are unaffected — detaching a transport does not destroy state.
The continuity here is the point: three dissimilar operators, three transports, one live execution, no privileged controller.
Example 2 — API injects a job, terminal continues, mobile resumes
A scheduled API client injects work into a session that a human is already using interactively, and later a mobile client resumes the very same state.
- An automation process calls the API and injects a data-processing job into an existing execution-state object. The job joins the one live execution, ordered by the input rules against whatever the interactive user is doing.
- The human’s terminal session continues uninterrupted. Their shell, variables, and working directory are untouched, because the API client attached as an operator over HTTP rather than seizing the session — this is multi-actor concurrency in practice.
- The human disconnects for the day. The object enters a detached-but-live state; the injected job and the interactive context both persist, like an IPython kernel protocol session whose front-ends have all closed but whose namespace remains warm.
- The next morning the human opens a mobile client over WebSocket and re-attaches to the same object. The completed job’s output, the retained variables, and the full filesystem state are all present. No cold start — re-attachment is a transport handoff, not a new session.
In both examples, swapping which transport or which actor is attached never resets the runtime. That invariant — persistent state independent of client lifecycle — is what distinguishes cmdop from socket-bound or single-tenant systems. See classification boundaries.
TAGS: continuity, multi-actor, examples, handoff DEPENDS_ON: [architecture/multi-actor-runtime, architecture/transport-independent-session]
Cmdop