How to Test an AI Workflow Before Your Team Relies on It

A demo is an existence proof: this workflow can produce a good output under conditions chosen by the person demonstrating it. That is worth knowing and it tells you nothing about reliability.

Testing asks the opposite question. Not “can it succeed?” but “under what conditions does it fail, and are those conditions common?”

Pull cases from history by sampling, not by memory. Take the last fifteen real instances of the job rather than the three someone remembers as interesting, because memory selects for unusual and the workflow will mostly meet ordinary.

Aim for a distribution that matches reality: mostly typical, a meaningful minority messy, a couple genuinely hard.

Messy means incomplete, contradictory, or badly formatted — not broken. A transcript that cuts off mid-sentence, an update with no owner, a ticket where the customer describes two separate problems as one.

These are the cases that distinguish a workflow from a prompt, because handling them well requires explicit branches rather than general competence.

A few recur across almost every workflow: input in an unexpected language, a case where the correct answer is “there is nothing to report,” a hostile or emotional input, and one where the right action is to escalate rather than produce the deliverable.

That last one is the most commonly missed. Many workflows have no representation of “do not do the job” and will produce a confident artifact regardless.

The cheapest and most effective check. Does the output contain every required section, in order, every time — including the sections that are empty because there was nothing to report?

An empty risks section that says so is correct. A missing risks section is a defect, even when there genuinely were no risks, because the reviewer cannot tell the two apart.

Take five material claims from the output at random and try to find their source in the inputs. Any claim you cannot locate is either invention or an undocumented inference, and both need to be visible as such.

This check is what makes review fast in production, which is why it belongs in the test rather than in the reviewer’s good intentions.

Deliberately remove something from an input and see what happens. A workflow that fills the gap plausibly has just told you its most dangerous behaviour, and it will do so silently in production.

The correct behaviour is an explicit statement that the information was not available. This is the single highest-value rule in most workflows.

Tone is checkable if you specify violations rather than adjectives: no commitments the team has not made, no absolute guarantees, no blame directed at a named person, no internal shorthand in client-facing text.

Leave the rest to the reviewer. Over-specifying tone produces stilted output and does not prevent the failures that actually matter.

Score per check, not per run. “Passed structure and unknowns, failed evidence on two claims” tells you what to fix; “6/10” tells you nothing and invites arguing.

A run passes only if it passes every hard check. Soft observations go in notes and inform the next revision. Checks are only scorable if the skill file states them as binary conditions in the first place — the authoring pattern is in writing checks as binary conditions.

Four names cover most of it. Omission: something required is missing. Invention: a specific that appears nowhere in the inputs. Wrong source: a real fact taken from a stale or out-of-scope place. Wrong next step: a correct analysis followed by the wrong recommendation.

Wrong next step is the most under-tested because the body of the output reads well. It is also the one most likely to reach a customer. When one of these reaches production, the write-up is itself a repeatable job — see writing up an incident as a repeatable job.

Before launch, have two people deliberately try to get a bad output: paste in something irrelevant, ask it to be more confident, feed it an input that implies an urgent customer promise.

Your team will do all of this accidentally within a month. Better to see the behaviour on purpose first. Where the workflow processes text you did not write — tickets, transcripts, fetched pages — those cases become a standing part of the suite, as described in adversarial cases as a standing part of the suite.

Every guardrail deserves at least one case designed to violate it. If the rule is “never draft an external commitment,” the test is an input where a commitment is the obvious, helpful thing to write.

A guardrail that has never been tested against pressure is an assumption. The categories worth covering are in the guardrail categories worth writing.

Default to assisted: the workflow drafts, a person approves. Move a category to unsupervised only when you have enough logged runs in that category to know the failure rate and the cost of a miss.

Autonomy is earned per category, not per workflow. “Simple password-reset replies” can be autonomous long before “billing disputes” should be. For the assisted majority, the review step itself needs designing so it takes minutes rather than a rebuild — see human review design.

Anything that touches money, a contractual commitment, a customer relationship, or a public statement should require a named person to approve before it leaves.

This is not a temporary caution. For most teams it is the permanent design, and it is compatible with large time savings because drafting is where the time goes.

The same skill behaves differently depending on where it runs: file handling, context limits, connected data, and tool access all vary. A coding-adjacent tool can read a repository; a chat tool may only see what you paste.

Run the same test cases in each target environment. Identical instructions do not guarantee identical behaviour, as one skill, five tools covers.

Keep a folder of representative runs — good and bad — with a note on what each one shows. It is the fastest way to onboard a reviewer and the only way to have a grounded conversation about whether quality has shifted.

Three minutes of reading real examples beats a page of description.

Every change re-runs the whole suite. Fixing one behaviour by adding an instruction routinely breaks another, and without regression testing you will find out from a reviewer weeks later.

This is cheap if the cases are stored and the checks are written down, which is why both belong in the deliverable. Batching edits into a version rather than patching after every complaint is what keeps the suite meaningful — the cadence is in batching edits into a version.

Three passing runs is reasonable evidence for a low-stakes internal job with an attentive reviewer. It is not sufficient for anything customer-facing, financial, or irreversible.

Scale the evidence to the cost of a miss. The question is not “did it work?” but “how confident do I need to be before a person stops checking?” Once it is live, the suite stops being the only signal — what to track from real runs is in what to measure once the demo ends.

Add a case every time production surprises you. Over a year the suite becomes an encoded history of how this job actually goes wrong, which is far more valuable than the original ten cases.

It also makes the workflow transferable. A new owner can understand the constraints by reading the failures.

Before the team relies on it: the suite passes, the guardrails have adversarial cases, every target tool has been run against the same cases, the install guide exists, an owner is named, and reviewers know what to check.

Miss the last one and quality degrades without anyone noticing, which is the failure mode described in why a prompt library still breaks.

In a Grokkit engagement, testing is a stage rather than a final check. Cases come from the team’s own history, the checks come directly from the definition of done written during discovery, and the results are handed over with the skill.

You can see how the stages fit together on the custom workflows page, look at the case studies for how safeguards appear in finished workflows, or bring us a job you are not yet confident enough to rely on.