Agentic Development Lifecycle: 7 Essential Stages (2026)

The short answer

The agentic development lifecycle (ADLC) is the method for planning, building, evaluating, releasing and operating AI agents whose behavior is probabilistic and changes after release. It adds what SDLC lacks: evals written before code, staged releases with a kill switch, and continuous monitoring that feeds fixes back into the next cycle.

Key takeaways

SDLC assumes behavior is fixed at build time. Agents keep changing after release.
ADLC means two things: building agents (IBM, Salesforce, EPAM) and agents building your software (AWS AI-DLC).
The 7 stages: Frame, Ground, Design, Prove, Build, Release, Operate, each with an exit test.
Write the evals before the code. The test set is the real specification.
Run one agent through all 7 stages in 90 days, then reuse the template.

In August 2025, Gartner forecast that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% a year earlier. That is this year. Most of those agents will be planned, tested and released with a lifecycle built for software that does exactly what it is told, every time.

Agents don’t. They reason, call tools and change behavior when a model, a prompt or a document changes. That gap is why the agentic development lifecycle (ADLC) went from a consultant slide to a term IBM, Salesforce and AWS now publish guides about. This guide explains it in plain English, shows the seven stages that matter, and gives you a 90-day plan to run your next agent through it.

Stat: Gartner forecasts 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from under 5% in 2025 — Source: Gartner forecast, August 26, 2025.

What is the agentic development lifecycle (ADLC)?

The agentic development lifecycle (ADLC) is the end-to-end method for planning, building, evaluating, releasing and running AI agents, where behavior is probabilistic and keeps changing after release. It adds three things classic SDLC lacks: an evaluation plan written before code, staged releases with a kill switch, and continuous monitoring that feeds fixes back into the next cycle.

IBM published its version in May 2026 as a structured methodology for building and managing enterprise AI agents, with stages from plan to monitor. Salesforce documents an agent development lifecycle for Agentforce with an inner build loop and an outer tuning loop. EPAM goes further, with eight phases starting at a “Phase 0” whose job is to slow teams down before they build the wrong agent.

The names differ. The idea is the same: an agent is never finished. It is operated.

Why does SDLC break when software starts reasoning?

SDLC breaks because it assumes behavior is fixed at build time and proven before release. Agents are probabilistic: the same input can produce different outputs, logic lives in prompts, models, tools and data as well as code, and failures show up as wrong answers that look right rather than errors that crash.

Four assumptions stop holding at once:

Behavior is fixed. In an agent it is not. A model provider ships an update, your knowledge base gets a new policy, and Tuesday’s answer differs from Monday’s.
Logic lives in code. Now it also lives in the system prompt, the tool descriptions, the retrieval index and the model version. Each one needs version control.
Tests pass or fail. Agent quality is a distribution. You measure how often the agent is right, how often it hallucinates and what each correct outcome costs.
Release means done. For an agent, release is the start of the riskiest phase: real users, real data and inputs nobody tested.

Agentic development lifecycle compared with SDLC: in SDLC behavior is fixed at build, logic lives in code, tests pass or fail and release means done; in ADLC behavior shifts after release, logic also lives in prompts, models, tools and data, quality is a rate and release starts monitoring — SDLC was built for software that never changes its mind

IBM puts the failure mode bluntly: agentic systems “typically fail through hallucinations or problems with alignment.” Those failures don’t throw errors. They show up in a customer’s inbox or a finance report.

Two things people mean by ADLC

Search for ADLC and you will find two different ideas sharing one acronym. Knowing which one you need saves a month of confused meetings.

1. The agent is your product. You are building a support agent, a finance agent or an internal assistant. ADLC here is the agent development lifecycle: how you plan, evaluate, release and operate it. This is the IBM, Salesforce and EPAM meaning, and it is the main subject of this guide.

2. Agents build your software. Coding agents plan features, write code, pick dependencies and open pull requests while engineers set intent and review. AWS introduced its AI-Driven Development Life Cycle (AI-DLC) on July 31, 2025, with three phases (Inception, Construction, Operations), work cycles called “bolts” measured in hours or days, and team sessions called mob elaboration where people validate what the AI proposes. Security vendor Cycode calls the same shift the agentic development lifecycle and maps six stages, from guardrails to monitoring.

Decision guide for the two meanings of ADLC: if the agent is your product, use the agent development lifecycle described by IBM, Salesforce and EPAM; if agents build your software, use an AI-driven development lifecycle such as AWS AI-DLC — Which ADLC do you mean?

The two meanings share one lesson. In both, people move from doing the work to defining intent and judging results. The evaluation becomes the real specification.

The 7 stages of the agentic development lifecycle

Here is the version I use, distilled from the IBM, Salesforce and EPAM models and from building agents myself. Each stage ends with an exit test. If you can’t pass it, you don’t move on.

1. Frame: decide if this is a job for an agent

Write the outcome, the owner and the autonomy level before anything else. Many tasks need a workflow or a single prompt, not an agent. IBM’s guide says the first decision is whether you need an agent at all. Exit test: one sentence that says what the agent may do alone, what needs approval, and how you will know it worked.

2. Ground: get data, tools and permissions ready

Agents are only as good as the context they can reach. List the systems it reads and writes, connect tools through a standard such as the Model Context Protocol, and give it the narrowest permissions that work. Exit test: every tool call runs as a named identity with logged, least-privilege access.

3. Design: pick the architecture and write the evals first

Choose a pattern (a single agent with tools, plan-and-execute, or several agents), the model and the guardrails. Then write the evaluation plan before code: what good looks like, which failures are unacceptable, and the cost ceiling per task. Exit test: a written eval plan the business owner signed.

4. Prove: build a golden dataset and test the risky assumption

Collect 50 to 200 real examples with known right answers, edge cases included. Build the thinnest prototype that tests the riskiest assumption and record baselines for accuracy, hallucination rate, latency and cost. Exit test: a go or no-go decision against those baselines, made by the owner.

5. Build and evaluate: every change runs the evals

Treat prompts, tools and model versions like code. Every change runs the golden set, adversarial cases and an LLM-as-judge pass, with human review on a sample. A prompt tweak that lifts one score and breaks another gets caught here, not by a customer. Exit test: scores at or above baseline, and no new critical failures.

6. Release in rings: canary first, kill switch ready

Release to a small group, in suggest-only mode where you can, then widen. Keep versioned rollback and a kill switch someone is allowed to pull. Exit test: production metrics match evaluation metrics for two weeks before the next ring.

7. Operate and govern: run it like a living system

Trace every run. Watch accuracy, cost per outcome, escalation rate and drift. Rerun the evals whenever the model provider ships an update. Keep the agent in a catalog with an owner, a version and a risk rating. Findings flow back to stage 1, and the loop starts again. Exit test: a weekly review where someone owns every red number.

What do teams actually measure once agents are live?

Most teams watch their agents but few grade them continuously. LangChain’s State of Agent Engineering survey of 1,340 practitioners found 57% have agents in production, and quality is the top blocker for 32%. Nearly 89% have some observability, yet only 37% run online evaluations on live traffic.

Bar chart from LangChain's State of Agent Engineering survey of 1,340 practitioners: 89% have observability, 62% detailed tracing, 60% human review, 53% LLM-as-judge, 52% offline evaluations and 37% online evaluations — Source: LangChain, State of Agent Engineering, 1,340 respondents.

That gap is the whole point of ADLC. Watching tells you something happened. Evaluating tells you whether it was right. Here is how the main methods compare:

Method	What it catches	When to run it
Golden dataset (offline evals)	Regressions on known cases	Every change to prompt, tool or model
LLM-as-judge	Tone, relevance, policy at scale	Every build, checked against human scores
Human review	Subtle errors, business context	A weekly sample, plus every escalation
Red teaming	Prompt injection, data leaks, misuse	Before each release ring
Online evals	Drift and real-world failure	Continuously, on live traffic

A mission control room with flight controllers watching a large tracking screen, a picture of how agents are run after release — In ADLC, the work after release looks more like mission control than a handover. · Photo: NASA, Public domain, via Wikimedia Commons

From the bench: when I build AI agents, the first file I write isn’t the prompt. It’s the test set. Agents that do real work without inventing facts come from a long list of questions with known answers, run after every change. The analytics tool I built shows the query behind every number for the same reason: if you can’t trace an answer, you can’t trust it.

How is ADLC different when agents write your code?

When coding agents build your software, ADLC shifts risk from slow delivery to fast, unreviewed change. The lifecycle still runs plan, build, test, release and monitor, but humans own intent and approval, and automated checks run at the moment code is generated rather than days later.

The risks are specific. Researchers presenting at USENIX Security 2025 tested 576,000 code samples and found hallucinated package names in at least 5.2% of cases for commercial models and 21.7% for open-source models. Attackers can register those names. Agents also inherit broad credentials, and prompt injection can arrive inside a ticket, a README or a tool description.

Three guardrails cover most of it:

Scan at generation. Check dependencies, secrets and vulnerable patterns before a pull request exists.
Give agents their own identity. Scoped tokens per repository and per task, never a developer’s full access.
Keep humans on the decisions that matter. Architecture, access changes and business logic get a named reviewer. Routine checks get automated gates.

A 90-day plan to adopt the agentic development lifecycle

You don’t need a new department. You need one agent run through all seven stages, then a repeatable template.

Three-step 90-day plan to adopt the agentic development lifecycle: frame and ground one use case, prove and build with evals on, release in rings and operate — Run one agent through ADLC in 90 days

Days 1–30: Frame and ground one use case. Pick a high-volume, rule-heavy task with a clear owner. Write the outcome, the autonomy level and the permissions. Build the golden dataset with the people who do the work today.
Days 31–60: Prove and build with evals on. Prototype, record baselines, decide go or no-go. Wire evals into every change and run one red-team session.
Days 61–90: Release in rings and operate. Suggest-only first, then a small group acting with approval. Start the weekly review with real numbers. Write down what you would change in the template for agent number two.

If agents also write your code, run the same 90 days on one repository with the three guardrails switched on from day one. For model choice inside stage 3, my guide on when a small language model beats a frontier model covers the cost side, and the review of AI agents in ERP shows what is in production versus still a demo.

Who owns each stage of ADLC?

ADLC fails most often on ownership, not technology. An agent touches a business process, a data set, a security boundary and a budget, so one team can’t own it alone. This split works in most enterprises:

Business owner (a VP or process lead): owns the outcome, signs the eval plan in stage 3, makes the go or no-go call in stage 4 and chairs the weekly review.
Agent product lead: owns scope, the autonomy level and the golden dataset. This is a product role: write the acceptance criteria as evals.
Engineering: owns architecture, tools, versioning, rings and rollback.
Data team: owns the sources the agent reads and how fresh, complete and permitted they are.
Security and risk: own identities, permissions, red teaming and the catalog entry with its risk rating.
The people who do the work today: write the hard examples and review a weekly sample. Leave them out and your test set will be too easy.

What does ADLC add to the budget?

ADLC moves cost from rework to prevention. Budget for four lines that a normal software project doesn’t have: building and refreshing the golden dataset (mostly expert time), evaluation and tracing tools, human review hours every week, and the model spend of running evals on every change. In return you buy the ability to say, with numbers, whether the agent is right and what each correct outcome costs. That is the sentence a CFO needs before funding agent number two.

The mistakes that stall agent programs

Building before the eval plan exists. Without a definition of good, every demo looks good.
Admin credentials “for the pilot”. Pilots become production faster than permissions get fixed.
Treating a model update as a no-op. It is a release. Rerun the evals.
Nobody owns the decision. IT owns the agent, the business owns the outcome, and the review meeting has no chair.
Measuring activity, not outcomes. Messages handled is not value. Cost per correct outcome is.

Gartner has warned that over 40% of agentic AI projects will be canceled by the end of 2027 because of cost, unclear value or weak risk controls. Every one of those causes maps to a skipped stage above.

The bottom line

The agentic development lifecycle is not a new tool to buy. It is a habit: define good before you build, prove it on real examples, release in rings, and keep grading the agent for as long as it runs. SDLC asked “does it work?” ADLC asks “is it still right, and what did it cost?”

My read: the teams that win with agents in 2027 won’t have the smartest model. They’ll have the best test set and someone who reads the weekly numbers. For more like this every week, join the Leading Indicator newsletter or see more guides on the site.

Frequently asked questions

What is the difference between SDLC and ADLC?

SDLC assumes software behaves the same way every time, so it validates fixed code paths and treats release as done. ADLC assumes behavior is probabilistic and shifts with models, prompts and data. It measures quality as rates and costs, releases in stages with rollback, and keeps evaluating the agent in production for as long as it runs.

Is ADLC the same as AWS AI-DLC?

Not quite. AWS's AI-Driven Development Life Cycle is about AI agents building software, with humans validating plans in mob elaboration sessions and work done in short bolts. The agent development lifecycle described by IBM and Salesforce is about building and operating AI agents as products. Both put evaluation and human approval at the center.

How long does it take to adopt ADLC?

About 90 days for a first agent: 30 days to frame the use case, ground data and permissions and build a golden dataset; 30 to prototype, set baselines and wire evals into every change; 30 to release in rings and start a weekly review. After that, the template makes each new agent faster.

What should an AI agent evaluation include?

A golden dataset of real cases with known answers, adversarial and edge cases, an LLM-as-judge pass checked against human scores, a weekly human review sample, red teaming for prompt injection and data leaks before each release, and online evaluation on live traffic to catch drift. Track accuracy, hallucination rate, latency and cost per correct outcome.

Who should own the agentic development lifecycle?

Ownership is shared. A business owner owns the outcome and the go or no-go call, an agent product lead owns scope and the test set, engineering owns architecture and releases, the data team owns sources, and security owns identities, permissions and red teaming. The people who do the work today supply the hard examples.

Sources

#ADLC#Agentic AI#AI agents#AI evaluation#AI governance#Software development

Written by

Gokul Dhamodaran

I turn what is happening at the AI frontier into what it means for enterprise systems, and I build AI products myself (Euliv Analytics, Vantage). I write Leading Indicator every Friday: the AI and enterprise tech moves that matter, and what they mean for you.

Views are my own and do not represent any employer or client. Graphics are original; sources are linked.

See my work →Follow on LinkedIn ↗