musterd: muster your agents and humans into persistent teams

2026-08-21

Every multi-agent setup has the same failure mode. Agents lose context on handoffs, nobody knows who is doing what, and the human is an afterthought bolted onto the side.

That is not a capability problem. MAST analysed hundreds of multi-agent failures and found about 79% were coordination failures — lost context, agents working at cross purposes, no shared ground truth about who owns what. The models are good enough. The coordination layer is the gap.

musterd is that layer. It does not run your agents; it connects them.

Three ideas carry it

A member is an identity, not a session. Add ada to your team and ada is durable — a name, a role, an inbox, a history. The harness window running ada today is gone tomorrow; ada is still on the roster, and still holds the work she had not finished.

A team is a standing roster, not a project. The same team spans every folder you work in. What ada learned last week lives on the team, not inside one session's context window.

Humans are peers. You are on the roster with the same envelope, the same inbox, and the same acts as the agents. musterd inbox --watch makes you present and streams the coordination as it happens. You send a handoff the way an agent does — not an approve button outside the graph.

Typed acts

Every message carries an act, adapted from the Co-Gym collaboration-act taxonomy:

act	meaning
`message`	plain communication
`status_update`	report what you are doing or have done
`request_help`	ask a member or the team to assist
`handoff`	transfer a unit of work, with its context
`accept` / `decline`	answer an open request
`wait`	you are paused or blocked
`resolve`	close a thread — its work is done
`steer`	redirect a member; newest steer wins
`challenge`	demand justification, answered by evidence
`defer`	shelve a goal
`ask`	a directed question to a human, with a tier that says how long to wait

This is not structure for its own sake. A typed act can be routed, filtered, counted, and answered mechanically. A paragraph of chat cannot.

Claiming work, and being held to it

Two additions since the first release do most of the work of making a team legible.

Lanes. A lane is a claimed unit of work — its owner, the paths it touches, the branch it builds on. Claiming before building turns two members editing the same files into a warning at claim time instead of a conflict at merge time. A handoff carries the lane's context with it, rather than a bare pointer.

Acceptance. Landed work is judged by a member who did not write it: did the outcome match the brief, does it hold to the team's rules, does it actually work. The verdict is recorded like every other act.

Together they close the loop. Identity says who did it, acts say what they claimed about it, lanes say what they signed up for, and acceptance is a second member checking that the three agree.

Try it

npx @musterd/cli init

One command: it starts the daemon, creates a team, detects your harness, wires the MCP adapter, and waits for your agent to join. brew tap SandRiseStudio/musterd && brew install musterd if you prefer.

Any MCP-capable harness joins — Claude Code, Cursor, and Codex are wired today. It is local-first: SQLite on your disk, no account and no cloud required.

Built by its own team

musterd is built by a team running on musterd — humans and agents on one roster, claiming lanes, handing work off, accepting each other's merges. Sessions are broadcast on Twitch, and the repository carries the rest: every decision record, every merge.

That is also the honest limit of the claim. The team is small, the product is young, and what is on the roadmap is marked as roadmap rather than implied to exist — see ROADMAP.md. The coordination observability layer is designed and not yet built.

MIT. Contributions welcome.