Step Three, Measured from a Company of One
Boris Cherny published a ladder in July: five steps of AI adoption, from Gated at step zero to AI-native at step four, with agent counts that go one, ten, a hundred, a thousand. It is written for organisations, with columns about IT approval paths and decision throughput and executive alignment. I run a regulated fintech alone, so I read it the way you read a growth chart for a species you are not quite a member of, and then I measured anyway.
The honest reading: I operate at step three, supervised autonomy, with one foot on the rung above and one boundary where I refuse to climb at all. This essay is the measurement, including the parts where the ladder and a company of one disagree.
What step three looks like without an org chart
The step three description says Claude writes nearly all the code, agents kick off agents, and the question shifts from "did you read the code" to "what context was the model missing." Checked against a normal week here:
Most working sessions in my repositories are agent sessions. They start from fresh checkouts in isolated worktrees, run their own gates, open their own pull requests, and an automated reviewer decides whether low-risk work merges. Overnight, scheduled routines write content drafts, hunt defects, and watch pull requests without anyone asking. This week one agent built an entire property module from a written brief while another crawled 131 accounting firm websites for an outreach list and a third redrew nine blog illustrations, and I reviewed outcomes, not keystrokes.
The context question is real, and I can date my conversion to it. The property module brief I wrote claimed the new rent ledger could reuse an existing transactions table. The building agent checked the actual schema, found the claim false, flagged it at the top of its report, and built the correct table instead. My reaction was not to read its code more carefully. It was to ask why my brief carried a stale assumption, and to fix the checklist that briefs get written from. That is the step three reflex the ladder describes, arrived at not by policy but by being wrong in a documented way.
One rung-four behaviour already runs: some agents are started by agents. The defect pipeline finds a bug, files it, and a fixer session picks it up. But I still light most of the fires myself, and the ladder is right that this is the difference that matters.
The bottleneck is not what the table says
For step three the table names the bottleneck as trust in the loop and the team's decision throughput. A company of one has no throughput problem in the meeting sense. My bottleneck is stranger: it is that I am the only holder of the one key that must never be automated.
My codebase has a hard boundary. Calculation engines, schema migrations, payments, anything that decides what a customer is charged or what a tax figure says: agents author that work, and a human merges it, every time, after reading it. The ladder would call this a step-two behaviour surviving inside a step-three operation. I call it the reason the step-three operation is allowed to exist. The software computes people's retirement tax positions. A wrong figure there is not a bug, it is the end of the product's reason to be trusted.
So my version of the ladder bends at the top. Autonomy here does not converge on "Claude does everything and I steer by intent." It converges on a split: intent-steering across ninety five percent of the surface, and a deliberately manual, deliberately narrow gate on the five percent where being wrong compounds. If that caps me at step three and a half forever, the cap is the product working as designed. Climbing the last rung on the money paths would not be maturity. It would be the first step of the incident report.
The question in the margins: below the filesystem
The sharpest question I have seen asked about setups like mine is about depth. Fine, you restrict agents in the filesystem, worktrees and scoped writes and path rules. What restricts them at the system level? A filesystem boundary does not stop a credential from being used, a network call from being made, a deployment from going out.
The question deserves a straight answer, and mine has two halves.
The half I am comfortable with: the boundaries I actually rely on are not filesystem boundaries at all. They live in the identity plane. The credential an agent session holds cannot push to the main branch, because branch protection applies to every identity, including mine. It cannot apply a database migration, because the database credential is not present in its environment; migrations run through a console only I log into. It cannot touch payment configuration, deployment settings, or DNS, because those live behind dashboards whose sessions it does not have. When a prompt injection convinces an agent to try something destructive, and on a long enough timeline one will, the interesting question is not whether the agent wants to. It is what its keys can do. Restricting what an agent may write is etiquette. Restricting what its identity can reach is security.
The half I concede: below that, I am thinner than a platform team would be. Agent processes here can make arbitrary outbound network calls. They run as a normal user on a normal machine, not in an OS-level sandbox with an egress allowlist. The adoption ladder lists agent sandboxing as standard equipment at step three, and it is the piece of standard equipment I am missing. My compensation is that the blast radius design assumes the process is compromised and asks what the worst reachable action is, and the answer, because of the identity plane, stays bounded at "opens a strange pull request that a gate then refuses." That is a real mitigation and also not the same thing as the control. It is the next fence to build, and writing this paragraph is partly a commitment device.
Is any of this too simple?
I asked myself this reading the ladder, because the table's later rows are full of machinery I do not have: analytics dashboards, telemetry exports, classifier tuning, fleets of a thousand agents. Next to that, a tier table and a hard-stop rule and a vocabulary scanner can look like a garden shed next to an airport.
But the comparison runs in the wrong direction. The platform rows describe what the vendor builds so that adopters can climb. The guardrail column, the part that decides whether climbing is survivable, describes things that are small almost everywhere: a review gate, an isolation rule, a standards file, a pre-approved command list. Mine happen to be tuned for a domain where the worst mistake is quiet and financial rather than loud and embarrassing. Small is not the opposite of serious. In controls, small is usually what serious looks like, because every part of a small control gets exercised daily, and a control that is exercised daily is a control you actually have. The elaborate ones are where the gaps hide.
What a company of one contributes to this conversation is not machinery. It is a clean experiment. No committee effects, no adoption politics, no ambiguity about who decided what. One person, one rulebook, eight months, seven hundred pull requests, and a boundary that has not been crossed. The ladder says step three's trap is scaling agent count before the loop has earned trust. The single-operator version of that sentence is shorter: the trap is boredom. The loop earns trust slowly and loses it in one merge, and the only person watching is the person who is also tired. Mechanism, not vigilance, is what survives that. Which is the same conclusion the first essay in this series reached from the other direction, and I am beginning to think it is the only conclusion there is.