Running a Team of Agents

Once one coding agent feels normal, the hard part stops being the model. It becomes keeping track: which agent is doing what, where that idea from Tuesday went, and whether anyone checked the work. This is how I run several agents at once.

The record lives outside the chat

A chat scrolls away, and the next agent can't see it. So the chat is never the record. Each piece of work is a ticket (I use GitHub issues), and the ticket is where its story lives. Every change to code or documents goes through a pull request that links back to its ticket. When an agent finishes or gets stuck, it leaves proof on the ticket: a command and what it printed, a link, or a plain description of what's blocking it.

Each ticket gets its own branch, named after it (something like issue-12-fix-login), and the branch is deleted once its pull request merges. If you give agents separate working copies of a repo, use the tool's own command for it rather than making them by hand, so the tool also cleans them up afterwards.

Check, then claim

Two agents working on the same ticket waste time and step on each other. The rule has an order, and the order matters:

1. Before starting a ticket, look for a claim comment or an assignee. If there is one, leave it alone.
2. If there isn't, comment claim: your-name, then start.
3. If you stop early, comment handoff with what's done and what's left. If you're blocked, add a blocked label and say what would unblock you.

Checking first is the important half. If two agents both just comment "claim" at the same moment, both of them think they own the work.

Capture every idea the moment it's said

I do a lot of my thinking out loud to agents, and ideas come out mid-conversation. So every agent follows one rule: when I state a new idea, task or decision, it writes it down in the same turn and tells me where it went.

Where it goes is a board, a small command-line tool I built for myself. It holds threads (one per piece of work, each with a status, a next step, plan steps and links), quick ideas, and questions waiting for me. Every agent tool on my computer can write to it, and each write records who made it. Every write also adds a row to an event log that can't be edited or deleted, so there's always a history of what changed. A local page shows the whole board.

One more rule: an agent never asks me to go read a file. If it needs a decision, it puts the question on the board with the context written out and a button for each option. I click one, and my answer goes back into the record.

One window for every session

With several agents in several terminals, you lose track of what's running. I use OpenRig, an open-source control plane for agent sessions. Running rig ui open opens its web page, where my sessions show up as they start, and I've added my board to it, so one window shows both.

I also set a hard limit: at most one group of agents (OpenRig calls it a "rig") with at most six seats at a time, and the group is shut down, with a snapshot saved, as soon as its work is done.

Route by the shape of the task

Not every job needs the biggest model. Before handing out work, I sort it by shape:

• Must be right (anything public, anything on a resume, anything another person relies on) goes to the strongest model, with a second agent reading alongside.
• Bulk chores across many files, like tests, renames or cleanup sweeps, go to cheaper agents working in parallel on separate files.
• Orientation, meaning find the file, map the module or summarise a change, goes to a read-only explorer.
• A second opinion on an answer I already have goes to a model from a different company, told to attack it.

The same thinking applies when one agent hands a sub-task to a helper. Small models get small tasks, the big one is the ceiling, and you name the model every time. If you don't, a helper can silently inherit the most expensive model for a job a small one would finish just as well.

A second checker

The agent that wrote the code, the document or the answer doesn't verify it alone. A second agent or I check critical work before it counts as done, and nothing is called done until a check ran and passed. The Checking page has more on this, along with the rule that every claim has to point at something you can open.

Keep private things private

Agents write a lot of text into tickets and pull requests, and some repos are public or shared with other people. Three rules keep that safe:

• If you aren't sure a repo is private, treat it as public.
• Personal notes, money and strategy never go into tickets on shared or public repos. Track that work in a private repo, and leave only a short reference on the shared one.
• Ask before deleting, force-pushing, or rewriting shared history. Those are the steps you can't take back.