Lesson 01. The ladder you were sold is the wrong model

A staff engineer at a forty-person company spent the spring climbing. In March his agent ran inside his editor. By May he had four of them in terminal tabs, each on its own branch. By July every one of them started from an issue on a vendor's cloud and reported back as a pull request, and he told his team he had reached the top. On the first Friday of August he had six finished pull requests open that he could no longer tell apart, two agents stopped for reasons he could not determine without opening each one, an inference bill for the month larger than the team's entire tooling budget and forecast by nobody, and an afternoon spent reverting a database migration that two agents had each written into separate branches. Every one of those problems was new that quarter. Not one of them was caused by where the agents ran. Decide now: which of those four problems does moving to the cloud actually solve?

Illustrative composite. The engineer is fictional and his week is assembled from patterns that recur across small teams adopting parallel agents. The numbers in the worked case below are modelled, not measured. The shape of the failure is the part that is common.

This lesson gives you fleet/topology.md — your fleet scored on four axes, with the single axis you will move next. It serves Scope, the first stage of this course's loop of Scope, Isolate, Supervise, Land, because the axis you pick decides what every later decision in the course is even about. The course assumes you already run one coding agent reliably and read its diffs; if that is not true yet, Harness Engineering is the course that teaches it.

What is actually going on

You have seen the progression written up a dozen times, and it goes like this. An agent inside your editor, where it can see the file you have open. Then the same agent as a plain process in a terminal, with your shell, your repository and your permissions. Then several of those at once, in tabs or panes, because one was no longer saturating you. Then the whole arrangement moved onto a machine that is not your laptop, so you can close the lid. Then, at the top, a vendor's cloud, where you hand over an issue and collect a pull request.

Treat that model fairly, because most of it is right. It is a real progression, almost everyone who runs agents seriously has walked some of it, and its central observation holds up: past the second rung your scarce resource stops being prompt quality and starts being your own attention. That is exactly why session managers, agent dashboards and pull-request inboxes exist as a product category at all.

Here is what it is not. It is a description of venue, sold as a description of maturity. Each rung answers one question, which is where the process runs, and it is silent on the three questions that produced every symptom in the opening. Twenty well-managed agents on one laptop is not a less mature setup than one agent on a vendor VM; it is a different point on a different axis. And the ladder never mentions money, although the venue you pick changes which meter runs. Anthropic's own writeup of a production multi-agent system reports that multi-agent work consumes roughly 15x the tokens of a single chat, which makes "how many run at once" a budget decision before it is an architecture decision (anthropic.com/engineering, observed 2026-09-11).

So replace the ladder with four things that move independently. Concurrency: how many agents are running at once. Isolation: what contains each one, on a spectrum from a bare process on your working checkout, through a git worktree, a container, a microVM, to a remote VM rebuilt per run. Verification: what has to be true before a change lands, from the agent's own report, through a diff you read, to a gate that runs outside the agent and can block it, to a check written by someone who never saw the agent's work. Locus of control: who governs identity, credentials and network reach, which is your permission settings at one end and a platform issuing a scoped, revocable identity per run at the other.

Two of those axes fight each other, and the fight is the whole lesson. Plot common setups with Concurrency running right and Verification running up, and watch which corner the painful ones fall into.

The chart makes one thing visible that a rung number hides. The eight cloud agents and the four terminal tabs sit in the same quadrant, separated only by how far right they went, and climbing the ladder moved the engineer from one to the other without lifting him a single point upward. Raising Concurrency raises arrivals. Verification is the only axis that raises acceptance. Move the first without the second and the queue grows by construction, which is arithmetic, not a warning.

The four axes, scored one to five

Copy this table into fleet/topology.md and circle a cell per row. Score what happened last week, not what your tooling could do if you configured it. The gap between those two readings is the reason most topology documents are fiction.

Alongside each score, write the evidence. "Verification 2, because I read nine of the twenty-three diffs we merged last week" is a score you can argue with. "Verification 4, we have CI" is not, because CI that nobody has configured to block a merge is Verification 3 wearing a costume. The document is one page and it is worth an hour, because every later decision in this course is an argument about which cell to move and what it costs.

Isolation and Locus of control look like one axis and are not. Isolation answers what the agent can reach from inside its box. Locus of control answers who issued the keys it carries in there. A container with your personal cloud credentials mounted into it scores high on the first and low on the second, and the blast radius of that combination is the whole cloud account, not the container.

The rule and its condition

Raise exactly one axis at a time, and never let Concurrency sit more than one point above Verification.

Lowering Concurrency to get back under that cap does not count as a move. It returns the fleet to a level you have already run and measured, so it adds no new cause to explain next month's result. Raising any axis does, which is why only one goes up at a time.

The condition is countable in your own repository this afternoon. Take last week: how many changes did your agents open, and how many were examined by a human or blocked-capable gate before they merged? If arrivals exceed examinations, your next move is Verification, whatever rung anyone says you are on. If examinations comfortably exceed arrivals, you have room, and the axis you move is the one your last observed failure names.

The measured evidence for that ordering is unusually consistent, and it points the opposite way to intuition. DX's longitudinal study across forty companies found a 65% average rise in AI tool usage produced a 9.97% rise in pull-request throughput, which is the signature of a system where generation got cheaper and acceptance did not (newsletter.getdx.com, observed 2026-09-11). METR's randomised trial with sixteen experienced open-source developers across 246 real tasks is sharper still: the AI-allowed condition took 19% longer, while the same developers expected a 24% speedup beforehand and still believed they had been 20% faster afterwards (metr.org, observed 2026-09-11). Read those as evidence about the gap between felt and measured throughput, not as a verdict on agents. Lesson 11 takes the studies apart properly, including what does not transfer from them.

Most proposals you will hear this year are a venue change wearing the language of maturity. This is the table that sorts them.

Notice that the second row is the ladder's own top rung, and it moves neither of the two axes that were hurting the engineer in the opening. That is not a criticism of cloud agents. It is a statement about what you are buying.

Only the last box in that tree adds an agent, and it adds one, because a move you cannot attribute is a move you cannot undo. Two axes raised in the same week means the next bad month has two suspects and no evidence.

Worked case

Return to the engineer from the opening. He runs eight agents on a vendor cloud. Each one gets a fresh VM that is destroyed at the end of the run, and the platform issues the agent a short-lived identity scoped to the repository rather than handing it his personal token. His team is three people. He does not want to go backwards, because the throughput is real and his manager has noticed it.

Illustrative composite. Last week his agents opened 23 pull requests. A human read 7 of them before merge. Another 9 merged on a green CI tick with nobody reading the diff. Five were abandoned after the agent ran out of context and left a half-finished branch. Two are still open and nobody knows whether they are blocked or finished. The month's inference bill was 3.1x the previous month's. One migration collision cost a Friday afternoon. Two agents sat idle for four hours waiting on a permission prompt that nobody saw.

Score the four axes from that ledger, not from the marketing page. Concurrency is 4: eight agents with a board that shows them. Isolation is 4: a disposable VM per run, which is genuinely strong containment. Locus of control is 4: no long-lived secret, a scoped identity per run, revocable centrally. Verification is 1. Not 2, because 9 of 23 merged with no human in the loop at all and the CI he has cannot block a merge; it reports. His own honest description was "the agent says the tests pass."

Decide now: he wants to keep the throughput. Which single axis does he move next, and what does he give up to move it?

The answer is Verification, and what he gives up in the short term is Concurrency. Here is the reasoning in order.

First, find the largest gap, not the lowest score. Three of his axes are within one point of each other at 4. One sits at 1. A three-point gap between Concurrency and Verification is the only structural imbalance in the fleet, and the rule caps Concurrency at one above Verification, which currently means a score of 2: a single agent running unattended.

Second, map each symptom to an axis before choosing, because symptoms lie. The six indistinguishable pull requests and the nine unread merges are Verification. The unexplained bill is cost, which Lesson 03 models and which Verification partly drives, since abandoned runs are pure spend. The two idle agents are neither Verification nor Isolation: that is a supervision failure, and Lesson 10 builds the working, blocked and done signal that fixes it. The migration collision is Isolation, but of systems rather than files, which Lesson 04 shows worktrees do not solve. Only after that mapping is the choice defensible: three of the four symptom classes trace to the axis scoring 1.

Third, price the rejected option. The tempting move is to raise Concurrency to 5 by moving to a larger tier, adding four agents and wiring a queue to feed all twelve, because that is the rung the ladder points at and it is a purchase rather than a project. It widens the gap to four points. Arrivals roughly double, the share merging unread rises because the reading capacity is fixed at three humans, and the first production incident traced to an unreviewed agent change costs more than the quarter of tooling spend the move was meant to justify. The cheaper failure is the one that shows up as a slower week, not the one that shows up as an incident review.

So he drops from eight agents to three for two weeks, which is Concurrency 3 on the scale, builds a gate that can block a merge, and raises Concurrency back only when examined changes match arrivals. That is still one move. Verification is the only axis going up; Concurrency is coming down to a level he has already run. Here is what he commits.

# fleet/topology.md
Scored 2026-09-11 from the week of 2026-09-01. Evidence: PR log, CI history, billing export.

| Axis | Score | Evidence |
|---|---|---|
| Concurrency | 4 | 8 agents, vendor board shows all of them |
| Isolation | 4 | Disposable VM per run, destroyed on completion |
| Verification | 1 | 23 PRs opened, 7 read, 9 merged unread, CI reports but cannot block |
| Locus of control | 4 | Scoped identity per run, no long-lived token on any machine |

## The axis I raise next
Verification, 1 -> 4. A required status check that blocks the merge, plus a rule
that no PR merges unread until the check exists.

## What I give up to raise it
Concurrency 4 -> 3 (eight agents down to three) for two weeks. The one-point rule allows 2; I am accepting
3 deliberately and writing the risk down rather than pretending it is compliant.

## What I am NOT doing, and why
- Not raising Concurrency. Three of last week's four symptom classes trace to
  Verification; more agents makes all three worse.
- Not changing Isolation or Locus of control. Both score 4 and neither produced
  a failure last week. The migration collision was shared-system isolation,
  which is a separate decision (see fleet/isolate.sh when it exists).

## Reopen this document when
- Examined changes match arrivals for two consecutive weeks.
- Any axis produces a failure that costs more than half a day.
- The cost per landed change is known, which currently it is not.

The last line matters more than it looks. He cannot yet say what a merged change costs him, so he cannot say whether the fleet is worth running at all. That is the next document.

Faded case

Skip to the open case if this is familiar.

Two engineers maintain a Rails monolith. Each runs one agent, in their own checkout, straight on the host with no worktree and no container. They read every diff, every time, and CI runs on the pull request and is configured as a required check that blocks the merge. The agent inherits the developer's shell, which has a .env on disk holding a database URL for shared staging that has not been rotated in a year. Last Tuesday, while its developer was at lunch, an agent decided a failing test needed a clean slate and ran a destructive rake task against that staging database. The team lost an afternoon and asked whether they should each start running three agents to make up the time.

Three of the four scores are straightforward. Concurrency is 2: one agent each, running unattended. Verification is 4: every diff read, plus a gate that can block. Locus of control is 1: a personal shell, a long-lived credential sitting in a file the agent can read. The fourth axis, and the decision, is yours.

Open case

A payments team of four engineers runs twelve agents on one shared remote box. Each agent works in its own git worktree, and all twelve point at the same Postgres instance and the same Redis. Every change passes a CI gate that blocks on tests and a dependency scan. One of the four reads every diff that touches the ledger; the other three merge on the gate alone for everything else. All twelve agents authenticate with one deploy key that has write access to eleven repositories, stored on the box.

Last month: no file-level collisions at all, three incidents where one agent's test run poisoned another agent's fixtures mid-run, and one dependency bump that reached production with no named owner and no record of which agent proposed it.

Score all four axes, then name the axis they move next.

Where this breaks

The axes are not equally expensive, and the rule can read as though they are. Isolation and Locus of control are largely purchasable: a container runtime, a sandbox vendor, a secrets broker, and an afternoon of configuration will move either one two points. Verification is not for sale. Nobody ships you review capacity, and the substitutes that do exist, which are smaller diffs, evidence attached to the change, trust tiers by change class and machine pre-review, are all projects rather than purchases. Expect the cheap axes to drift upward on their own and the expensive one to stay where you left it.

A score of 5 is not a goal, and the numbers do not compare across teams. A developer running one agent against a static site with a full CI gate is at 1, 1, 4, 1 and is correctly configured; raising anything would be waste. The scale only means something measured against your own last month and your own failures. Treat a topology document that shows fives everywhere as a document written from a vendor page rather than a pull-request log.

Two real costs of scale sit outside the four axes entirely, and both bite hardest exactly when Concurrency rises. Reconciling N finished branches into one main is not an axis score and is the most underserved problem in this whole field; Lesson 13 is about nothing else. And whatever tool you standardise on may not outlive your adoption of it, which is a risk you price rather than a property you configure; Lesson 09 makes venue mortality part of the choice. If you need a fifth and sixth column in your own table for those, add them, but do not let them turn into scores, because neither improves by moving a slider.

Key Takeaways

• Replace the ladder with four axes: Concurrency, Isolation, Verification, Locus of control.
• Raise exactly one axis at a time, so the next result has one cause; pulling Concurrency back under the cap is not a move.
• Never let Concurrency sit more than one point above Verification.
• Score from last week's pull-request log, never from what your tooling could do.
• Ask of any proposal which axis it moves and which it leaves untouched.
• Buy Isolation and Locus of control; build Verification, because nobody sells it.

What You Have Now

fleet/topology.md — your fleet scored on four axes, with the single axis you will move next. It is the first file in the fleet/ directory you will carry through this course, committed to a real repository rather than kept in a notes app, because later lessons add scripts and policies beside it that have to live where your agents run. It closes Scope's first question, which is what you are actually scaling, and it hands two open questions forward: which of your work is even fleet-shaped, which Lesson 02 answers with a task template, and what a landed change costs you, which Lesson 03 turns into the number that picks your topology for you.

Further Reading

• Measuring the impact of early-2025 AI on experienced open-source developer productivity: the randomised trial behind the gap between felt and measured speed; read the limitations section, which is unusually honest.
• How we built our multi-agent research system: the most quantified production writeup of running many agents, including the token multiplier and where orchestration stops paying.
• Simon Willison on that system: an independent read of the same post that isolates which claims are load-bearing and which are vendor framing.
• DX: AI in engineering, Q2 2026 benchmarks: longitudinal data on what rising AI usage did and did not do to delivery throughput across forty companies.
• Stacked pull requests in public preview: one platform's answer to agent-sized diffs, and a useful preview of the Verification-axis tooling Lesson 11 relies on.

Exercises

1. Pull last week's merged pull requests authored or co-authored by an agent. Count the arrivals and count how many a human read or a blocking gate rejected. Write the two numbers at the top of fleet/topology.md before you score anything, because they settle the Verification row on their own.
2. Score all four axes with one line of evidence each, then write the "What I am NOT doing, and why" section first. If you cannot name an axis you are deliberately leaving alone, you have not scored honestly; a fleet with four weak axes is a fleet nobody has looked at yet.
3. Take the last change an agent made that surprised you, in either direction. Trace it to exactly one axis, then write the version of your topology document that would have prevented it, and the cost of that prevention in money, latency or throughput. If the cost is zero, you have mislabelled the axis.

Check your understanding