The Agent Development Lifecycle (ADLC): A Practical Guide

Traditional software has a standard frame: the Software Development Lifecycle. It works because software is deterministic. The same input gives the same output, so a green test suite means the system works. LLMs break that. The same input gives a different output on every run. An agent is a probabilistic system, and it has to be built, tested, and improved like one. That is what the Agent Development Lifecycle (ADLC) is for.

The first thing that breaks is test-driven development. You cannot unit-test behavior that lives in a prompt and a model. So the tests change shape. They become inputs and scenarios with expected results. We call them evals, and the discipline around them eval-driven development. Like tests, evals come first. They are the spec that aligns the team on what “good” means, and they keep growing for the life of the agent.

Many companies now describe a lifecycle like this one. But look at their models and one stage is missing everywhere: nobody gives diagnosis a stage of its own. The numbers show what that costs. 89% of teams have observability. Only half run evals. Barely a third evaluate in production. Everyone watches, few close the loop.

This guide walks all five stages and goes deepest where others go quiet: how diagnosis and the loop actually work.

What is the ADLC?

The Agent Development Lifecycle (ADLC) is the process a team follows to build an AI agent, from problem statement to a production system that keeps improving. It is eval-driven. A methodology, not a tool. (It is not the “Agentic Development Lifecycle” you may have seen elsewhere; the FAQ settles the difference.)

It runs in five stages:

1. Build: define what good means, then build a working agent.
2. Evaluate: prove it works against a quality bar you can trust.
3. Deploy: ship it pinned and identifiable.
4. Monitor: find out what production is actually doing.
5. Diagnose: turn production signal into root causes and new evals.

The five stages run as one continuous loop: Monitor → Diagnose → Build → Evaluate → Deploy, again and again. There is no separate “optimize” stage, because optimization is not a stage. It is the circle turning. The loop is not an add-on after launch. The loop is the lifecycle. And the stage the circle depends on is Diagnose: it converts production signal into new eval cases and guardrails, so the eval suite grows with every pass.

You can enter the circle anywhere. Greenfield teams start at Build. Teams with a live agent start at Monitor or Diagnose, with the traces they already have.

ADLC vs SDLC: why you cannot just run the tests

The logic moved out of the code

In classical software, the logic lives in code, so testing the code tests the system. In an agent, the logic lives in code, prompts, models, and tools. A provider updates a model or a document goes stale, and the behavior changes without a single line of your code changing.

Software fails loudly. Agents fail plausibly.

Software fails with a crash and a stack trace. An agent fails with a confident answer that is simply wrong: a hallucination, a reply built on empty retrieval. No alert fires. And because outputs vary between runs, the failure may not even reproduce when you look for it.

The measuring tool is probabilistic too

An LLM judge can score the same output differently across runs. So you cannot trust an evaluator just because you wrote one. We measured this directly. Building a judge you can trust is part of the work.

	SDLC	ADLC
Behavior	Deterministic	Non-deterministic
Where logic lives	Code and configuration	Code, prompts, models, tools, external services
”Is it working?”	The tests pass	Verified by evaluation against real cases
How you test	Unit and integration tests	Eval datasets, a calibrated judge, regression cases
What checks it	A fixed assertion, trusted by default	A judge you must calibrate before you can trust it
A failure is	A loud crash with a stack trace	A plausible wrong answer, traced to a root cause
After launch	Maintain and patch bugs	Monitor, Diagnose, rebuild, re-evaluate, continuously

The ADLC keeps everything good about the SDLC and adds what non-determinism forces on you: evaluation as the gate, and a production loop instead of a maintenance backlog. If you take one idea from this guide, take that one.

The stakeholders

Building an agent takes three people, each owning one question. One person can wear several hats, and early on one person often wears all three.

Stakeholder	Owns	What they do
PM	Why, what, and the bar	Defines the problem, the KPI, the success criteria, the cost budget, the agent’s authority, and the go-live bar. Owns go/no-go at Deploy. Owns Monitor with the Domain Expert.
AI Engineer	How, and whether it works	Designs the architecture, builds the agent, builds the eval framework, deploys, and diagnoses. Wires the monitoring signals the other two watch.
Domain Expert	Ground truth	Authors and rates the evals: defines cases, labels outputs correct or incorrect, reviews production behavior in Monitor, reads failure clusters in Diagnose.

Three rules keep the split honest:

• The PM defines good, the Domain Expert judges it. The PM sets the KPI and the bar. The Domain Expert decides, case by case, whether an output is correct.
• Name one quality voice. A single accountable expert beats an annotation committee. Committees average away exactly the judgment you need.
• Never outsource the labeling. Reading your agent’s outputs is where product intuition comes from. Hand it to a vendor and you keep the labels but lose the learning.

The split exists because the failure modes exist. Without a PM, the engineer optimizes for the wrong outcome. Without a Domain Expert, the evals encode what engineers think correct looks like, and the first customer finds the error. Without an AI Engineer, the prompt demos well and breaks on the unhappy paths.

The end user is the fourth voice. They own no stage, but every thumbs-down, correction, and abandoned session is ground truth about whether the agent delivers value. Build in a way to capture that feedback from day one.

---

The five stages

Every stage has the same spine: goal, owner, activities, concepts, output. Skim the goals and activities and you can run the lifecycle. The depth sits in Evaluate and Diagnose, on purpose.

Stage 1 · Build

Goal: a working agent, aligned across all stakeholders before code.

Owner: PM (the definition) and AI Engineer (the system).

Build is also where every loop pass lands. When Diagnose names a root cause, Build applies the fix: a prompt change, a tool fix, a guardrail, a model swap.

Activities

• Define the problem, the KPI, the success criteria, the cost budget, and the go-live bar.
• Hand over everything that exists: SOPs, scripts, historic cases, tone guides.
• Set the autonomy level and the business rules.
• Design the architecture: tools, state, control flow, context. Keep every step as deterministic as it can be.
• Write the first test cases with the Domain Expert, from clustered historic cases.
• Build the agent with observability wired in, and functional tests that prove the data flow works.

Do you even need an agent?

The first Build decision is whether an agent is the right tool at all. Often it is not.

• If the rules are enumerable, write normal code.
• If one prompt does the job, ship a single LLM call.
• If the steps are fixed and only the content varies, build a workflow where your code decides the path.

An agent, where the model directs its own tool use, is the right call when the input is messy, the decisions branch, and no fixed path covers the cases. Every step away from plain code costs you testability, and the rest of this lifecycle is what buys it back. Anthropic’s and OpenAI’s agent guides help with this choice. Both end the same way: evaluate and iterate. The ADLC is the method for that part.

The agent charter

The charter is the one signed artifact Build produces before code. One page, in domain language, specific enough that the engineer never has to guess.

One field deserves a warning: check the knowledge before you build. Stale or contradictory documents are a reasoning failure you scheduled in advance.

The agent spec

The charter says what the agent must achieve. The spec is the technical contract it is built against: the agent loop, the tools with their inputs and outputs, the context layers, the data model, endpoints, integrations, memory, and the human gate. The engineer writes it, the stakeholders review it, and the coding agent builds from it.

Deterministic guardrails

Rules that must always hold do not belong in the prompt. The model can override anything in its context. Guardrails run as code, outside the model:

• Input checks: relevance and safety classifiers, PII filters.
• Output checks: schema validation, policy patterns, blocklists on tools and actions.
• Layer them. No single check catches everything.

Design the first set now. Diagnose adds more with every production failure.

Human gates

Decide where a human stands between the agent and the world.

• Rate every tool for risk. Does it read or write? Is it reversible? What does a mistake cost? High-risk tools pause for approval, low-risk tools run free.
• Define the escalation. When does the agent hand over to a human? A failure threshold, a risky action, low confidence. And what context travels with the handoff, so the human gets a decision, not a mystery.
• Design the review surface. Show the agent’s reasoning, prefill the data, capture every rating and correction back to its trace. If existing tools cannot do this, build a small custom one.

Crawl all available data

Crawl everything the team already has: historic cases and traces, company docs and SOPs, tone guides, the API surface. That corpus is enough to autogenerate the spec, the expected trajectories, the context blocks, and the input scenarios. The entire spec can be prepared from context that already exists.

01Mutagent Agent · BuildSpec Agent Interactively automates defining your agent. It fills the charter section by section with you and emits a signed, framework-agnostic spec with eval criteria baked in. IN requirements · traces · docs    OUT architecture · spec · eval criteria Explore the Spec Agent →

Building it

If the charter and the design are right, most of the implementation is mechanical, and a coding agent can do the bulk of it.

• Run a builder-verifier loop: one agent builds, a second checks the result against the charter.
• Write tool descriptions a new hire could act on. Most “wrong tool” failures trace back to a vague description.
• Verify generated code and dependencies, and give an agent that takes real actions a sandbox while you test it.

Output: a running, traced agent, its functional tests, guardrails live, and the signed charter it was built against.

01Mutagent Agent · BuildBuild Agent Takes the signed spec and turns it into a working agent: scaffolds the code, maps your existing prompts and traces, and wires telemetry into your stack. IN signed spec · prompts · traces    OUT working agent · telemetry Explore the Build Agent →

Stage 2 · Evaluate

Goal: a measurement framework you can trust and run any time. It gates every version: the launch, and every fix after it.

Owner: AI Engineer with the Domain Expert.

Activities

• Build the eval dataset: cases, expected outputs, categories.
• Have the Domain Expert label ground truth.
• Write the criteria, one per target, anchored so tightly the judge cannot drift.
• Calibrate the judge against the expert’s labels.
• Run experiments across models and settings. Pick the version that clears the bar.

Why build evals at all

• Evals are the executable spec. A few dozen labeled cases align PM, engineer, and expert on what “good” concretely means, before anyone argues about a prompt.
• Manual testing works, then stops. At thousands of cases you cannot re-check by hand, and improvement turns reactive: wait for complaints, reproduce, fix, hope.
• Evals give you testing on demand. Before any change ships, the whole suite runs. Regressions surface before users do.
• Start now. Evals get harder to build the longer you wait, because early on your requirements translate directly into cases.

Your Domain Expert and product team write most of the cases and run the evals. The engineer builds the harness, not the opinions.

Your evals are the agent’s DNA

An eval system is a dataset of cases and the scorers that grade them. Everything downstream optimizes toward that score, so whatever your criteria reward is what the agent becomes. That cuts both ways. Point an optimizer at a shallow eval and the agent learns to game the score while real behavior degrades. This is Goodhart’s law: when a measure becomes a target, it stops being a good measure. Keep the criteria tied to the KPI from the charter, and skip generic scores like “helpfulness: 4.2”. They measure nothing your product needs.

Three kinds of graders

Choose per criterion. Anthropic’s Demystifying evals for AI agents is a good deep dive.

• Code graders: regex, schema checks, tool-call verification. Fast, free, reproducible. Blind to nuance.
• LLM judges: rubric scoring, comparisons. They handle everything that needs reading, but they are probabilistic and must be calibrated first.
• Humans: the gold standard, and the source of truth the other two are calibrated against. Expensive, so spend them where they teach the most.

Make everything deterministic that can be. Judge only what needs reading. Use humans to calibrate the judges.

Three grading rules

• Grade binary. Pass or fail. The difference between a 3 and a 4 on a rating scale is a mood, not a measurement. Report pass rates.
• Grade outcomes, not claims. “The agent said the refund was issued” is a transcript. Whether the refund exists in the payment system is an outcome. Where a tool changes state, check the state.
• Treat the path as a diagnostic, not a gate. Score tool choice and grounding to find where things break, but do not hard-fail on exact tool sequences. There is usually more than one sane path.

Two suites: quality and regression

Quality evals are the bar you are climbing toward: hard cases the agent does not pass yet. A healthy quality suite starts at a low pass rate. If it starts at 95%, it tests nothing. Regression evals are everything the agent already passed, re-run on every change so no win silently unwinds. When a quality eval saturates near 100%, it moves to the regression suite. That graduation is how the framework grows every cycle.

Where the cases come from

What a case contains depends on the agent: an input and an expected output for single-turn work, a persona and a goal for a multi-turn agent, a full trajectory where the path matters. The sources, in the order teams usually reach them:

1. The prompt. Every rule in your system prompt becomes a case. This is the day-one suite.
2. Historic data. Cluster what humans already handled and seed from real inputs.
3. Synthetic generation. LLM-made variations for the unhappy paths your history is thin on. A supplement, never a replacement.
4. Shadowed live traffic. Run the new version silently next to production and harvest what it sees.
5. The review surface. Where a human already approves outputs, their labels are ground truth for free.
6. Known failure patterns. Wrong tool, ungrounded answer, guardrail violation. Seed the classics before production teaches them to you.
7. Adversarial cases. Prompt injection, guardrail circumvention, ambiguous inputs. The higher the risk, the more of these you need before shipping.

Most of the value sits in the failure cases, balanced between situations where a behavior should fire and where it should not. And give every case a reference solution. A case that fails on every trial is usually a broken case, not a broken agent.

The human-in-the-loop interface

Ground truth only exists if the expert labels runs, and the expert only labels runs when labeling is cheap. The most common eval failure is not bad criteria. It is that nobody built a place to label, so labeling never happens.

The interface is deliberately simple. It pulls real runs into a queue and shows everything in one view: the input, the agent’s reasoning, the output, and the criteria beside it. The expert approves, corrects, or rejects, with a reason, in seconds per case. Every decision is captured against the exact run it came from.

One pass through the queue feeds three things at once:

• The dataset. Every correction becomes a labeled case, so the suite grows out of real runs instead of invented ones.
• The judge. Calibration means grading the judge against these labels. Where judge and expert disagree, the criteria are not anchored tightly enough yet.
• The bar. Ratings tied to runs show whether “good” is drifting, per category, over time.

An annotation queue in your observability tool is enough to start. If it cannot show the reasoning, prefill the data, and write the label back to the trace, build a small custom one. This is the same review surface from Build doing double duty: approvals on the way out, ground truth on the way back.

Grade every layer of the run

Most agent failures hide in the path, not the final answer. So score the run on axes that fail independently: task completion, tool correctness, path quality, and grounding in what was actually retrieved. Keep the axes separate. A right-looking answer off a broken path is exactly what a single blended score hides.

Calibrate the judge

The judge is an LLM too. It scores the same output differently on two runs, and it knows nothing about your domain until you teach it. You trust it because you measured it, not because you wrote it.

• The Domain Expert labels a set of cases. The judge labels the same cases. Measure how often they agree, especially on the failures.
• Have the expert write a short critique with each label. The critiques become the judge’s few-shot examples, and they are how a diverging judge gets fixed.
• Where the judge matches the expert, it runs unattended. Where it diverges, the criterion is usually missing an anchor. Fix it before it gates anything.

Output: the two suites, a calibrated judge, and a scorecard against the go-live bar. When the scorecard clears the bar, ship. The temptation to polish is the temptation to never ship.

02Mutagent Agent · EvaluateEvaluator Agent Builds the evals and a calibrated judge that scores every change, aligned to your domain expert before it gates anything. IN dataset · expert labels    OUT calibrated judge · criteria Explore the Evaluator Agent →

Stage 3 · Deploy

Goal: ship it safely, every pass.

Owner: AI Engineer with the PM, who owns go/no-go.

Activities

• Run both eval suites. The go-live bar decides, not the calendar.
• Pin the version, so every production trace ties back to exactly one artifact.
• Cutover, rollback, and environments are your ops stack’s job. The methodology only demands the gate and the pin.

A shipped version never changes. Every trace, scorecard, and rollback points to exactly one artifact. If the prompt can be hot-edited in production, you do not have versions, you have a mystery.

For an agent that takes real actions, the safest way to ship keeps a human in the loop: the agent drafts, a person approves, edits, or rejects. Every one of those decisions becomes labeled training signal. Autonomy is raised with evidence, not optimism.

Output: a deployed agent and a pinned, immutable version.

Stage 4 · Monitor

Goal: find out whether the agent is delivering value in production.

Owner: the PM and the Domain Expert. The AI Engineer wires the signals; the PM watches the value, the Domain Expert watches the correctness.

Activities

• Collect the five signals below in one stakeholder-facing overview.
• Flag unusual cases and route them to Diagnose and to expert review.
• Track the KPI, cost, and latency against the charter’s budgets.
• Re-run the regression suite when anything underneath the agent changes.

The five signals

1. Code evals on every trace. Deterministic checks are free, so they run on all traffic.
2. Judge sampling. The LLM judge runs on all traces or a budget-sized sample.
3. User feedback. Ratings, corrections, escalations, abandoned sessions, each tied to its trace.
4. Operational alerts. Drift, cost, latency, error rates, plus circuit breakers that stop an agent stuck in a loop before the invoice does.
5. Expert review. The Domain Expert reads the flagged outputs. No metric replaces the person who knows what right looks like.

Watch the KPI, not just the evals

The eval suite says whether the agent behaves. The KPI from the charter says whether it matters, and adoption says whether anyone uses it. The metric named in Build must be a chart in Monitor, or the charter was theater.

Watch for changes you did not make

Agent behavior changes without a deploy. A provider updates the model, an API changes, the input distribution drifts. A model update fires the regression suite, every time. Behavior change with zero code change is normal here.

Output: feedback events, a signals overview, alerts, and flagged cases for Diagnose. (Why this stage decides production value: the last-mile problem.)

04Mutagent Agent · MonitorMonitoring / Incident Agent Catches live issues in production and triages them, routing each one to expert review or a full diagnosis. IN production traces · alerts    OUT triaged issues Explore the Monitoring Agent →

Stage 5 · Diagnose

Goal: turn production signal into root causes, and root causes into new evals. This is the stage every other lifecycle skips.

Owner: AI Engineer with the Domain Expert.

Diagnose earns its place because of what it returns. Three outputs, three destinations:

• New eval cases and sharper criteria go to Evaluate.
• New guardrails go to Build.
• Scoped fixes, each with a root cause attached, go to Build.

The eval suite you run tomorrow is bigger than today’s because this stage ran.

Activities

• Filter traces by version, cohort, and time window to scope the investigation.
• Cluster failing traces by shared root cause. Read representative transcripts from each cluster.
• Classify each failure: what broke, why, and where the fix lands (prompt, tool, data, code).
• Rank failure modes by frequency, severity, and cost.
• Fold every confirmed failure into the regression suite. Compound recurring patterns into the failure index.

Error analysis has a name

This is classic qualitative error analysis. Describe each failing trace in your own words. Merge the descriptions into named failure modes. Keep reading until new traces stop producing new modes. The people who teach evals call this the single most important activity in the discipline, and they are right. It is not overhead. It is the job.

Cluster first, then read

At three traces you read each one. At three thousand you cluster first, because the same root cause repeats across hundreds of traces, and one fix covers all of them. But clustering only tells you where to look. The diagnosis comes from reading representative transcripts. No score or dashboard replaces that. (How the diagnostics agent works walks the full method.)

Not every failure deserves a judge

• A one-off oddity becomes nothing.
• A recurring, mechanical pattern becomes a code check. Free forever.
• Only a persistent failure that genuinely needs reading becomes a judge criterion, because judges carry maintenance cost.

The cheap check bank grows fastest, and that is correct.

Output: ranked failure modes, the new cases and guardrails above, and the failure index. Without the index, every pass starts from scratch and the same root cause gets rediscovered six times.

05Mutagent Agent · DiagnoseDiagnostics Agent A failure-mode scan that finds root causes, not a wall of logs. Every finding is traced to a step and an origin, and ranked by impact. IN production traces    OUT ranked root causes · failure index Explore the Diagnostics Agent →

One pass through the loop

Monitor flags a cohort of failing traces. Diagnose clusters them, names the root cause, adds the failure to the regression suite, and hands Build a scoped fix. Build applies exactly that change. Evaluate runs the before and after on a held-out slice, full regression suite included, and blocks anything that degrades. Deploy ships the pinned new version. The loop turns, and the suite it gates with next time is larger than the one it used this time.

The scorecard decides the redeploy, not the engineer’s confidence. This is not ceremony. Intuitive fixes regress more often than teams expect, and the gate is what catches it. The fixes themselves range across the whole agent: prompt, tools, code, retrieval, the model itself. What to change when is its own topic: see our optimization strategies and Karpathy on the decade of agents, on why this loop is permanent infrastructure rather than a phase.

∞Mutagent Agent · The LoopMutation Agent Runs the diagnose, mutate, evaluate loop and ships verified fixes, each scoped to a root cause and validated on a held-out slice. IN root cause · eval suite    OUT verified fix · before/after scorecard Explore the Mutation Agent →

Not every stage carries equal weight. Build decides the architecture every later stage pays for. Evaluate builds the machine that lets everything run on its own. Diagnose is where the suite starts compounding. Get those three right and the rest largely pays for itself.

Tooling, by stage

Each stage leans on a category: agent frameworks, observability tools, eval tools, model providers, and the glue between them. Bring your own vendors. A gap in this table is usually a gap in your lifecycle. (Find your stage before you buy your next tool.)

Stage	What you reach for
Build	An agent framework or orchestration layer, a spec format, tracing instrumentation
Evaluate	An eval harness, a dataset store, code graders and an LLM judge
Deploy	Version pinning, CI, rollback
Monitor	Online evals, drift and cost alerting, feedback capture
Diagnose	Trace search, failure clustering, root-cause analysis
The loop	Prompt and model optimization, before/after scorecards

Prefer open standards per category (OpenTelemetry for traces, MCP for tools), so no vendor owns your lifecycle. That is the principle Mutagent is built on too: the methodology is tool-agnostic, so the tooling has to be. Mutagent connects to whatever you already run, from Langfuse, LangSmith, and Braintrust to OpenTelemetry, Datadog, and local traces.

Your agent on day one is a draft

Almost every team we talk to has the same gap: no working method for the optimization problem. Most guidance stops at the first working version, and coding agents made that part cheap. The first version is a draft, and almost nobody has a method for turning a draft into a system that compounds. Waiting for the next model release does not close that gap. The loop does.

Today you walk the ADLC by hand, and it works with nothing but a whiteboard. The same lifecycle can be run agentically: one orchestrator takes a work item, runs every stage with a fleet of agents, and hands you back validated PRs, with you as the human in the loop. That is where we are taking it.

∞Mutagent Agent · The orchestratorAuto Engineer Agent Chains every agent into one orchestrator that runs the whole lifecycle end-to-end. You set the goal and stay the human in the loop; it runs the stages. IN a work item (feature or incident)    OUT validated PRs · agent + skill updates Explore the Auto Engineer →

Build the future. Engineer the evolution.

The methodology is yours to run with a whiteboard. If you also want the tooling that makes the Diagnose loop compound on its own, see what Mutagent does, or book a demo and we will run a diagnosis on your own traces.

FAQ

What does ADLC stand for?

Agent Development Lifecycle. The staged, eval-driven methodology a team follows to build an AI agent from a problem statement to a running, evaluated, continuously improving production system.

How many stages does the ADLC have?

Five: Build, Evaluate, Deploy, Monitor, and Diagnose. They run as one continuous loop: Monitor → Diagnose → Build → Evaluate → Deploy. You will find other counts under the same name: LangChain describes four stages, Salesforce five, IBM six, Glean seven. The difference is that none of them gives diagnosis a stage of its own, and that stage is the one that makes the others compound.

Is the ADLC the same as the “Agentic Development Lifecycle”?

No. The Agentic Development Lifecycle (sometimes AI-DLC) describes AI agents autonomously writing and shipping software. The Agent Development Lifecycle, this guide, is a methodology for humans building and improving AI agents. Same acronym, unrelated lifecycle.

Who is the ADLC for?

Teams building AI agents: the PM defining what the agent should do and the bar it must clear, the AI Engineer building and operating it, and the Domain Expert authoring evals and judging outputs. One person can wear several hats.

Do I need to use all five stages?

For your first agent, yes. The stages exist because skipping them is the most common failure mode. For mature teams the stages become implicit. Methodology is scaffolding, not bureaucracy. And you do not have to start at stage one: teams with a live agent enter at Monitor or Diagnose and work backward.

What is the difference between Monitor and Diagnose?

Monitor watches the running agent: it collects signals and flags what looks wrong. Diagnose explains it: it clusters the flagged traces, attributes each failure to a root cause, and converts the findings into new eval cases and guardrails. Monitoring without diagnosis is the most common production anti-pattern: dashboards full of symptoms and no named causes.

What is eval-driven development (EDD)?

The agent-era counterpart of test-driven development. Because you cannot unit-test behavior that lives in a prompt and a model, the checks become evals: input scenarios with expected results, graded by code, calibrated LLM judges, and humans. Like tests, evals are written first, as the executable spec that aligns the team. Unlike tests, the suite keeps growing from production failures.

What is the difference between quality evals and regression evals?

Quality evals are the bar you are optimizing toward: hard cases the agent does not pass yet, so a healthy quality suite starts at a low pass rate. Regression evals are everything the agent already passed, re-run on every change. When a quality eval saturates near 100% it graduates into the regression suite. That graduation is how the eval framework compounds.

How is the ADLC different from the SDLC?

The SDLC assumes deterministic software: unit tests pass and the code works. The ADLC assumes a probabilistic agent: the logic lives in prompts, models, and tools as much as code, and failures are plausible rather than loud. So evaluation against real cases gates each stage, and a continuous Monitor and Diagnose loop replaces the maintenance backlog.

How do you evaluate an AI agent?

Build an eval dataset from real and historic cases, have a Domain Expert label ground truth, and grade the whole run: task completion, tool correctness, path quality, and grounding, with code checks wherever the criterion is mechanical. Then calibrate an LLM judge against the expert’s labels (how an eval system grows from traces) and score every candidate against a quality bar before it ships.

---

Written by Dorian Schlede (CPO, Mutagent). We spent two years building production AI agents the hard way before productizing the methodology as Mutagent. The ADLC stands on its own.