ADLC (Agentic Development Lifecycle): What It Actually Means, and Why Six Frameworks Disagree (2026)

ADLC - the Agentic Development Lifecycle - is the attempt to answer a fair question: if the SDLC governs how deterministic software gets built, tested and shipped, what governs software whose behaviour changes run to run? Agents plan, call tools, read untrusted content and act. You cannot unit-test your way to confidence in that, and a change-approval board designed for pull requests has nothing useful to say about a model that picks a different tool today than it did yesterday.

So a lifecycle model makes sense. The problem is that the term arrived faster than the consensus. Independent analysis in 2026 found six competing ADLC definitions published in the first half of the year, with different phase counts, different orderings, and claims that directly contradict each other. IBM, Salesforce, Cycode and others each shipped a model, and several are attached to a product. This guide does three things: defines the term honestly, compares what the frameworks actually share, and names the precondition all of them skip.

Why ADLC appeared when it did

Two numbers explain the urgency. Gartner projects that enterprise applications using agentic AI will go from under 1% in 2024 to 33% by 2028. It also projects that more than 40% of agentic AI projects will be cancelled by the end of 2027 - attributed to escalating costs, unclear business value, and inadequate risk controls. Read together, those say adoption is arriving faster than the ability to govern it, and the governance gap is a leading cause of failure rather than a compliance footnote.

There is a security clock running alongside the adoption clock. Cisco notes that the interval between disclosure and weaponization has compressed from weeks to days or hours, while enterprises still take an average of 43 days to patch a critical vulnerability. For the agent layer that gap is worse than it sounds, because a meaningful share of agent issues ship with no CVE and no vendor advisory at all - the DeepJack deeplink flaw in Cursor had neither, and was still reproducible months after the vendor confirmed the root cause internally. A lifecycle that depends on patch notifications to trigger action will not fire.

What the frameworks disagree about

The disagreements are not cosmetic. They change what you build.

A practical consequence: do not adopt a vendor's ADLC diagram as your control framework. Several models are shaped by what the accompanying product does - Cycode, for instance, shipped an ADLC Security offering covering *prompt to runtime*, whose first capability is auto-discovering shadow AI, coding assistants and MCP servers. That is a reasonable capability and a reasonable emphasis, but it is an emphasis. Use ADLC as vocabulary for planning, then map onto control frameworks you can produce evidence against.

What they agree about - the part worth adopting

Strip out the branding and five requirements survive in every published model. These are the durable content of ADLC, and they are all implementable without picking a side.

1. Identity per agent. Each agent needs a distinct, attributable identity - not a shared service account and not a developer's personal credentials. This is the non-human identity problem, and it is the foundation everything else rests on.
2. Least-privilege tool access. Scope what each agent may call and reach, rather than granting the union of everything it might one day need. An agent's blast radius is the set of tools it can invoke.
3. Evaluation before promotion. Behavioural evaluation against a held-out set, not just unit tests. Whether it is a gate or continuous, nothing reaches production unevaluated.
4. Runtime observability and enforcement. Because behaviour is non-deterministic, pre-deployment testing cannot be the last line. You need to see tool calls as they happen and be able to deny them.
5. An audit trail. A queryable record of what each agent did, what it accessed, and what was allowed or denied - see how to audit AI agent activity.

The precondition every framework skips

Here is the gap. Almost every ADLC model begins at design or intake, which silently assumes the agents in scope are the agents you decided to build. That assumption fails in exactly the environments the frameworks are sold into. Agents are not procured centrally; they are installed - a coding assistant per developer, an MCP server per project, a skill or hook per repository, a browser extension per person. They arrive the way AI agents became the new shadow IT: bottom-up, individually justified, collectively uncounted.

A lifecycle applied only to agents that entered through the front door governs a minority of the fleet, and produces a governance report that is technically accurate and materially wrong. Worse, the install-time consent step that most of these agents rely on is itself now an attack surface - DeepJack hid an MCP install command off-screen in the confirm dialog, and PromptFiction removed the consent step altogether. If your lifecycle's entry point is *someone approved this*, both of those walk straight past it.

So treat discovery as phase zero: a continuous, fleet-wide inventory of the AI artifacts actually present, independent of whether anyone filed a request. Anomity's Endpoint Sensor inventories eight AI artifact types per endpoint - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks and CLIs - which is the concrete version of phase zero. Practical guidance on building it lives in how to build an AI agent inventory and, for the server layer, building an MCP server registry.

A phase model you can defend

If you need a model, this is the minimum that survives contact with a real fleet. It is deliberately boring, and each phase names an artifact you can show an auditor.

Phase 6 is routinely forgotten and routinely bites. Removing an agent is not the same as removing what it left behind: hooks in .claude/settings.json, tasks in .vscode/tasks.json, MCP entries, and credentials still valid. Supply-chain campaigns have specifically exploited that residue - a package fix that leaves a planted hook on disk reports green while the persistence mechanism is untouched.

Mapping ADLC onto frameworks you can evidence

ADLC is a planning vocabulary. Assurance still comes from control frameworks with defined requirements and auditable evidence. The mapping is straightforward once phase zero exists, because most of these frameworks open with an inventory or context requirement that discovery satisfies directly.

How Anomity fits

Anomity implements phase zero and phase four - the two that most ADLC models either assume or leave to the reader. The Endpoint Sensor is unprivileged, runs on Windows, macOS and Linux, and inventories eight AI artifact types per endpoint, so discovery is continuous rather than a survey. Where an agent exposes a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each call against policy and returns allow, deny, or log before it runs, which is runtime governance at the point of action rather than the point of approval.

Decisions and artifact changes land in a queryable 90-day audit trail, which is the evidence phase. Anomity collects metadata only, with on-endpoint secret redaction, so governing the agent layer does not create a new store of credentials to protect. Findings route to SIEM, Slack, email, or Jira, the platform is SOC 2 Type II, and it complements EDR, DLP, network and GRC tooling rather than replacing it. See how it works.

You can't govern what you can't see.The Anomity principle

Getting started without picking a vendor's model

• Write down which agents you *think* you have, then run a discovery pass and compare. The delta is your actual starting position, and it is usually the most persuasive artifact you will produce all quarter.
• Adopt the five points of agreement - identity, least privilege, evaluation, runtime enforcement, audit trail - before adopting anyone's phase diagram. They are uncontested and independently useful.
• Put discovery ahead of design in whatever model you use, and make it continuous. An annual inventory of a surface that changes per commit is not an inventory.
• Include installed agents in scope, not only built ones: coding assistants, MCP servers, skills, hooks, extensions and CLIs. This is where the volume and the incidents are.
• Stop treating install-time consent as a control. It has been defeated by truncation and bypassed entirely - govern at the tool call instead.
• Define retirement explicitly, including hooks, MCP entries, leftover configs and credential revocation. Removing the agent is not removing its residue.
• Map each phase to a control you can evidence in ISO 42001, the NIST AI RMF or the EU AI Act, so the lifecycle survives an audit.
• Name an owner for runtime. Unowned runtime is the most common way an otherwise sound lifecycle quietly stops working - see how to audit AI agent activity for the ownership pattern.

ADLC is a useful idea with an unfinished definition. The honest position in 2026 is that the phase diagrams are marketing artifacts in varying degrees, the five shared requirements are real, and the precondition - knowing which agents exist - is both the least discussed and the most load-bearing. Start there. For the surrounding governance picture see the AI governance framework for enterprises, and for the layer ADLC has to reach in practice, securing AI coding agents and CLIs and the MCP Server Security guide. To see what a real phase-zero inventory returns on your own fleet, request early access.