How I run many agents.

01The loop

One request goes around a loop.

Everything I hand over takes the same route. I make a request to the orchestrator. If there is something to decide, a thinker decides it. Workers build what was decided. A reviewer checks what they built. Whatever the reviewer finds goes back to the worker, and round it goes until the reviewer accepts.

I see two things: the request going in and the checked result coming out. The loop in between runs without me unless it has a question.

This page went around it. A thinker designed and wrote it, a worker built it, and a reviewer on the other provider sent it back more than once.

02The request

I talk to one tab. It runs the rest.

Each project has one orchestrator, and it is the only tab I talk to. I say what I want in plain words: a feature, a fix, a page, a plan. It splits the request into pieces, opens a tab for each and keeps track of who is doing what.

It coordinates and builds nothing. A lead who starts doing the work stops watching the board.

Every tab it opens has a role. The role says what the tab is for and which model it runs.

03Thinking

Decide first, then build.

Some requests have a decision inside them: how a feature should work, what a page should say, which of two designs is right. Those go to a thinker before anyone builds. A thinker runs the strongest model, takes one question, answers it and stops.

This is the fun part. I describe what I'm after, and a thinker comes back with a decision and a plan I can push on before anything is built.

The plan is clear enough to hand straight to workers, and the thinker can brief them itself. It doesn't build.

What I send to a thinker:

• A design or architecture decision
• Anything a person will read: names, copy, the shape of a product
• Work that cuts across several parts of a project
• Security questions
• A fix that has failed twice, instead of a third try
• Anything where being wrong costs far more than the tokens

04The build

Then it gets built, and I watch.

Workers take the plan and build it, several at once. A reviewer checks each piece and sends back what needs fixing. I don't have to read the code to know where things stand.

What I watch is the thing itself. Web work runs in a preview beside the chat, where the agents open the page, click through it and read the result. iOS work runs in a simulator in the same panel, and each project keeps its own. I see the same screen they do, and I can take over with a click.

05Workers

A worker gets one shot at what I meant.

Workers do the building, one task each. A worker starts with nothing but its brief, so a vague brief comes back wrong. Mine carry six things: what I asked for in my own words, where the evidence is, what is known, what is only a guess, what was already tried, and the test that says it is done.

The guess line matters most. A cause I mention in passing reads like a fact to an agent unless it is labeled. If the scope changes mid-task, the whole brief goes again, restated. A patch on top gets half read.

Several workers can build at once. Each one that writes gets its own git worktree on its own branch, so they never overwrite each other. Finished branches merge one at a time, and a conflict stops the merge cleanly and goes back to the worker that owns the branch. When two branches touch the same files, ManyAgents flags it.

06Reviewers

A second model checks the work.

When a worker reports done on anything that matters, a reviewer reads the result against the brief. The reviewer runs on the other provider, so work written by Claude is checked by Codex. It can't edit, so its only output is what it found.

It reports a table of findings and one of three verdicts. This is where the loop closes. Fix rows go back to the worker that did the work, pasted word for word, and the result is reviewed again. Accepted work goes back to the orchestrator, and the orchestrator tells me. Finding nothing is a fine result.

07Tokens

Spend tokens where they change the answer.

A board of agents can burn through a plan's limits in a morning. Much of this method is about not doing that, and ManyAgents does a good part of it for me.

The role picks the model. Thinking gets the strongest one I have. Building gets a mid-tier model. Tests, screenshots and review fixes get the cheapest model that can do them. A strong model left on mechanical work is the usual leak.

The second leak is long conversations. Every call an agent makes re-reads everything it has said so far, so a tab that has worked all day costs more per step than a fresh one. I keep Compact earlier switched on in Settings: when a tab's context reaches a cap, ManyAgents rolls it into a short working brief and carries on from that. For my orchestrator, a typical one saved about 27 times what it cost.

The rest is small habits the app keeps for me:

• A new task gets a fresh tab. Starting one costs about 4% of a typical worker session.
• An agent waiting on a build registers a wait and stops. It doesn't sit polling.
• Only so many tabs run at once, and the number drops as a plan's limit gets close.
• The orchestrator stays out of the files, so the most expensive context on the board isn't spent on grep.
• Every tab shows how much of its context and of my plan it has used.

08Cause first

Prove the cause before the fix.

An agent will happily commit a plausible fix for a cause nobody checked. I ask for evidence first: a reproduction, a log line or a stack trace. A worker that can't find one says so, and that is a useful report.

On one crash, a worker committed a guess in two minutes. A thinker then found the real exception in the system log in two more. The log had been there the whole time.

09The go

Nothing ships without a go.

Agents build, test, review and commit without asking. Releasing, deploying and anything else that leaves my Mac waits for me to say go, every time. A go for one release is not a go for the next.

This is a rule I give the orchestrator, not a lock in the app.

10Away

It reaches me only when it needs me.

Questions land in one list, each with what the agent would do. When I'm away from the desk I open the iPhone app, see which projects are waiting on me, and answer or approve from there. If I message a project and put the phone away, the reply comes back as a push. The Mac keeps running the agents.

The other half is quiet. An error shows only when something failed and I have to act. A turn that delivered its result never gets a red row.

The iPhone app is available through TestFlight.

Wednesday, November 11

9:41

web-appnow

The rounding fix is in and on its way to review. Three bags now total $20.27.

11Still tuning

What I'm still tuning.

I went back through ten days of my own board. Reviewers said fix these 71 times and accept 36 times, about two fix rounds for every accepted change. Nearly every finding I checked was a real defect. They never once used escalate.

fix these

71

accept

36

escalate

0

The roles hold up. Quality slips at the seams between them:

• A brief written in seconds carries a guessed cause as if it were known.
• Reviewers read code and rarely run it, so a regression from a fix is found one round later.
• A promise made in passing gets lost when a long conversation is summarized.
• The orchestrator sometimes paraphrases a report instead of passing it on.

Most of the rules on this page exist because of one of those.

12Who it's for

Built for more work than one session can hold.

This method is for builders: people with more ideas than hours. It earns its keep when there is more to do than one agent can carry: several features moving at once, a bug being chased while a page gets written, a release going out in the background. It trades tokens for attention, and the more parallel work you have, the better that trade gets.

You don't have to run the whole loop. A single tab works like a terminal, and you can add an orchestrator, a reviewer or a thinker when a project grows into them. The 14-day trial is long enough to find your own version of it.