Agent Mission Control

Running a fleet of AI agents

02 · July 2026 · 3 min read

I run AI agents the way a team runs people: with a queue of work, a manager, and accountability. This page walks through the mission-control platform I built to run my fleet of OpenClaw agents: how agents join, how the system survives them failing, and how cost and quality stay under control.

1. Agents connect over WebSockets and report heartbeats. An agent that goes quiet is presumed dead.
2. The platform owns the queue: tasks are handed out, re-queued when an agent dies, and gated behind approvals when they matter.
3. Postgres is the source of truth. Every state change lands there first.
4. Database notifications fan out to a live dashboard, so the whole fleet is watchable in real time.

Agents connect in, they are not spawned #

Most orchestration tools own their workers: they start processes, watch them, and kill them. I inverted that. The platform I built speaks a connector protocol: an agent, running anywhere, opens a WebSocket to the platform, authenticates with its own token, registers what it can do, and starts taking tasks. The platform never needs to know how to launch anything, which means any agent runtime can join the fleet, whether it lives on my server, my laptop, or somewhere else entirely.

That inversion keeps responsibilities clean. Agents own their environment, tools, and models. The platform owns work: what needs doing, who is doing it, what it costs, and whether it got done well.

Heartbeats decide who is alive #

Every connected agent reports a heartbeat on a fixed cadence. Miss a few in a row and the platform marks the agent disconnected and re-queues its in-flight tasks for someone else. Nothing is lost when a machine sleeps, a process crashes, or a network path dies; the work simply flows back into the queue. This is the property that makes a fleet of unreliable workers into a reliable system, and it falls out of two small mechanisms: a timer and a queue.

Postgres is the source of truth #

Agents, tasks, projects, activity, costs, reviews: everything is a row in Postgres, and nothing else is authoritative. When a row changes, a database notification fires, the server fans it out over WebSockets, and the dashboard updates live. There is no cache to invalidate and no second store to drift. If the dashboard shows it, the database says it; if the database says it, the dashboard shows it within a heartbeat.

The dashboard itself is a working surface, not a status page: a Kanban of tasks with dependencies and review states, a live activity stream, per-agent profiles, and an audit trail of everything that happened.

Gates, budgets, and reviews #

Autonomous workers need boundaries more than they need capabilities. Tasks can declare dependencies, so nothing starts before its inputs exist. Sensitive work routes through approval gates that stop for a human. Credentials live in an encrypted vault rather than in prompts or configs. Every task meters its token usage into a cost ledger, and budgets put a ceiling on what a runaway job can spend.

The part I like most: agents review each other. On a schedule, completed work gets scored by another agent against defined criteria, and those scores accumulate into per-agent performance records. It is the same discipline you would want in a human team, applied to a fleet of machines, and it catches quality drift long before I would notice it by hand.

Why self-hosted #

The whole platform ships as a Docker deployment I run on my own infrastructure, behind two-factor authentication. It is about 30 thousand lines of TypeScript: a Next.js dashboard, a Fastify server, and a Postgres schema managed by migrations. Owning the stack end to end means the fleet's memory, credentials, and work history never leave machines I control, and the platform can grow in whatever direction the fleet needs next.