The agentic SDLC is the same software development lifecycle teams have always run, requirements, design, development, testing, release, maintenance, except AI agents now do a meaningful share of the work inside each stage, while a person still owns what gets built and what ships.
Half a dozen vendors have published their own definition of the term in the past few months, techcommunity.microsoft.com, coderabbit.ai, port.io, sonarsource.com, devinterrupted.substack.com, and a domain built for nothing else, asdlc.io. A keyword this small doesn't usually draw that much attention at once. It's drawing it now because the category is still being named, and whoever's definition sticks first tends to stick. Almost every one of those definitions says the same thing: agents do more, across more stages. None of them says what has to be left behind at each stage for the answer to a question asked later to still hold up.
What were the SDLC's stages before agents showed up?
Before agents, the software development lifecycle moved through six stages, whatever methodology sat on top of them: requirements and planning, where someone decided what to build and why; design, where that decision became an architecture and a set of interfaces; development, where a person wrote the code against that design; testing and QA, where the result got checked against the requirement, not just against itself; deployment and release, where the change reached production under someone's authorization; and maintenance, where the team watched what happened after release and fixed what broke. Each stage left behind its own artifact: a spec or a ticket, a design document, a diff, a passing test run, a release record, an incident log. The agentic SDLC keeps all six stages. What changes is who, or what, produces the work inside each one, not the shape of the lifecycle itself, and that's exactly the distinction most current definitions of the term skip past.
Where do agents actually insert themselves in the SDLC?
Coding is where agents are furthest along, and it isn't close: agentic coding, the plan, edit, run, verify loop, is mature enough that a headless agent can take a real ticket from a repository to a passing build without a person touching an editor. Testing comes next: agents write and execute test suites against a change, though a generated suite is only as trustworthy as the requirement it was built to check. Planning is newer and moving fast: Microsoft's Spec Kit turns a stated goal into requirements, a plan, and a task breakdown that a coding agent then executes against, which means the spec itself can now come from a tool, not only from a person, and that shifts risk earlier in the lifecycle instead of removing it. Review sits in between: agents summarize a diff and flag likely issues well; the risk shows up when that summary gets treated as the review itself, instead of as one input into a decision a person still has to make.
Which stages just got louder, not different?
Deployment, security review, and incident response didn't get reinvented, they got louder, because more change now moves through them every week while the process at that stage still runs at the same speed it always did. A survey of 700 enterprise technology professionals published by Harness in September 2026 puts a number on the gap: 74% of organizations are confident their testing catches agent failures, but only 19% actually have automatic gates that block a bad release from going out; 76% believe they could disable a misbehaving agent within 15 minutes, but only 33% have a kill switch that fast. That's the same gap showing up twice, at testing and at release: confidence scaled with how much agents produce, the control that would justify it didn't. Coding was never the actual bottleneck in a software team's output, and these numbers show it isn't the bottleneck in an agentic SDLC either. The stages that were always about judgment, not typing, are exactly where the unchecked volume now piles up.
What artifact does each stage now have to leave behind?
The distinction that matters for a given stage isn't whether an agent touched it. It's whether the stage still produces something a person who wasn't there at the time can check later, without asking whoever ran the agent to reconstruct it from memory.
| Stage | What an agent can do there now | What has to survive it |
|---|---|---|
| Planning | Turn a goal into requirements and a task breakdown | A spec that's checkable against what actually shipped |
| Development | Write and edit code against that spec | A diff tied to the authorization that scoped it, not just a commit message |
| Testing | Write and run the test suite | A test run a machine executed, not the agent's own report that it passed |
| Review | Summarize a diff and flag likely issues | A recorded accept or reject decision from a person, not the summary alone |
| Release | Package and ship the change | A signed release record naming who authorized it |
| Maintenance | Triage and patch what broke | An incident log tied back to the change that caused it |
Some of this is already mechanical: a tool like Claude Code can run hooks that force a check before a commit is even accepted, so the gate exists whether or not someone remembers to run it by hand. A hook enforces that the check runs. It doesn't replace the artifact the check has to leave behind, it only automates getting there.
Can you still explain this lifecycle to a client, stage by stage?
That's the actual test of an agentic SDLC, not whether agents touch more stages, but whether someone facing a client, an auditor, or their own team months later can walk the six stages in order and point to what survived each one: the spec, the diff and its authorization, the test run, the review decision, the signed release, the incident tied back to its cause. Most of the vendor definitions racing to name this category answer a narrower question, how much of the work an agent can now do. Detent, the end-to-end delivery system (detent-ai.com), is built around the other one, keeping intent, authorized context, execution, and a human signature linked across every stage, from request to release, so the lifecycle stays explainable after the fact, not just faster while it runs.