AI Production Systems
The AI Software Development Lifecycle
Requirements, development, testing. That lifecycle built the software industry, but it breaks down when the system you are shipping is probabilistic. Here is the eight-stage lifecycle we use to build AI systems that survive production.
Curated by Matt Perry
CTO
What Is the AI Software Development Lifecycle?
The AI software development lifecycle (AI SDLC) is the process teams use to take an AI system from a business problem to a system that keeps improving in production. It has eight stages: problem, agent design, context design, knowledge, evals, production, monitoring and improvement.
Traditional software follows a familiar loop. You gather requirements, you develop, you test, you release. That works because traditional software is deterministic. Given the same input, it produces the same output every time. Once a feature passes its tests, it stays passed.
AI systems do not behave like that. They are probabilistic, which means the same input can produce different outputs. Quality depends on context, data and model behaviour, and all three shift over time. A system that worked perfectly in the demo can quietly degrade in week three without a single error appearing in the logs.
So the lifecycle has to change. This article sets out the one we use at Original Objective when we build AI systems for clients.
The Old Lifecycle and the New One
The traditional software development lifecycle looks like this:
The AI software development lifecycle looks like this:
Two things stand out. First, "development" barely appears. Writing code is now the fastest part of the job. The hard work has moved into design, data and measurement. Second, the lifecycle does not end. Improvement feeds back into design, and the loop keeps running for as long as the system does.
Here is what each stage involves and what goes wrong when you skip it.
Stage 1: Problem
Every AI project should start with a problem statement that does not mention AI. For example: "Our team spends 30 hours a week answering the same 50 questions." Or: "Quotes take four days to produce and we lose deals in the gap."
A good problem statement includes a number you can move. If you cannot say what changes when the system works, stop and rework the statement. This is also the stage where honest teams discover that some problems need a process fix or a spreadsheet, not a model.
Skip it and: you build an impressive demo that solves nothing anyone measured.
Stage 2: Agent Design
Agent design means deciding what the AI system is responsible for, which tools it can use, and where humans stay in control. An agent is an AI system that can take actions, such as looking up an order, drafting a reply or updating a record, rather than only answering questions.
The key decisions are scope and autonomy. What actions can it take on its own? Which ones need human approval? When must it hand over to a person? These boundaries shape everything that follows, including cost, risk and how much your team trusts the system.
Skip it and: you get either a toy that helps nobody or an unsupervised system taking actions nobody signed off.
Stage 3: Context Design
Context design, often called context engineering, is controlling exactly what information the model sees at each step: its instructions, examples of good output, retrieved documents and the results of tool calls.
This is where most of the engineering effort in a modern AI system goes. Models rarely fail at random. They fail because the right information was not in front of them at the right moment, or because too much irrelevant information was. Designing context well is the difference between an assistant that sounds like your business and one that guesses.
Skip it and: output quality becomes a lottery, and every fix is a prompt tweak made in the dark.
Stage 4: Knowledge
Knowledge is the stage where you prepare the data the system relies on: documents, product data, policies, pricing and the APIs it can query.
Three questions matter here. Is it accurate? Is it current? Who is allowed to see it? Most real-world failures we get called in to fix trace back to this stage. The model was fine. The knowledge it was given was stale, contradictory or missing the case the customer asked about.
Skip it and: the system answers confidently from last year's price list.
Stage 5: Evals
Evals are automated tests that score an AI system's outputs against examples of what good looks like. They are the AI equivalent of a test suite, with one difference: instead of asserting an exact answer, they grade behaviour across a set of real inputs.
A useful eval set starts small. Fifty real questions with agreed good answers will do. Score each release on correctness, tone and safety. Without evals, every prompt change is a gamble. With them, you can swap models, rewrite prompts or restructure context and know within minutes whether the system got better or worse.
Skip it and: "it seems fine" becomes your quality bar, and regressions ship silently.
Stage 6: Production
Production means shipping with the guardrails a probabilistic system needs: fallbacks for when the model fails or times out, limits on cost and rate, safe default responses, and a clear route to a human.
This is also where the unglamorous engineering lives. Authentication, logging, data retention, cost caps per conversation. It is the difference between a prototype and a system your business can stand behind.
Skip it and: your first bad week in production becomes a public one.
Stage 7: Monitoring
Monitoring an AI system means watching behaviour, not just uptime. A wrong but confident answer throws no exception, so error logs will tell you everything is healthy while customers are being misled.
Track the numbers that reflect behaviour: resolution rate, escalation rate, cost per task, and drift in the kinds of questions coming in. Review a sample of real conversations every week. Ten minutes of reading transcripts catches problems no dashboard will.
Skip it and: you find out about degradation from a customer complaint, weeks late.
Stage 8: Improvement
Improvement closes the loop. Real conversations become new eval cases. Failures become context fixes. Gaps in answers become knowledge updates. Each cycle makes the next one measurably better, because stage 5 gave you the measuring stick.
This is why the AI SDLC is a cycle rather than a line. Traditional software is finished when it ships. An AI system is never finished. It is either improving or drifting.
Traditional SDLC vs AI SDLC
| Traditional SDLC | AI SDLC | Why it changed |
|---|---|---|
| Requirements | Problem | Requirements describe features. AI projects need a measurable outcome first. |
| Development | Agent design, context design, knowledge | Writing code is quick now. Designing behaviour and data is the real work. |
| Testing | Evals | You cannot assert exact outputs, so you score behaviour against examples instead. |
| Release | Production | Probabilistic systems need guardrails, fallbacks and cost controls, not just a deploy. |
| Maintenance | Monitoring and improvement | AI systems drift. Watching behaviour and feeding it back is continuous, not occasional. |
| Ends at ship | Never ends | The loop from improvement back to design runs for the life of the system. |
When You Do Not Need the Full Lifecycle
Not every use of AI needs eight stages. Be honest about which category you are in:
- Personal productivity. A team member using ChatGPT or Claude to draft emails needs guidance, not a lifecycle.
- Throwaway prototypes. If you are testing whether an idea works at all, build fast and expect to bin it.
- Low-stakes internal tools. A single-prompt summariser used by two people can live without formal evals.
The rule of thumb: the moment an AI system talks to customers, handles money, or writes to your systems of record, you need evals, monitoring and the rest of the lifecycle. That is the line between a tool and a liability.
How to Adopt the AI SDLC
You do not need to adopt all eight stages on day one. This sequence works for most teams:
- Write the problem statement with a number in it. Get it agreed before anyone opens an editor.
- Design the agent boundaries on one page: what it does, what it never does, when a human steps in.
- Collect 50 real examples of inputs and good answers. This becomes your first eval set.
- Build the smallest version that passes those evals, with context and knowledge designed deliberately.
- Ship behind guardrails, monitor weekly, and feed what you find back into the eval set.
Teams that work this way ship slower in week one and faster every week after, because they are never guessing about quality.
Where Original Objective Fits In
We build production AI systems for UK businesses, and this lifecycle is how we do it. Our engineers have shipped software for brands including Bet365, Ticketmaster and Kohler Mira, and we bring the same production discipline to AI agents, automations and customer-facing assistants.
If you have an AI project that is stuck at the demo stage, or a system in production that nobody is measuring, book a free intro call. We will tell you honestly which stages you are missing and what it would take to fix them.
More in AI Production Systems
View all
Ready to put AI to work in your business?
Book a free 30-minute discovery call. We will discuss your goals, identify quick wins, and outline a practical plan to get started.
Book a discovery callCurated by Matt Perry
CTO
What Is the AI Software Development Lifecycle?
The AI software development lifecycle (AI SDLC) is the process teams use to take an AI system from a business problem to a system that keeps improving in production. It has eight stages: problem, agent design, context design, knowledge, evals, production, monitoring and improvement.
Traditional software follows a familiar loop. You gather requirements, you develop, you test, you release. That works because traditional software is deterministic. Given the same input, it produces the same output every time. Once a feature passes its tests, it stays passed.
AI systems do not behave like that. They are probabilistic, which means the same input can produce different outputs. Quality depends on context, data and model behaviour, and all three shift over time. A system that worked perfectly in the demo can quietly degrade in week three without a single error appearing in the logs.
So the lifecycle has to change. This article sets out the one we use at Original Objective when we build AI systems for clients.
The Old Lifecycle and the New One
The traditional software development lifecycle looks like this:
The AI software development lifecycle looks like this:
Two things stand out. First, "development" barely appears. Writing code is now the fastest part of the job. The hard work has moved into design, data and measurement. Second, the lifecycle does not end. Improvement feeds back into design, and the loop keeps running for as long as the system does.
Here is what each stage involves and what goes wrong when you skip it.
Stage 1: Problem
Every AI project should start with a problem statement that does not mention AI. For example: "Our team spends 30 hours a week answering the same 50 questions." Or: "Quotes take four days to produce and we lose deals in the gap."
A good problem statement includes a number you can move. If you cannot say what changes when the system works, stop and rework the statement. This is also the stage where honest teams discover that some problems need a process fix or a spreadsheet, not a model.
Skip it and: you build an impressive demo that solves nothing anyone measured.
Stage 2: Agent Design
Agent design means deciding what the AI system is responsible for, which tools it can use, and where humans stay in control. An agent is an AI system that can take actions, such as looking up an order, drafting a reply or updating a record, rather than only answering questions.
The key decisions are scope and autonomy. What actions can it take on its own? Which ones need human approval? When must it hand over to a person? These boundaries shape everything that follows, including cost, risk and how much your team trusts the system.
Skip it and: you get either a toy that helps nobody or an unsupervised system taking actions nobody signed off.
Stage 3: Context Design
Context design, often called context engineering, is controlling exactly what information the model sees at each step: its instructions, examples of good output, retrieved documents and the results of tool calls.
This is where most of the engineering effort in a modern AI system goes. Models rarely fail at random. They fail because the right information was not in front of them at the right moment, or because too much irrelevant information was. Designing context well is the difference between an assistant that sounds like your business and one that guesses.
Skip it and: output quality becomes a lottery, and every fix is a prompt tweak made in the dark.
Stage 4: Knowledge
Knowledge is the stage where you prepare the data the system relies on: documents, product data, policies, pricing and the APIs it can query.
Three questions matter here. Is it accurate? Is it current? Who is allowed to see it? Most real-world failures we get called in to fix trace back to this stage. The model was fine. The knowledge it was given was stale, contradictory or missing the case the customer asked about.
Skip it and: the system answers confidently from last year's price list.
Stage 5: Evals
Evals are automated tests that score an AI system's outputs against examples of what good looks like. They are the AI equivalent of a test suite, with one difference: instead of asserting an exact answer, they grade behaviour across a set of real inputs.
A useful eval set starts small. Fifty real questions with agreed good answers will do. Score each release on correctness, tone and safety. Without evals, every prompt change is a gamble. With them, you can swap models, rewrite prompts or restructure context and know within minutes whether the system got better or worse.
Skip it and: "it seems fine" becomes your quality bar, and regressions ship silently.
Stage 6: Production
Production means shipping with the guardrails a probabilistic system needs: fallbacks for when the model fails or times out, limits on cost and rate, safe default responses, and a clear route to a human.
This is also where the unglamorous engineering lives. Authentication, logging, data retention, cost caps per conversation. It is the difference between a prototype and a system your business can stand behind.
Skip it and: your first bad week in production becomes a public one.
Stage 7: Monitoring
Monitoring an AI system means watching behaviour, not just uptime. A wrong but confident answer throws no exception, so error logs will tell you everything is healthy while customers are being misled.
Track the numbers that reflect behaviour: resolution rate, escalation rate, cost per task, and drift in the kinds of questions coming in. Review a sample of real conversations every week. Ten minutes of reading transcripts catches problems no dashboard will.
Skip it and: you find out about degradation from a customer complaint, weeks late.
Stage 8: Improvement
Improvement closes the loop. Real conversations become new eval cases. Failures become context fixes. Gaps in answers become knowledge updates. Each cycle makes the next one measurably better, because stage 5 gave you the measuring stick.
This is why the AI SDLC is a cycle rather than a line. Traditional software is finished when it ships. An AI system is never finished. It is either improving or drifting.
Traditional SDLC vs AI SDLC
| Traditional SDLC | AI SDLC | Why it changed |
|---|---|---|
| Requirements | Problem | Requirements describe features. AI projects need a measurable outcome first. |
| Development | Agent design, context design, knowledge | Writing code is quick now. Designing behaviour and data is the real work. |
| Testing | Evals | You cannot assert exact outputs, so you score behaviour against examples instead. |
| Release | Production | Probabilistic systems need guardrails, fallbacks and cost controls, not just a deploy. |
| Maintenance | Monitoring and improvement | AI systems drift. Watching behaviour and feeding it back is continuous, not occasional. |
| Ends at ship | Never ends | The loop from improvement back to design runs for the life of the system. |
When You Do Not Need the Full Lifecycle
Not every use of AI needs eight stages. Be honest about which category you are in:
- Personal productivity. A team member using ChatGPT or Claude to draft emails needs guidance, not a lifecycle.
- Throwaway prototypes. If you are testing whether an idea works at all, build fast and expect to bin it.
- Low-stakes internal tools. A single-prompt summariser used by two people can live without formal evals.
The rule of thumb: the moment an AI system talks to customers, handles money, or writes to your systems of record, you need evals, monitoring and the rest of the lifecycle. That is the line between a tool and a liability.
How to Adopt the AI SDLC
You do not need to adopt all eight stages on day one. This sequence works for most teams:
- Write the problem statement with a number in it. Get it agreed before anyone opens an editor.
- Design the agent boundaries on one page: what it does, what it never does, when a human steps in.
- Collect 50 real examples of inputs and good answers. This becomes your first eval set.
- Build the smallest version that passes those evals, with context and knowledge designed deliberately.
- Ship behind guardrails, monitor weekly, and feed what you find back into the eval set.
Teams that work this way ship slower in week one and faster every week after, because they are never guessing about quality.
Where Original Objective Fits In
We build production AI systems for UK businesses, and this lifecycle is how we do it. Our engineers have shipped software for brands including Bet365, Ticketmaster and Kohler Mira, and we bring the same production discipline to AI agents, automations and customer-facing assistants.
If you have an AI project that is stuck at the demo stage, or a system in production that nobody is measuring, book a free intro call. We will tell you honestly which stages you are missing and what it would take to fix them.
More in AI Production Systems
View allReady to put AI to work in your business?
Book a free 30-minute discovery call. We will discuss your goals, identify quick wins, and outline a practical plan to get started.
Book a discovery callFrequently Asked Questions
What is the AI software development lifecycle?
The AI software development lifecycle (AI SDLC) is the process for taking an AI system from a business problem to a continuously improving production system. It has eight stages: problem, agent design, context design, knowledge, evals, production, monitoring and improvement. Unlike the traditional lifecycle, it is a loop rather than a line, because AI systems drift and need continuous measurement.
How is the AI SDLC different from the traditional SDLC?
Traditional software is deterministic, so the lifecycle centres on requirements, development and testing. AI systems are probabilistic, so the effort moves into designing behaviour, preparing knowledge and measuring output quality with evals. The other big difference is that the AI SDLC never ends. Monitoring and improvement run for the life of the system.
What are evals in AI development?
Evals are automated tests that score an AI system's outputs against examples of what good looks like. Instead of asserting an exact answer, they grade behaviour across a set of real inputs on measures like correctness, tone and safety. A starter set of around 50 real questions with agreed good answers is enough to make prompt and model changes safe.
What is context engineering?
Context engineering, also called context design, is controlling exactly what information an AI model sees at each step: its instructions, examples, retrieved documents and tool results. It matters because models usually fail when the right information is missing or buried, not because the model itself is weak. It is where most engineering effort in modern AI systems goes.
Why do AI projects fail after launch?
Most AI projects fail after launch because nobody is measuring behaviour. A wrong but confident answer produces no error, so traditional monitoring reports a healthy system while quality drifts. The fix is behavioural monitoring, such as resolution rates and cost per task, plus regular transcript reviews and an eval set that catches regressions before customers do.
Do small businesses need the full AI SDLC?
Not always. Personal productivity use, throwaway prototypes and low-stakes internal tools do not need eight stages. The full lifecycle becomes necessary the moment an AI system talks to customers, handles money or writes to your core systems. At that point evals, guardrails and monitoring are what separate a useful tool from a liability.
Subscribe to the AI Growth Newsletter
Get weekly AI insights, tools, and success stories — straight to your inbox.
Here's what you'll get when you subscribe::
- AI for SMBs – adopt AI without big budgets or complex setup
- Future Trends – what's coming next and how to stay ahead
- How to Automate Your Processes – save time with workflows that run 24/7
- Customer Service AI – chatbots and agents that delight customers
- Voice AI Solutions – smarter calls and seamless accessibility
- AI News – how to stay ahead of the ever changing AI world
- Local Success Stories – how AI has changed business in the UK.
No spam. Just practical AI tips for growing your business.
Not sure if your app is production-ready?
Not sure if your app is production-ready?
Take the AI Readiness Quiz