Before You Improve An AI Workflow, Build The Set You Test It Against

A workflow has been running for a few months. Someone notices the summaries are drifting, or a newer model gets released, or a vendor deprecates the exact version in use. A change gets made on a Friday afternoon, checked against three or four examples pasted into a chat window, and shipped. A week later the complaint arrives: it used to handle these fine, and now it does not.

Nobody can say exactly what broke, because nothing recorded what “fine” looked like. This is the most common way an AI workflow degrades — not through a dramatic failure, but through a series of small edits nobody could measure.

The fix is not more careful prompting. It is a fixed, scored set of examples you run every change against, built once, early, while the workflow is still simple.

The change that quietly makes things worse

Every AI workflow has two kinds of changes: those that add capability and those that adjust behaviour. Capability changes are easy to reason about — the agent now also reads the invoice table. Behaviour changes are the dangerous ones. Reordering two instructions, tightening a description, switching tool names, upgrading the model, changing the retrieval cut-off. Each looks like an improvement in isolation.

With ordinary software, a test suite catches the regression. With an LLM in the loop, there is no compiler and no assertion unless you write one. The output is still fluent, still confident, still plausible — which is exactly why a regression slips through review. Plausible wrong output reads identically to plausible right output until someone who knows the domain looks at a specific case.

Fifty examples beat a vibe check

The regression set is small, boring, and the highest-leverage artefact in the project. It is real inputs, the expected outcome, one command to run them, and a pass/fail count.

Fifty examples is usually enough to be useful and small enough that two people can maintain it. You are not trying to prove correctness statistically. You are trying to catch directional change: did this edit break the cases we already solved?

What goes in it:

• The ordinary cases. Twenty to thirty examples of the workflow doing exactly what it is for, drawn from real traffic, not written by hand. Handwritten examples are cleaner than reality and hide the failure modes you actually have.
• The edge cases you already know about. The customer with two accounts. The invoice with a credit note. The ticket where the attachment matters more than the body. These are the ones a change breaks first.
• The correct refusals. Cases where the right answer is “I cannot determine this” or escalation to a person. Without these in the set, every change nudges the system toward confident guessing, and no test objects.
• The near-misses. Inputs that look like a normal case but must not be treated as one — the internal test account that should never receive a customer email, the draft record with no date. These encode your safety rules as data.

A set built only from successful production output will pass forever and prove nothing. The value is concentrated in the awkward fifth of it.

Score the outcome, not the wording

The most common reason regression sets get abandoned is that they compare text. A model rephrases, the string comparison fails, someone concludes the test is broken, and the file stops being run.

Score the decision, not the sentence. For a classification or routing workflow, that is the label and the destination. For an extraction workflow, that is the fields and whether the critical ones are right. For a drafting workflow, it is a short rubric applied by a person or a second model: does it cite the right record, does it include the required element, is anything invented. Where the output is genuinely free text, score specific properties, not the whole string.

Two things worth recording on every run, beyond pass and fail:

• A per-example score, not just a total. A change that breaks three specific cases and fixes six others has a different risk profile than a flat trade. Totals hide that.
• The cost and latency of the run. An edit that improves quality by two points and doubles the tokens per task is a decision, not an improvement. Keep it visible in the same report so it is argued on its merits.

Where the set pays for itself

Three moments make the investment obvious, and all three arrive whether or not you planned for them.

Model deprecation. Vendors retire versions on their own schedule. When a pinned model stops being available, the change is not optional, and without a regression set you are shipping a new model blind across every workflow at once. With one, you know within an hour whether the replacement behaves the same on the work you care about.

The upgrade that is not an upgrade. Newer models sometimes get worse at very specific things — following a rigid output format, respecting a narrow instruction, refusing when it should. The regression set turns “the new one feels better” into a number, and saves you from a rollout that quietly breaks the strictest workflow in the building.

The accumulation of good ideas. Every month, someone suggests a small improvement. Each is defensible. A year of defensible improvements with no measurement is how a workflow that was reliable in March becomes unreliable in November while every individual change was approved. This is the same discipline as the four numbers, moved one step earlier: measure before the change, not only after it ships.

Keep it alive, or it is dead

A regression set decays the moment it stops reflecting production. Two habits keep it honest: add an example every time someone reports a real failure — the report is free labelled data and the most valuable example you will get that month — and review the set quarterly for cases that no longer occur, because a set full of retired scenarios gives false confidence and slows every run.

Run it on every change, including the small ones — the Friday-afternoon edit is the one that needs the check most, and it is the one a discipline that allows exceptions will skip.

Build it before you need it

The awkward truth is that a regression set is cheapest to build at the beginning, when there are twenty examples in production and the workflow is still a draft. It is most valuable a year later, when the system is load-bearing and nobody remembers what the original behaviour was. Teams that skip it are not saving work; they are deferring it to the day they can least afford it.

Practically, that means the first two weeks of a build should include a fixed set of scored examples, a single command that runs them, and a report someone can read in a minute. That belongs in scope, not in a later phase. If you are scoping that work now, our services page describes how we structure it.

Improving an AI workflow you cannot re-test is not improvement. It is a confident edit and a hope.