Running an AI coding agent on one computer is straightforward. Running several
agents across a laptop, a build machine, and a home server changes the problem.
The hard part is no longer starting a process. It is remembering where the work
is happening and returning to the right context without reconstructing it from
terminal history.
Cmdop approaches that problem as messaging. A machine becomes an addressable
endpoint in a conversation list, and the conversation becomes the durable place
where an operator sends work and receives results.
Why terminals stop scaling
A terminal is an excellent execution surface, but it is a weak coordination
surface. Once work spans multiple machines, the operator has to remember several
unrelated facts:
- which host owns the current task;
- which shell or multiplexer session is still alive;
- whether a command is running, waiting, complete, or failed;
- where the result should be collected;
- whether the action still needs human approval.
Those facts form a workflow, but a set of terminal windows does not model that
workflow explicitly. The missing layer is not another terminal tab. It is a
stable identity for each endpoint and a persistent thread for the work assigned
to it.
A machine as an addressable endpoint
The useful abstraction is simple: install an agent, let it establish an outbound
connection, and show the machine as a named endpoint in the product. The operator
can then open the endpoint, issue a task, leave, and return to the same thread
when the result is ready.
Outbound connectivity matters because the first-run network model stays easy to
understand. The machine initiates the connection; the operator does not need to
open an inbound port just to make the endpoint reachable. Authentication,
authorization, and transport security still require explicit controls, but the
basic topology is clear.
The endpoint identity is also intentionally separate from task state. A machine
being reachable does not prove that a task succeeded. The conversation must show
whether work is queued, active, waiting for a decision, completed, or failed.
Reachability answers where to send work. Receipts and lifecycle state answer what
happened to it.
Fan-out without losing accountability
The same model becomes more useful when one action targets several machines.
Instead of treating fan-out as a shell shortcut, the system can represent it as
a coordinated operation with a finite result:
- which endpoints accepted the request;
- which endpoints are still working;
- which endpoints failed;
- which result requires a human decision.
That structure is important for AI-first workflows. The product should prioritize
the result and its state, not make the operator fill out a large form before work
can begin. A concise request can fan out, while the response remains inspectable
and attributable to the endpoint that produced it.
The trust boundary remains visible
Messaging is a better interaction model only if it does not blur permissions.
An easy-to-reach machine must not become an implicitly authorized machine. Task
execution, approval, cancellation, and evidence belong to explicit lifecycle
transitions rather than free-form status text.
The same rule applies to agent engines. A conversation may coordinate Claude
Code, Codex, or another tool, but the interface should preserve which engine ran
the task and which machine owned the execution. A polished conversation is not a
substitute for provenance.
What this changes
Treating machines as endpoints turns remote AI work from a memory exercise into
an observable system. The operator no longer has to navigate through host names,
shell sessions, and process state before reaching the task. The product presents
the task where it naturally belongs: in the ongoing conversation with the machine
that owns it.
That is the direction behind Cmdop. The goal is not to
hide the terminal or make remote execution look magical. It is to give
multi-machine agent work a small, durable coordination layer with clear state,
explicit trust boundaries, and a result that is easy to return to.
The concrete parts of the above, if you want to look rather than take my word
for it:
- cmdop-docker — the runnable version of this argument. One compose file starts a machine agent beside an editable project; you can watch the browser update while the agent edits the site.
- How the connection works — the outbound-only topology described above, in more detail than this post goes into.
- Agent tools — what an agent can actually do once a machine is reachable. It includes the browser-control trade-off, stated plainly rather than sold.
- Python SDK — if you would rather drive a fleet from code than from a conversation.
Top comments (1)
The endpoint/task separation is doing most of the work here. Reachability is transport state; completion is durable job state. Mixing them is how a disconnected laptop turns into a ghost “success.”