Show HN: Mission Control – Open-source task management for AI agents

[meisnerd]

I've been delegating work to Claude Code for the past few months, and it's been genuinely transformative—but managing multiple agents doing different things became chaos. No tool existed for this workflow, so I built one. The Problem

When you're working with AI agents (Claude Code, Cursor, Windsurf), you end up in a weird situation: - You have tasks scattered across your head, Slack, email, and the CLI - Agents need clear work items, context, and role-specific instructions - You have no visibility into what agents are actually doing - Failed tasks just... disappear. No retry, no notification - Each agent context-switches constantly because you're hand-feeding them work

I was manually shepherding agents, copying task descriptions, restarting failed sessions, and losing track of what needed done next. It felt like hiring expensive contractors but managing them like a disorganized chaos experiment.

The Solution

Mission Control is a task management app purpose-built for delegating work to AI agents. It's got the expected stuff (Eisenhower matrix, kanban board, goal hierarchy) but built from the assumption that your collaborators are Claude, not humans.

The killer feature is the autonomous daemon. It runs in the background, polls your task queue, spawns Claude Code sessions automatically, handles retries, manages concurrency, and respects your cron-scheduled work. One click: your entire work queue activates.

The Architecture

- Local-first: Everything lives in JSON files. No database, no cloud dependency, no vendor lock-in. - Token-optimized API: The task/decision payloads are ~50 tokens vs ~5,400 unfiltered. Matters when you're spawning agents repeatedly. - Rock-solid concurrency: Zod validation + async-mutex locking prevents corruption under concurrent writes. - 193 automated tests: This thing has to be reliable. It's doing unattended work.

The app is Next.js 15 with 5 built-in agent roles (researcher, developer, marketer, business-analyst, plus you). You define reusable skills as markdown that get injected into agent prompts. Agents report back through an inbox + decisions queue.

Why Release This?

A few people have asked for access, and I think it's genuinely useful for anyone delegating to AI. It's MIT licensed, open source, and actively maintained.

What's Next

- Human collaboration (sharing tasks with real team members) - Integrations with GitHub issues and email inboxes - Better observability dashboard for daemon execution - Custom agent templates (currently hardcoded roles)

If you're doing something similar—delegating serious work to AI—check it out and let me know what's broken.

GitHub: https://github.com/MeisnerDan/mission-control

[formreply]

The pattern you're describing — tasks scattering across Slack, email, and the CLI — is really a signal flow problem. Email is still where a lot of meaningful work originates (a client sends a question, a contractor delivers an update), but nothing today bridges that into an agent-native task queue cleanly.

Your roadmap mentions GitHub issues and email inboxes as upcoming integrations. For email specifically, the friction point I'd flag is that most inbound email carries context that agents need: who sent it, what prior thread it belongs to, what action is expected. A raw forward loses that structure. Worth thinking about whether the inbox integration consumes a parsed webhook payload (structured sender, subject, body, thread ID) vs. raw MIME — the former is dramatically easier for agents to act on.

The compressed context snapshot (ai-context.md) is a clever workaround for the amnesia problem. The gap it can't close is task provenance — knowing why a task exists, not just what it is. Linking tasks back to their originating email/Slack message/PR would give agents (and you) much better auditability when something goes wrong.

[meisnerd]

You're right that this is fundamentally a signal flow problem. The whole architecture is designed around that — tasks, inbox messages, decisions, and activity log are all just JSON files that any agent can read/write. The daemon polls for new signals and dispatches work automatically.

On email specifically: great callout about structured vs raw MIME. My current thinking is a parsed webhook approach — sender, subject, body, thread ID as structured fields. Raw MIME would be a nightmare for agents to parse and waste tokens on headers nobody cares about. The GitHub Issues integration is closer to shipping (it's one of our open issues now), email is further out but the inbox architecture already supports it — just needs an ingest layer.

Task provenance is an interesting gap you've identified. Right now tasks have createdAt, assignedTo, and the activity log tracks every state change, but there's no explicit "originated from" field linking back to an email or Slack message. That would be a clean addition to the schema — something like source: { type: "email" | "github" | "manual", ref: "..." }. Appreciate the specific feedback.

[AlexCalderAI]

When you're running multiple Claude Code agents (or even just one agent working on complex problems), this task scattering is real.

We solve it differently—all agent state lives in markdown files + git history. Simpler than MCP, more transparent than a database.

The key insight: make debugging obvious. When something breaks, you should be able to grep the logs and understand exactly what happened. Black box task managers fail at this.

[meisnerd]

100% agree on making debugging obvious. That's exactly why everything is local JSON files — you can literally cat tasks.json | jq '.tasks[] | select(.kanban=="in-progress")' and see exactly what's happening. No database queries, no admin panels, just files.

The activity log captures every state change with timestamps and actor IDs, so when something breaks you can trace the exact sequence. And since agents communicate through inbox.json, there's a full message trail — who delegated what, what reports came back, what decisions were requested.

Curious about your markdown + git approach — do you get merge conflicts when multiple agents write to the same state files simultaneously? That was the main reason I went with JSON + async-mutex instead. Git history gives you great auditability but concurrent writes to the same file need some kind of coordination layer.

[cschneid]

Can this take vague ideas, do iterative design with me, and breakdown tasks to then pass off to agents to build?

I was playing with a very similar project recently that was more focused on a high level input ("Build a new whatever dashboard, <more braindump>") and went back and forth with an agent to clarify and refine. Then broke down into Epics/Stories/Tasks, and then handed those off automatically to build.

The workflow then is iterating on those high level requests. Heavily inspired by the dark factory posts that have been making the rounds recently.

From a glance, it seems like this is designed so that I write all the tasks myself? Does it have any sort of coordination layer to manage git, or otherwise keep agents from stepping on each other?

[bumpyclock]

I've been working on a similar project https://github.com/BumpyClock/tasque . Tracks tasks (Epics, tasks, subtasks) with deps between them. So I plan for an hour or so and then when I walk away from my desk I had the tasks for the agents to code and then I can come back and verify.

Edit: minor note, one additional thing that is in the skill that the tool installs is to direct the agent to create follow up tasks for any bugs or refactor opportunities that it encounters. I find this let's the agent scratch that itch of they see something but instead of getting sidetracked and doing that thing, they create a follow up tasks that I can review later and they can move on.

[zingar]

Could you tell us what makes this different from other agent orchestration software?

Also I’m struggling to understand the significance of the 193 tests. Are these to validate the output of the agents?

If they’re just there to prevent regressions in your code, the size of a test suite is not usually a selling point. In particular, for a product this complicated, 193 is a small number of tests, which either means each test does a lot (probably too much) or you’re lacking coverage. Either way I wouldn’t advertise “193 tests”.

[brickers]

I agree with what you’re saying. However given the reputation of openclaw (and I presume many other vibe coded spaghetti monsters) I appreciate the signal “I care about quality”.

[ge96]

Interesting that most of it is markdown

well except the mission control folder

code is mix of old and new style JS eg. function vs. =>

at a cursory glance the UI has way too many buttons/features but probably makes sense when you're in the weeds/using it, it makes sense the more I look at it though

[bravura]

How opinionated is this? Could it be a CLI?

Can it work with beads for tracking the state of everything?

i.e. do I need to buy in to an entire worldview to adopt this, or can I use it piecemeal?

[meisnerd]

It's modular by design, but the UI is the primary interface — no standalone CLI yet. On the opinionated/piecemeal question: the data layer is intentionally unopinionated. Everything is plain JSON files — tasks.json, inbox.json, decisions.json, etc. Any tool that can read/write local files can participate. I've had Claude Code, Cursor, and custom scripts all interacting with the same task queue without touching the web UI. So at the data level, it's fully piecemeal. The UI is more opinionated — it assumes an Eisenhower matrix + kanban + inbox workflow. But you don't have to use all of it. Some people just use the kanban and ignore the priority matrix entirely. A CLI is an interesting idea and something I've thought about. The API is already there (token-optimized REST endpoints for everything), so wrapping it in a mc tasks list --assignedTo=developer --kanban=in-progress style CLI would be straightforward. If that's something you'd use, I'd bump it up the roadmap — would you open an issue? Haven't looked at beads specifically — could you share more about what you mean by tracking state with beads? Curious if it maps to something Mission Control already does (the checkpoint/snapshot system saves full workspace state and lets you roll back) or if it's a different paradigm entirely.

[slake]

I'm wondering if this can use different workspace folders for different projects? I'd like to manage all my side projects through this but I can't put them all in one folder.

[meisnerd]

Yes. When you're making the task (or asking claude code to populate the mission/subtasks), you can mention what folder to output to (like in the task description or mission). So far I havent specified, and it has just been dropping research reports in a /research folder that it made; a /projects folder for project outputs, etc.

[xiphias2]

Congrats! Great try!

I have a different view point on what to automate and I'm working differently with agents, but I much prefer seeing projects like this on HN to just product announcements.

[nikolas_sapa]

wow bro, more people need to hear about this. I dont have access yet to Claude Code but I use the free claude for coding tasks and it is still a headache. so when I will get Claude Code will use it for sure. also why dont you have a landing page that lead to the git so you can get more traffic?

[meisnerd]

Thanks, man! A landing page is definitely on the list — right now I'm focused on getting the core solid first, but you're right that it would help with discoverability. For now the GitHub README is doing double duty as the landing page.

And you don't actually need Claude Code to use it — Mission Control works with any AI agent that can read/write local files. The data layer is just JSON, and the API is token-optimized (~50 tokens per request vs ~5,400 unfiltered, about a 94% reduction) so it's lightweight for any agent to consume. The Eisenhower matrix, Kanban, goal hierarchy, and brain dump all work standalone too. The daemon and agent orchestration just layer on top when you're ready for it.

[nikolas_sapa]

thanks bro for the mission. in deed building the core is more important. give value to initial users and then focus on making it mainstream. good luck