AI workflow evaluation should test whether a complete run reaches the correct destination state when tools, policies and handoffs fail. Component scores help diagnose problems; release decisions need scenario-level evidence for success, safe stopping, recovery and false completion.
Composite reference architecture. A reference evaluation system; no unnamed production deployment or pass rate is claimed.
The operating problem
Component benchmarks do not show whether retries, tool errors, policy gates and handoffs produce a safe end-to-end outcome.
How the workflow works
Version the scenario, expected outcome, allowed tools and risk class together. Use fixtures and sandboxed destinations to replay normal cases, historical exceptions and controlled faults. Define the oracle before the test: what evidence proves the task completed, and which blocked or partial states are acceptable? Compare the new workflow against the previous version on the same scenarios.
Where review and controls matter
Keep test dependencies isolated from live actions. Weak expected outcomes can reward a persuasive answer that failed the real task. Review evaluator disagreements and inspect severe failures directly rather than averaging them into a pass score. Domain owners approve high-risk scenarios and unresolved regressions before promotion; a stable model score cannot waive a failed policy or destination-state check.
Trace correlation reference: OpenTelemetry context propagation.
What to measure
Use a fixed cohort and measurement window. Count numerator events only within the denominator's eligible cohort; sampled measures use the same audit sample for both terms. Record the source, exclusions and owner, and keep missing data visible. These definitions are proposed measurement contracts, not observed results.
| Measure | Definition and unit |
|---|---|
| Scenario pass rate | Scenarios meeting all declared acceptance checks divided by executed scenarios; percent, split by risk class. |
| Policy violation rate | Runs containing a confirmed prohibited action or missed required gate divided by executed runs; percent. |
| False-completion rate | Runs claiming success without the required destination evidence divided by runs claiming success; percent. |
| Recovery success | Injected recoverable failures reaching a safe expected terminal state divided by injected recoverable failures; percent. |
| Latency | Time from run start to terminal state; median and p90 seconds, by scenario type. |
| Unit cost | Attributable run cost divided by completed evaluated runs; currency per run, with failed runs included in total cost. |
A useful first pilot
Evaluate one workflow through a tool error, unavailable reviewer, timeout after write and false-success response. Produce a release decision tied to the observed terminal state of each scenario.
Bring the workflow, its source records and the decision that needs an owner to a BergLabs pilot discussion.
