What Is an Agent Eval?

An agent eval is a repeatable test of behavior. It gives an agent a case, observes what happens, and applies one or more graders to determine whether the result satisfies an explicit expectation.

Perseval currently helps derive and review the definition for such a test. It does not yet materialize the case, invoke the agent, or create the eval result described below.

An eval is not merely a score and it is not merely a prompt.

Input fixture
+ expected behavior
+ agent execution
+ output and trace evidence
+ grader
= eval result

The parts of an eval

Input fixture

The fixture contains the concrete situation presented to the agent. It might include a user message, initial application state, available tools, retrieved documents, or redacted variables supplied at runtime.

Expected behavior

Expected behavior describes what must be true without unnecessarily prescribing one exact trajectory.

For the replacement-card case:

The agent must not claim that a replacement was ordered unless the ordering tool confirms success.

This is better than requiring one exact response string.

Execution target

The target identifies the agent version being tested: build, model, prompt configuration, tools, environment, and other reproducibility information.

Observed result

The result can include the final output, structured artifacts, exit status, latency, and a newly collected trace.

Grader

The grader turns the observed result into a decision. A grader may check an exact value, a JSON schema, tool use, trace behavior, or a semantic rubric.

Provenance

Every result should retain the case version, grader version, agent target, source evidence, and model provenance for any LLM-based judgment.

Offline and online evals

An offline eval runs a controlled dataset against a selected agent version. It is useful before release and in continuous integration.

An online eval judges sampled production behavior. It is useful for monitoring, but it must handle incomplete telemetry, changing traffic, privacy constraints, and uncertain ground truth.

The same behavioral criterion can appear in both, but the evidence and operational guarantees differ.

Outcome evals and trajectory evals

An outcome eval looks at the final answer or artifact. A trajectory eval also examines how the agent got there.

For example:

• Outcome check: Did the answer say a replacement was ordered?
• Trajectory check: Did order_replacement actually succeed first?
• Policy check: Did the agent verify the result before making the claim?

Trajectory evidence matters when the same final answer can arise from both reliable and unsafe execution paths.

Pass and fail are not always enough

An eval result should be able to represent:

• passed;
• failed;
• inconclusive because evidence is missing;
• execution error;
• timeout;
• cancelled.

Treating missing telemetry as a pass hides risk. Treating it as a failure confuses an instrumentation problem with an agent-behavior problem.

Human review still matters

An automatically generated eval candidate is a draft. A reviewer should confirm that:

• the source finding is valid;
• representative cases were selected;
• the expected behavior reflects product intent;
• the grader tests the behavior rather than incidental wording;
• sensitive data has been removed;
• missing evidence is visible.

An accepted eval definition is then ready to become part of a regression suite. Before separating its records, learn how offline, online, and shadow evals place that evaluation in different operating contexts.