From Demo to Dependable: Closing the Agent Maturity Gap

Imagine an agent that wowed the steering committee in a demo. Leadership asks for a launch date. The team hesitates but cannot say why, because every example they try works. Then the first week in production brings a refund granted by mistake, a tool call that loops, and a bill twice what anyone expected.

The demo was real. What was missing was everything between “it worked once” and “we know how it behaves.” That is the maturity gap, and it is a gap in practice, not in talent. Software engineering and machine learning each have mature habits for closing it. Agents need both sets, adapted for systems that vary from run to run.

Why agents are different

A traditional service that passes its tests usually keeps passing until someone changes the code. Agents lack that stability in three ways:

The same input can yield different outputs, so one success is weak evidence.
Behavior depends on things outside your repository: the model provider, retrieved data, the prompt.
Failures are often subtle. The agent answers fluently and wrongly.

From software engineering you keep release gates, rollbacks and monitoring. From ML you keep representative datasets and statistical reading of results. What is new is joining them: a release gate that reads a rate, with a rollback plan, and monitors that watch for drift in behavior rather than just uptime.

A five-level ladder

This ladder is a thinking aid, not a standard. Real teams straddle levels, and the labels are ours.

Level	Name	Signs you are here	Next step
1	Demo	Success is judged by trying a few examples by hand. No saved examples.	Save every example you try, with the answer you expected.
2	Checked	A small saved set of cases exists. Someone runs it before changes. Changes are tracked.	Run each case several times; report the spread. Add known-hard cases.
3	Measured	Written targets for quality, cost and latency. Repeated runs. Evaluator checked against human judgment.	Make the targets a release gate with a named decision owner.
4	Gated	No release without recorded evidence. Hard constraints enforced in code. Rollback tested.	Monitor production and feed failures into the dataset.
5	Evidence-based operation	Production monitors compare live behavior to the release evidence. New failures become new test cases. Re-evaluation is triggered by model, data or prompt changes.	Review thresholds and datasets on a schedule; retire stale cases.

Moving up a level does not need a tool purchase. It needs a habit and an owner.

The practice: climb one rung

Locate yourself honestly. Use the checklist below. Choose the lowest level where any answer is “no.”
Climb exactly one rung. Teams that try to jump from 1 to 4 build process nobody follows.
Assign an owner for the rung. Unowned practices decay within a quarter.
Set a date to re-check. Maturity slips when models, data or staff change.

Self-assessment checklist (illustrative)

Answer yes or no for one agent.

We keep a saved set of example cases, versioned.
Every change to prompts, models or tools is recorded.
We run the set more than once per candidate and look at spread.
Quality, cost and latency targets are written down with thresholds.
Someone has compared our evaluator with human review.
Actions with side effects are limited by code, not just by instructions to the model.
A named person decides whether a release ships, based on recorded evidence.
We have rolled back a release in practice, not just on paper.
Production failures are added to the evaluation set.
We know within a day if behavior in production shifts.

Roughly: the first three “yes” answers mean level 2, the next three level 3, the next three level 4, and the last level 5. Treat this scoring as a rule of thumb, since the checklist is ours and not validated.

A worked example (illustrative)

Imagine a refund agent at level 1. The architect proposes three changes over six weeks, one per rung.

Week 1: save all demo prompts and expected answers in a file. That is 25 cases, and it is level 2.

Weeks 2 to 3: write targets (for example, correct answers on at least a stated share of cases, under a stated cost cap) and run each candidate five times. A prompt change that looked better in one run turns out to be within the run-to-run spread. The team stops arguing about it. That is level 3.

Weeks 4 to 6: the leader names a release owner and a rule: no release unless hard constraints pass every run and quality targets pass on the lowest run. A rollback is rehearsed. That is level 4.

Nothing here is a measured result. It shows the shape of the climb: each step is small, specific and owned.

Common traps on the way up

Skipping straight to dashboards. Monitoring an agent whose targets were never written down tells you something changed, not whether it matters.
Treating the gate as a formality. If every release passes, either the bar is too low or the cases are too easy. Add harder cases and see.
Letting the evaluation set go stale. The set that described last quarter’s users may miss this quarter’s. Schedule additions from production failures.
Confusing a prompt freeze with stability. Even with nothing changed on your side, a provider can update a model. Re-run your set on a schedule.

What this doesn’t solve

The ladder is not validated. We have no study showing teams at higher levels have fewer incidents. Evidence that would support it: incident rates and time-to-detect compared across teams at different levels, using the same definitions.
Levels do not transfer between agents. A mature refund agent says nothing about a new one.
Evidence has limits. Passing a gate does not guarantee behavior on inputs you never imagined. Monitoring exists for this reason.
Risk differs. An internal summarizer and an agent that moves money deserve different bars. Decide the target level by risk, not by habit.

Who this is for: engineering leaders and architects deciding whether and how an agent should go to production.