Where Session 15 starts

By now one agent has built a workflow with you (Session 13) and a dashboard on top of it (Session 14). You have seen how to brief an agent and read what it hands back (Session 12). Session 15 multiplies that: up to eight agents working at the same time, each on its own task. Element F01, chapter 11, explained how a fleet is put together and what a night of it costs. This element is the hands-on version: how to split the work, how to keep each agent's context useful, and how to keep the bill in proportion to what you get.

A good task for a fleet

A fleet task is a brief one agent can finish and prove on its own, without waiting for another agent and without touching files another agent is changing. A good task has five properties:

Waves: respect the dependencies

Some tasks need others first. Nothing can query a table before the migration that creates it has merged. Draw the tasks as boxes with an arrow from each task to the ones that need it. Tasks with no arrows into them form the first wave; when they merge, the next wave can start ^[1].

Notice that eight tasks did not become eight agents at once. The widest wave here has four tasks. Starting more agents than a wave has tasks only produces agents waiting, or worse, agents inventing work that collides.

One owner per file

The most common cause of a broken night is two agents writing the same file. Even if each change is right, the second merge conflicts with the first, or quietly undoes it. Give every folder in a wave exactly one owner, and keep the shared files (the package list, shared configuration, the database schema) with the lead: the person or orchestrator agent who merges.

Isolation, set up once per worker

Each worker gets its own copy of the repository on its own branch (a git worktree is the cheapest way: a second folder sharing one repository), its own test database and its own port range, so its tests cannot reset another agent's data or stop another agent's server ^[2][3]. Claude Code can create worktrees for its sessions and subagents; any agent tool works with a worktree you make by hand ^[4].

# Wave 2: four workers, each with its own folder, branch, database and ports. Run from the repository folder.
for N in 2 3 4 5; do
  git worktree add ../agent-$N -b wave2/agent-$N
  createdb "platform_agent_$N"
  printf 'DATABASE_URL=postgres://localhost:5432/platform_agent_%s\nPORT=%s\n' "$N" "$((3000 + N * 100))" > ../agent-$N/.env.test
done
git worktree list   # four folders, four branches

How much faster, really?

In 1967 Gene Amdahl pointed out that the speed-up from running work in parallel is capped by the part that stays serial ^[5]. In a fleet, the serial part is mostly you: reading each pull request, merging them one at a time, and sorting out anything that conflicts. If one fifth of the total effort is serial, eight agents give at best about 3.3 times the speed of one.

The formula: speed-up = 1 ÷ (s + (1 − s) ÷ n), where s is the serial share and n the number of agents. Two practical lessons follow. First, shrink s: small pull requests, tests that decide for you, and a merge order fixed in advance. Second, size the fleet to your review time. If you can carefully review four pull requests in the morning, run four agents, not eight.

The context window

A model has no memory between requests. Every request an agent makes sends the whole conversation so far: the system instructions and tool definitions, your project's memory file, the brief, every file it has read, every command's output, and every earlier turn. That bundle is the context, and the most a model can take in one request is its context window. Current models offer windows from about 200,000 tokens up to a million ^[1].

More context is not better

A bigger window does not mean you should fill it. Anthropic's engineering team describes context rot: as the number of tokens in the window grows, a model's ability to recall what is in it accurately goes down ^[2]. Earlier research found models use information at the start and end of a long input better than information in the middle ^[3]. For a fleet, the lesson is practical: give each agent what its task needs, and no more.

Project memory: one short file every agent reads

Agent tools read a project memory file at the start of every session: CLAUDE.md for Claude Code, AGENTS.md for many other tools ^[4][5]. It is where the rules that never change live: how to run the tests, the folder layout, the rules from your matrix and your clamps, what never to do. Claude Code's documentation recommends keeping each such file under about 200 lines, because longer files cost context on every request and are followed less reliably ^[4].

# Plant platform: rules for every agent
## Run
- npm ci, then npm test (unit and end to end against a fresh local database). Both must pass.
- Verify from a fresh clone before any pull request.
## Never
- Never edit a test under test/acceptance/ (the lead owns them).
- Never put a key in a file, a prompt or a commit. Keys live in Vercel and Supabase settings.
- Never write outside the folders your brief names.
## Rules
- Every table has row-level security generated from docs/matrix.md. A new route is closed until the matrix opens it.
- Every screen passes the phone check at 360 and 390 px: 44 px tap targets, 16 px fields, 15 px text.
- Money is integer cents. Times are stored in UTC and shown in plant time.
## Layout
- app/ screens · lib/ shared rules · db/migrations/ schema · test/ tests · docs/ intent, matrix, measures

Keeping each agent's context relevant

All five come from the same idea: the agent's working context should hold the task, not the history of everything it has done ^[7][8][9].

Reading the cache statistics

Claude Code's /usage command shows, for the current session, the share of input tokens served from the cache, the number of cache misses and, where it can tell, the likely cause of the last miss ^[10]. A healthy agent loop serves most of its input from the cache. If the share drops, look for what changed at the top of the context: a tool or connector added mid-session, a model switch, or a memory file that differs between sessions.

Cost per merged change, not per token

A plant does not judge a press by its electricity bill; it judges cost per good part. Judge a fleet the same way. A night's token bill means little on its own: what matters is how many changes passed their tests, survived your review and merged, and what each one cost in total.

Take the worked night from element F01: eight Sonnet 5.5 workers with good caching cost about $115.78 in tokens, plus about $11.14 for the orchestrator ^[1]. Suppose six of the eight pull requests merge after review, one needs another night, and one is thrown away.

Two conclusions. First, the merge rate moves the cost more than the price per token: if only three of eight merge, every change costs twice as much in tokens. Better briefs and tests written first raise the merge rate. Second, your review time is the biggest single line, so make review fast: small pull requests, tests that decide, and a checklist (Session 16).

The cheapest model that passes

Model prices differ by about four times from the small to the largest tier ^[1]. Most fleet tasks, built from a clear brief with tests written first, do not need the largest model. Run a task on a cheaper model; if it fails its acceptance checks twice, move it up a tier. Keep the largest model for planning, hard bugs and reviewing other agents' work.

Caps on every run

A fleet runs while you are not watching it, so every run needs a hard ceiling. There are three layers, and you want all of them:

# One worker, bounded: a budget, a turn limit and only the tools its task needs. Run inside the worker's worktree.
claude -p "$(cat briefs/agent-3.md)" \
  --max-budget-usd 8 --max-turns 80 \
  --allowedTools "Read" "Edit" "Bash(npm test *)" "Bash(git add *)" "Bash(git commit *)" "Bash(git push *)" \
  --output-format json > logs/agent-3.json

Rate limits are shared

API rate limits (requests and tokens per minute) apply to the whole organisation, not to each agent ^[4]. Eight agents starting at the same second all ask for their big first request at once. Start workers a minute or two apart, and give the fleet its own workspace so it cannot starve anything else that uses the same account ^[3].

Subscription or pay per token

Prices and plan limits change; check claude.com/pricing and the API pricing page on the day you choose, and record the choice and the reason on your platform's costs page ^[5][1].

Keep a fleet ledger

Each night, write one line per task: model, turns, tokens, cost from the run's output, merged or not, and your review minutes. After a week you will know your own merge rate and cost per merged change, which beats any estimate in this element. The JSON output of a headless run includes the run's cost, so a short script can fill in most of the line ^[6].