SDLC vs ADLC: What Changes When You Ship an Agent

Two conversations about AI often happen in the same engineering leadership meeting. One is about assistants in the IDE: code is written faster, reviews are quicker, tests appear sooner. The other is about putting an agent into the product: a support assistant that resolves tickets, or an internal tool that reads a request and updates the CRM. Both get called "AI adoption", but they sit on different lifecycles. The SDLC vs ADLC split is a practical way to keep them apart, so that each one gets the right budget, the right controls, and the right definition of done.

This article is for CTOs and heads of engineering who already use AI in delivery and are now scoping their first agent in production.

What we mean by SDLC and ADLC

The software development lifecycle (SDLC) is the familiar loop: plan, design, build, test, release, operate. It relies on one assumption. Behaviour is written in code, so the same version given the same input returns the same result. That is what makes a unit test, a code review, and a rollback meaningful.

ADLC has no single industry definition yet. Vendors expand it as "AI development lifecycle" or "agentic development lifecycle" and draw the phases differently. In this article it means the agent development lifecycle: the work needed to keep an agent's behaviour acceptable from the first prototype through every change after release.

The simplest test is to ask who makes the decision at runtime. If the code decides and a model only drafts text, you are on the SDLC. If a model chooses what to do next (which tool to call, which record to change, what to tell a customer), you also need an ADLC.

AI in the SDLC: faster delivery, same lifecycle

Coding assistants change the speed of the SDLC, not its shape. Planning notes are drafted faster, boilerplate appears in seconds, and test scaffolding is cheaper to write. The product that ships is still deterministic code that a person reviewed and merged.

That is why the controls stay the same. Architecture, code review, CI, and release ownership remain with the team. We describe how this works in practice in AI-driven development, and the quality gates we keep in place in code quality as part of the SDLC.

Calling this stage "ADLC" causes a real planning error. The team believes it already has an agent lifecycle, and the first product agent is then scoped like an ordinary feature: an API integration, a few unit tests, and a demo.

What changes when an agent enters the product

An agent is code plus three things that code alone does not fix: a mandate (what it is trying to achieve and where it must stop), a context it reads at runtime, and a set of tools it can call. The code around the model can be fully tested. The choices the model makes cannot be tested in the same way.

Four differences matter in delivery:

• Same input, different output. Two identical requests can lead to different answers or a different sequence of tool calls. Quality becomes a rate across many cases, not a pass or fail on one.
• Plausible failures. A broken function usually throws an error. A misbehaving agent produces a confident, well-formatted wrong action, such as the wrong account updated or a policy that does not exist.
• Change without a deploy. Behaviour can shift when the provider updates a model, when a knowledge base is edited, or when a connected system changes its data. Your repository may not change at all.
• Cost per decision. Every step consumes tokens and calls. A loop that a person would stop after two attempts can run until a limit is hit.

None of this replaces the SDLC. It adds a second loop that watches behaviour rather than code.

The agent development lifecycle, step by step

A workable ADLC for custom AI agents fits into six steps. The names matter less than the fact that each one has an owner and an output.

1. Define the mandate. Write down what the agent may decide on its own, what it must refuse, and which actions need a person to approve. This becomes the reference for every later check.
2. Curate the context. List the documents, records, and schemas the agent is allowed to read. Name an owner for each source who is responsible for freshness and access rights.
3. Scope the tools. Give each action the smallest permission it needs. A tool that reads an order should not be able to refund it.
4. Build an evaluation set. Collect real requests (from tickets, emails, or logs, not from the demo script) and state what a good answer looks like. Agree on a threshold, for example the share of cases that must be handled correctly before release.
5. Release behind controls. Ship through the normal product pipeline, behind a feature flag or for a limited group of users where the impact of mistakes is high. Add limits on steps, spend, and the tools available in the first release.
6. Observe and re-evaluate. Log what the agent read, what it decided, and what it did, next to the business record. Re-run the evaluation set whenever the prompt, the model, the tools, or the main content sources change.

Step 6 is the one teams most often leave out. With ordinary software, the release is the end of the build. With an agent, the release is when the real input starts arriving.

SDLC vs ADLC side by side

	SDLC	ADLC
What changes between releases	Code	Code, prompt, model, context, and tools
How quality is measured	Tests pass for a given version	Share of evaluation cases handled acceptably
What triggers a new check	A code change	A code change, a model update, or a content change
How failures look	Errors, crashes, failed tests	Plausible but wrong answers or actions
Definition of done	Tested, reviewed, deployed	Above the agreed threshold, and still above it after changes
After go-live	Incidents, patches, next scope	The same, plus drift, cost, and reviews of agent decisions

Both columns describe one product. Read the table as two kinds of acceptance on the same backlog, not as two teams.

One product, two loops

In a typical LLM integration, most of the work is still the SDLC: identity and permissions, the service that calls the model, storage, audit logs, and the user interface. The ADLC covers the decisions the model makes inside that system.

A practical split looks like this.

Stays on the SDLC

• service boundaries, authentication, and permissions
• the logging path that stores agent actions next to the business record
• rollback of the build, independent of the model version that was called

Belongs to the ADLC

• the mandate and the list of actions that need human approval
• the evaluation set and its threshold
• owners for each context source
• limits on tools, steps, and spend
• a re-evaluation whenever the provider changes the model

Keep one backlog and split the acceptance criteria. A story is done when the code passes review and tests, and, if it touches agent behaviour, when the evaluation still passes. Our anonymised property data platform case shows the same pattern: grounded search, scoring, and agents on top of ordinary data engineering.

How to tell which lifecycle you need

Answer four questions about the system you are about to build:

1. Does a model choose the next step, or does the code follow a fixed sequence?
2. Can the system write to a system of record (CRM, ERP, billing) without a person confirming?
3. Does it talk to customers or employees without a person reviewing each reply?
4. Would a wrong action cost money, data, or trust before anyone notices?

If every answer is no, the SDLC with good quality gates is enough. A model that drafts text for a person to send, or a search box that returns cited passages from a fixed set of documents, belongs here. It still needs data ownership and a quality check, but not the full agent loop.

If any answer is yes, plan the ADLC from the start. Our AI adoption checklist draws the same line: a live AI feature with weak monitoring is an early stage, while evaluation, cost control, and a fallback mark a mature one. That mature level is, in practice, the core of an agent development lifecycle.

Common mistakes

• Renaming the SDLC. Using coding assistants does not mean the team can run an agent in production.
• Testing only the wrapper. Unit tests on the API client pass while the agent takes the wrong action.
• An evaluation set written from the demo. Happy-path examples hide the cases that fail in real traffic.
• Nobody owns the context. An outdated policy document turns into a confident wrong answer.
• No check after a model update. Behaviour changes, the code does not, and nobody re-runs the evaluation.

FAQ

Does ADLC replace the SDLC?
No. The agent runs inside a product that is still built, tested, and released on the SDLC. ADLC adds checks for the part whose behaviour is decided by a model.

Is using GitHub Copilot or another coding assistant part of ADLC?
No. That is AI in the SDLC. The output is reviewed code, and the usual quality gates apply.

Do we need ADLC for a simple chatbot?
It depends on what the chatbot can do. If it only answers from a fixed set of documents and a person handles anything beyond that, a lighter process is enough. Once it can take actions or speak for the company without review, treat it as an agent.

How large should an evaluation set be?
Large enough to cover the main request types and the known failure cases. Start with real examples from your own tickets or requests, and add every production failure to the set.

Who owns the ADLC in the team?
Usually the same product team that owns the feature, with a named person for the evaluation set and for each context source. It does not need a separate department.

Key takeaways

• AI in the SDLC makes delivery faster but does not change the lifecycle. Review, tests, and release ownership stay as they are.
• The agent development lifecycle starts when a model decides what the product does next.
• An agent ships with a mandate, curated context, scoped tools, an evaluation set, and monitoring, not only the code that calls the model.
• Behaviour can change without a deploy, so re-evaluation is triggered by model and content changes as well as code changes.
• Both lifecycles run on one product and one backlog, with separate acceptance criteria.

If you are planning an agent that will act in your product, tell us what it should be allowed to do. We can scope the product and the behaviour loop as AI development, or a narrower AI workflow automation where a person still approves each action.