What an AI-Native SDLC Roadmap Sequences

An AI-native SDLC roadmap is the order in which an enterprise adopts the plays of an AI-native software development lifecycle — intent files, plan mode, hooks, agentic code review, continuous evals, self-closing maintenance loops — so that each play arrives only after the controls it depends on already exist. Anthropic published the plays on August 21, 2026 in The AI-Native SDLC playbook. Earlier today I mapped its six lifecycle stages to the posts on this blog. That post answered what the playbook says. This one answers the question I actually get from engineering leaders: in what order do I adopt this, and how far should my organization go right now?

The playbook has a partial answer. It ships a dependency graph — arrows that tell you which play must exist before the next one. That is necessary and it is not sufficient. A dependency graph tells you what has to be in place before a play. It does not tell you how much autonomy your organization has earned the right to hand that play. Those are two different axes, and conflating them is how a bank ends up with a self-feeding maintenance loop wired to a codebase whose CLAUDE.md was last touched in a hackathon.

My Five-Stage Agentic AI Roadmap — Prompted, Piloted, Governed, Assured, Autonomous — is the second axis. Instructions in, results out was IT; intent in, outcomes out is agentic AI, and the roadmap is how an enterprise grants autonomy over intent one earned increment at a time. Below is what the playbook means at each of the five stages: which plays belong there, which to hold back, and the one thing each stage has to prove before the next one is safe.

The Plays, Sorted by Roadmap Stage

By my count the playbook contains sixteen plays across its six lifecycle stages. Here is where each one lands on the roadmap:

1. Prompted: capture intent as intent.md; write the CLAUDE.md; start every session in plan mode and commit plan.md.
2. Piloted: requirements-and-design in one session with skills; give the agent a feedback loop; build-time hooks as guardrails; sandboxed execution; parallel sessions and subagents; skills as institutional knowledge.
3. Governed: managed settings the engineer cannot override; hooks as human approval gates; AI in the PR review loop under branch protection; the agent inside CI/CD with its own identity; auto mode for routine work.
4. Assured: continuous evals on the agent’s configuration; recurring scheduled codebase scans; rehearsed rollback; every gate decision exported to observability; leading and lagging indicators read from git and the incident tracker.
5. Autonomous: closing the loop from a deterministic control-band breach; Claude on call in the incident channel; the agent writing the next intent.md with no person in the invocation path.

Notice one mechanism shows up at almost every stage: the hook. It starts as a guardrail, becomes a gate, and ends as a tier boundary. Track the hook and you can see how far along the roadmap an organization really is, regardless of what its slide deck claims.

Stage 1 — Prompted: Start the Artifact Chain

The plays at this stage: intent.md, CLAUDE.md, and plan mode. Nothing else.

A human drives every session, so the human is the sensor, the permission gate, and the audit trail. What the playbook adds at this stage is not automation. It is bookkeeping. The originator brainstorms with the agent and commits the result as intent.md in their own words — what is wanted, why, under which constraints. An engineer runs /init, cuts the generated CLAUDE.md down to what a new joiner needs on day one, and keeps it under a page because the agent reads all of it at the start of every session. And nobody writes a line of code without an accepted plan.md.

This is the same discipline I called the mistake ledger in my harness governance post, and the playbook gives it a working rule I would adopt verbatim: when the agent makes a mistake twice, the correction goes into CLAUDE.md. Teams that skip this stage’s paperwork rebuild it at Stage 3 from incident reports instead of annoyances.

What to hold back: auto mode, parallel sessions, anything headless. The playbook is explicit that auto-accept is earned by mature guardrails, and at Prompted you have none.

Stage 2 — Piloted: The Agent Checks Its Own Work, in a Box

The plays at this stage: the feedback loop, build-time hooks, the sandbox, skills, parallel sessions with worktrees, and the verifier subagent.

The agent now acts with limited supervision, which means it has to be able to verify itself before a person sees the output. One command that runs the tests and exits non-zero on failure. For bug fixes, the failing test is written first, committed, and the agent is told to make it pass without touching the test — with a hook that blocks edits to test files during the fix. That last detail matters more than it looks: an agent that can weaken the check on its own code is not being tested, it is being flattered.

Build-time hooks arrive here as guardrails, not gates. Block edits to protected paths, run the linter after every edit, keep credentials out of the diff. Fast, scoped to the file that changed, no human in the path. The playbook says an approval prompt during the build puts a person back on the critical path of every parallel session, and I agree completely. A pilot drowning in approval gates tells you nothing about the agent. Sandbox the execution — I wrote about what happens when isolation lives in a policy document instead of the infrastructure in the sandbox isolation post — and start exporting session traces to OpenTelemetry even though nobody is reading them yet. You are building the evidence habit before the evidence is required.

Skills belong here too, with one caveat the playbook states plainly and most teams miss: a skill is an advisory control. It makes the agent likely to apply the policy. Nothing forces a session to comply. A policy that must always hold needs a hook behind it, and that is Stage 3’s problem.

What to hold back: agentic PR review as a merge condition, CI/CD write steps, anything touching production. The pilot proves the loop converges. It does not yet prove the loop is safe to grant authority.

Stage 3 — Governed: Hooks Become Gates and the Agent Gets an Identity

The plays at this stage: managed settings, hooks as approval gates, AI in the PR review loop, and the agent inside the CI/CD pipeline.

This is where the agent touches production systems, and it is the stage where most enterprise agent programs die — because security review asks questions a pilot harness cannot answer. The playbook’s worked example of managed settings is the answer, and it is the single most useful artifact in the document: permissions.deny on secrets and network egress, a sandbox that refuses to start if it cannot initialize, credential files denied to sandboxed shells, allowManagedHooksOnly so nothing local can add or replace a gate, and a plugin marketplace allowlist so every skill and MCP server on an engineer’s machine arrived through an approved channel. Engineers cannot edit or override any of it. Read that as a compliance officer and it is an entitlements policy, enforced in code, every session.

The same hook mechanism from Stage 2 now asks instead of blocks. A production deploy without a named release authorization exits with a message and stops. Branch protection turns anything the agent writes into a PR, with no route to main, and the agent that wrote the code has no way to approve it — separation of duties, preserved mechanically. Each non-interactive run acts under the agent’s own identity, so the pipeline log separates what the agent did from what the engineer who triggered it did. That is agent identity arriving exactly where the roadmap says it must.

In loan origination terms: Stage 2 was the agent drafting against synthetic applicant data in a sandbox. Stage 3 is the agent reading real applicant data, which means the fair lending policy has to exist as a skill the agent reads while it writes and a hook that blocks the write when the skill was ignored. The skill makes violations rare. The hook makes them close to impossible. You need both, and an examiner will ask about the second one.

What to hold back: the self-closing loop. The playbook’s own dependency graph lists review gates and approval hooks as prerequisites for Stage 6 maintenance. Do not argue with it.

Stage 4 — Assured: Regression-Test the Harness Itself

The plays at this stage: continuous evals in CI, recurring codebase scans, rehearsed rollback, and gate telemetry.

The question changes here from can the agent do the work to can I prove the controls worked, continuously, to someone who distrusts me. The playbook’s answer is an eval suite of 20 to 50 real tasks that runs on a schedule and on any change to CLAUDE.md, skills, or hooks — because that configuration steers the agent and deserves the regression testing that code gets. A skill change that drops the pass rate gets reviewed before it merges. Every production incident becomes an eval and stays in the suite. This is the second instrument panel I argued for in the performance metrics post, run as a merge check rather than a quarterly review.

Scheduled security scans do for the codebase what evals do for the configuration. A scan is a point-in-time statement under a particular model, and both halves go stale, so the playbook runs it weekly per repository, validates each finding before it is reported, and dates coverage from the last run rather than the first. Bounded findings go through the PR gate. Anything wider becomes an intent.md. Dismissals carry a reason so the same finding does not return as new.

Two things I would add that the playbook implies but does not state. First, every hook decision is already written to the OpenTelemetry export with a timestamp and an allow-or-block verdict — that export is your continuous controls evidence, so make sure it lands somewhere an auditor can query without asking an engineer. Second, rollback has to be the most rehearsed path in the pipeline before Stage 5 exists, because Stage 5 will call it at 3 a.m. with no one watching. An organization that has never run its rollback in staging has not earned Stage 5, whatever its eval pass rate says.

Stage 5 — Autonomous: Detection Stays Deterministic

The plays at this stage: closing the loop, and Claude on call.

A version-controlled script watches a metric with a stable baseline — CI failure rate, post-deploy 5xx rate, PR cycle time — and invokes the agent when a control band is breached. No model in the detection path. The tiers live in a config file: at one sigma the script logs, at two the agent is invoked read-only to diagnose, at three the agent may act, but only by opening a PR into the review gate or triggering a runbook that was approved in advance. The agent writes its finding as intent.md in the Stage 1 format and the loop feeds itself. Incidents arriving in a Slack channel get the same treatment, with the channel as the audit trail.

Look at what Anthropic did not do. The highest autonomy tier still terminates at a gate built in Stage 3, on a rollback rehearsed in Stage 4, writing an artifact defined in Stage 1. Nobody reviews individual agent actions at this throughput; humans steer by editing CLAUDE.md, tuning the bands, and adjusting the deny list. That is what I meant by govern the harness, not the agent. And the ratchet runs both ways: a dismissal tunes the bands, an incident adds an eval, and an eval regression should contract the agent’s tier automatically. Autonomy at Stage 5 is not granted. It is collateralized by Stages 1 through 4, and the scoring for how much collateral is enough is the subject of Earned Autonomy.

What Neither Axis Covers

The playbook measures cycle time, survival rates, first-pass CI success, and DORA. My roadmap measures institutionalized controls. Neither one counts the dollars, and every stage above multiplies token consumption — three review passes per PR, a nightly eval suite with its own API budget, an agent invoked on every two-sigma breach. Put cost per completed task on the same dashboard as the eval pass rate from Stage 2 onward, not after the loop closes. The CISO asks about the gates in the first meeting. The CFO asks about the loop in the second.

The Question for Your Engineering Leadership

Adopt the plays in the playbook’s dependency order — it is correct. Then place each team honestly on the roadmap and ask whether the plays it is running match that stage. A team running parallel auto-mode sessions with no managed settings is a Stage 2 team doing Stage 3 work on a Stage 1 harness, and it will produce your next incident report. A team that built the full eval suite and the production gate for an agent that drafts release notes will produce your next ROI write-down. Find the hook in each team’s setup and ask what it does today: block, ask, or tier. That single answer tells you which stage they are at. Which of your teams is running a play it has not earned?

My frameworks are laid out in full in my two books, Agentic AI and Earned Autonomy, and the vocabulary in my Agentic AI Glossary.

Go deeper — I write four newsletters on LinkedIn:

• Agentic AI Architect — control design and architecture patterns for enterprise agentic AI
• Agentic AI Case Studies — teardowns of real enterprise deployments and what made them work
• Agentic AI P&L — the cost, ROI, and payback math behind agentic AI
• Agentic AI Governance — the controls, accountability, and oversight layer

Get every post first by email: subscribe on Substack.

© Dr. Harish Kotadia, Ph.D., All Rights Reserved, 2026.

Dr. Harish Kotadia, Ph.D., is an Enterprise AI Architect with 20+ years of IT consulting experience serving Fortune 100 clients, specializing in agentic AI systems built on Anthropic Claude, AWS Bedrock, and Google Vertex AI.

Disclaimer: This blog post is based on publicly available academic publications, vendor documentation, open standards, and news items from reputed media sources linked above. This post is intended for educational purposes, to help the enterprise agentic AI community build a shared vocabulary from public, authoritative sources.

Views and opinions expressed here are my own and do not represent those of any employer or client, past or present. The analysis presented is my independent interpretation of the published sources linked above and does not constitute legal, financial, or consulting advice of any kind.