Skip to content

AI Adoption Maturity Model

A five-step ladder (0–4) describing how an engineering organisation moves from gated AI access to agent-native development, from Boris Cherny's Steps of AI Adoption (Anthropic, July 2026). The headline axis is agent count — 0 → ~1 → ~10 → ~100 → ~1,000+ — but that number is a symptom, not the mechanism.

This is a vendor document

The source is authored inside Anthropic and each step carries a "products that help" column, so the ladder doubles as a purchase path. The bottleneck analysis below stands on its own and is the durable part; the tool lists are a snapshot of one vendor's catalogue in mid-2026. Read the diagnosis, discount the prescription.

Diagram

Five-step AI-adoption ladder as a matrix — AGENTS, STEP & ROLE, WHAT BREAKS, and GUARDRAIL SHIFTS columns across steps 0–4

Four columns matching this page's three analytical sections: agent count, step & role, what breaks (the bottleneck spine), and guardrail shifts (what each step's controls escalate to, not just how tight they get). Transition unlocks sit in the gap between rows. The source's "products that help" column is deliberately omitted — it is the vendor-catalogue part, the least durable and already recorded verbatim in steps-of-ai-adoption.

Editable copy: https://excalidraw.com/#json=iwrmnmLSpg2gjascb0w_H,k4riJSHXx7hOyegjU4iDqg (a public excalidraw.com scene; the file in wiki/assets/ is canonical.)

The real spine: the bottleneck moves

Each step is defined by what breaks, not by how many agents run. The agent count is what the organisation can sustain once the previous bottleneck is cleared — which is why buying more capacity without clearing the bottleneck does nothing.

Step Your role Agents Bottleneck
0 Gated — 0 Legacy security/approval processes; cost-per-token containment over outcomes; no true technical voice in decisions
1 Assisted you + an agent (a pair) ~1 Your attention. Low trust in output plus no self-verification means you read everything and never look away. Work stays synchronous
2 Parallel orchestrator ~10 Review. You hand-write less but check six streams of it; prompting and steering while juggling sessions
3 Supervised autonomy manager of managers (an org tree) ~100 Trust in the loop and team decision throughput. Also token efficiency at scale
4 AI-native VP steering by intent ~1,000+ Identifying which work to automate, and picking the right guardrail per work type

The through-line: at step 1 you review keystrokes, at step 2 final diffs, at step 3 the question stops being "did you read the code?" and becomes "what context was the model missing, and how do we fix that for next time?" The unit of human attention gets coarser at every step. That reframing — from inspecting output to engineering context — is the model's most useful single idea, and it is why agent-memory-at-scale and claude-code-memory-architecture are step-3 infrastructure rather than conveniences.

The transitions carry the prescription

The gaps between steps are more actionable than the steps themselves.

  • 0 → 1 — Executive/buyer alignment and escalation of blockers; frameworks for launching securely. A political problem, not a technical one.
  • 1 → 2 — Run more than one agent at a time; build a self-verification loop you actually trust (tests + build + lint + e2e against a real dev environment); auto mode so permission prompts stop blocking; automate code review. The verification loop is the load-bearing item: without it, trust never rises and attention stays pinned at keystroke level.
  • 2 → 3 — Give the agent a way to pull in context (let it read code, wikis, discussions); agency and code-review speed, since agents start touching other teams' code; break work into loops and routines; let Claude kick off Claude.
  • 3 → 4 — Scaled automation of domain-specific use cases: code migration, fuzzing, feature-building, feedback remediation.

Guardrails escalate in kind, not just degree

The governance story is not "more of the same, tighter" — each step needs a categorically different control, because the thing being controlled changes.

Step Control shifts to
0 Access: SSO/SCIM, role-based access, org budget caps, deploy inside existing IAM
1 Spend and visibility: per-seat caps, centrally managed model/effort settings and policy, OpenTelemetry export into the existing SIEM
2 Automated verification: code review + security review on by default, lint/test/typecheck enforcement, Claude-powered e2e, pre-approved safe bash/MCP commands. Same quality bar for human and agent code
3 Containment and encoded standards: agent sandboxing, worktree isolation, CLAUDE.md and Skills as the standards themselves, tuned auto-mode classifier, active token-use management
4 Automation economics: cost controls and model selection for unattended runs

Two of these are worth isolating. The step-2 line "hold the same quality bar for human and agent-generated code" is the cheapest governance rule in the document. And the step-3 move — encoding standards in CLAUDE.md and Skills rather than in review comments — is the point where process becomes artifact; it is the same shift claude-code-memory-architecture describes at the level of a single session, applied to an organisation.

The step-3 trap is named explicitly: scaling agent count before the loop has earned widespread trust. The cost discipline is framed as a question rather than a budget — "is this something an engineer would have done?" — which generalises better than a token ceiling.

Tension with ai-agent-architecture

This source and the architecture guide disagree about multi-agent systems, and the disagreement is real rather than terminological.

  • ai-agent-architecture §2.3 warns: "be sceptical of multi-agent… every agent-to-agent handoff is a lossy context transfer," and advises reaching for it only when sub-tasks are genuinely independent — keeping orchestration in your code, not another agent's discretion.
  • This source treats scaling agent count as the adoption path itself: step 3 is "manager of managers (an org tree)" with subagents, and step 4 has Claude kicking off Claude across 1,000+ agents.

A partial reconciliation: much of the ladder describes independent tasks under worktree isolation — parallelism, not collaboration — which is precisely the case §2.3 permits. Step 2 (5–10 agents, each on its own checkout) fits the guide's advice without strain.

But it does not fully resolve. Step 3's "org tree" is hierarchical delegation with an agent choosing what to fan out, and step 4's closed loop puts orchestration explicitly in the agent's discretion — the thing §2.3 says to keep in your own code. The genuine difference is about what makes handoffs safe: the guide treats context loss as intrinsic to agent-to-agent transfer, while this source treats it as an engineering problem solved by verification loops, sandboxing, and encoded standards — hence "what context was the model missing?" as the step-3 question. Neither position is tested here; note both.

Note also that both agree on the shape of the constraint even while disagreeing on the ceiling: the guide's bounded autonomy and this model's trust in the loop are the same variable, and both insist verification must precede autonomy.

  • ai-agent-architecture — the mechanisms underneath: §5.2 activation (agent-to-agent triggering is the step 3→4 unlock), §8.5 HITL checkpoints and bounded autonomy, §13 cost architecture, §14.2 on skipping the workflow stage
  • agent-memory-at-scale — the context-supply problem the 2→3 transition names
  • claude-code-memory-architecture — encoding standards as durable artifacts

Sources