Skip to main content

Agent runtimes are organization data, built from kinds the server defines

Organizations set up their agent runtimes themselves, in the API and the web app: each is a runtime kind the server offers (Claude Code, Codex, Oh my pi) under a name, optionally with a model. One is the organization's default; a role uses the default or picks another. What a kind runs — its program, arguments and the variables it takes from the host — is code in the server (runtime-kinds/runtime-kinds.ts) and never comes from outside it. An organization therefore chooses among programs the server already has, and the rule of ADR 0004 holds: nobody can make the server run a program of their choosing. Claude Code and Codex run on ACP bridges that ship with the server; Oh my pi uses its own omp acp mode and must be installed on the host. All of them use the sign-in their CLI already has on the host.

Considered Options​

  • Runtimes in server configuration (MC_AGENT_RUNTIMES, a JSON map of commands): what we had. Rejected; every change meant stopping the server, writing commands and variable names by hand and starting it again, and the choice belongs to the organization, not to whoever runs the server.
  • Runtimes with a command set through the API: rejected; any organization owner could then run any program on the host as the server's user.
  • Settings per kind (a schema each kind declares): deferred; the only setting today is the model, which every kind takes the same way, through ACP's session model option.
  • Pi, through the pi-acp bridge: left out; pi has no MCP support, so its agents could not reach Mission Control's tools, and runs refuse such agents.

Consequences​

  • An organization with runtimes always has exactly one default: its first runtime becomes it, and deleting the default makes the oldest remaining one the default. Roles on a deleted runtime fall back to the default, as do role revisions restored after it was deleted.
  • The runtime is looked up each time a run starts, so a role continues on whatever runtime it uses now. A session belongs to the runtime it was started on; on another runtime the run starts a new one.
  • A model is matched against what the runtime offers when the session opens (its id, else a unique name, else a unique part, so "opus" works), and a run fails, naming what is offered, when nothing matches.
  • Adding a kind, or settings a kind needs, is a server change. A sandboxed kind (ADR 0004's intended route) is one more kind.
  • Tests replace the kinds through the configuration (runs.kinds) with a stand-in agent.