One AI agent in a chat window is manageable. You ask, it works, you read the answer. The trouble starts at two. Put a coding agent on one project, a second on the documentation for another and a third grinding through a batch of files, and the chat window stops being an interface and becomes a row of tabs, each showing the last screen of something you half remember starting.
Mission Control is the dashboard I built for that. It is a real-time view of multi-agent work with six things on the page: project heat-maps, agent orchestration, service health, a document viewer, interactive to-dos and usage tracking. The server is Express, the front end is plain HTML, CSS and JavaScript, and it is a personal tool rather than a product.
I’m Wayne George, a software engineer in London. I build custom software and AI systems for UK businesses through Frontier Consulting, and I use agents heavily in my own work; Mission Control sits with my other projects on the Work page. What follows is not a tour of the code. It is the problem the tool exists to solve, the questions any dashboard of this kind has to answer, and what I would tell you if you were about to build your own.
Why a single chat window stops working
A chat window is designed for one conversation with one participant who waits for you. Run several agents and it fails in three ways.
First, you lose the thread. Each transcript is a linear scroll, so switching between three of them means re-reading the tail of each to work out where it got to. The reading is not the work, and it grows with every agent you add.
Second, you lose track of side effects. An agent that can write files, run commands and make commits is changing things, and in a transcript those changes arrive as a line of prose: “I’ve updated the config.” Which config, in which project, and did something else touch the same file twenty minutes later? The window cannot tell you, because it only knows about itself.
Third, you lose sight of cost. Every exchange is a bill you cannot see while you are running it up, and a long task against a large codebase is a very different bill from a chat about wording.
The interface is the problem, not the agents. So the fix is a different interface.
The three questions
The temptation with a dashboard is to show everything, which produces a wall you stop reading by Wednesday. The discipline is to decide what you would want to know if you glanced at the screen for four seconds while making tea. For me that comes down to three questions per agent: what is it doing, what has it touched, and what is it costing me? The six things on the page are there because each answers part of one of those.
What is it doing: agent orchestration
The orchestration view answers the first question, and the point of it is that it is not a transcript. A transcript tells you what an agent said. A status tells you whether it is working, whether it has finished, and whether it is stuck waiting for a human — and that last state is the one worth building a whole screen for. An agent blocked on a question it needs answering is achieving nothing while the meter runs, and it is exactly the state a row of terminal tabs hides best. If a dashboard like this does nothing else, it should make “waiting on you” impossible to miss.
Where is the effort going: project heat-maps
A heat-map is a crude instrument and that is its virtue. Projects as tiles, warm where there has been activity and cold where there has not, and you can see at a glance that three agents have piled into one repository while the project you promised somebody you would look at has been grey all day. There is no fact on that screen you could not get from a list, but nobody reads the list. Attention is the scarce resource in this kind of work, and a picture of where it went beats an accurate table of where it went.
What did it produce: the document viewer
Agents generate a lot of Markdown — plans, notes, reports, summaries of what they have just done. That output is the main artefact of a research or planning agent, and if reading it means hunting for a file path and squinting at raw text in a terminal, you will skim it. Skimming is how you end up three steps down a road nobody chose. Rendering documents in the same place you watch the agents removes the friction from the one task you should never rush: actually reading the thing before you act on it.
Is the ground solid: service health
Agents lean on other software — a database, a git host, a model endpoint, whatever API the job is really about. When one of those goes down you rarely get a clean failure. You get an agent that retries politely, or one that carries on with stale information and produces confident nonsense. A service health panel is the least clever part of a dashboard like this and probably the biggest time-saver in it, because “the thing it depends on is down” should be a ten-second diagnosis on a screen rather than a twenty-minute one in a log.
What is it costing: usage tracking
Cost has to be visible while it is being incurred, because that is the only point at which seeing it changes anything. A figure you meet at the end of the month is trivia; a figure you can watch climb against a task that is plainly going nowhere is a decision. The roll-ups worth having are by project and by day — by project, so you can see which piece of work is eating the budget, and by day, so a bad afternoon shows up as a bad afternoon. Treat any figure your own tooling produces as an estimate, incidentally, and reconcile it against what the provider actually bills you.
Where the human’s turn lives: interactive to-dos
The easiest mistake with several agents running is to remove yourself from the loop entirely. Watching a chain of them work unattended is enormously satisfying, right up to the moment you discover that step two was wrong and everything since has been built on it.
So a dashboard like this needs somewhere for the human’s turn to live, and a to-do list is the honest form of it: a short queue of the things only you can decide, in the same place as everything else, rather than a decision buried in a transcript you have not opened since lunch. My rule for what belongs there is simple enough to apply while tired. Anything expensive, anything irreversible, and anything visible to somebody else — deleting, pushing to a shared branch, spending real money, sending work to a client — is a person’s call. The rest can run.
It is the same question I put to businesses in You’re asking AI the wrong questions: which steps genuinely need a human, and which involve one only out of habit? Running several agents forces you to answer it, because you cannot supervise everything, and pretending otherwise just means supervising nothing properly.
Keep the record on hardware you control
A dashboard like this accumulates a detailed account of what your agents have been doing, which by extension is an account of what you have been doing and which projects and clients you have been doing it for. That is not something I want sitting on a service I do not control, and it is the same instinct that has me running a private Tailscale network and my own Git host rather than putting everything on somebody else’s box. If you build one, treat it as internal-only from the first commit: retrofitting privacy onto something you have already exposed is a far worse afternoon than starting there.
If you are thinking of building one
Do not start with the dashboard. Start with a log: have every agent write what it is doing, what it touched and what it cost to one place, in whatever crude format takes ten minutes, and live with that for a week. You will find you keep going back for two or three things and ignoring the rest, and those two or three things are your dashboard. The version you would have designed on day one is always prettier and always wrong.
Then build it boring. This kind of tool is scaffolding, not product, so choose something you can fix in ten minutes at eleven at night over something that is elegant on a Tuesday. Every hour spent on the dashboard is an hour not spent on the work it is meant to be watching.
And whatever else you do, keep a step in it that a human has to click. The point of running several agents at once is to get more done, not to find out later what got done to you.