Boris Cherny, the creator of Claude Code, published a framework this week called Steps of AI Adoption, and it moved fast — a quarter-million views on the announcement post within hours, reposts still circulating two days later. The ladder has five rungs, indexed by rough agent count: Step 0, Gated (zero agents, access blocked); Step 1, Assisted (one engineer, one agent, everything reviewed); Step 2, Parallel (~10 agents, one orchestrator); Step 3, Supervised autonomy (~100 agents, decision throughput is the limit); Step 4, AI-native (1,000+, most work self-initiated, humans steer by intent).

His sharpest line is the one getting the least attention: tokens aren't what separates the steps. Bottleneck breakdowns and guardrails are.

We can vouch for that line with unusual specificity, because we've spent six months running a ten-agent harness in production — a real store, real deploys, real consequences — which puts us squarely at Step 2 with a foot on the Step 3 rung. Here's what each transition actually required, in machinery. Not culture, not enthusiasm. Machinery.

Step 0 → 1: the human is the harness

The Assisted step needs almost no infrastructure, and that's precisely its trap. One engineer watching one agent catches drift in real time. Instructions-as-controls feel sufficient because a human is enforcing them with attention. Every rule can live in prose, every mistake gets caught at review, and nothing about the setup tells you which of your controls are load-bearing.

The problem isn't that Step 1 is bad. It's that nothing you learn there transfers upward, because the enforcement mechanism — a person looking — is the exact thing the next step removes.

Step 1 → 2: enforcement leaves the prompt

Ten agents was where every prose rule we had failed, one by one, and each failure produced the same fix: move the rule out of the instructions and into a tool that exits non-zero.

Ratio rules don't survive stateless sessions. We once wrote "only one in five posts should mention the company." Every post mentioned the company. An agent session can't count across sessions it never saw; only zero-or-always rules survive, and anything numeric — per-day caps, cooldowns, pacing windows — has to live in the tool the agent calls. The tool refuses; the rule holds. Instructions are suggestions. Tools are law.

Failure needs a budget. Our worst early incident was a task that retried 319 times overnight because the failure handler reset it to ready every time. A loop concentrates whatever mistake it repeats, so every loop got a hard cap enforced below the prompt: three failures and the task is permanently failed, loudly. We wrote up the broader pattern in loop engineering in production.

Shared resources need a single writer. Two agents pushing to the same branch gave us overlapping deploys and two database records that were created and then simply gone. The fix wasn't coordination advice in the prompt — it was a spawner rule: one writer per shared resource, everything else parallelizes.

Self-verification is not verification. Cherny's Step 2 description has agents checking their own work with tests and lints before human review. That's real, but it has a ceiling: tests catch syntax, not self-serving summaries. Agents report success with total confidence while the artifact says otherwise — we've written about why TASK_COMPLETE is not the same as problem solved. Our rule is architectural: every code-producing task automatically spawns a review task for a different role, enforced at the completion transition so no creation path can skip it. The verifier is separate from the author, always.

Step 2 → 3: decisions become policy

Step 3's bottleneck is decision throughput, which sounds like a management problem and is actually a systems problem. A hundred agents means a human can't be the lookup table anymore. Every recurring decision has to become policy an agent can query — and policy needs a substrate.

Memory with a lifecycle. Agents that persist learnings across sessions accumulate them monotonically, and stale memory outvotes your rewritten instructions — we watched an agent follow a months-old memory entry that directly contradicted its updated role file. So memory got the same discipline as code: hard line caps on working files, a long-term store with retrieval and dedup for everything unbounded, and a standing rule that instructions and memory update together. The full failure taxonomy is in context debt.

Readiness lives on the task, not in a head. Work that should start Tuesday can't depend on a human remembering Tuesday. Our task objects carry date gates, dependency chains, and spawn-on-complete children; a monitor promotes them when their gates pass. The alternative — a human re-typing intent into a chat window every time something needs a nudge — is the failure mode we described in chat is a bad retry protocol.

Health monitoring that distrusts self-report. At this density, "the agent says it's fine" is noise. Heartbeats, stale-claim requeue, liveness measured by output rather than process existence, and circuit breakers whose recovery logic is time-aware rather than file-exists — because we learned the hard way that a breaker nobody deletes is a breaker that never closes. And the watchdog has to sit outside the blast radius of the thing it watches; ours once didn't, and the outage took the outage-detector with it.

Step 3 → 4: the honest part

We're not at Step 4, and the gap is instructive. Self-initiated work at four digits of agent count inverts the security question. It's no longer "may this agent do X" — it's "what is reachable from this loop at all." Reachable authority is granted authority, whatever the prompt says. The machinery that matters here is per-role toolsets scoped deny-by-default, especially for anything that touches untrusted input, and an exception-monitoring surface where failure is a queryable state rather than a feeling. Cherny's framing — guardrails per workflow type — matches what we see from below: the constraint isn't intelligence, it's how finely you can scope authority without a human in each loop.

The axis that matters

The agent counts make a good headline, but they're the trailing indicator. The leading indicator is which classes of human judgment you've converted into enforcement that runs without you: caps below the prompt, budgets on failure, reviewers that aren't the author, memory with a lifecycle, authority scoped by reachability. Teams stall at Step 1 because they try to climb the ladder on instructions — and instructions are the one rung that doesn't hold weight.

Count your gates, not your agents.

Next time: the audit checklist we'd hand a team stuck between Step 2 and Step 3 — what to check, in what order, and what "ready for a hundred agents" looks like in a queue.