The Future of Evals: From LLM as a Judge to Agent as a Judge — Aparna Dhinakaran, Arize AI

How do you know whether an agent is working once real users start interacting with it? Pre-release tests provide one view; production traces provide another, exposing what the agent actually did. Aparna Dhinakaran, Arize AI’s cofounder, draws on teams evaluating both agents under development and agents already serving users.

Dhinakaran reports that Arize runs over 100 million evaluations per month, with the average team running about 12 evaluation jobs and top teams running over 3,800 evaluators. These are reported operational figures; the talk does not specify the reporting window, team population or counting definitions.

Offline and online evaluations each have a place. The focus here is evaluation over traces: using recorded agent behavior to identify what works, catch failures and supply evidence for continual learning loops.

Dhinakaran invokes enthusiasm for evaluations from leaders associated with Anthropic and OpenAI, along with Greg Brockman and Gary Tan. But that consensus leaves a practical question unanswered: does adding evaluations mean you now catch every failure?

While teams were building their first generation of evaluations, the systems being evaluated changed underneath them. Dhinakaran frames the progression as three stages:

This is her framing of the capability shift, rather than a precise chronology of individual model releases.

Each stage adds more than complexity. It changes the kinds of failure an evaluator must recognize. An answer can be assessed as an output; an agent also has a trajectory—the sequence of actions through which it attempts a task. As that sequence becomes longer and more variable, failures can arise in the process itself.

Arize encountered this shift in Alyx, its agent embedded in the product UI. As frontier labs introduced new functionality, the team incorporated it. Alyx gained longer memory, the ability to create dynamic interfaces and search across an enormous volume of traces. Yet it still forgot context, failed to recognize when a task was done and sometimes became stuck in loops.

These failures exposed gaps in Arize’s classical LLM-as-a-Judge evaluations. A rubric that covered an expected behavior did not necessarily catch every failure the expanded agent could exhibit. The accompanying slide broadens the picture with failure categories including model–harness fit and false completion, beside an Alyx trace interface.

The departure from a deterministic flow was especially visible in the UI: each user interaction could produce a new interface and a different trajectory. The evaluator therefore had to account for behavior that varied with the task and interaction. That led to the central proposal: evaluate an agent with another agent, capable of adapting its analysis to the path taken.

Agent judging adds another evaluation tool; deterministic checks and classical LLM judges retain their roles. The slide maps the three methods to different failure types:

The useful distinction is what each evaluation method can investigate and how it performs that investigation.

Dhinakaran contrasts a classical judge applying a predefined rubric and returning fixed scores with Agent-as-a-Judge performing adaptive, dynamic analysis. When user inputs lead to different trajectories, the investigation can vary with the behavior encountered. This is a comparison of evaluation workflows, not a claim that an LLM judge is inherently unable to inspect a trajectory.

Her expectation is that teams will combine all three methods. Most teams, in her account, already use the first two; agent judging extends their coverage to failures that require a more adaptive investigation.

Dhinakaran announces Arize’s release of Agent-as-a-Judge and introduces Signal as a long-running agent that reads submitted traces and discovers patterns of issues. The aim is to find problems beyond those anticipated by a predefined judging rubric.

She reports that Signal helped uncover subtle failures: loops that continued repeatedly, prolonged calls to the same tool and inefficient trajectories. These are properties of an execution path. Recognizing them requires examining how the agent progressed through its work, including where it repeated actions without useful progress.

The accumulated analysis can then support a proposed repair. Dhinakaran says the agent can open a pull request with a fix, connecting failure discovery to a concrete change for review. The dashboard makes that handoff visible through its detected issues and the selected issue’s Overview, Evidence and Proposed fix headings. A proposed fix is the endpoint shown here; no completed merge or deployment is demonstrated.