Mission Control: When Agents Become a Team

There is a strange moment in every automation project where the system starts doing enough useful work that you lose track of it.

That sounds like a good problem, and in some ways it is. The Hub had agents with different personalities and responsibilities. It had scheduled skills waking up on their own. It had FOUNDRY exposing workflows as tools. It had a growing set of projects, docs, logs, and capture pipelines. Individually, each part made sense.

Together, they started to create a new problem: I no longer had a single place to answer the basic operational question.

What is the system doing?

Not “what can it do?” That was documented reasonably well. Not “what happened yesterday?” The session logs were there for that. I mean the live, practical question: which agents are active, what work is assigned, what is scheduled, what is stale, and where should I look when something needs attention?

That was the beginning of Mission Control.

The problem with invisible work

Most personal automation starts as a script. A script is easy to reason about because you run it, watch it finish, and move on. Once automation becomes scheduled, distributed, and agent-driven, the work becomes less visible.

Nightcrawler might process captures. JARVIS might scan repositories. SAGE might classify videos. FOUNDRY might run workflows in response to tool calls. A background runner might wake up every few minutes and decide nothing is due. Each individual action is small, but the system as a whole becomes alive in a way that is hard to see from one terminal window.

The first instinct is to add logs. Logs help, but logs are history. They tell you what happened after you know where to look. I needed something closer to an operating surface: a place that could show capabilities, scheduled work, assigned work, and status in one view.

The real shift was realizing that “agent operations” is a product surface, even if the only user is me.

Two kinds of work

The first split I made was between scheduled operations and assigned tasks.

Scheduled operations are the work agents do because time passes. Birthday reminders, repository scans, capture processing, sync jobs, recommendation runs. These belong to the heartbeat model. They have cadence, ownership, last run status, and failure modes.

Assigned tasks are different. They are pieces of work I want an agent, CLI session, or background worker to pick up intentionally: improve a workflow, investigate an issue, write a blog post, fix a broken integration, evaluate a model. Those need assignment, priority, progress, discussion, and a durable record.

Trying to force both into the same storage model felt wrong. A cron-like skill and a product issue are not the same thing. So Mission Control got two conceptual lanes: scheduled ops for recurring work, and project tasks for intentional work.

Capability register versus work board

This led to the second important distinction: what agents can do versus what agents are doing.

Inside The Hub, I keep a Tasks area as a capability register. It describes skills and repeatable task types: what the task is, which agent can run it, what inputs it expects, what output should look like, and which systems it touches. This is not a backlog. It is closer to a catalog of available moves.

GitHub issues and project boards are a better fit for actual work. They already have status, labels, assignees, comments, history, and pull request links. They also sit near the code, which matters because a lot of agent work eventually becomes a branch, a commit, or a review.

That separation feels small, but it prevents a lot of confusion. The Hub can document that “classify YouTube inbox videos” is a capability. A GitHub issue can track “make the classifier faster on the local model.” One is a reusable operation. The other is work in progress.

When I started thinking this way, Mission Control became less like a dashboard and more like an air traffic control surface. It should not own every plane. It should know what is flying, where it is going, and what needs attention.

GitHub as the work surface

I briefly considered building a custom task system inside The Hub. That would have been fun, but also exactly the wrong kind of fun.

GitHub already has the primitives I need for software-shaped work. Issues are durable. Pull requests are reviewable. Project boards add workflow state without inventing a database. Labels are good enough for routing. Comments are good enough for handoff notes. Most importantly, agents and CLI tools can already interact with GitHub safely and predictably.

So Mission Control does not replace GitHub. It reads from it.

The board becomes the place where assigned work lives. The Hub remains the place where long-term context lives. The agents sit between them: reading context, acting on issues, and writing results back in a way I can audit.

This is also where the worker model started to matter. Not every task should be picked up by an always-on agent. Some work needs a terminal. Some work needs a browser. Some work needs credentials that should stay inside FOUNDRY. Mission Control needed to show the work, but the runtime choice needed its own model.

That became the next post.

What I wanted to see

The first version of Mission Control did not need to be fancy. I wanted a few concrete answers:

1. Which scheduled skills exist, who owns them, and when did they last run?
2. Which GitHub issues are assigned to agent-related work?
3. Which pull requests are open, stale, blocked, or ready for review?
4. Which projects in The Hub have active work?
5. Which failures need a human decision instead of another retry?

The last one is the most important. A good operational surface should reduce pointless checking. If everything is fine, it should be quiet. If something needs me, it should make the next action obvious.

That is the same design principle I use for proactive agents. Silence is a feature. Noise is debt.

The emotional side of operations

The funny thing about building personal infrastructure is that it changes your relationship with your own attention.

Before Mission Control, my agents were helpful but slightly uncanny. They would do things, message me, write logs, update files, and then disappear back into the system. I trusted them individually, but I did not yet trust the whole operation. There was no shared room where everyone stood around the same map.

Mission Control is that room.

It turns agents from isolated helpers into a team I can reason about. Nightcrawler can have scheduled duties. JARVIS can watch code health. SAGE can handle recommendation and classification work. FOUNDRY can provide the hands. GitHub can hold the active work. The Hub can hold the memory.

Once those roles are visible, the system feels less like a pile of clever automation and more like an organization.

That is a big word for a personal project, but it fits. The moment agents become proactive, distributed, and able to change things, you need operations. You need a way to see the work. You need a way to route the work. You need a way to tell the difference between “the system is quiet” and “the system is broken.”

Mission Control is my answer to that.

Not a flashy dashboard for its own sake. A place where the work becomes visible.