Run a whole team of coding agents like one product

One agent is easy to watch. Five are not. Mission Control gives a fleet of Claude Code, Codex and Pi sessions a single control room: a board that tells you who needs you, a backlog that feeds them work, an autonomous operator that handles the routine interruptions, a review system that decides what "done" means, a merge gate for what lands without you, and a memory so the next agent does not repeat the last one's mistake. When a whole SDLC engine is driving the work instead, it watches that too.

01The board

One column per state, so "what is my fleet doing" is a glance, not an investigation.

• Needs you comes first. A card is amber only when a person has to act. When nothing is waiting, the column says All clear out loud instead of leaving you to infer it.
• Every card answers "what is this for?" - a one-line goal written from your own prompts, the tool it is running right now, how far its review has got, its branch, its model, its cost so far, and how much context it has left. You choose which of those it draws, with a live preview card beside the checklist - except the flags that ask for you, which cannot be switched off, because no setting should make a session that needs you look like one that does not.
• Cards group under the repository they belong to, so a fleet spread over four checkouts reads as four teams rather than one queue.
• Drag a backlog item onto a free agent to hand it over. If that agent is not actually free, the board says so rather than quietly resetting it.
• Fully keyboard-driven. Arrow keys move, Enter opens, Esc backs out one layer at a time, / filters - by name, by repository, or by pull request number - and every button prints its own shortcut.

You get told when something needs you

Notifications fire the moment an agent starts waiting - not repeatedly while it waits. Turn on Away mode and Mission Control holds everything back and hands you one digest when you return, except for genuinely stuck agents, which always get through. A one-key Sitrep gives you the whole fleet as a readable summary.

It also runs as a real macOS app rather than a browser tab, which is what makes that promise keepable: the window can be closed and the alerts still arrive. It installs from your own machine, keeps itself current from releases, and will hold the Mac awake with the screen dark while agents work.

02Every agent's desk

Click any card and you get the conversation, the change, and the files - plus every control you need to steer it.

Conversation

Read the session as a terminal stream or as a chat log. Your messages, the agent's, and Foreman's are colour-coded, tool activity is folded into a single line you can expand, and a side rail indexes either every tool the agent ran or just your own messages - useful, because most of a transcript is not you.

• Type to any agent, any time. Messages queue up visibly, and you can edit or reorder them before they land. ↑ recalls the last one.
• Answer questions in place - single choice, multi-select, permission prompts, folder-trust checks. If Mission Control cannot be sure a message was delivered, it tells you and offers to retry rather than assuming.
• Change its posture on the fly - ask-me-first, accept edits, plan mode, read-only - and interrupt a turn with one key.
• Drop in screenshots and images straight into the composer, and read the agent's own HTML - a report, a plan - rendered in the conversation instead of as a path you have to go and find.

Diff

The diff shows what this agent changed - not everything that has happened on the main branch since it started. If a file cannot be opened for editing, the row says why instead of failing silently.

Files

You can also review a file the way you would review a pull request: leave a comment on a line, then walk the agent through your comments one at a time - one per turn, and the next only once it has finished with the one before. Its answer lands in that comment's thread, on that line, and the tab raises a count of answers nobody has read yet.

Review progress

A terminal in the agent's own working copy is one click away, in whichever terminal app you actually use - WezTerm, Ghostty, iTerm2, tmux - and the ones that are not installed are listed with the reason, not hidden.

03Dispatch & task types

Describe the work, pick who does it, and it starts - in its own isolated copy of the repo, so agents never trip over each other.

• Guided or straight to the form. The guided pass is four keystrokes; skip it whenever you already know what you want.
• Send it now or shelve it. The same form adds to the backlog, and clicking a shelved item reopens it for editing.
• Attach more than one repo. A change that spans services stays one agent and one conversation - a worktree per repository, one pull request per repository it actually changed, and a full review run per changed repository, each spending its own repair budget so a finding in one never holds up a sibling's merge. The task is done when every one of them has merged.
• Nothing is claimed until it is true. If an agent cannot be confirmed as started, the dispatch fails - it is never reported as running when it is not.

Five kinds of work

04Standing instructions

The things you would otherwise re-type into every agent you point at a repository.

Every repository has a handful of rules that are not in its README and are not worth a pull request. Integration tests need Postgres up first. Never edit the generated client. This service owns the public API, so a route rename is a breaking change. Write them once here and the next agent dispatched into that checkout already knows.

05Scouts & the archive

Not every question needs a code change. Send a scout and you get an answer you can keep.

Half of what a team asks an agent is not "build this" - it is why is this slow, where did this behaviour come from, which of these three approaches is least risky. A scout is that job. It investigates, and instead of a branch and a pull request you get one page that answers the question - filed, searchable, and still readable long after the work is gone.

What a scout gives you

The archive

• Everything is searchable, including the question. You can find a report by what it concluded, by the file it examined, or by what you originally asked.
• Reports outlive their work. The branch, the agent and the task are all temporary. Deleting any of them never deletes the report.
• They are just files. Portable, openable outside Mission Control, and honest about their own gaps - a report missing part of its evidence says so instead of looking complete.
• Plans land here too, so the reasoning behind a piece of work stays available after the work ships.

06Backlog & sources

Everything that should happen but has not started yet - fed by the tools where you already wrote it down.

• Order it how you like - priority, labels, and a hold switch that keeps an item on the list but off the launch pad.
• Chain work together. Say one task depends on another and it waits until the first one's pull request has actually merged.
• Or let it run itself. Turn on autopilot and Mission Control works down the list one item at a time, reusing agents that are genuinely free, never exceeding the number of agents you allow.

Work arrives on its own

A sweep's rows arrive parked, with autopilot switched off for them, so what a tracker hands you is a list you triage rather than work that starts dispatching before you have read a title. Enabling a row is you saying yes to that row - and a source whose upstream you already curate can be set to file ready-to-schedule tasks instead. Agents can file follow-up work themselves, a finished retrospective can queue its own task, and a shelved idea can be pushed out to GitHub as an issue when it belongs in the open.

Recurring missions

Missed runs are handled honestly: if the machine was asleep, the schedule says so and accounts for the run once, rather than pretending it happened on time.

07Foreman

An optional operator that handles the interruptions you would have handled anyway - and escalates the ones only you can decide.

Most of what a fleet asks you is routine: may I read this file, is this the right directory, shall I run the tests. Foreman reads what each blocked agent is actually asking, answers the routine calls, and turns the real forks into a short brief with a recommendation - so the only things that reach you are the things worth your attention.

It also keeps agents moving without you: it drains the follow-up work you queued - one item at a time, each one verified as landed before the next is released - checks each against your repo's own standards before calling it done, nudges an agent when one of its pull requests picks up review comments or fails CI, and wraps up work that is finished.

08Workflows & Personas

Decide once what "done" means, then have every change held to it.

A review that runs itself

• Cheap checks first. A change that does not compile never reaches a reviewer, so it never costs one.
• Reviewers run in parallel against the same snapshot of the work, and a stage only advances when all of them pass.
• Failures come back as one clear list of what to fix - not a wall of restated opinions - and you set how many attempts it gets.
• The pull request is a stage, not an afterthought, and the run cannot finish until Mission Control has seen the pull request exist at the commit it reviewed.
• Published reviews are frozen. Editing a reviewer tomorrow cannot change what a review that already ran was judging against.

Reviewers you write yourself

Each reviewer has exactly one job, which is what makes their verdicts useful: the risk reviewer is told not to demand an abstraction as the price of passing, the design reviewer is the only one that may object to shape, and the intent reviewer only fails a change that removed something you asked for or added something you forbade. The slop filter is the newest of them, and it rejects the thing a fast agent produces most: redundant comments, defensive branches nothing asked for, mock-only tests, padded prose.

They judge more than the diff. Whatever the agent registered as evidence - a screenshot it took, a focused log, the exact output of a command it ran - is part of what they read, none of it committed. A reviewer that could not be reached is reported as unavailable - never as a rejection.

Steps that ask the agent to do something

09Shipping & the GitHub reviewer

The last mile, and the one place an autonomous fleet can do real damage - so it is gated at every step and off until you say otherwise.

The reviewers in the last section run on your machine, before a pull request exists. The GitHub Inspector is the other half: it reviews the pull requests Mission Control opened - and only those - on GitHub itself, against standards you keep in the repository, so each project sets its own bar.

• It comments inline on what it finds, answers replies in its own threads, re-reviews on every push, and resolves its own threads once a push fixes what they were about.
• It never approves and never blocks. When a review finds nothing further and every earlier finding is resolved, it says so in one comment - and that is all it does.
• Only pull requests it can prove are ours. A pull request is adopted when the agent was seen to open it. One a colleague opened on the same branch is never touched.
• Dry run is genuinely dry. It reviews, records what it found, and posts nothing - so you can read what it would have said before it says it.

And, if you let it, the merge

With YOLO mode on, a pull request Mission Control opened merges itself once every one of these is true on the same read - and each of them is a way the fleet could otherwise have shipped something nobody looked at:

• Reviewed, and published, on this push. A review of the previous head is not a review of what would land. Dry run means dry for the merge too: it reviews and publishes nothing, so nothing qualifies.
• Nothing outstanding - no open findings, and no unresolved review thread, whoever asked it. It will not merge over a colleague's unanswered question.
• No human veto. Anyone requesting changes, or a required review still outstanding, stops it dead.
• CI green on the head commit. A commit with no checks does not pass this - it has never been asked.
• Open for the soak - the window in which somebody can look and say no. Ten minutes by default, and a push resets the review rather than the clock.
• Two separate grants. Letting the reviewer comment on a repository is a smaller permission than letting it merge there, so a repository has to be on both lists - and the one dangerous combination, merge granted without review, is flagged in amber.

The merge is a compare-and-swap against the exact head that was evaluated, so a push landing in the seconds between the decision and the call makes GitHub refuse rather than merge code nothing has looked at. When GitHub refuses for a reason this app cannot see - a branch protection rule - its own message is shown verbatim, because that is the only account you get of it.

10AI Conductor

When the work is driven by a whole SDLC engine instead of a single agent, that shows up on the same board as everything else.

Some work is not one agent taking a task from start to finish. ai-conductor walks a feature through a fixed, gated 22-step pipeline in its own worktree, runs its own agents, keeps its own state on disk, and halts for a human when a gate refuses. Mission Control does not replace it and does not merge with it. It watches - and acts through the engine's own command line, which is a different thing, deliberately.

What it looks like once it is on

• A second tab on Runs. Workflows is the page it always was; Pipelines is what the engine is driving - grouped per repository under its daemon's state, each feature's whole gated sequence drawn in the same grammar a workflow run uses. A step this build has never heard of renders in the state the engine reported rather than breaking the page.
• The engine's agents appear on your fleet, marked as its rather than yours: they wear the run's badge, group under it, and have a sentence where the composer would be, because nothing typed at them would be read.
• A halt is a row in your inbox - with its class, what the engine said stopped it, and the runbook that clears it. It is the one thing waiting on you with no session behind it, because the agent that hit the gate has usually already exited.
• You can act, not just read. Start, stop, pause and resume the engine's daemon, park and unpark a feature, authorize one re-entry with your own written rationale, watch the daemon's console, and run its re-seal ceremony in a real terminal.
• Dispatch a pipeline like anything else. An observed repository offers pipeline as a task kind; when the run opens a pull request it is adopted under pipeline provenance and joins Shipped beside the rest. What a shipped feature cost lands in the spend strip under the engine's own figures.
• Foreman can help, narrowly. A separate switch, off by default, lets it unpark only a halt the engine classified as mechanical. Everything else - anything needing a human, anything unclassified - stays yours.

11Retro & memory

So the next agent does not repeat the last one's mistake.

When a piece of work is finished, Mission Control offers a retrospective - but only when there is something to learn, which it works out from whether you had to correct the agent or a reviewer found something real. It never nags, and it is never offered greyed out.

Nothing is written that you did not approve, and the commit is the agent's own - so a lesson arrives for review in the same pull request as the work that taught it.

12Ensembles

When one attempt is not enough, run several and pick the best.

• Judged blind. Judges never see which agent or model produced which attempt, so they cannot have a favourite.
• Judges recommend, you decide. Nothing is promoted and nothing is thrown away until you confirm it.
• Every attempt is kept. The results you did not pick stay available - there is no automatic clean-up you did not ask for.
• Ties are declared, not broken. If the judges genuinely split, you are told that rather than handed an arbitrary winner.

Candidates appear on the board as a group with a progress square each, so a five-way attempt reads as one thing rather than five unrelated agents.

13The whole loop

Read separately these look like a dozen features. They are one loop, with you at the decision points.

The habits that run through all of it