AI Operators

CMDOP doesn’t have a “bot mode”. Humans and AI use the same SDK, the same auth, the same session surface, and the same audit log. An AI is just another operator.

The thesis

A CMDOP session belongs to a fleet, not to a human. Anything that can authenticate against the fleet — a human at a CLI, a script with an API key, an LLM-powered SDK call — can attach to a session, send commands, and see output. Roles, permissions, and audit are uniform. There is no privileged path “for bots”.

Two ways AI shows up in CMDOP

There is no special “AI runtime”. AI participates through one of two doors:

• Built-in agent loop. Inside the daemon — cmdop chat, the Desktop chat tab, a remote ask_machine. The agent loop runs, the LLM calls tools, and the result lands in a session transcript. See Agent Loop.
• External AI calling the SDK. A Python or TypeScript program holds a fleet API key and drives sessions with the same calls a human script would use. The auth header doesn’t say who you are at runtime; it just authorises calls.

Both paths are operators. Both obey the permission model.

Equal-participation model

All operators — human or AI — read the same output stream and submit input through the same channel. Observers (read-only) can attach without affecting input arbitration. See Multi-Client for operator/observer mechanics.

Structured output (one example)

The SDK supports typed responses via Pydantic. Use this when you want the AI to return data, not text:

from pydantic import BaseModel
from cmdop import AsyncCMDOPClient
 
class ServerHealth(BaseModel):
    hostname: str
    cpu_percent: float
    issues: list[str]
 
async with AsyncCMDOPClient.remote(api_key="cmd_xxx") as client:
    await client.terminal.set_machine("prod-1")
    result = await client.agent.run(
        prompt="Check server health and list any issues",
        output_schema=ServerHealth,
    )
    health: ServerHealth = result.output
    for issue in health.issues:
        notify(issue)

The AI runs commands, parses output, and returns a value matching the schema. No regex, no glue. For depth — schemas, retries, validation patterns — see Multi-Machine Prompts and the SDK reference.

Cross-machine AI dispatch

When an AI on machine A needs to call into machine B, it uses the same ask_machine / ask_machines tools any other operator would use. Calls funnel through the remoteagent client, the receiver’s permission gate fires, and results stream back into the original session.

The mechanics live in Agent Communication. This page just notes that AI doesn’t get a backdoor.

Audit and limits

Every tool call (human or AI) is appended to ~/<log>/audit.log as one JSON line. The permission gate fires for remote calls regardless of who initiated them — an AI on machine A asking machine B is gated by B’s permissions.yaml exactly the same as a human running the same prompt.

Self-to-self calls (same OAuth identity) bypass the gate by design. See Permissions.

What AI cannot do

• Escalate beyond the OS user that runs the daemon.
• Write permission rules. The agent’s permissions_helper(suggest_rule) operation routes to the human modal — it can propose, never apply.
• Bypass the floor. The non-bypassable safety net (writes to .env, rm -rf /, fork bombs) blocks AI tool calls regardless of mode.

Related

• Agent Loop
• Agent Communication
• Permissions
• Multi-Client
• Peer execution identity

Background reading: AI as Operator, Not Controller — the operator model versus the controller model, and why authority is asymmetric but transferable.

TAGS: ai-operators, llm, observer, structured-output, audit DEPENDS_ON: [agent-loop, agent-communication, permissions, multi-client]