What Is ADLC (Agent Development Lifecycle)?

What Does ADLC Stand For?

ADLC, short for agent development lifecycle, is the process for planning, building, testing, releasing, operating and monitoring AI agents, with what the team learns in production fed back into the next build. Its scope is the agent's behavior across releases, including after changes the team did not make, such as an update to the hosted model the agent calls.

IBM's ADLC explainer, published in May 2026, describes it as "a structured, scalable end-to-end methodology for building and managing enterprise AI agents." The acronym has several meanings in search results, so check which one a source has in mind:

• Agent development lifecycle - building, testing and running AI agents, the meaning in this guide and the name IBM, Salesforce and Glean use.
• Agentic development lifecycle - some writers use it for the same process, while others mean building ordinary software with AI agents doing much of the work, a meaning close to the one covered in agentic SDLC vs STLC.
• Analytics development lifecycle - dbt Labs uses ADLC for the way data teams change, maintain and use analytical systems, a meaning unrelated to AI agents.

Who Has Published an ADLC Framework?

IBM, Salesforce and Glean published ADLC frameworks between October 2025 and May 2026, Salesforce in two versions:

• October 2025, Salesforce - the architecture blog post Exploring the Agentforce Development Lifecycle names five phases: ideation and design, development, testing and validation, deployment and release, and monitoring and tuning.
• April 2026, Salesforce - the paper Applied AI: Why Building AI Agents Requires a New Playbook lists six phases: design, build, test and evaluate, deploy, observe, and control and orchestrate, with governance across all of them.
• May 2026, IBM - six phases that start with plan and end with monitor, the version the next section follows.
• May 2026, Glean - an Enterprise ADLC with seven stages: opportunity, design, performance, context, develop, launch, and monitor and improve.

Earlier, in August 2025, Sam Julien, Director of Developer Relations at WRITER, presented From SDLC to ADLC: The Enterprise Agent Development Lifecycle at TestMu AI's TestMu 2025 conference. The session's abstract says the SDLC "is breaking under the weight of agentic AI systems," which it calls "outcome-driven, adaptive, and non-deterministic."

The published versions agree that release does not end the work. IBM's explainer says that "The ADLC does not end when your AI agents have been fully and successfully deployed." Salesforce's 2026 paper says ADLC "recognizes that deployment is merely day one."

What Are the Phases of ADLC?

IBM's six phases make a workable reference: the first five phases of Salesforce's 2026 paper, from design to observe, cover much the same work. Salesforce's sixth phase, control and orchestrate, is the exception, because the paper says the first five describe the lifecycle of a single agent while the sixth covers many specialized agents that collaborate and hand off tasks.

IBM pairs four of the phases into two loops. Code and build repeats with test and release until the agent meets "whatever minimum performance threshold is necessary to achieve expected business outcomes," and deploy repeats with operate in a loop whose goal, in IBM's words, is optimization.

The middle column summarizes IBM. The right column is this guide's recommendation for what each phase should leave behind, using the routing agent:

Inside test and release, the testing loop has a sequence of its own, set out in the agentic testing life cycle. The security testing and red teaming in that phase can draw on ISO/IEC 27090:2026, ISO and IEC guidance from October 2026 that addresses data poisoning, model inversion, prompt injection and other threats aimed at AI systems, along with their consequences throughout the AI system life cycle. For the operate and monitor phases, AI agent monitoring covers the signals to watch. The ongoing audits in IBM's monitor phase are one kind of AI audit, which checks evidence against criteria fixed before the review begins.

ADLC vs SDLC: What Changes When the Product Is an Agent?

Salesforce's paper notes that ADLC "starts with phases that are also present in SDLC (design, build, test, and deploy)." What changes is what those phases have to handle, because, as IBM puts it, "providing the same input twice might yield two different outputs."

A model update from the provider, a tool definition changed by its vendor and new data in the sources the agent reads can all reach the agent with no commit in its repository. IBM describes traditional software as having "behavior that changes only if the code governing that behavior is actively changed." Salesforce describes drift as performance that degrades "even when no one has changed the agent's instructions, its actions, or its code," and lists a foundation model update from the provider among the causes.

In the June 2025 revision of the MCP tools specification, each tool's inputSchema defines the parameters it expects, and a server that declares the listChanged capability "SHOULD send a notification" when its list of tools changes. The specification ties that notification to the list of tools and does not say that a changed parameter on an existing tool triggers one, so the renamed parameter from the opening example can arrive with no notification and no commit on the agent's side. An agent that still holds the tool definition it loaded before the rename, or whose prompt names the old parameter, keeps sending priority.

A new version of the agent harness, which carries out the model's tool calls, is a retest trigger as well, even with the model and prompt unchanged. For model, prompt, tool, data and permission changes, AI agent validation explains why an earlier sign-off stops covering the agent and how much to rerun.

Which Gates Should an ADLC Have, and When Does Each Pass?

Salesforce calls ADLC "a gated process, and only high-quality agents get through." The gates in this guide are a proposal: each sits between two of IBM's phases, or between rollout stages inside deploy, and passes on a condition someone can check. AI TRiSM, Gartner's framework for AI trust, risk and security management, also calls for continuous validation across the AI life cycle.

How Do You Adopt ADLC Without Reorganizing Your Team?

A team can add the gates one at a time to the agents and pipelines it already runs:

• Choose an agent that writes - begin with an agent whose mistakes land in another system, as the routing agent's do in tickets; an agent that only drafts text for a person to send can wait.
• Pass its spec gate - write and assign its acceptance criteria before its next change.
• Add the release gate to your current pipeline - the CI pipeline that already runs your other test suites can run the agent's suite as one more step.
• Add the change gate - decide who is told when the model, a tool or a data source changes, and rerun the release suite on each such change, or on a schedule when no notice comes.
• Turn incidents into scenarios - each production incident becomes a scenario in the release suite, so the next release is tested against it.
• Add the promotion gate with staged rollout - once releases go out in stages, set a limit for each stage.

Each agent also needs one named owner, and IBM recommends a catalog of agents and tools that records "Ownership to facilitate accountability and issue escalation." Salesforce's paper adds that ADLC success "depends less on traditional job titles and more on the mastery of specific jobs to be done (JTBD)."

The description of the TestMu 2025 session names four new enterprise roles: agent owner, builder, champion and supervisor. Of the four, the gates need only an agent owner, and the rest of their work can go to people already on the team:

• Spec gate - the agent's owner approves the criteria.
• Release and change gates - whoever owns the CI pipeline runs the suite, and the agent's owner reviews every unverifiable result.
• Promotion gate - the team that runs production rollouts sets the limit for each stage.

Running the ADLC Release Gate With Agent Assurance

Agent Assurance, which TestMu AI makes for testing agents that take actions, is a pre-release test step inside the test-and-release phase for an agent such as the routing agent. Its terminal client is Rook CLI (you type rook), which reads the routing agent's code, or failing that its written spec, and writes scenarios for ordinary tickets and adversarial ones, each with its own acceptance criteria. A profile then hands each scenario to the agent itself, by calling an HTTP endpoint, running a command or using an MCP tool, and each criterion's verdict rests on evidence the run left behind:

• Queue and priority - a criterion about a ticket field can be checked against the MCP tool calls the profile's hooks pass back, or against the ticket itself, read back by a read-only tool your team supplies and approves. For the renamed parameter, the call's arguments still show priority set to urgent, so the criterion has to be checked against the priority stored on the ticket.
• Forbidden calls - a scenario can require that the agent never calls the tool that closes tickets, and any hook-reported call to that tool fails the criterion.
• The agent's notes - a note saying a ticket was escalated is never taken as evidence that it was. Where a criterion concerns a note's wording, the grade rests on quotes from the agent's actual output, and some of those criteria go to a model judge.
• Unable to Verify - when neither the hooks nor an approved read-only tool show a ticket's final priority, that criterion ends Unable to Verify, which the pass rate leaves out and the report counts apart from Pass and Fail.

Most eval and observability tools rate an agent by what it said and what its traces recorded. Agent Assurance rates it by what the run changed, such as the priority on a ticket, and lists every criterion left without evidence.

On two runs of the same ticket the agent may call its tools in a different order, and Agent Assurance does not pin that order. It fixes the check instead: a CI gate runs a reviewed set of scenarios, selected by ID, against one profile, so each candidate version is graded on the same written criteria, and every run keeps the scenario definitions it used. Generating new scenarios calls a model, so generation stays outside the gate.

A CI gate needs the verdicts, and the exit code does not carry them. A completed rook run returns exit code 0 regardless of how many scenarios failed, and exit 1 means the command could not do what it says: the user is signed out, the run is refused, something it needs is unreachable, a flag is wrong or the run never starts. The Rook CLI README warns that "an exit code of 0 alone does not mean scenarios passed."

A declined or interrupted run can exit 0 as well, so the gate first confirms that the run completed and covered the selected scenarios, then reads the verdict totals from rook report --json. Those totals count scenarios in fields such as passed, failed, unverifiable and not_run, and each scenario's saved verdicts stay behind as the evidence for the decision.

The output below was captured with Rook CLI 0.1.14 on October 29, 2026, on a Windows 11 machine. It is trimmed to the lines a gate uses, with ... marking cuts in the help text, and leaves out the update notice printed before the version number. No test run was made for this guide, so it shows no verdicts.

$ rook --version
0.1.14
$ rook report --help
Usage: rook report [options] [runId]
...
Arguments:
  runId           which run. The most recent one otherwise

Options:
  ...
  --json          machine-readable output
  ...

Without a run ID, rook report reads the most recent run, so pass the current run's ID. Run Agent Assurance in CI/CD also has the gate check the current run's identity, and that docs page has a gate script and links recipes for GitHub Actions, Jenkins and Argo CD.

Run the suite against a staging ticketing system and CRM seeded with synthetic customers: every queue and priority the agent sets during a test is a real write that stays on the ticket, and Rook CLI cannot reverse any of it. Rook CLI is a pre-release tool that neither watches the tickets the deployed agent handles nor blocks anything that agent does at runtime. The promotion gate's limits therefore come from your own production measures, and the change gate depends on someone hearing about each change or on a scheduled rerun.

Agent Assurance is generally available, with self-serve plans and a free trial of 14 days that comes with 4,000 credits; the paid tiers are listed on the pricing page under Agent Assurance plans. Without a plan or an active trial on your TestMu AI account, Rook CLI stops before calling a model or using credits.

On the npm route, the first command below installs Rook CLI and the second sets up its skill in Claude Code:

npm install -g @testmuai/rook@latest
npx @testmuai/rook-skill@latest install \
  --agent claude-code

Rook CLI is available for macOS and Linux, and 64-bit Windows through npm or WSL. The npm route works with Node.js 20 or newer, the skill installer needs Node.js 22 or newer, and Homebrew and the shell installer, which cover macOS and Linux only, need no Node. Their commands are in the Rook CLI installation guide.

If the routing agent also answers customers, those conversations are tested with Agent Testing, a different TestMu AI product, which covers chat, voice, phone, video and image agents.

TestMu AI, the company behind KaneAI, has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Agentic Software Quality Assurance Platforms.

Set Up the ADLC Change Gate: List What Changes Without a Commit

Before your agent's next release, write down everything it depends on that can change without a commit in its repository: the model version its provider serves, each MCP server and tool definition it calls, and each data source it reads. Every item on that list is a change-gate trigger, and each one needs a named person who hears when it changes.

Rook CLI's exploration reads an agent's code, prompts, tool registries and MCP server declarations and records what it finds, which gives that list a starting point. Exploring spends credits, and the docs page Connect and Explore AI Agents shows how to run it.

Gartner, Magic Quadrant for Agentic Software Quality Assurance Platforms, By Ross Power, Sushant Singhal, C.A. Swan, 12 October 2026.

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner's business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.