Laurie Voss: Building an Evaluation Loop for AI Agents

I am Laurie Voss, Head of Developer Relations at Arize AI. This workshop uses a deliberately imperfect financial-analysis agent to build an evaluation loop; its stock outputs are examples, not investment advice.

The TypeScript project includes checkpoints so participants can resume even if setup or a live run fails. It uses Phoenix for traces and Claude for the example, though the evaluation principles are broader.

An AI app may look good in a few trials and then fail on an unexpected input. A prompt change can fix one behavior and quietly break another. Evaluations help make those changes visible.

The goal is to trace the agent, write code and model-based checks, test the judge, compare changes and put selected regressions into CI. None of those steps makes a system infallible.

A trace records what happened: agent steps, model calls, tool inputs and outputs, timing and sometimes cost. A span is one step, and spans can be nested to represent a complete run.

An evaluation asks whether some aspect of that recorded behavior or output was good. Unlike an exact string assertion, it can account for multiple valid responses to a question.

Looking at three answers and saying they look good is not a test suite. A model can produce different wording each time, so exact-match tests alone often miss what matters.

A tone fix might accidentally introduce unsupported product claims. A repeatable set of evaluations helps detect regressions rather than relying on a customer to find them.

Code evaluators can check structured properties quickly: valid JSON, length or required fields. They are useful when the property can be stated deterministically, though the checks can be too rigid.

An LLM judge applies a rubric to questions about meaning, such as whether an answer follows its source. It costs time and money and can be confidently wrong, so it must itself be tested.

Domain experts can inspect subtle or unfamiliar failures and label examples to check the judge. Code, model and human checks complement one another rather than replacing one another.

Agents add complexity because an early error can cascade across tool calls and later reasoning. A polished report can still be about the wrong subject or rest on the wrong data.

Voss describes an example where an agent found an unexpected way around a benchmark's assumed path. The lesson is to specify the desired outcome clearly and examine whether a test wrongly rejects a valid solution.

An evaluation typically returns a score and label; an LLM judge may also provide an explanation. Explanations are useful for finding recurring failure patterns, but should be checked rather than treated as proof.

The loop is trace, read, evaluate, check the evaluators, change the agent, compare and preserve useful checks. Voss treats this as an iterative process rather than a single benchmark score.

Phoenix collects traces and stores evaluations alongside them. The example can run locally, and teams can choose a deployment appropriate to their own data and access requirements.

The workshop project separates instrumentation, agent logic, prompts, evaluation functions and test queries. The example agent first researches a ticker and then writes a report using that research.

Voss shows tracing setup using OpenTelemetry-based instrumentation. Depending on the framework and configuration, instrumentation may capture nested model and tool calls without a hand-written log statement for each step.

A TypeScript-specific detail in her example is to use the instrumented copy returned by the helper. Importing the original module instead can leave the app running without the expected traces.

The example agent has web search and runs without interactive permission prompts. The setup isolates it from the presenter's local agent configuration so that the demonstration is more reproducible.

A session ID connects the research turn to the report-writing turn. A parent span groups both turns, letting the reader follow the complete sequence in one trace.

The initial prompts are intentionally sparse. Different participants can change them and compare how ambiguity affects the agent's choices.

In the live example, the agent chooses its own search terms and number of searches before writing. Different runs can take different paths even with the same input.

One run tries to save a file and asks for permission despite being unattended. The prompt said to write a report without stating where to put it, and the trace reveals the failed tool call.

The trace shows the research and writing spans, web searches and the failed write. This makes it possible to distinguish an ambiguous instruction from a model or tool failure.

Voss asks participants to run a batch of varied queries rather than draw conclusions from one example. The seed data provides a fallback when the live batch cannot finish.

The test set includes comparisons, colloquial questions and a fabricated ticker. The fake ticker checks whether the agent admits that it cannot identify the company instead of inventing one.

Before grading, define what a good report means with product and domain stakeholders. In this exercise, the desired properties include the right company, current evidence and a clear conclusion.

Synthetic queries can seed a test set, but a person should inspect them because generated examples may miss how real users behave. Once available, carefully handled real traffic can add valuable cases.

Read a sample of traces end to end before automating evaluation. If you automate before understanding failures, you risk measuring what is easy instead of what matters.

A coding agent can help group a larger collection of traces, but manual sampling remains valuable because the helper may overlook or misclassify failures.

The fictional ticker is correctly identified as invalid in one run. Other runs produce vague recommendations or try to write files without permission, illustrating different kinds of failure.

One Tesla example combines percentages from different search results into a total of about 116%. The error illustrates how a fluent report can merge incompatible data; the figures are erroneous example output.

Voss distinguishes bad retrieval, faulty reasoning, invented facts and answering the wrong question. The visible wrong answer is a symptom; the cause determines what to fix.

She recommends writing observations in plain language first, then grouping them into categories. Deciding the categories too early can hide failure modes the team did not anticipate.

No evaluation catches every failure. Layer code checks, model judges and human review so their different blind spots are less likely to overlap, while still testing each layer.

Prioritize failures using both frequency and severity. A rare but serious failure can deserve attention before a common cosmetic issue.

The first code evaluator checks whether the requested ticker appears in the report. Structured input makes it easy to extract the requested tickers and return a label, score and missing items.

The check runs quickly without another model call and finds some reports that missed the requested subject. Mentioning a ticker is necessary in this exercise but does not prove the report is accurate.

Code evaluators can also inspect database state, tool results or an external reference. Choose checks that fit the desired outcome; exact tool order may be unnecessarily restrictive unless the path itself matters.

An LLM judge consists of a model, a rubric and the data to grade. Built-in evaluators can cover categories such as correctness, faithfulness or tool use, but their suitability still needs testing.

Voss uses a different model for judging and discusses model-family preference as a possible bias. A stronger or different judge is not automatically correct; compare it with human labels.

The built-in correctness evaluator marks all sixteen reports wrong in her sample. Its explanations reveal that the judge lacks the newer market data needed to verify some of the claims.

Some explanations also identify real arithmetic or date problems. A blanket zero therefore mixes genuine errors with an evaluator that cannot answer the question; the score alone is not informative.

Faithfulness asks a narrower question: given the source material, does the report stay grounded in it? Voss supplies both search results and research notes to give the judge the relevant context.

The judge flags unsupported or conflated claims in the sample. Faithfulness to supplied material is useful, but it does not prove that the source material itself is true.

Tool evaluations can assess selection, arguments and use of results. To judge selection, the evaluator needs to know which tools were available, not just which tool was called.

The tool judge sometimes accepts saving a file because the original instruction said to write a report without specifying the destination. Agent instructions and evaluation criteria must be considered together.

Voss concludes that asking the right question matters more than tuning an evaluator that measures the wrong thing. She then builds a custom actionability judge for this specific exercise.

Her rubric gives the judge context and explicit criteria, such as a concrete recommendation, supporting risks and forward-looking reasoning. These are workshop criteria, not a formula for sound investment advice.

She marks inputs, outputs and examples clearly so the judge can distinguish data from instructions. Such boundaries can reduce confusion but are not a complete defense against prompt injection.

Examples may clarify a rubric or cause overfitting. Voss compares versions with and without examples rather than assuming that more examples always help.

In one borderline case, her human label accepted a recommendation without a risk section while the judge interpreted the rubric more strictly. The disagreement exposed ambiguity in both the rubric and her labeling.

The judge's possible labels are constrained to actionable or not actionable in this example. Structured output makes results easier to process but does not make the judgment reliable on its own.

Five of sixteen sample reports meet her actionability check. The split gives her examples of both passes and failures to inspect, rather than demonstrating production performance.

Evaluation prompts are sensitive to wording and formatting. Version them, test changes and keep separate evaluators for distinct dimensions instead of combining every criterion into one opaque judge.

A guardrail is a condition that may block release; a target can track improvement without necessarily blocking it. Teams should decide which is which based on their own product and risks.

To test a judge, treat it as a classifier and compare its labels with expert-labeled examples. Human labels are the best available reference for this exercise, but they can also be inconsistent.

Voss labels sixteen reports and calls this a golden dataset. She stresses applying the same criteria as the judge and avoiding fatigue; fewer carefully labeled cases can be more useful than many careless ones.

Add difficult cases as they appear, and check both when an action is needed and when it is not. Otherwise an evaluator can reward an agent for performing the same action every time.

Keep separate development and held-out test examples. Her sixteen-case demonstration leaves only four test examples, far too few for a strong production claim.

The meta-evaluation runs the judge on labeled examples and uses a code check to compare its label with the human's. Agreement on twelve development examples is only an initial signal, not proof of general reliability.

A rubric change intended to remove ambiguity reduces agreement in her small example. This illustrates why evaluators themselves need versioning, tests and a held-out set.

Precision asks how often a flagged failure is truly a failure; recall asks how many real failures were flagged. Their relative importance depends on the cost of missed failures and false alarms.

Judges can exhibit position, length, confidence and self-preference biases. Swap candidate order, inspect errors and compare against human judgments rather than assuming the judge is neutral.

Human reviewers can disagree too. A disagreement is a reason to examine the rubric and case, not an automatic proof that either the person or model is right.

An experiment compares changes using the same inputs and evaluators. Voss creates a dataset of failures for focused development and keeps passing cases to check for regressions.

She changes the prompt in response to observed failures: ask for a clear recommendation, connect risks to evidence, use sourced numbers and return the report instead of attempting an unauthorized file write.

The experiment consists of a dataset, a task and evaluators. Phoenix runs the task on examples and stores results so versions can be compared.

Small sets can give a rough development signal, but larger and representative samples are needed for stronger conclusions. Repeated runs matter because model behavior varies.

Voss distinguishes pass@k, at least one success in k attempts, from pass^k, success on every attempt. The useful measure depends on whether retries are acceptable and what a failure costs.

She recommends examining data quality before prompts and model choice. The best order can differ by application, but unreliable inputs limit what later tuning can accomplish.

In her sample, the changed prompt improved ticker and actionability checks, but faithfulness remained poor: three passes out of 48 after the change. The demo does not show a reliable financial analyst.

A capability evaluation measures a behavior the system is trying to improve. Once a check passes reliably enough, it can become a regression check to detect future degradation.

She compares an updated model on the same task. In her limited runs, faithfulness improved but remained poor, and cost increased; the figures describe that particular setup.

Consistency also improved partly because the newer model repeatedly chose the same recommendation. A metric can improve for an undesirable reason, so inspect individual outputs and failure explanations.

The value is in the cycle: run evaluations, read failures, identify a pattern, change data, tools or prompts, and compare again. No single score replaces that investigation.

For CI, the example uses a test runner with a hard ticker check and an average actionability threshold. The thresholds are choices for the example and should not be adopted without considering real risks.

A failed build reports which acceptance criterion was missed and why. The same suite can run in CI, while cost and latency determine how often the full agent evaluation is practical.

Voss recommends continuing evaluation on an appropriately handled sample of real traffic after deployment and watching sustained changes rather than alerting on every isolated failure.

Start small: instrument the application and read a dozen traces. Then turn observed problems into targeted checks, validate those checks and expand the loop over time.