Mission Control by Builderz Labs: a self-hosted control plane for AI agents

The problem Mission Control solves for multi-agent operators

Running one agent on one laptop is legible. Running four runtimes across a fleet is not. The README frames the gap directly: use Mission Control when multiple agents or runtimes make it hard to answer who owns a task, what executed, which result passed review, or where spend and failures accumulated. That is an operations problem, not a reasoning problem, and the project is explicit that the control plane sits above agent runtimes and does not replace their reasoning or tool loops. The audience is therefore the operator, not the agent author: someone who needs a task inbox, run inspection, failure review and a cost view in one place, backed by SQLite, without handing the data to a vendor. The README also lists the cases where it is the wrong tool, which is unusually candid for a project README and worth taking at face value. If one agent on one machine already stays understandable from its native CLI, adding a dashboard adds a layer without removing ambiguity. If you want a managed multi-tenant SaaS, this is self-hosted by design. If you want a framework to define planning and tool use, Mission Control deliberately does not do that.

How the control plane sits above runtimes

The architecture is a Next.js application with a SQLite store for local control-plane state, and it is workspace-aware. Shared workspaces can use deployment-level runtime integrations; strict workspaces block those integrations until the underlying resources carry workspace ownership. That distinction matters because it decides whether a workspace can reach shared runtime resources at all. A gateway is optional for task, project, agent, scheduler, webhook, alert and cost work. Live session messaging is the exception: it needs a connected runtime gateway. So the shortest path to a working system is gateway-free, using the REST API, and the gateway becomes relevant only when you want to talk to a running session. The shipped surfaces are grouped in the README as Tasks, Agents, Operations, Knowledge, Governance and Interfaces. The interface list is the part that determines integration cost: a web UI, a CLI, an MCP server, an OpenAPI-described REST API, WebSocket and SSE. The REST contract lives in openapi.json, and a running instance serves the interactive reference at /docs and the OpenAPI JSON at /api/docs. Adapter depth varies by runtime, and the README points to docs/agent-setup.md and docs/cli-integration.md before assuming feature parity. Treat that as the honest boundary of what is shipped versus what is documented.

Installing Mission Control locally or with Docker

A source install needs Node.js 22 or newer and pnpm. The README gives a single script as the shortest path: it clones the repository, changes directory and runs the installer in local mode.

git clone https://github.com/builderz-labs/mission-control.git
cd mission-control
bash install.sh --local

After it finishes, open http://localhost:3000/setup, create the first admin account, then copy the API key from Settings if an agent or script needs headless access. Windows users run `./install.ps1 -Mode local` in PowerShell instead. If you already manage Node and pnpm, the manual path is three commands, and the dev server binds to 127.0.0.1 on port 3000 by default.

nvm use 22
pnpm install
pnpm dev

Docker is the other route. `docker compose up` builds from the repository's Dockerfile, and the published multi-architecture image can be pulled and run directly on port 3000.

docker pull ghcr.io/builderz-labs/mission-control:latest
docker run --rm -p 3000:3000 ghcr.io/builderz-labs/mission-control:latest

For a network-accessible deployment the README points at the hardened Compose overlay, layered on top of the base file with `-f docker-compose.hardened.yml`. Once you have an API key, the first real use is the gateway-free REST loop: export the URL and key, register an agent, create a task, then read the queue back. The README gives exactly these calls, and the agent named in the task payload is the agent whose queue you read.

export MC_URL=http://localhost:3000
export MC_API_KEY=replace-with-your-api-key
curl -s -X POST "$MC_URL/api/agents/register" \
  -H "Authorization: Bearer $MC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"scout","role":"researcher"}'
curl -s -X POST "$MC_URL/api/tasks" \
  -H "Authorization: Bearer $MC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"Review open incidents","assigned_to":"scout","priority":"medium"}'
curl -s "$MC_URL/api/tasks/queue?agent=scout" \
  -H "Authorization: Bearer $MC_API_KEY"

The CLI equivalents are shorter if you prefer a terminal. The package.json exposes `pnpm mc` as the entry point, and the README shows list, queue and event-watch subcommands with a `--json` flag for scripting.

pnpm mc agents list --json
pnpm mc tasks queue --agent scout --json
pnpm mc events watch --types agent,task

For MCP, the README registers the server with Claude using the bundled script and passes the URL and key through `env`.

claude mcp add mission-control -- \
  env MC_URL=http://127.0.0.1:3000 MC_API_KEY=replace-with-your-api-key \
  node /absolute/path/to/mission-control/scripts/mc-mcp-server.cjs

The first-agent quickstart in docs/quickstart.md continues with heartbeats, task results and queue behavior.

Aegis review and the completion receipt

The task board is not a simple to-do list. Work moves through inbox, assignment, execution, review, quality review and completion, and Aegis review requires an approval record before a task reaches done. That is a deliberate gate: an agent cannot mark its own work finished without an approval artifact attached. The README's operator field notes push the same idea further. Dashboards compress a sequence into current state, so when a run needs review, record the identity, task, tool call, approval, result and verification evidence before changing it, and keep unresolved items distinct from accepted risk. The distinction between logs and receipts is stated plainly: logs show what ran, while a completion receipt or an inspected artifact shows what finished. If you have ever debugged an agent by reading a stream of tool calls and guessing whether the last one succeeded, that distinction is the reason to care about this project. It also implies a workflow cost. Someone has to produce the approval record, and on a small team that someone is you. The gate is only as useful as the evidence attached to it, and the README does not claim the system generates that evidence for you.

Where Mission Control is the wrong tool

The alpha warning sits at the top of the README for a reason: APIs, schemas and configuration may change between releases, and the README tells you to read the security guidance before exposing the instance to a network. If your deployment cannot tolerate alpha schema or API changes, the project says so itself. That is a genuine constraint, not a formality, because the REST contract in openapi.json is the integration surface agents and scripts depend on. There is a parity check script in package.json, `api:parity`, which compares the API against the OpenAPI document with an ignore file, but a parity check confirms the document matches the code. It does not promise the contract is stable across versions. The second limitation is adapter depth. The README lists OpenClaw, Claude Code, Codex, CrewAI, LangGraph, AutoGen and Claude SDK workflows as covered, then states that adapter depth varies by runtime and points to the setup docs before assuming feature parity. A runtime with a thin adapter may give you registration and presence without the richer session behavior you expected. Third, live session messaging needs a connected runtime gateway, so a gateway-free deployment is a task and cost dashboard, not a live console. Fourth, the network access control defaults are strict by design: MC_ALLOWED_HOSTS ships as localhost,127.0.0.1,::1, and production access is blocked unless a host is explicitly allowed. That is the right default, but it means a remote deployment needs configuration before anyone can reach it.

How it differs from LangGraph, AutoGen and CrewAI

The comparison the README invites is with frameworks rather than dashboards. LangGraph, AutoGen and CrewAI define how agents plan, call tools and hand work to each other. Mission Control does not. It is the layer above: registration, assignment, review gates, spend, alerts and audit. The practical difference shows up when you already have an orchestration framework and still cannot answer operational questions. Adding Mission Control does not replace the framework; it observes and governs the work the framework produces, and the README lists all three as covered by adapters and observation surfaces. The trade-off is that you now run two systems instead of one. The framework owns the reasoning loop, Mission Control owns the record of what happened, and the adapter between them is the part whose depth varies. If you are choosing between adopting a framework and adopting a control plane, they are not substitutes. If you have a framework and no operational view, the control plane is the missing piece, provided the adapter for your runtime is deep enough for what you need.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-07-25, which is roughly two months before the date of writing. The release history is recent and dense: v2.1.0 on 2026-07-04, v2.2.0 on 2026-07-17, and v2.3.0 on 2026-07-25. The v2.3.0 notes describe a dependency security patch, a toolchain refresh and locale integrity, and v2.2.0 is titled Security Hardening and Workspace Isolation. Two security-themed releases inside a month is a signal about where the maintainers are spending effort, and it also tells you upgrades are not purely cosmetic. The project is MIT licensed, which is permissive and places few obligations on how you deploy or redistribute it; the LICENSE file is at the repository root. Nothing in the repository describes a support contract or a compatibility guarantee, so treat version upgrades as work you own. The Dockerfile pins Node 24.18.0-slim by digest and pins pnpm to v10.29.3 with a comment noting that pnpm 11 turns ERR_PNPM_IGNORED_BUILDS into a hard error and breaks fresh Docker builds. That pin is the kind of detail that saves an afternoon, and it is also a reminder that the toolchain moves underneath the application. Read CHANGELOG.md and RELEASE.md before upgrading a deployment you depend on.

Configuration traps worth knowing before you deploy

One trap is documented at length in both .env.example and docker-compose.yml: NEXT_PUBLIC_* variables are baked into the client-side JavaScript bundle at build time. Changing one requires running `pnpm build` again for the change to take effect in the browser. Server-side variables such as OPENCLAW_* and AUTH_* are read at runtime and do not need a rebuild. The Dockerfile carries matching ARG and ENV pairs for the gateway variables precisely because, without them, operators could not configure the browser-facing gateway URL without a custom image build. The Compose file offers a workaround: the Advanced Settings on the login page set the gateway URL at runtime, and it persists in localStorage and overrides the baked-in value. The second trap is the split between the server-side gateway host and the browser-side one. OPENCLAW_GATEWAY_HOST defaults to host.docker.internal, which resolves to the Docker host on Docker Desktop for macOS and Windows, and the Compose file adds an extra_hosts entry so the same value works on Linux. NEXT_PUBLIC_GATEWAY_HOST must be reachable from the user's browser, not from inside the container, so it should stay empty for local Docker and be set to the public hostname or IP for a remote deployment. Getting these two backwards produces a dashboard that loads but cannot reach the gateway. A third setting is worth noting: an environment variable can skip probing local CLI binaries such as claude, codex and hermes for install, version and auth status, which the file recommends for demo instances and screenshots. Skipping the probe changes what the agent views report, so do not leave it on in a real deployment.

Editorial conclusion

Adopt Mission Control if you already run more than one agent or runtime and cannot answer who owns a task, what executed or where spend went. Skip it if a single agent on one machine is legible from its native CLI, or if you need a managed multi-tenant SaaS. Before deploying, verify the hardened Compose overlay, whether your workspace is strict, and whether a connected runtime gateway is available for live session messaging.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes