The production-readiness review is one of the better habits software teams have picked up. Before a service takes real traffic, somebody walks a list. Is there an owner and an on-call rotation? Are there dashboards and alerts? What happens under load? How do you roll back? What does it depend on?
Put an AI agent through that review and it will usually pass. It has an owner and latency and error dashboards, and its code deploys and rolls back like any other service. Every item on the list is about whether the system runs, and it does.
None of the items asks what it decides.
That gap matters for two reasons the list was never built around. The failures worth worrying about in an agent tend to complete successfully: a refund refused that policy allowed, a lead routed to the wrong place, a credit issued to one customer and not another. And the behavior can change without anything a deploy pipeline would see. A model version moves. A provider changes a default. Someone edits a prompt held in config, or the guidance document the agent reads.
I ran into the second one directly this month. Claude Haiku 5.5, which Anthropic released earlier this month, thinks by default, where Haiku 4.5 only thought when asked. Swapping one for the other is a one-line change in most stacks. Once the requests succeed, the outputs may look fine, and nothing in a code review or a service dashboard will say whether the decisions moved.
The second review
Here's the object this piece builds: a behavior-readiness review asks, for each consequential decision a system makes, whether you could notice it going wrong, explain it, and undo whatever changed it. It sits next to the service review. It doesn't replace any of it.
A service review asks whether the system will stay up. A behavior review asks whether you'd know if it started choosing differently.
The checklist
Seven items. They're written for a team without a dedicated ML engineer, and none of them needs one.
1. Name the decisions, not the endpoints
List the choices the system makes that someone outside engineering would care about: approve or refuse, route here or there, credit or don't, escalate or close. Most agents have a handful. Write down who owns the outcome of each one, meaning the person who'd have to explain it to a customer.
A decision with no owner is your first finding. It usually means the person who'll get the question hasn't been told yet.
2. List everything that can change those decisions without a deploy
For each decision, list what it reads and what shapes it: the model and its version, including any alias that silently moves to a newer one; provider defaults; the prompt and tool descriptions, especially if they live in config; whatever it retrieves; and the documents people edit by hand, like policy pages and intake guidelines.
Next to each, write who can change it and whether anything records when it changed.
The reason this item comes so early: anything a decision depends on is part of the system, whether or not it lives in the repository. Change control usually covers the code and stops there. When teams say "nothing changed, but the behavior did," the missing change is often somewhere on this list.
3. Write down what normal looks like before launch
From your pilot or staging runs, record roughly how each consequential decision splits. What share of leads go to sales. How often refunds are approved. How often the agent escalates. It doesn't need to be precise, and it shouldn't wait for a perfect metric.
For a new system, treat this as an initial reference, not as production normal. Real traffic will move it, and the first weeks after launch are when to update it.
You can't call something a change without a before. A team that skips this will eventually be asked whether the agent is behaving differently since last month, and the honest answer will be that nobody knows what last month looked like.
4. Run the explanation drill
Take one real decision from the pilot or from staging, ideally a borderline one. Time how long it takes someone to answer "why did it do that?" using only what you'll actually keep in production. I wrote up a time-boxed version of that investigation a few weeks ago if you want a structure for it.
The drill fails in two ways worth separating. It can need the engineer who built the system, which is a staffing finding. Or it can need something you won't have kept, like the input as the agent received it or the version of the guidance that was in effect, which is a capture finding. The second kind is cheaper to fix before launch than after.
5. Decide what notices a bad decision before a customer does
For each decision on your list, ask what would surface a bad one that completed successfully. A sampled human review. A periodic comparison against the baseline from item 3. A downstream signal, like a refund that gets reopened or a lead that turns up in a competitor's announcement.
"We'd hear about it from a customer" is a legitimate answer for a low-stakes decision. Write it down as the answer, so it's a choice and not a default.
6. Check how long you keep the evidence against how late problems arrive
Ask how long it usually takes for a bad decision to reach someone who'd question it. For a support reply it might be hours. For a routing or approval decision it can be weeks.
Then check how long the evidence for that decision survives: the input, the context it had, the versions in effect. If the evidence is gone before the question tends to arrive, the drill in item 4 will pass in staging and fail in production.
7. Make behavior rollback real
You can roll back code. Can you roll back a model version, a prompt, a guidance document? Do you pin model versions, or use an alias? For a decision made last Tuesday, could you say which version of each input from item 2 was in effect?
If the answer to the last one is no, a rollback is a guess at which change to undo.
At a glance
| Item | The question | It fails when |
|-------------------------------|-------------------------------------------------------------------|-------------------------------------------------------------|
| **Decisions** | Which choices matter, and who answers for each? | A decision has no owner |
| **Changes without a deploy** | What can move a decision outside the pipeline? | Nothing records when it changed |
| **Baseline** | What did each decision look like before launch? | There's no before to compare against |
| **Explanation drill** | Can someone explain one decision from what you keep? | It needs the builder, or evidence you won't have |
| **Noticing** | What surfaces a bad decision that completed? | The only answer is a complaint, and nobody chose that |
| **Retention** | Does the evidence outlast the delay before questions arrive? | It's deleted before anyone would ask |
| **Behavior rollback** | Can you undo a non-code change, and know which one to undo? | You can't say which versions were in effect |What this doesn't give you
It doesn't tell you the decisions are right. A system can pass every item and still make bad calls. What it tells you is whether you'd find out, and how much work finding out would be.
It's a snapshot. The review is done before launch, and the system keeps changing afterwards, often through exactly the inputs item 2 lists. Rerun it when a model version or a major prompt changes, not just once.
Your list in item 2 will be incomplete the first time. That's fine. The first unexplained change you investigate will usually add something to it.
And it can grow into paperwork. I wrote about why governance without decision history ends up governing the logs. A behavior review that produces a document nobody opens again has the same problem. Keep it short enough that someone would actually rerun it.
One thing to do this week
Pick the one decision whose bad version would cost you most. Do items 2 and 4 for it and nothing else: list everything that can change it without a deploy, then run the explanation drill once, against what you actually keep.
Most teams learn more from that hour than from the rest of the list.
Where this goes
Done by hand, this is a review you run before launch and, if you're disciplined, after each model or prompt change. Items 3 through 5 are the ones that decay fastest, because they depend on someone remembering to look. Keeping them current for every consequential decision, across every change, is the part that doesn't stay manual for long.
That continuous version is the direction I'm building Nalyqor toward. You don't need it to run the review this week.