Mission Control: a control plane for a fleet of AI agents

A control plane over agents you already run

Mission Control is not a chat client and not a model. It is a control plane for a fleet of agents, and the author explains the reason for it in one line: past two or three agents, terminals stop working as an interface. One agent writes code, one does research, one watches an inbox, and the person supervising them is left switching windows, losing track of what is running and guessing at what it cost.

Underneath, the dashboard drives OpenClaw as the engine, and it runs locally on your own machine. The sections map onto the things a supervisor of agents actually needs. The dashboard opens on a live overview of which agents are active, gateway health, running cron jobs and system load. Chat is a real conversation with any agent in the browser, with file attachments, model selection, streamed responses and the ability to switch agents without losing context. The task board has a card per job rather than a note, and an agent picks a card up and moves it. The agents view is a live org chart of every agent and subagent, with the channels and workspace each one sits on, and you can spin up new subagents from it. Usage tracks every token across every model and agent so you can see which one is burning budget.

Thin by design, with two small files as the only state

The architectural decision is stated more plainly than most projects state theirs. Mission Control does not store your data, run a database, or try to be the source of truth. It reads and writes straight through to the engine underneath, live, so a change made in the interface lands immediately with no sync step and no cache to go stale. The only state it keeps is two small local files, usage history and the task board.

From that follow four properties the project claims. It is accurate, because what you see is what is running right now. It is boring to maintain, with no migrations, no backups and no cleanup jobs, on purpose. It is hard to break, because if the dashboard goes down the agents keep running. And it is instant, with nothing to provision and nothing to upgrade between versions. The summary the project gives is that pulling the dashboard out still leaves the fleet running, that it is glass over the engine and not the engine. For a tool that manages other tools, that is the right default, and it is also why the interface has no concept of a migration.

The install is a prompt you hand to an agent

The setup path reflects what the project is for. Instead of a manual install, the project provides a block of instructions to give to the agent you drive, whether that is Claude Code, Codex or something else. The steps check the prerequisites, clone the repository, run the setup script, deal with a port clash and verify the result:

     cd ~/.openclaw
     git clone https://github.com/robsannaa/openclaw-mission-control.git
     cd openclaw-mission-control
     ./setup.sh
   (setup.sh is safe to re-run if anything fails.)
3. If port 3333 is already taken, re-run as: PORT=3344 ./setup.sh

The re-runnability is the point, because an install that fails halfway should be recoverable without a manual cleanup. The verification step asks for a status code from a local request and expects 200, and the final instruction is to report the exact URL and how the background service was registered, with launchd, systemd and nohup named as the options. The default port is 3333 and the port can be changed with an environment variable when it is taken. A lot of the code here was written by the agents the harness runs, and the project says so plainly.

OpenClaw has to be there before the dashboard is

The engine is a prerequisite, and the quick start makes that explicit before it installs anything for the dashboard itself:

# Install OpenClaw if you haven't already
curl -fsSL https://openclaw.ai/install.sh | bash

# Verify it's running
openclaw --version

The agent-facing install block makes the same point in a stricter form, requiring node at version 20 or newer and a working openclaw version command, and pointing at the vendor documentation if OpenClaw is missing. This is a real constraint on adoption: the dashboard is not a standalone tool you can evaluate in isolation, and any evaluation means installing the engine it drives first. The project also offers a hosted option for people who are not technical users, with a deployment offered on agentbay.space, and the homepage points there.

The task board and the scheduler are the real workflow

Two features change how the work is organised rather than merely how it is watched. The task board is a set of four columns, Backlog, In Progress, Review and Done, and a card is not a note but a job an agent runs: you drop one in, an agent picks it up, and you watch it cross to Done. That is the difference between a to-do list and a dispatch queue, and it is the feature the project description ties directly to the idea of pointing a few agents at a problem and walking away.

The cron section covers the other half, running agents on a schedule such as summarising an inbox every morning or checking for updates every hour, with the ability to create, edit, pause and test a job, and full run history so you can see what happened overnight. The rest of the panels fill in the surrounding needs: a terminal with multiple tabs and colour support, a documents browser over workspace files, semantic search across everything with a keyboard shortcut, a memory view for long-term memory and daily journals, a models page for provider credentials and fallback chains, a security audit, a permissions panel for what agents may execute, and an accounts and keys page that masks credentials. Channels connect the agents to Telegram, Discord, WhatsApp, Signal and Slack, and a Tailscale integration reaches the dashboard from another machine with tunnel controls built in.

What the repository is built from

The package is a Next.js application published as @openclaw/dashboard at version 0.15.0, licensed MIT, and it requires node 20 or newer. It installs a command called openclaw-dashboard, and the development and build scripts are the standard Next.js ones, with a development server bound to the loopback address on port 3000 and a separate script for a virtual private cloud setup.

The test story is where the engineering effort went. The end to end suite runs on Playwright with a CI project, and there are separate projects for a live gateway and a live interface, so the same tests can run against a stub and against a real engine. Unit and component tests run through Vitest with named projects, and a pre-merge script chains an API contract check and a capability gate check before the unit and integration suites. The contract check is the interesting one, because it means the dashboard and the engine are checked against an agreed interface rather than against whatever the code currently does. The repository also carries an OpenClaw plugin directory, end to end tests, a Playwright configuration, a Vitest configuration, an ESLint flat config and a setup script at the root.

Where the sharp edges are

Three things deserve a look before you commit to it. The first is the dependency on the engine, which is absolute: without OpenClaw installed and configured there is no dashboard, and the install flow has to be run twice, once for each. The second is the repository naming, since the install instructions in the project notes clone a repository called openclaw-mission-control, which is not the same name as the project this overview describes, so check the URL you are pulling if the clone fails. The third is the release rhythm. The published versions include v0.13.0, v0.14.0 and v0.15.0 on the same day and the next, 2026-08-13 and 2026-08-14, with the last push on 2026-08-19, which is fast enough that you should expect to be reading release notes rather than a changelog of behaviour. Nothing here is version 1.0, and the interface is expected to keep moving.

Editorial conclusion

Mission Control suits someone running several agents at once, where the bottleneck has stopped being the model and become the person tabbing between terminals, because the overview, task board and cost page answer the questions you would otherwise answer by guessing. It is the wrong choice if you run a single agent, since the harness adds nothing there, and it is the wrong choice if you want the dashboard to be the system of record, because it deliberately stores nothing and would lose its own state if the engine went away. Before you install, check that OpenClaw is already working on the machine, since the setup script assumes it, and note that the install instructions in the project notes clone a repository named openclaw-mission-control, so check which URL you are actually pulling if the one you expected is missing. The licence is MIT, the package is published as @openclaw/dashboard at version 0.15.0, and the last push was on 2026-08-19.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. robsannaa/mission-control on GitHub