Foundations

What a Good Evaluator Agent Actually Does

A plain guide to evaluator agents: read the whole trace, apply the right standard, cite evidence, and return a useful verdict.

By Burak Ozafsar • June 30, 2026

Before you trust the eval, judge the judge: inner loop scores the agent and outer loop keeps the judge honest.

What a Good Evaluator Agent Actually Does

A judge prompt is not an evaluator. It is a question you ask a model.

A good evaluator agent is stricter than that. It reads what the agent did, checks the work against the right standard, cites the evidence, and returns a verdict that another person or system can act on.

That matters because agent failures rarely look like one bad final answer. The agent may use the wrong source, skip a required handoff, call a forbidden tool, guess when it should ask, or produce a correct answer for the wrong task. A one-number score hides those differences.

A useful evaluator makes the failure legible.

Figure 1: the evaluator reads the whole trace, not only the final answer. Figure 1: measure the run, not only the answer.

1. Measure the run, not only the answer.

Most eval setups start at the final answer. Sometimes that is enough. Often it is not.

An agent run has a path. The user request sets the goal. Search or retrieval brings in sources. Tools return data. The agent makes intermediate decisions. Then it stops, asks for help, refuses, escalates, or writes the final answer.

Two runs can produce the same final text for different reasons. One used the right source. One copied a stale source. One asked for approval. One skipped it. The answer alone will not show that.

The first job of an evaluator agent is simple: preserve the trace and inspect the path.

2. Judge against the right standard.

A support agent, a research workflow, a recruiting workflow, and an operations handoff should not be judged by the same checklist.

The standard must define what good looks like for that job. What outcome should the agent produce? What evidence should a reviewer see? Where should it ask for help? What would make the work unusable, even if the final answer sounds right?

Without that standard, the judge invents one. Then the team optimizes toward a hidden preference instead of the rule that actually matters.

Figure 2: the standard comes before the judge. Figure 2: define success before judging the work.

3. Turn real examples into checks.

Do not start with a generic rubric. Start with examples.

Put good runs, bad runs, and unclear runs next to each other. Ask what separates them. Did the good run cite the exact source? Did the bad run act before approval? Did the unclear run lack enough evidence to judge?

That contrast becomes a check.

A good check is small, visible, and fixable. “Be helpful” is not a check. “Ask for the account ID before changing billing” is a check. “Cite the retrieved policy before refusing the request” is a check.

Each check should answer four questions:

What behavior is being inspected?
Where is the evidence in the trace?
Can code check it, or does it need judgment?
What should happen if it fails?

Figure 3: real outcomes become one concrete check. Figure 3: examples are useful only when they become inspectable checks.

4. Use code before using a judge.

Some questions should never go to an LLM judge.

Did the JSON parse? Did the response include the required field? Did the cited URL exist in the retrieved sources? Did the agent call a forbidden tool? Did the handoff include the next step?

Code should answer those. It is faster, cheaper, and less ambiguous.

The judge is for the remaining questions: whether the answer matched the user’s intent, whether the evidence was used honestly, whether an escalation was appropriate, or whether a refusal was justified.

A judge should not be used to compensate for missing structure.

5. Make the verdict cite evidence.

A weak judge picks a verdict first and explains it after. That explanation can sound convincing even when the verdict is wrong.

A stronger evaluator forces the order:

find the relevant check
point to the evidence
write the critique
return pass, fail, or cannot tell

“Cannot tell” is important. It means the trace does not contain enough evidence, the check is unclear, or the evidence cannot be inspected. Without that option, the judge is pushed to fake certainty.

Figure 4: evidence comes before the verdict. Figure 4: no evidence path, no useful verdict.

6. Send the fix to the cause.

A failed check should not end with “improve the prompt.”

Sometimes the prompt is wrong. Sometimes the source data is missing. Sometimes the tool failed. Sometimes the task instruction is unclear. Sometimes the judge is being asked a question the trace cannot answer.

Those are different problems. Treating all of them as prompt problems creates churn.

The evaluator should name the failed check, show the evidence, and point to the likely cause. That is what makes the output useful.

Figure 5: a failed check points to the cause. Figure 5: fix the cause, not the score.

What to expect from a good evaluator agent.

A good evaluator agent should return:

the run it evaluated
the standard it used
the checks it applied
the evidence behind each verdict
which checks were handled by code
which checks needed a judge
what failed, what passed, and what could not be judged
the likely cause of each failure

That is the point: not a prettier score, not a louder judge, and not another agent doing the task again.

A good evaluator makes the measurement boundary explicit. It keeps the judge accountable to evidence. It turns vague failure into something specific enough to fix.

02Mutagent Use CaseEvaluate Builds the evals and a calibrated judge that scores every change, aligned to your domain expert before it gates anything. IN dataset · expert labels OUT calibrated judge · criteria