Ask six vendors what “Agentic Development Lifecycle” means and you’ll get six different phase counts, six different priorities, and at least two flatly contradictory claims about whether it’s even a new lifecycle at all.
That’s not a hypothetical. I pulled every substantive ADLC framework published in the first half of 2026 — from a cloud consultancy, a security vendor, a systems integrator, a boutique dev shop, and an enterprise ops firm — checked whether Gartner or Forrester had stepped in to settle it, then lined all of it up side by side. They all use the same four-letter acronym. Almost nothing else about them agrees, and the analysts made it worse, not better.
Before picking this apart, it’s worth being fair to the underlying idea, because the problem it’s responding to is genuine.
The classic Software Development Lifecycle assumes you can specify behavior at build time, test it before release, and expect it to run the same way in production as it did in staging. Agentic systems break that assumption in a specific way: they reason across context they don’t fully control, their outputs vary even given similar inputs, and small upstream changes compound into materially different downstream behavior. One preprint circulating on the subject — not yet peer reviewed, worth flagging — points to just how fast this shifted using SWE-bench Verified as a proxy: issue-resolution rates on that benchmark rose from under 2% to over 78% between October 2023 and April 2026. Whatever you call the practice of managing that shift, something in the SDLC does need to change.
The question is whether “ADLC” actually names a coherent answer to that problem, or whether it’s a label six different companies are attaching to six different things they already wanted to sell.
EPAM frames ADLC around what it isn’t: not the old SDLC with AI coding assistants bolted on, but a lifecycle for systems where the model sits at the core of product behavior rather than accelerating a human who’s still doing the real work. Its version front-loads work traditional SDLC never required — defining business and technical KPIs upfront, mapping which decisions belong to humans versus the agent, and running a data-readiness review before anything gets built — because, in EPAM’s telling, skipping that step pushes compliance and accountability problems into production where they’re expensive to fix.
Codebridge structures ADLC as six named phases: Ideation and Intent Specification, Architecture and Scaffolding, Development and the Inner Loop, Behavioral Testing and Validation, Deployment and Orchestration, and Governance. Its distinguishing idea is the “Capability Matrix” — a tool for deciding, phase by phase, which parts of a workflow need non-deterministic LLM reasoning and which need to stay deterministic, rule-based logic. A customer-intent classifier gets the model; an SLA timer or a financial calculation doesn’t.
Sumatosoft takes a completely different shape: five pillars — zero-hallucination architecture, financial governance, security by architecture, human-in-the-loop control, multi-modal grounding — applied across seven phases. One worked example from its post illustrates the cost-governance pillar specifically: a token-economics review caught a design flaw that would have cost $180,000 a month at projected volume, and a model-routing fix — a cheap model for screening, a flagship model only for the hard cases — brought that down to $22,000.
Cycode defines ADLC almost entirely through a security lens: autonomous agents calling tools, reading and writing code, querying APIs, and pulling dependencies without waiting for human approval at each step. Its central argument is that this creates two problems the old SDLC never had — the volume of AI-driven changes now exceeds human review capacity, and the agents making decisions have no innate sense of an organization’s risk tolerance or compliance posture.
Palo IT takes the most deflationary position of the six, and it directly contradicts EPAM’s core claim. Its version of ADLC keeps the traditional SDLC phase names intact — requirements analysis, architecture, implementation, testing, deployment — and simply reassigns who performs them: AI agents handle execution, human engineers shift into orchestrator, reviewer, and decision-maker roles. In this telling, ADLC isn’t a new lifecycle at all. It’s the old one with the seats reshuffled.
SPTech skips phase-counting altogether and frames ADLC as an executive governance concern first, an engineering framework second. Its version covers the full arc from idea to launch to ongoing iteration, but the emphasis sits on organizational risk — illustrated with a scenario where a customer-service agent quietly drifts into giving wrong refund answers for weeks before anyone notices, because agent lifecycle management got treated as a developer’s problem instead of a leadership one.
Lay all six next to each other and the disagreement isn’t cosmetic. EPAM says this is fundamentally not the old SDLC. Palo IT says it’s exactly the old SDLC with different actors. Codebridge and Sumatosoft both propose fixed phase counts, and they don’t match — six phases versus seven. Cycode treats it as a security discipline. SPTech treats it as a leadership discipline. None of these sources cite each other. None acknowledge the others’ definitions exist.
The obvious next question: what do Gartner and Forrester say? Normally, when a technical term goes through exactly this kind of vendor-driven chaos, an analyst firm eventually steps in, picks a definition, and the market converges around it — that’s roughly what happened with terms like MLOps and DevSecOps.
That hasn’t happened here, and checking why is more revealing than the six vendor definitions on their own. Neither Gartner nor Forrester has adopted “ADLC” as a term at all. Instead, each has coined its own distinct acronym for an adjacent — but narrower — slice of the problem. Forrester calls its framing AppGenSec: security built proactively into code generation itself. Gartner calls its version ACSA (AI Code Security Assistance): real-time systems that validate code inline regardless of whether a human or a model wrote it. Both are specifically about code security, not the full development lifecycle six vendors are calling ADLC. Gartner has weighed in on the broader category in one respect — a widely cited projection that more than 40% of agentic AI projects will be canceled by the end of 2027 — but that’s a warning about project failure rates, not an endorsement of any lifecycle framework, let alone this one.
So the convergence mechanism that usually resolves this kind of naming chaos isn’t just absent. It’s actively adding a seventh and eighth acronym to a space that already couldn’t agree on one.
Widen the search past polished vendor blog posts and the fragmentation gets more concrete, not less.
AWS has the most credible entry on this entire list, for one simple reason: it’s not a company describing a framework in prose, it’s an actual open-source, actively maintained repository — awslabs/aidlc-workflows — with versioned releases and its own specification document. And its structure agrees with none of the six above: AWS's AI-DLC runs five phases broken into 32 stages (Initialization, Ideation, Inception, Construction, Operation), executed through a roster of 14 specialized agents, with explicit approval gates between stages. That's a seventh distinct structure, more granular than any vendor blog's, and it's the only one on this list you can actually install and run against a real codebase rather than just read about.
There’s also at least one dedicated ADLC tooling vendor — agenticlifecycle.ai — that defines the term around runtime enforcement rather than planning-phase diagrams: deterministic gates that produce evidence, human gates that record attestation, and IDE-level plugins (built for Claude Code, Copilot CLI, and other coding agents) that block or roll back tool calls in real time. That’s an eighth definition, and a genuinely different category from either the consulting-phase-diagram model or AWS’s stage-based workflow.
And the naming problem alone tells you how unsettled this still is. The same underlying idea currently circulates under at least four different names: Agentic Development Lifecycle, Agentic-SDLC (the same concept reframed as an evolution rather than a replacement, because — as Cycode’s own post admits — that framing “resonates better” with teams wary of a full rewrite), Agent Development Lifecycle (dropping the “-ic”), and an academic variant called A-SDLC that models the whole thing as five technical layers — reasoning and memory, the agent-computer interface, tools and environment, orchestration, and governance — instead of sequential phases at all.
Fair objection, and worth answering directly rather than ignoring. Most technical terms take time to converge, and ADLC is genuinely young. But the usual reason terms do eventually converge is that someone with the authority to arbitrate — a standards body, a dominant platform vendor, or an analyst firm everyone already trusts — picks a definition and the rest of the market falls in line around it. That’s what happened with DevOps, and later with MLOps.
That mechanism isn’t stalled here. It’s missing entirely, and where it should be, something worse is happening: the two firms best positioned to arbitrate this have instead each launched their own separate, narrower acronym, which means the fragmentation is being reinforced by the same institutions that normally end it. This isn’t “too early for consensus.” It’s a term with no path to consensus in its current form, because nobody with the standing to declare a winner is trying to.
None of this is really about ADLC being an unusually hard concept to pin down. It’s about incentives.
A security vendor writing about ADLC is going to define the lifecycle’s central problem as a security problem, because that’s the framework that leads naturally into their product. A firm that sells organizational-change consulting is going to define it as a governance and leadership problem, because that’s the engagement they close. A cost-optimization-minded shop is going to lead with token economics and model routing, because that’s the win they can point to in a case study. A tooling vendor is going to define it as something you install. None of these framings are dishonest, exactly. They’re each company’s business model wearing the same acronym.
Compare that to how DORA’s four metrics actually got established: one research program, one book (Accelerate, by Forsgren, Humble, and Kim), built on years of the same team’s survey data, published by a single group that then continued to own and revise the definition. That’s why “deployment frequency” means the same thing whether you hear it from Google, a startup, or a Fortune 500 platform team. ADLC has no equivalent anchor, and — per the analyst gap above — nothing currently positioned to become one.
If someone on your team, or in a vendor pitch, says “we’re implementing ADLC,” the useful response isn’t to nod along, and it isn’t to assume they mean a recognized industry standard — because right now, there isn’t one. Ask which version. The answer will tell you a lot about what you’re actually being sold: a security audit, a cost-governance exercise, an org-design consulting engagement, an installable enforcement layer, or an actual engineering process change. More usefully, strip away the branding and look at what actually repeats across all eight definitions, because that’s the part that’s real regardless of whose acronym you attach to it:
That short list is the actual signal. The phase diagrams, the pillar counts, the acronym itself — that’s packaging, and right now it’s packaging with no analyst, no standards body, and no shared origin behind it. Build the practices. Skip the framework shopping.
ADLC Has Six Definitions and Zero Consensus — I Compared Every Major Framework was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.