An LLM call doesn’t always return the same output twice, so you can’t assert on specific outputs like in traditional software testing. As a follow up to the canvas prototype, here are some thoughts on what testing a single step might look like.

The concept

You can test deterministic steps such as a tool call or a trigger firing the way you’d test any function: run it, assert the output matches exactly. LLM steps are probabilistic, so the assertion has to change shape too: does the output contain the right information, does it match a schema, is it semantically correct?

That’s the core idea for a test bench: each step type gets assertion types that fit whether its output is deterministic or probabilistic. Anthropic’s Demystifying evals for AI agents calls these two families code-based graders (exact match, regex, schema checks — fast and reproducible, but brittle to valid variation) and model-based graders (an LLM or human judging against a rubric). Equals, Contains, and Has JSON keys below are code-based graders; Semantic match is a rough stand-in for a model-based one.

The bench

Pick a step type below, edit its mocked output, then run the assertions against it. LLM Call is the only type with a “Semantic match” option — a real system would use an AI model to judge meaning; this demo just checks for overlapping keywords as a rough stand-in.

Sampling across runs

A single mocked output can’t show how an assertion holds up, because that’s not how LLM steps behave — the wording changes every time. Below are three plausible responses to the same request. Edit an assertion once and run it against all three at the same time.

This is a small version of what evals literature calls pass^k versus pass@k: pass^k requires every sample in the batch to pass (what the per-row count below is measuring), while pass@k only requires at least one to. Which one matters depends on whether the step needs to be consistently right or just capable of being right.