Five Questions for Your Next AI Design Review

Mostafa Dhouib·September 6, 2026·7 min read

Five Questions for Your Next AI Design Review

The short answer. Five questions, none requiring you to read code: what measures progress, what happens when it runs out of budget, what bounds the whole task rather than one call, what has your verifier rejected, and which actions cannot be undone. Each has a right answer and a wrong answer you will recognise immediately. Together they cover the failure modes that pass every demo, because those failures live in what the system does when it does not succeed, and demos only show success.

A demo shows you the happy path. That is what a demo is for, and there is nothing dishonest about it. The problem is that the failures that hurt in production are not on the happy path, and there is a standard set of them.

You do not need to read a trace to find them. You need five questions.

One: what measures progress?

Ask it exactly like this. "What value does the system compute that tells it the work is getting closer to done?"

The right answer names a quantity computed in code from ground truth: rows still unmigrated, tests still failing, records still unmatched, fields still empty. It shrinks as the task nears completion, and nothing in the system can reset it.

The wrong answer is one of two. Either "the model decides when it is finished," which means the stopping condition is a sample from a distribution rather than a function of state, so the same situation can produce two different verdicts. Or "we cap it at N iterations," which is a real bound on spend and tells you nothing about progress. A fuel gauge cannot distinguish arriving from running dry.

If the answer is the second one, that is not a small gap. It is the most common defect in production agents and everything else on this list gets worse because of it.

Two: what happens when it runs out of budget?

Ask it exactly like this. "When the iteration cap or the timeout is hit, what does the caller receive?"

The right answer is a distinct outcome. Done, gave up, and killed are three different states, and the caller can tell them apart without inspecting the content. A run that exhausted its budget must not be representable as a completed result.

The wrong answer is "it returns whatever it has." That is the silent failure, and it is worse than a crash by a wide margin. A crash is loud, alerts, and gets fixed. A partial result wearing a completed result's clothes gets written to a database, sent to a customer, or used as the input to step six of a chain where it becomes a foundation.

Follow up with: "show me where in the type signature those are different." If they are the same type, they are the same thing to every layer downstream, whatever the intent was.

Three: what bounds the whole task?

Ask it exactly like this. "If this agent can call other agents, what limits the total?"

The right answer is a budget carried through every nested call: wall clock, spend, and depth, enforced outside any individual agent, decremented by the tree as a whole.

The wrong answer is "each one is capped at twenty steps." Twenty capped agents each calling twenty capped agents is four hundred runs, and every single one of them stayed inside its limit. Nothing was violated, nothing alerted, and the bill arrives anyway.

This is the failure mode where two correct bounds compose into no bound at all, and it is invisible to per-component monitoring by construction. Ask what the largest tree observed in the last month was. If nobody knows, nobody is bounding it.

Four: what has the verifier rejected?

Ask it exactly like this. "How many times has the verification step rejected something in the last thirty days, and what were those cases?"

The right answer is a number and a handful of examples, which you can then sanity-check by eye.

The wrong answers are all informative. "Nobody is counting" means the component has never been evaluated. "It has never rejected anything" means either the generator is perfect or the verifier is a rubber stamp, and one of those is much more likely than the other.

The follow-up that settles it: "is the verifier the same model that produced the answer?" If it is, it shares the generator's priors, so where the generator is confidently wrong the checker is confidently agreeable. That is a verifier that verifies nothing, and it is on the architecture diagram doing a great deal of work in this exact meeting.

Five: which actions cannot be undone?

Ask it exactly like this. "List the actions this system can take that you cannot reverse, and tell me what gates each one."

The right answer is a short, explicit list with a gate on each: money moving, messages to customers, deletions, external commitments, production writes. The gate might be a human, an idempotency key, a dry-run diff, or a hard scope limit. It is named, and it is enforced in code rather than in the prompt.

The wrong answer is "the model knows not to do that." A prompt is not a permission system. It is a suggestion evaluated by a component whose outputs you have just established are nondeterministic.

The compounding version of this question: "what happens if it retries after a partial success?" Most systems retry, most actions are not idempotent, and the intersection is where the duplicate payment lives.

What to do with the answers

You are not grading a team. You are locating which of five known gaps this system has, and the useful property of this list is that the gaps are independent: a system can pass three and fail two, and the two it fails predict exactly how it will hurt you.

Two patterns worth naming when you see them.

All five answered in terms of the prompt. Progress is judged by the model, budget exhaustion is handled by the model, verification is the model, and the irreversible actions are gated by instructions to the model. This is a system with one component and four names for it, and no amount of prompt work changes that.

Answers that are confident but not evidenced. "It handles that" is not an answer. The follow-up is always the same and it is always fair: show me the last time it happened. If the situation has never occurred in production, ask how they know it works. If it has occurred, there is a trace, and the trace settles the question in a minute.

FAQ

What should I ask in an AI design review? Five things: what value measures progress toward done, what the caller receives when the budget is exhausted, what bounds the whole task rather than a single call, what the verification step has actually rejected, and which actions cannot be undone and what gates each one. None require reading code.

How can a non-engineer evaluate an AI agent? By asking about failure rather than success. A demo shows the happy path by design, so the questions that matter are about what the system does when it does not succeed: how it reports giving up, what stops a call tree, and what it is prevented from doing irreversibly.

Why is "the model decides when it's done" a wrong answer? Because it is a sample from a distribution rather than a value computed from state. The same situation can produce two different verdicts on two runs, which means it is not a stopping condition in any reliable sense, however good the prompt is.

What is wrong with capping iterations? Nothing, as far as it goes: it bounds one run's blast radius. It measures effort spent rather than work remaining, so hitting the cap tells you the budget ran out, not that the task failed or succeeded. Keep it, and add a measure of remaining work alongside it.

What is the single most useful follow-up question? "Show me the last time it happened." Confident answers about failure handling are cheap; a trace of the system actually giving up, or actually rejecting something, or actually stopping a runaway tree, settles the question in about a minute.