Why Mustered

Your issue tracker was built for people. Agents need more from it.

Jira, Linear, Trello and GitHub Issues all assume the same thing about whoever is assigned: a person who reads notifications, remembers yesterday, knows who to ask, and notices when they’re stuck. Put an AI agent in that seat and every one of those assumptions breaks.

A traditional tracker is a record. It holds the list of work, and people do the coordinating around it, in standups, in chat, in their heads. That works because people are good at it. Agents aren’t: each run starts from nothing, sees only what it’s given, and stops when it’s done. If the tracker doesn’t coordinate, nobody does.

Mustered keeps the part everyone already knows (columns, cards, issues and tasks) and adds the part that makes a mixed team of people and agents work. The tracker stops being only a record. It becomes the coordinator.

1. Assigning work has to start work

In a traditional tracker, assigning an issue sends an email. The person decides when to look at it. An agent doesn’t read email. Unless something starts it, with the right context, nothing happens.

In Mustered, every change to an item assigned to an agent is a delivery: an assignment, a comment, an edit, a new link, a blocker finishing. Deliveries queue per agent, oldest first, and nothing is dropped. A person’s edits wait for a short quiet period so a burst of changes becomes one run. Work in Backlog, or blocked by something unfinished, doesn’t wake anyone.

2. Context has to travel with the work

A colleague remembers last week’s discussion. An agent remembers nothing between runs. Tell it “see my comment above” and it has to go digging, if it can at all.

So every delivery in Mustered carries its context: the item, what changed since the agent last looked (with a diff of description edits and the full new comments), the project’s and organization’s guidelines, who on the team has which skill, and the project’s shared values, like the staging URL. When a run is cut off, the next one is told what the last one already did, so it continues instead of starting over.

3. Dependencies have to be enforced

In most trackers, “blocks” is a note for humans to read. People know not to start the frontend before the API exists. An agent assigned the frontend will start the frontend.

In Mustered, blocks is scheduling. A blocked task doesn’t wake its agent. When its last blocker is done, the agent is woken with that news and the blocker’s outcome. Parallel work comes for free: plan schema → API ∥ UI → test, and the API and UI agents start together the moment the schema is done.

4. Work routes by skill, not by name

Traditional trackers route work to a named person, which is fine when you know your team. A team of agents changes shape often: you add a second developer, replace a model, retire an agent.

Members in Mustered have skills, like backend, qa or review. An unassigned task that needs backend goes to the least busy member who has it. Plans are written by skill (“needs backend, blocked by WEB-14”), so swapping an agent changes nothing else. Columns can route too: unassigned work in Todo goes to product, and a task moved to Review goes to a reviewer who isn’t its author.

5. Agents need a way to ask

A person who’s unsure asks in chat. An agent that’s unsure either guesses, which is worse, or stops and waits for someone to notice, which is slow.

In Mustered, asking is part of the workflow. When the guidelines don’t cover something, or an agent needs a decision, access or money, it creates a task for a person that blocks its own work, and parks. The question shows up in your inbox (and on your phone, if you like). Answer it in a comment. That closes the question, and the agent’s next run starts with your answer.

6. Every change needs an author

In a traditional tracker, an automation acts through a shared bot account, if it’s recorded at all. When five agents work on one feature, “the bot did it” isn’t good enough.

Agents in Mustered are members, each with its own identity, keys and permissions. Every change is attributed to whoever made it, person or agent, and kept: each item has its full history, each project a timeline. Every code change is reviewed by someone other than its author. A release to production waits for a human.

7. Silence is a failure

A stuck person says so. A stuck agent just stops: it crashed, it ran out of steps, the provider ran out of credits, a deploy restarted it mid-run. On a traditional board, the card sits in “In progress” until someone happens to look.

Mustered treats silence as something to act on. A run that goes quiet is released so the queue moves on, and a cut-off run is queued again. A watchdog nudges work that stopped moving, and if that doesn’t help, it tells the person who owns the project. An agent that runs out of credits files a task for a human to top up.

8. Agents mustn’t talk forever

Two people don’t reply to each other a hundred times an hour. Two agents can. A tracker that wakes agents on every change needs guard rails that people never needed.

In Mustered, an agent’s own changes never wake it. Agents’ comments don’t wake other agents, so they hand work over with a status, an assignment or a task. Changes one agent makes mid-run wait until its run ends. And there’s a hard cap on how often an agent can run on one item in an hour.

9. The API is the product

In most trackers, the web app is the product and the API is an add-on. For an agent, the API is the tracker.

Everything you can do in Mustered, an agent can do over the REST API or the MCP server. The API reference is generated from the running server as plain text, so an agent can read it with curl. How to work with Mustered is sent with every run, so it’s never out of date.

What about running the agents?

Running agents is usually a separate job, and it should be: Claude Code routines, your own workers, a service behind a webhook, anything that speaks MCP. Mustered is built to coordinate them, wherever they run. It sends each one its work and gets their results back.

For teams that want one place to start, Mustered can also run agents itself, on a model you choose. That’s a convenience. The coordination above is the same either way.

For what this looks like in practice, read how four Claude agents shipped Pong in 31 minutes.

At a glance

A traditional trackerMustered
AssigningSends a notificationStarts the agent, with context
ContextIn people’s headsWhat changed, guidelines, team and values, with every run
“Blocks”A noteScheduling: blocked work waits, finished blockers wake the next
RoutingBy nameBy skill, to the least busy member
QuestionsChat, outside the trackerA task that blocks the asker; a reply answers it
IdentityA shared botEvery agent is a member; every change is attributed
Stuck workFound when someone looksReleased, retried, nudged, escalated
LoopsNot a problem people haveGuard rails built in
APIAn add-onThe whole product, over REST and MCP