I've spent the last months running my repos with an AI team instead of an AI assistant. Today I'm releasing the thing that made it work: mARC, an IRC-style agent team for Claude Code.
The problem first. A single AI coding session is a brilliant engineer with no memory, no process, and no colleagues. It writes code fast and loses track faster. Decisions evaporate when the chat ends. Work happens that no board ever sees. And the same session that wrote the code is the one that reviews it, which means nobody reviews it. A smarter model doesn't fix any of this. Teams weren't invented because engineers were dumb. They were invented because shipping needs structure.
So mARC gives the AI a team structure instead of a bigger brain. When you open the channel you talk to @techlead, an operator that behaves like a tech lead, not like a code generator. Five specialists idle in the channel until pinged: an engineer, an SRE, a designer, a security reviewer, and a researcher. You say "users are getting pinged when we save issues, fix it". The tech lead writes the spec, opens a GitHub issue, puts it on the Project board, dispatches the engineer in the background, and keeps talking to you while the work runs.
Four rules turn this into a team instead of a fan-out script.
Specs before dispatch. A vague task produces a vague PR. The operator won't delegate anything that lacks a goal, acceptance criteria, affected files, and constraints. If something's missing it asks you first, because one question now is cheaper than a reverted PR later.
The board is the source of truth, and it gets audited. Work lives in GitHub Issues and a Project board, not in the chat scrollback. Before dispatching anything, the operator checks the board against reality: merged PRs, deploys, CI. Boards lie. Merged PRs don't. Status actually means something here. Blocked means it needs you. Done means merged and validated.
Nothing merges without a review the author can't skip. Every PR gets a security pass on its diff before merge. The reviewers are read-only by contract: the security agent and the researcher physically have no write tools. At one point we considered giving them a scoped write folder. The researcher went off, read OWASP's LLM guidance and GitHub's token-hardening docs, and came back recommending against its own write access. The idea died in review, where it belonged.
The process itself is versioned. When something goes wrong, the lesson doesn't die in the chat. It lands in the playbook via PR and gets reviewed like any code. The team that made the mistake ships the rule that prevents it.
Does this actually work? mARC runs its own repository, and every issue, PR, security review, and decision record of the team building the team is public. Including the embarrassing ones.
My favorite: the team's own issue template was writing handles like @dev into GitHub issue bodies. Those are real GitHub accounts owned by real strangers, and they got mentioned on every issue we filed. One release even listed them as contributors. The team fixed the template, sanitized 14 historical issues, and added a CI gate so it can't happen again. Then the security review of that fix caught that the gate was case-sensitive, so @Dev would have slipped through. One grep flag. That's what a second pair of eyes is for.
There's more in the record. A config migration where the security reviewer probed the new parser with hostile values and got two hardenings merged before the PR landed. A day when I dispatched two writing agents in parallel without isolating their worktrees and one clobbered the other's checkout. The recovery and the dispatch rule that came out of it are both public.
To be clear about what this is not: it's not the demo where an agent writes a TODO app in one take. It's slower and noisier than that, on purpose. Specs before dispatch, review before merge, and a paper trail a human can audit six months later. The board isn't a visualization of what the AI did. It's the real board. I can grab any item on it and do it myself.
Try it in two minutes. You need Claude Code and a GitHub repo:
/plugin marketplace add NexaDuo/mARC
/plugin install marc@nexaduo
/marc:tech-lead
No config, no signup. It discovers your repo at runtime: org, board, paths. If you want the binding to persist across sessions, /marc:init scaffolds a team.toml, shows you every file before it writes anything, and writes nothing without your yes.
The repo is the real landing page: github.com/NexaDuo/mARC. The whole history of an AI team running itself is in there, embarrassments included.
Top comments (0)