Many agents

Several agents work at the same time on separate parts of a job, each in its own session. You get more done per hour only if the parts really are independent, and only if you can check all of what comes back.

The limit is rarely the agents. It is how cleanly the work splits and how much you can review. Starting a fourth agent takes seconds, and reading what it did does not.

One job is split into pieces, each goes to its own worker at the same moment, and their results are gathered into one answer, which is the fan-in. The whole job takes as long as the slowest worker, plus the gathering.

It suits reading far better than writing. Ten agents can look through ten modules and report back without touching each other. Ten agents editing the same app cannot.

An agent whose job is running other agents. It splits the work, briefs each worker, tracks what comes back and judges it, and writes no code itself. A mistake in its brief is repeated by every worker it sends.

You can't watch fifty agents, and neither can your context window. An orchestrator holds the plan and stays small, because the details stay in the workers.

Each agent gets its own git worktree: a separate folder with its own branch, sharing the same repository. One agent's half-saved file can't break another's test run, and an edit can't quietly overwrite another. They only meet at merge time.

Agents on one folder do not see each other coming. One saves a file the other read a minute ago, and the first agent's work is gone with no error. Two worktrees turn that silent loss into a merge conflict you can see.

The time a team spends staying in step and not working: waiting, conflicts, re-reviews, explaining things again. It grows with the pairs of workers and not the workers. Past some point, adding one makes the whole team slower.

Agents make this worse in one way. They are confident, they do not talk to each other unless you build that, and each conflict costs another run and another review. A reviewer is a queue too, and that queue is you.

Pull requests wait in line, and each is tested on top of main plus everything ahead of it before it merges. Two changes that pass alone and break together get caught before they reach main, not after.

Agents open pull requests faster than people do, so two green ones colliding stops being rare. One renames a function, the other adds a new call to it. Git sees no conflict, and main is red for everyone.

Give each agent one job with its own prompt, tools and check: one writes specs, one writes code, one tidies, one reviews. Each is told what not to do, so that each check stays with someone who did not write the code.

An agent asked to do everything cuts its own corners, and marks its own work. Roles put the corner and the check in different hands. Every role is also another handoff, another prompt to maintain and another bill.

One side writes and the other judges, in a loop. The judge's notes go back to the writer until it passes or the tries run out. It works when the judge has clear criteria, and the result ends up as good as what the judge can see.

Agents grade their own work too kindly. Splitting the writer from the judge fixes more than a stricter prompt does, and an automatic loop saves you from carrying the notes yourself. A blind spot in the judge stays a blind spot, however many rounds you run.

A reviewer whose job is to break the work and not to approve it. It is fair only when each finding must be proved by a run. Without that rule, a reviewer told to find problems will find problems, whether or not they exist.

A pushy prompt finds more real bugs and invents more false ones, and every round costs tokens you could spend on a test or a real run. Asking for a failing run first makes a false alarm cheap to spot, because an opinion cannot produce one. It doesn't make the round free, and the author of the best-known rule for this now doubts it pays.

The same prompt, fed to a fresh agent, over and over, in a shell loop. Each run does one thing, writes down what it did, and exits. Its memory is on disk. It is cheap to set up, and it has no way of stopping unless you build one.

A fresh session each time means no drift and no bloat, and a loop means it carries on while you are away. It only works with a plan on disk, a check that can say no, and a limit, or it will happily spend your money making things worse.

An agent working on one goal for hours or days, usually across many sessions that cannot remember each other. What lets it last is outside the model: a plan on disk, notes on progress, tests it can run, and a clean way to start again.

Nothing goes well for long on its own. Each session starts cold, and long ones drift or declare victory early. A run this long is decided by the harness you set up before it began.

A file in the repo saying what has been done and what comes next, which each new session reads first and updates last. It is how a session with no memory finds its place. It is only as true as whatever checks it.

A fresh agent believes the file, so a wrong line sends every later session the wrong way. Agents also like finishing, so "done" gets written too soon. Tie each claim to a test that a script can run.

A file one agent commits for the next to pick up: a spec, a diff, a report. Unlike a chat message it outlives the session, has a version, and can be checked. If you pass a commit, the next stage knows exactly what it received.

A summary passed along a chain changes at each step, like a game of telephone. A committed file doesn't. It also means you can open what each stage really handed over, not what it said it did.

A saved state you can go back to when a run goes wrong. Claude Code makes one per prompt, covering files its editing tools changed. Git commits cover everything git tracks. Neither can undo a database change or a sent email.

An unattended run makes many changes before you look, so you need to know how far back you can go, and what that leaves behind. People find out that files changed by shell commands are not covered at the worst moment.

An agent started by a clock or an event and not by a person: triage overnight, check a deploy every five minutes. Nobody is watching when it runs, so it needs narrower permissions than you'd give yourself, and its own way to stop.

It is the cheapest way to get work done while you sleep, and also a good way to get surprised. It acts with whatever access you gave it, on a schedule you may have forgotten about.

A loop that keeps spending because nothing told it to stop, or a growing session where each turn resends everything before it. Spend rises with every turn, and if nobody is watching, the first sign is the bill.

A bug in ordinary code wastes CPU. A bug in a loop wastes money and carries on doing it, since a confused agent often does more work, not less. Set the cap before you leave. A cap you add afterwards helps nobody.

A tool for running a line of AI agents, one role each, in separate git worktrees and tmux sessions (tmux keeps several terminals running side by side). Work passes on as committed handoffs, and you approve it at a gate.

It is the clearest public example we found of using checks in place of reading the code: every role owns one gate, so trust comes from the line and not from anyone's eyes. Whether that is enough is exactly what people disagree about.

A set of skills by Lauren Tan (poteto) for Cursor and Claude Code. It teaches going deep with one agent first, then running many with proof. It is instructions for the agent you already use, with no runtime of its own, and poteto-mode is the router.

It shows that a lot of this can live in text. Its central claim is an order of work: earn trust in one agent's output, and only then parallelise. It also has the most exact public rules we found for what counts as proof before a merge.

A setup where specs and scenarios go in, and agents write, test and ship code, with few or no people reading it. People build the line and its checks. The phrase names a way of working. It is not a product, and not a measured result.

If it holds, your job moves from writing code to writing checks that decide whether code is any good. If the checks are weak, you get a lot of confident software that nobody understands. Everything turns on that if.

A software factory where no person writes or reads the code, so the lights can stay off. All the trust has to come from evidence such as hidden scenarios and real runs. Few teams claim to do this, and we found no outside audit of any.

It is the far end of the range, and it is useful to think about even if you never go there, because it forces the question: if you stopped reading this code tomorrow, what would tell you it broke? For most teams, the honest answer is the customers.

Agents copy what they find. Good and bad patterns alike spread with every run, so a repo nobody tidies gets less consistent, and faster than people alone would make it. No single change looks wrong. The drift shows up later.

More agents means more copying per day. The harm is that bad patterns become examples: the next agent finds them, sees that they pass, and copies them. A rule enforced by a machine is the only kind that works at that speed.

Small background agents that each look for one kind of decay, such as stale docs or a broken convention, and open tiny pull requests to fix it. They pay down entropy in small amounts, so nobody has to hold a clean-up day.

Small fixes are cheap to review and easy to automate. A giant clean-up is expensive and gets put off. Stale docs matter more with agents, because an agent believes them.

Write down what good looks like as a set of scored cases before you change anything, then change the prompt or harness and run them again. An eval is a test of behaviour across many runs. It tells you if the change helped, not how it felt.

With agents, a change can feel better and be worse, and any single run can mislead you. If you don't set the bar first, you will end up picking the bar that suits the result you got.

Most work does not need many agents. If it fits in one session, or the parts share files, or you can't check the output, use one. If you could do it in the time it takes to write the brief, use none. Add more only once you have measured a gain.

Every idea in this chapter adds something to run, pay for and understand. Many agents can feel productive because a lot is happening. The test is whether more correct work reached users, per hour of your attention. Very often it did not.