The code that stands still does not reflect your agentic systems.

Over the past five years, more than a thousand agentic systems have found their way into production at organisations across banking, insurance, aviation, health care, and logistics. A familiar pattern has surfaced: systems that performed admirably in the laboratory often falter when exposed to the untidy realities of the real world. The issue is not a deficit of engineering discipline, but rather a software development lifecycle built on an assumption that no longer withstands examination.

Summary

1. The traditional software development lifecycle (SDLC) assumes deterministic behaviour and static systems, but this approach fails for agentic systems that learn, adapt, and operate in dynamic environments.
2. Agentic systems are inherently non-deterministic; their behaviour depends on evolving prompts, models, context, and external services, meaning the same input can lead to different outputs over time.
3. The Agentic Development Lifecycle (ADLC) is proposed as a new framework, emphasising continuous evaluation, monitoring, and adjustment rather than treating deployment as the endpoint.
4. The ADLC reinterprets each SDLC phase for agentic systems, stressing early problem discovery, ongoing testing during development, and persistent monitoring after release to manage uncertainty and system drift.
5. Skipping early discovery or continuous evaluation leads to greater risks and costs later, as agentic systems require active stewardship and cannot be managed using traditional “build, test, deploy, and move on” methods.

The traditional software development lifecycle is founded on the comforting notion that behaviour can be exhaustively specified from the outset, tested along familiar routes, and then set in stone at the moment of release. Deployment is regarded as the end of development and the beginning of a tranquil operational phase. Defects, when they arise, are dutifully reported and addressed in due course. This model has served us admirably for decades, largely because conventional software is deterministic: identical inputs, predictably, produce identical outputs.

Agentic systems, by contrast, overturn this foundational premise. These systems reason, adapt, and operate across a constellation of tools and environments that frequently escape the engineer’s complete control. Logic is no longer neatly contained within code and configuration; it now lurks in prompts, models, context, and a variety of external services. The same input may produce different outputs from one day to the next, not as a sign of malfunction, but as a direct result of the system’s design to learn and evolve. Even minor contextual changes can ripple outward, resulting in outcomes that differ markedly from those previously observed.

To approach an agentic design system as though it were a conventional piece of software—build, test, deploy, and promptly move on—is to court a subtle decay in production, often escaping notice until cost, accuracy, or trust has already been quietly undermined.

The Agentic Development Lifecycle (ADLC) arises as a considered response to this intrinsic non-determinism. Rather than treating uncertainty as a defect to be eliminated, it acknowledges uncertainty as a permanent resident—something to be managed through continual evaluation, observation, and adjustment.

While the ADLC preserves the familiar seven-stage structure of the traditional SDLC, each phase is reinterpreted for systems whose behaviour continues to evolve long after release:

This shift is perhaps most apparent in the way success is measured. Where the traditional SDLC asks, 'Did the test pass?', the ADLC poses more nuanced questions: Is the accuracy distribution within acceptable limits? Is the hallucination rate tolerable? What are the costs associated with these outcomes? Crucially, while the SDLC treats deployment as the end of the journey, the ADLC regards it as the beginning of active stewardship, recognising that model updates, context drift, and changing environments ensure the system’s behaviour remains in motion long after go-live.

This is not merely the SDLC with an AI assistant bolted on. Instead, it is a lifecycle crafted for systems where large language models constitute the very heart of product behaviour, shaping outcomes directly rather than simply accelerating the efforts of their human creators.

The seven phases of the ADLC naturally coalesce into three distinct working stages, each requiring its own particular discipline.

Shaping the proposition (Phases 0–1). Before any agent design or model selection is settled, teams must first develop a thorough understanding of the problem at hand. Phase 0 is dedicated to uncovering pain points and existing knowledge: engaging with users and operators familiar with the current process, reviewing documentation and policies, and forming provisional hypotheses about where an agent might deliver genuine value. Phase 1 then distils this into a manageable scope—mapping the end-to-end business process, establishing both business and technical KPIs (cycle time, accuracy, cost, latency, escalation rates), and defining the human–agent responsibility model: who decides what, what requires approval, and where the agent’s autonomy is to be limited.

Shaping the design (Phases 2–3). At this stage, architecture and business case are developed in concert. Phase 2 covers agent architecture (such as ReAct, Plan-and-Execute, and multi-agent patterns), data architecture and governance, cost structure (both CAPEX and OPEX, including token economics), and technology stack selection. Crucially, the testing strategy is also defined here—success metrics and evaluation methods are agreed upon before a single line of code is written. Phase 3 then puts these plans to the test: a golden dataset is established as a lasting ground-truth asset, a lightweight proof-of-value prototype is built to challenge high-risk assumptions, and the resulting figures for accuracy, hallucination rate, and cost are compared with the original business case. This forms a decisive go/no-go gate; if the numbers do not withstand real data, it is discovered at this point, not after scaling.

Refinement and development (Phases 4–5). In the world of agentic systems, building and testing are inseparable. Phase 4 weaves development and evaluation into a single, continuous loop—change, evaluate, confirm, proceed—repeated as often as necessary during implementation. Evaluation tools become an integral part of the build process itself. Phase 5 then submits the stable, well-understood system to formal validation: end-to-end testing under production-like conditions, user acceptance testing with business stakeholders, bias and fairness assessments, compliance and red-team exercises, and performance testing under both expected and peak loads. The process concludes with a data-backed sign-off against clearly documented risk thresholds.

For teams setting out on this journey, the most valuable discipline to adopt from the outset is simple: resist the urge to skip Phases 0–1 in the haste to showcase AI progress, and do not consign Phase 4’s continuous evaluation loop to the realm of optional refinement. Both are fundamental.

The most common objection, predictably, is time: 'We cannot afford months for discovery and proof-of-value before commencing development.' Yet, the evidence from real-world deployments tells a different story. Skipping the proposition-shaping phase does not save time; it simply moves the cost elsewhere. Agents that automate the wrong tasks or lack a clearly defined human–agent responsibility model tend to introduce compliance, risk, and accountability issues into production, where remedies are both more expensive and more conspicuous.

A second objection frequently surfaces: 'Our QA team already tests everything before release—why introduce a separate continuous evaluation loop during development?' The answer lies in the nature of agentic systems: by the time formal QA is conducted in Phase 5, it is often too late to catch failures that stem from a single prompt or contextual change rippling through a workflow. Batch testing is inadequate for agentic systems precisely because delayed validation allows minor issues to blossom into complex, elusive failures. The tight loop of Phase 4 and the formal sign-off of Phase 5 are not redundant; they address different concerns, at different speeds, for different stakeholders.

A third, often unspoken, concern is the belief that these considerations cease to matter once the system is live and seemingly functional. Phase 7 exists precisely because agentic systems remain in flux after deployment: model providers update their offerings, input distributions shift, and edge cases accumulate, all without a single line of code being changed. Without ongoing monitoring and re-evaluation, quality and safety quietly deteriorate. Teams that treat deployment as the finish line are those most likely to be caught off guard months later.

The unifying thread across all eight phases of the ADLC is a principle that underpins effective, transparent delivery in any context: uncertainty must be made explicit and managed deliberately, rather than left to resolve itself by chance. Clear KPIs and a documented responsibility model at the outset (Phases 0–1), a rigorous validation gate before scaling (Phases 2–3), evaluation woven into the build process (Phases 4–5), and active monitoring after deployment (Phases 6–7) together replace guesswork with a framework that anticipates ongoing change, for such change is, after all, inevitable.

Large language models may be non-deterministic, but the way in which teams build and operate them need not follow suit.

If your software lifecycle still treats deployment as the finish line, your agentic systems are already drifting; you simply have not yet measured it. Discover how a structured lifecycle can bring clarity to this uncertainty at https://designatscale.co