You replayed yesterday's failed request. Did you test yesterday's situation?

Imagine a customer asking whether their refund has been sent. The payment service still shows it as awaiting processing, but the assistant replies that it has been issued. The customer checks their account and contacts support again.

The team changes the assistant’s instructions and reruns the message the next day. This time, “issued” agrees with the payment record: a colleague has processed the refund in the meantime. That successful-looking answer does not show whether the assistant would still give premature confirmation on a pending refund.

The same message now describes a different situation.

The distinction matters whenever an agent reads changing business systems. A saved prompt is only part of a useful test case. The records and tool responses available at the time can determine what the agent should do.

Reconstruct the decision point

Begin by identifying the behaviour you are trying to reproduce.

Was the assistant supposed to explain the current refund status, request an authorised decision or perform an approved action? Those are different tests. “Give a better answer” is too vague to establish whether a repair worked.

For the chosen decision point, preserve the relevant input and the evidence the system actually saw. That may include the order state, the tool response, applicable policy version and the actions already attempted. Keep only what is necessary, with appropriate access controls and retention. A test collection should not become an uncontrolled copy of customer records.

Record what is missing. If the original tool response was never captured, do not describe a later reconstruction as an exact replay. It may still be a useful approximate test, provided its limits are explicit.

Tenex's guide to eval-driven development makes this practical distinction: evaluating the final answer alone can miss the steps and tool calls that produced it. It also notes the difficulty of replaying cases when external state has changed. That is the part of evaluation this article concentrates on.

Write the expected behaviour before trying the repair

For the pending refund, the expected result might be to report its actual state and avoid initiating a second refund. The precise expectation must come from the company's process and the authority assigned to the agent.

Describe acceptable actions as well as acceptable words. A friendly explanation is not a passing result if the assistant also performs an unauthorised write. Conversely, an appropriately refused action may be correct even if the test expected a cheerful confirmation.

Include uncertainty. If the destination system timed out after a request, the correct next step may be to reconcile whether the action happened. A test that demands an immediate yes or no can reward invented certainty.

Have the process owner review the expected outcome. Otherwise the test can faithfully enforce the implementer's misunderstanding.

Freeze the parts that should stay comparable

Build a controlled version of the case using the relevant historical state. The goal is to let the old and proposed versions encounter equivalent evidence.

Record the agent configuration, instructions and tool definitions used in each run. Where a model service changes outside your control, record the identifier and date available rather than claiming perfect reproducibility.

Keep the test input separate from the proposed answer. If the assistant receives the expected resolution as part of its source material, the result tells you little about its ability to handle the original problem.

There is a balance here. A small, understandable case can reveal a specific regression. An elaborate simulation that nobody can inspect may conceal assumptions of its own. Preserve enough of the original sequence to test the behaviour, and state what the simulation leaves out.

Make sure the replay cannot perform the real action

Do not replay a refund, shipment release or customer message against production write permissions merely to see what the agent does.

Use a test environment or controlled tool substitutes that record proposed actions without executing them externally. The boundary should be enforced by the environment and credentials, not just by an instruction telling the model that this is a test.

Check the substitutes as well. If they always report success, they cannot test how the agent handles a rejected action or uncertain result. Include the relevant failure response deliberately.

A simulated tool call is evidence of what the agent attempted in that setup. It does not prove that the production integration works. Integration testing remains a separate task, with its own safe scope.

Compare the sequence, not just the last paragraph

Inspect which records the agent consulted, which action it proposed and how it handled missing information.

In the refund example, a version that reads the correct state before answering is different from one that guesses correctly without checking. They may produce similar final text on this case and behave differently on the next one.

Repeat enough runs to understand whether the result is stable for the intended use. There is no universal run count that certifies every workflow. A single successful response from a variable system is weak evidence of dependable behaviour.

Keep nearby cases in the comparison. A change that fixes a pending refund might break a case that was already completed, cancelled or awaiting approval. Choose the neighbouring states that matter to the process rather than adding a large pile of unrelated questions.

Keep a useful failure, not an endless archive

When a real incident teaches the team something, turn it into a maintained test case with a clear purpose. Record the failure it protects against and the owner who can update its expected result when policy changes.

Retire or revise cases that no longer describe the service. Otherwise the test collection can reward obsolete behaviour as confidently as an outdated manual.

This work complements testing a workflow when models improve. The narrower question here is whether the before-and-after comparison is actually fair. Yesterday's text, today's database and a successful-looking answer do not establish that yesterday's failure has been fixed.

Bring one failed case to a Strategy Session. Include what the system saw and what happened, with sensitive information removed. If parts of that evidence are missing, identifying those gaps is a useful place to begin.