The agent development lifecycle: six stages, and why it is a loop

The short version

• The agent development lifecycle has six stages: scope, build, evaluate, test failure, deploy and monitor.
• Agents can give different outputs for the same input, so the release decision rests on evaluation against real cases, not on code review alone.
• An evaluation set built from real examples outlasts every other part of an agent project, and it should grow with every production failure.
• Agents should be deployed in stages: shadow mode, then read-only, then actions behind human approval, then autonomy only for actions the record supports.
• An agent's behaviour can change without a code change, when the model is updated or its data drifts, so monitoring never ends.

What is the agent development lifecycle?

The agent development lifecycle is the sequence of stages that takes an AI agent from an idea to a system that runs in production and keeps working there. There are six: scope, build, evaluate, test failure, deploy and monitor. The last stage feeds the third, so the sequence is a loop rather than a line.

An agent here means a system where a language model decides which steps to take and which tools to call, rather than following a fixed script. That freedom is the point of an agent. It is also why the lifecycle looks different from ordinary software. You are not only shipping code. You are shipping a behaviour, and behaviour has to be measured rather than read.

How is the agent development lifecycle different from the software development lifecycle?

The main difference is what decides a release. In ordinary software, code review and tests tell you whether a change is correct. An agent can give different answers to the same input, so the release decision rests on evaluation: running the agent against a set of real cases and measuring how often it gets them right.

Three other differences follow. Behaviour can change without a code change, because a model provider updates a model or the data the agent reads drifts. Prompts and tool descriptions are effectively code, and need version control and review like code. And failure is often silent. An agent that answers confidently and wrongly raises no exception.

The familiar parts still apply. The tools an agent calls are ordinary software and deserve ordinary unit tests. Access control, logging and deployment pipelines work the way they always have. The agent lifecycle adds stages. It does not replace the ones you already have.

What does each stage need before you move on?

What happens at the scoping stage of agent development?

Scoping decides what the agent does, how success will be measured, and what it is not allowed to do. The output is a short written brief: the task, a success measure someone outside engineering would recognise, the tools and data it may touch, and the actions that always need a human.

The success measure matters most because it is the easiest part to skip. 'Handles support tickets' is not a measure. 'Resolves password reset requests without escalation, with no wrong account changes' is. Without one, there is no way to tell later whether the agent is working, only whether it is running.

The cost of skipping it shows up later. Deloitte's 2026 survey of 3,500 director- to C-suite-level leaders across 25 countries described enterprise AI as entering an 'ROI reckoning', with more use and uneven value. A success measure written before the build is how you find out whether your project is part of the value or only part of the use.

Scoping is also where you decide whether to build an agent at all. If the steps are the same every time, a fixed workflow with a model call in one or two places is cheaper, faster and easier to test. An agent earns its cost only when the path through the task genuinely varies.

What does building the first version of an agent involve?

Building the first version means assembling the smallest agent that could plausibly do the task: one model, one prompt, the fewest tools that cover the job, and the narrowest permissions those tools allow. The aim is something you can evaluate quickly, not something finished.

Start with read-only tools where possible. An agent that can look things up but not change them is far safer to iterate on, and much of what you learn early is whether it finds and uses the right information. Write actions can come once evaluation shows it reasons well about when to use them.

Turn on tracing from the first run. A trace records each model call, each tool call, the inputs and outputs, and the time and cost of each step. Without traces, a wrong answer is a mystery. With them, it is usually a specific step you can point at.

How do you evaluate an AI agent?

You evaluate an agent by running it against a fixed set of real cases and scoring the results, every time anything changes. The evaluation set is the most valuable thing an agent project produces. It outlasts the prompt, the framework and probably the model.

Build the set from real examples of the task, not invented ones: past tickets, real documents, actual requests, with the correct outcome agreed by someone who does the work. Include the awkward cases deliberately. A set made only of typical requests will tell you the agent is ready when it is not.

Score the path as well as the answer. An agent can reach the right answer by a route you would not accept, such as calling a tool it did not need or reading data outside the task. Where a check can be exact, make it exact. Where it needs judgement, a model can grade, but a person should read a sample of those grades regularly, because graders drift too.

Run the full set on every change to the prompt, the tools or the model version. A change that fixes one case and quietly breaks four others is normal, and only a regression run will show it.

How do you test how an agent fails?

You test failure by deliberately giving the agent the conditions that break it: tools that error or time out, searches that return nothing, ambiguous or contradictory requests, and content written to redirect it. The question is not whether it fails. It is whether it fails safely.

Safe failure has a recognisable shape. The agent says it cannot complete the task, hands over to a person, or asks a clarifying question. Unsafe failure is the agent inventing a result to cover a failed tool call, retrying in a loop, or taking an action the request never asked for.

Prompt injection belongs in this stage. Any text the agent reads, whether a web page, an email or a retrieved document, can contain instructions. Assume some of it will, and test that the agent does not follow them, especially where it has write access.

Set hard limits here too: a maximum number of steps, a spending cap per task, and timeouts. These are not evaluation metrics. They are circuit breakers for the cases your evaluation set did not foresee.

How should an AI agent be deployed?

Deploy an agent in stages, widening what it can do only as the evidence supports it. A sensible sequence is shadow mode, then read-only answers to real users, then actions behind human approval, then autonomy for the specific actions where the record justifies it.

In shadow mode the agent runs on real traffic but nobody outside the team sees its output. This is the cheapest way to find the requests your evaluation set missed. Human approval comes next for any action that changes something: the agent drafts, a person confirms.

Every stage needs a way to switch the agent off quickly and an audit trail showing what it did and why. Neither is optional once the agent touches customers, money or records.

What does agent monitoring look like after launch?

Monitoring means watching what the agent actually does in production and turning every new failure into an evaluation case. It is the stage that closes the loop: production finds the cases you did not think of, and the evaluation set makes sure they stay fixed.

In practice that means four habits. Review a sample of traces regularly, read by someone who knows the task. Track cost and latency per task, not just in total. Watch escalation and override rates, because a rising rate can be the first sign of drift. And re-run the full evaluation set whenever the model provider ships a new version, before you switch to it.

An agent is never finished in the way a feature is. Model updates, new tools, new kinds of request and changes in the underlying data all move its behaviour. The lifecycle does not end at launch. Launch is where the most useful evaluation cases start arriving.