ADLC Is Not One Thing Yet: How to Evaluate Agentic Development Lifecycle Frameworks

If you have started seeing ADLC next to SDLC, DevOps, coding agents, and AI governance, the confusing part is not the acronym. The confusing part is that different projects are using the same acronym for different lifecycle models.

One current implementation describes an eight-phase Agentic Development Lifecycle built around model failure modes, machine-checkable gates, and two human attestations. Another 2026 manifesto describes an Agentic Development Life Cycle as a concurrent loop of Intent, Generate, Validate, Govern, Deploy, and Observe. A separate project uses ADLC for an Agent Development Lifecycle focused on enterprise AI agent governance.

Those ideas overlap, but they are not the same framework.

That means the useful question is not “What is the official ADLC?” There is no evidence yet of one universally accepted ADLC standard. The useful question is:

What problem is this ADLC trying to solve, what controls does it introduce, and what evidence does it leave behind?

That framing is much more practical for teams already experimenting with coding agents, orchestrators, model routers, and autonomous workflows.

Why ADLC Is Appearing Now

Traditional software delivery assumes that humans are the primary execution unit.

Requirements are interpreted by people. Code is written by people. Tests are authored and reviewed by people. CI automates parts of the pipeline, but the human remains the component that translates intent into implementation.

Coding agents change that assumption.

An agent can read a ticket, inspect a repository, write code, add tests, run commands, repair failures, and prepare a change without waiting for a human at every intermediate step. Once that becomes normal, the bottleneck moves.

The problem is no longer only:

How do we help developers write code faster?

It becomes:

How do we make an autonomous execution loop safe,
reviewable, recoverable, and aligned with intent?

That is the space ADLC frameworks are trying to occupy.

This is closely related to the distinction between an agent orchestrator and a model router. Once execution is delegated to agents, architecture has to define who owns decisions, which checks are mandatory, what state survives a handoff, and when a machine is allowed to continue without a person.

ADLC is an attempt to move those decisions from ad hoc prompting into an explicit delivery system.

The Term Is Already Fragmented

The first thing to understand is that ADLC is not currently one fixed lifecycle.

The project at agenticlifecycle.ai describes eight phases:

Triage
Interrogate
Decompose
Rail
Build
Prosecute
Integrate
Distill

Its design is explicitly tied to model failure modes such as premature satisfaction, context rot, confident hallucination, reward hacking, and coherence loss. Six gates are machine-checkable, while two require a person to attest.

The manifesto at adlc.io uses a different model:

Intent
Generate
Validate
Govern
Deploy
Observe

It emphasizes concurrency, continuous feedback, human governance, and treating delivery as a loop instead of a sequential pipeline.

The ADLC framework documented by Oceansoft uses the same acronym for an Agent Development Lifecycle aimed at governance and auditability for AI agent teams.

These are meaningful differences.

If someone says, “We are adopting ADLC,” that statement is incomplete. You still need to ask which definition, which controls, and which artifacts.

This is similar to the early days of many engineering terms. A label becomes popular before its boundaries stabilize. The right response is not to argue about naming. It is to inspect the operational model underneath it.

Look for the Failure Model First

A lifecycle only makes sense if you know what it is defending against.

Classic SDLC controls grew around familiar risks:

• ambiguous requirements;
• accidental defects;
• missing tests;
• risky releases;
• undocumented changes;
• security mistakes;
• operational regressions.

Agentic systems add different failure modes.

An agent may stop too early because a change appears plausible. It may invent an API that does not exist. It may optimize for passing a visible check while missing the actual intent. It may lose context after a long session. It may create a large amount of technically valid but unnecessary code. It may switch strategy after a model fallback and leave inconsistent assumptions behind.

A serious ADLC should make those risks explicit.

When evaluating a framework, ask:

What specific agent failure does each phase or gate prevent?

If the answer is vague, the lifecycle may just be SDLC terminology with AI words added.

A useful control should have a traceable reason to exist.

For example:

failure: agent declares success too early
control: independent verification gate
evidence: test output + changed-file review + explicit pass/fail

failure: agent loses original intent
control: frozen acceptance criteria
evidence: machine-readable ticket or spec artifact

failure: implementation games visible tests
control: adversarial review or mutation-style validation
evidence: independent finding record

This turns the lifecycle from ceremony into engineering.

Gates Matter More Than Phase Names

Phase names are easy to copy.

A diagram can always add boxes such as Plan, Build, Validate, and Deploy. That does not tell you whether the process actually constrains an autonomous agent.

The stronger question is:

What prevents the agent from moving forward when the required evidence is missing?

One current ADLC implementation makes this concrete by giving gates process exit codes. A passing gate returns one status, an operational error another, and a refusal another. That matters because the lifecycle can be enforced by CI rather than existing only in documentation.

The exact CLI is not the important part.

The important pattern is:

agent produces work
        |
        v
deterministic gate
        |
   +----+----+
   |         |
 pass      refuse
   |         |
continue    repair

A lifecycle becomes much more credible when every critical transition has a machine-readable contract.

This is also why a prompt alone is not enough. Prompts can guide behavior, but a prompt that says “always run the tests” is weaker than a CI rule that refuses the change when tests are absent or failing.

For agentic delivery, prompts describe expectations. Gates enforce them.

Human Involvement Should Move, Not Disappear

A common mistake is to read “agentic development” as “remove humans from development.”

The better ADLC proposals do not require that.

They move human effort toward decisions that are expensive to automate incorrectly.

A person is especially valuable when the system needs to answer questions such as:

• Is this actually the right problem?
• Does the proposed behavior match product intent?
• Is this trade-off acceptable for the business?
• Is this security or compliance risk acceptable?
• Should this autonomous change be allowed to affect production?
• Is the evidence strong enough to trust the agent’s conclusion?

Those are governance questions, not typing questions.

An agent may be excellent at generating five implementation alternatives. It still cannot hold organizational accountability for choosing one.

A practical agentic lifecycle therefore separates two categories:

machine-verifiable decisions
human-accountable decisions

Do not put a human gate around every low-risk action. That destroys the speed advantage.

Do not remove humans from irreversible or context-heavy decisions. That creates a fast system with weak accountability.

The design problem is finding the boundary.

Evidence Is More Important Than Agent Confidence

One of the most useful ideas across agentic workflows is that completion should be evidence-based.

An agent saying:

The implementation is complete.

is not strong evidence.

A stronger completion record contains facts such as:

commit: abc123
tests: passed
lint: passed
build: passed
security scan: passed
changed files: 7
acceptance criteria: 6/6 verified
review findings: 0 blocking
deployment: healthy

That evidence does two things.

First, it makes the agent easier to trust because the conclusion can be inspected.

Second, it makes failures recoverable. Another agent or a human can see where the previous attempt stopped and continue from the actual state instead of reconstructing a conversation.

This is the same reason durable agent handoff and fallback needs explicit state. The important artifact is not the chat transcript. It is the structured record of what was attempted, what passed, what failed, and what still needs a decision.

A good ADLC should leave that kind of trail.

Separate Generation From Verification

Agentic systems make it tempting to let one powerful model do everything.

The same agent interprets the task, writes the code, writes the tests, runs the tests, reviews the diff, and announces success.

That is efficient, but it creates correlated failure.

If the agent misunderstood the requirement, it may write tests that confirm the same misunderstanding. If it invented an API, it may also produce a mock that makes the invented API appear valid. If it optimized for a visible metric, it may rationalize the result during review.

You do not always need a completely different model or vendor, but you do need independence of verification.

That can come from:

• deterministic tests;
• static analysis;
• schema validation;
• policy checks;
• a separate reviewer agent;
• mutation testing;
• sandbox execution;
• production health checks;
• human attestation.

The principle is simple:

generation asks: can I produce a solution?
verification asks: what would prove this solution is wrong?

An ADLC that only accelerates generation is not solving the hardest agentic problem.

Decide Whether the Lifecycle Is Sequential or Concurrent

This is one area where current ADLC approaches visibly differ.

An eight-phase gated chain is easier to reason about as a sequence. Each stage has a clear exit condition, and the next stage does not begin until the current control passes.

A loop-oriented model argues that agentic work is naturally concurrent. Code, tests, documentation, monitoring, and validation can evolve together.

Both views can be useful.

For high-risk changes, explicit sequential gates can make control easier:

intent -> frozen acceptance -> build -> verify -> integrate

For exploratory work, strict sequencing can be wasteful:

generate prototype
validate assumption
update intent
generate again

The mistake is treating the diagram as ideology.

Use sequencing where a dependency must be protected. Use concurrency where parallel work does not weaken the control boundary.

A practical hybrid often works well:

inside a phase:
    agents work concurrently

between trust boundaries:
    explicit gate

That gives you speed without making the whole system one uncontrolled loop.

Check What the Framework Actually Integrates With

A lifecycle is much easier to adopt when it maps onto tools your team already uses.

For a coding-agent workflow, that usually means checking whether the framework can connect to:

• repository state;
• tickets or specs;
• Git branches or worktrees;
• CI;
• tests;
• code review;
• deployment checks;
• observability;
• the coding-agent harness itself.

The agenticlifecycle.ai project currently documents integrations for several coding-agent environments, including Codex, Claude Code, Cursor, OpenCode, Pi, Google Gemini tooling, and GitHub Copilot CLI.

That does not automatically make it the right framework. It simply makes integration an inspectable part of the decision.

Avoid choosing a lifecycle because its conceptual diagram looks good while its actual enforcement depends on manually copying prompts between tools.

The more autonomous the workflow becomes, the more important it is that policy travels through machine-readable interfaces.

Do Not Confuse ADLC With Multi-Agent Architecture

ADLC answers a delivery-process question.

Multi-agent architecture answers a runtime-system question.

You may have:

planner
coder
reviewer
test agent
release agent

without having a meaningful agentic lifecycle. Those agents could still operate with unclear ownership, weak completion criteria, no durable evidence, and no recovery state.

Likewise, an ADLC does not require a swarm of agents. A single coding agent can operate inside a disciplined lifecycle if the gates, artifacts, and human decisions are explicit.

Keep the layers separate:

multi-agent architecture
    = who performs work

ADLC
    = how work is allowed to progress

CI and policy
    = what is mechanically enforced

governance
    = who is accountable for consequential decisions

Blurring those layers is how teams end up adding more agents while making the system less understandable.

A Practical Evaluation Scorecard

Before adopting any ADLC framework, evaluate it against a short set of operational questions.

1. Failure model

Can you name the agent-specific failures the lifecycle is designed to catch?

2. Exit contracts

Does every important phase have a clear definition of done?

3. Machine enforcement

Can critical gates fail automatically in CI, or are they only instructions in a prompt?

4. Evidence

Does the lifecycle create durable, inspectable proof of what passed and failed?

5. Human boundaries

Are human approvals placed around accountable decisions rather than every trivial action?

6. Recovery

If an agent stops halfway through, can another process continue from durable state?

7. Tool independence

Can you change models or agent harnesses without rewriting the whole lifecycle?

8. Feedback

Does production or user signal feed back into future work?

9. Cost visibility

Can you measure the cost of verified changes rather than only model token usage?

10. Simplicity

Does the lifecycle remove ambiguity, or does it create a second bureaucracy beside the existing SDLC?

A framework that scores poorly on these questions is unlikely to improve just because it uses the ADLC label.

Start With One Control, Not a Transformation Program

The safest way to experiment with ADLC is not to rename your entire engineering process.

Pick one recurring agent failure.

For example:

Problem:
Coding agent frequently claims completion before the release build is verified.

Then add one enforceable control:

Change:
No agent-created patch is complete until the release build,
tests, and required static checks produce evidence.

Then persist the result:

{
  "change": "task-142",
  "tests": "pass",
  "release_build": "pass",
  "static_checks": "pass",
  "review": "pending"
}

After that works, add another control.

Maybe acceptance criteria need to be frozen before coding. Maybe review needs an independent agent. Maybe repeated findings should become repository rules.

This incremental path has an important advantage: you can measure whether each control removes a real failure mode.

You are building an operational system, not installing a new vocabulary.

What I Would Borrow From ADLC Today

Even if the term eventually settles into a different standard, several ideas are already useful.

Make intent explicit. Agents need a stable definition of what they are trying to achieve.

Treat validation as a first-class activity. Do not wait until the end of generation.

Use machine-checkable gates where possible. A deterministic refusal is stronger than a reminder.

Keep humans at accountability boundaries. Human involvement should be deliberate, not accidental.

Persist evidence. Every autonomous run should leave enough state for review and recovery.

Feed failures back into the system. Repeated review findings should become tests, lint rules, policies, or reusable skills.

Those ideas are valuable whether you call the result ADLC, agentic SDLC, autonomous delivery, or something else.

The Decision Rule

Do not adopt ADLC because the acronym sounds like the successor to SDLC.

Adopt specific ADLC practices when they solve specific problems created by autonomous execution.

The strongest frameworks will be the ones that can answer four questions clearly:

What can the agent do?
What must it prove before continuing?
Where must a human decide?
What evidence survives after the run?

If those answers are explicit, the exact phase names matter much less.

ADLC is still an emerging family of approaches. That is not a weakness. It means teams have an opportunity to evaluate the mechanisms before the terminology hardens into ceremony.

For now, treat ADLC as a design space.

Compare definitions. Inspect the gates. Demand evidence.