I build cmdop, a messenger for AI agents. The product idea started with a small
friction: when an agent is running on another machine, the useful question is not
“which terminal window is it in?” but “which contact should I message?”
That shift sounds cosmetic. It changes the workflow.
The terminal is not the right unit of attention
An AI coding session has a location: a laptop, a build box, a home server, or a
temporary machine. The session also has a job: fix a test, inspect logs, prepare a
release, or keep a long-running task moving.
When the interface is only a terminal, I have to remember process IDs, SSH hops,
tmux windows, and which machine owns the current context. That is workable for one
machine. It becomes mental bookkeeping as soon as several agents are active.
Cmdop treats the machine and its agent session as named contacts. I can open a
conversation with one machine, send a command to the whole fleet, and return to
the same conversation when the work produces an answer. The interaction becomes
closer to messaging than to remote shell archaeology.
What the workflow looks like
The basic loop is deliberately boring:
- Install the cmdop CLI on a machine.
- Let it connect outbound, so there are no inbound ports to open.
- Sign in to the web messenger.
- See the machine as a contact and start a conversation.
The important part is not a clever dashboard. It is the persistent identity of the
machine in the conversation list. “Mark’s MacBook” and “build-box-01” are easier to
reason about than two anonymous terminal tabs.
For a concrete first pass, the shell path is intentionally small:
curl -fsSL install.cmdop.com | sh
cmdop enroll <enrollment-password>
The enrollment password belongs to the fleet owner; it is shown by the product’s
Connect flow rather than being invented in the article. After the machine is
enrolled, the web messenger is the place to address it. If Claude Code is part of
the workflow, cmdop mcp status is the local verification step for the embedded
fleet integration.
One conversation, many agents
The same interaction model is useful when an agent is not running locally. Cmdop
can connect Claude Code and Codex through its fleet tooling, so the conversation
surface can coordinate work across several named endpoints.
That makes fan-out an explicit action instead of a shell trick. A request such as
“run the diagnostic on every machine” should produce a fleet-level result that can
be inspected as a unit. The interface should help answer three questions:
- Which machines received the request?
- Which ones are still working?
- Which result needs a human decision?
The trade-off: a contact is not a guarantee of success
Making a machine easy to reach does not make the work trustworthy by itself. A
reconnectable conversation can still hide a failed run, a stale approval, or a
result that was produced by a different engine than the one I expected. The
machine contact is only the durable handle; task state, permission state, and
execution receipts need their own boundaries.
That is also why I do not want the messenger to pretend that every message is
progress. A useful system should be able to say: the task is waiting for a
decision, the run failed, the result is ready, or nothing has been verified yet.
The contact metaphor reduces the navigation cost; it does not remove the need
for explicit state and human judgment.
The trust boundary is part of the UX
Remote control products often make the network boundary hard to explain. Cmdop’s
starting point is simpler: the agent dials out, and the user does not need to open
ports or expose a machine for inbound access.
That does not mean “no cloud” or “magic security.” It means the first connection
story is understandable: install the agent, authenticate, and let the machine
establish its outbound connection. Security claims still need to be checked against
the actual transport and deployment mode.
Why I am building this
AI agents are multiplying faster than the interfaces around them. We have good
tools for starting a session and good tools for sending messages, but the boundary
between “agent” and “machine where it runs” is still awkward.
I want the fleet to feel like a set of useful contacts: addressable, observable,
and easy to return to. That is the product I am building with cmdop.
If you run agents across a laptop, homelab, or build fleet, I would like to hear
where the contact metaphor breaks down for you. cmdop messenger
Top comments (0)