A mission control dashboard is the set of screens that turns a running agent operation into something a human can steer: a task board, an activity feed, a runs ledger, a calendar, squad chat, and an approvals queue. The proof that this is the right set is convergence: every serious DIY build arrives at the same screens independently.
346k+
GitHub stars on the most popular agent runtime, and its community's most-built accessory is the same thing every time: a dashboard with a task board, calendar, and team view. The convergence is the spec.
Source: openclaw/openclaw on GitHubiShort answer
When hundreds of builders independently bolt the same screens onto their agent runtimes (board, calendar, projects, docs, team), they are discovering a spec, not expressing taste. This post is that spec: the seven core screens, the three that join later, and the one property that separates an operating surface from a pretty monitoring page: the screen must be able to CAUSE work. MissionControlHQ ships the full set hosted; the anatomy below applies whether you buy it or build it.
Key takeaways
| Screen | The question it answers |
|---|---|
| Task board | What is the work, who has it, what state is it in? |
| Activity feed | What just happened across every agent? |
| Runs ledger | What executed, why, on which model, at what cost? |
| Calendar | What runs on schedule, and when is the next one? |
| Squad chat + threads | How are agents coordinating, and where do I interject? |
| Approvals queue | What is waiting on ME, right now? |
The defining property of a mission control dashboard, screen by screen.
Every screen can act
Approve, nudge, reassign, comment, wake. A view that cannot cause work is a window, not a room.
Attention flows to gates
The default view is what needs YOU: approvals, blocks, escalations. Vanity charts go last.
Status anchors to reality
Done means the artifact moved, runs carry their triggers and costs, and silence is a flag, not a comfort.
One link shares it all
A live, read-only share view for co-founders or the public. Trust is built by visibility.
The convergence argument
The convergence argument is the strongest design evidence available: when the DIY mission-control trend swept the agent community, hundreds of builders independently bolted dashboards onto their runtimes, and the most influential walkthrough landed on a task board, a calendar, a projects view, a memory browser, a docs screen, and a team screen. Nobody coordinated that. The same screens keep emerging because the same questions keep needing answers: what is the work, what happened, what runs when, and who is doing what.
Treat that convergence as a spec, and the job becomes filling it deliberately instead of rediscovering it screen by screen.
The seven core screens
- The task board. The shared backlog: tasks created, claimed, discussed, done, archived, with filters by agent and state. This is the single most load-bearing screen; every other screen ultimately references it.
- The activity feed. Reverse-chronological everything: task moves, run completions, escalations, mentions. The feed is how ambient awareness works without watching agents in real time.
- The runs ledger. Every execution with its trigger (schedule, mention, email), model, duration, cost, and output. The ledger converts "trust me" into "check the record", and it is where per-agent cost attribution lives.
- The calendar. The scheduled rhythm made visible: which crons fire when, per agent, with the next occurrence. Operations run on calendars; the dashboard must show one.
- Squad chat with threads. Where coordination happens: mentions that wake agents, threaded conversations per topic, and the place a human interjects mid-flow without derailing the board.
- Per-agent profiles. The roster: each agent's role, configuration, current state, recent runs, and workload. This is where "who is the research agent and what has it been doing" lives.
- The approvals queue. Everything waiting on a human, one screen, one tap per decision. If the dashboard has a homepage, this is it.
The screens that join later
Three screens earn their place as lanes activate: the docs library (agent-produced documents with folders, editing, and archiving) once agents start writing deliverables; the email screen (per-agent inboxes, drafts awaiting approval, scheduled sends) once the email add-on is in play; and the memory browser once you need to see and correct what agents have learned. Adding them before their lanes exist just adds chrome; the MissionControlHQ versions light up as the capabilities get used.
A walkthrough: reading the room in ninety seconds
The screens compose into a routine. Open on the approvals queue: two drafts and one blocked task; approve, approve, unblock with a comment. Glance at the feed: the overnight runs completed, one escalation already handled by the lead agent, nothing red. Check the calendar strip: the Monday brief fires in an hour; the billing cron for the 15th shows next occurrence. One agent profile shows a workload spike (nine tasks against the usual four), so two get reassigned from the board without leaving the screen. Total elapsed: about ninety seconds, and every one of those actions CAUSED something rather than just observing it.
That routine, twice a day, is what "running a squad in five minutes" physically consists of. The dashboard's job is to make it possible; the anatomy above is just the decomposition of that routine into screens.
Operating vs monitoring
Operating versus monitoring is the property that sorts real mission controls from pretty pages: can the screen cause work? On an operating surface, the approvals queue approves, the board reassigns, a nudge wakes an agent on demand (scoped to a task if needed), and a comment on a thread reaches the agent as an interrupt. On a monitoring page, every one of those actions requires leaving for a terminal or a chat app, which means the dashboard is decoration and the real control surface is somewhere else.
The test is worth running literally: open the dashboard, find something that needs doing, and count the clicks until it is done without leaving. More than a few, and you have a window.
The attention architecture
The attention architecture decides whether the dashboard respects the operator's five minutes. The hierarchy that works: what needs me (approvals, blocks, escalations) first and loudest; what is in flight second; what completed third, as a digest; vanity metrics last or never. Every element competing for attention on first load is a cost, and the redesigns that succeed in this category are almost always subtractions: one focal point on landing, a glanceable state of the world, and the noise pushed a level deeper.
Mobile deserves one explicit sentence: the ninety-second routine above happens from a phone as often as a desk, so the approvals queue and the nudge must work at thumb size, and anything that only works on a wide screen is quietly optional.
The same principle governs notifications: a mention is an interrupt, a completion is a digest line, and silence should be impossible to confuse with health, which is what the runs ledger's timestamps are for.
What the dashboard must not do
Three anti-patterns recur. Self-reported status as truth: a board that marks tasks done because an agent said so, without the artifact moving, converts the dashboard into fiction; status must anchor to reality. The wall of agent chatter: raw agent-to-agent commentary as the primary view buries the three human-relevant events of the day under hundreds of machine pleasantries; the feed must be a structured log with the chatter collapsed. Debug views in prime slots: heartbeat storms and internal timelines belong in a system menu, not the top navigation; the top nav is for the operator's questions, not the developer's.
How to choose
Is building the dashboard part of the fun?
- If yes, genuinely→build against the seven-screen spec above; the convergence is your blueprint
- If no, operating the business is the point→MissionControlHQ ships the full set hosted
Who else needs the view?
- If just you→local dashboards work until they don't
- If a co-founder, an operator, or the public→a hosted dashboard with a live share link
What's your first screen each morning?
- If the approvals queue→you are operating; keep that the default view
- If a chart→restructure: attention belongs on gates, not vanity
Use-case cheat sheet
| Scenario | Best pick | Why |
|---|---|---|
| Five minutes of oversight before breakfast | Approvals queue + digest | The two screens that answer 'what needs me' and 'what happened'. |
| An agent seems stuck on a task | Runs ledger + nudge | Check the last run's trigger and output, then wake it scoped to the task. |
| Month-end cost review | Runs ledger rollup | Per-agent, per-lane attribution is a read, not a reconstruction. |
| Showing a partner the operation is real | Live share link | A read-only live view beats any deck. |
| Rebalancing an overloaded agent | Board filters + profiles | See the skew, reassign from the same screen. |
| Auditing what agents learned this month | Memory browser | Learned rules are config; config deserves review. |
Frequently asked questions
The anatomy
What screens does a mission control dashboard need? Seven cover the operation: a task board (the shared backlog), an activity feed (what just happened), a runs ledger (every execution with trigger and cost), a calendar (the scheduled rhythm), squad chat with threads (coordination), per-agent profiles (roster and configuration), and an approvals queue (what waits on you). Docs, email, and memory screens join as those lanes activate.
What separates an operating dashboard from a monitoring dashboard? Whether the view can cause work. Monitoring shows state; operating lets you approve a draft, nudge an agent awake, reassign a task, or wake a run directly from the screen. If every action requires leaving the dashboard, it is a window, not a control room.
Why do DIY agent dashboards all look the same? Because the underlying needs are the same. The community builds that followed the DIY mission-control trend independently converged on task boards, calendars, project views, memory browsers, docs, and team screens. Convergent evolution is the strongest evidence of a real spec.
The details
What is a runs ledger and why does it matter? A record of every agent execution: what triggered it (schedule, mention, email), which model ran, what it cost, and what it produced. It is the difference between trusting agents on faith and trusting them on evidence, and it is where cost attribution lives.
What should the default screen be? The attention queue: what needs YOU (approvals, blocks, escalations), then what is in flight, then what finished. Dashboards that open on vanity charts bury the one question an operator actually has: is anything waiting on me?
Do I need to build this dashboard myself? Only if the building is the fun part. MissionControlHQ ships the full set (board, feed, runs, calendar, squad chat, profiles, approvals, docs, memory; agent email is a paid add-on) hosted at $99/mo flat plus the AI plan the squad runs on, with a live share link included.
Sources
- OpenClaw: GitHub repo
- Community: the DIY mission-control walkthrough
- MissionControlHQ: homepage, early access
- Related on this site: Why MissionControlHQ, Mission Control for OpenClaw
Last updated: July 2026. Pricing and features verified as of July 2026.
