AI agent evaluation checks whether the output was actually right

Agent observability tells you what an AI model or agent did: it ran, it called a tool, it returned a response, it sent the email. That is worth having. When something errors out or a call times out, observability shows you where.

What it cannot tell you is whether the result was any good:

• the user got a response, but was the response correct?
• the agent sent the email, but was the email the right email?

“It ran and returned something” and “what it returned was right” are different questions. Observability answers the first. Checking the second is what evaluation is for, and it is the half that decides whether your customer got a good answer.

Evaluation measures the output against a standard you set

Evaluation is simple in shape. You query a model with a prompt, take the output it returns, and score that output against your own definition of a good answer. That definition takes one of two forms:

• a correct answer to match against (a gold standard), for questions with one right answer, or
• a set of named qualities to grade on, each with a weight (a rubric), for the many tasks with no single right answer.

A separate model, acting as a judge, reads the output and scores it against whichever you chose. A judge is just a model given one job, to compare an output to your standard and grade it, rather than write an answer of its own.

Scoring two models’ answers against a known-correct standard

Here is the whole idea in one real example. The task is a support question, and the catch is that the reference document the models are given to answer from is out of date. Everything the judge saw is shown below, in the order it saw it.

First, the context supplied with the question. This is the document the models answer from, and it still carries last year’s numbers.

Then the question itself, and separately the gold standard. The gold standard is the known-correct answer you hand to the evaluation as its grading target. It goes to the judge, not to the models, so the models never see the right answer, they only get the question and the context above. The current policy is a 4 business hour first response and 20 priority hours a month, which is what the gold standard records, while the supplied document still says 24 and 10.

Two strong models answered, and both reported exactly what the supplied document said.

Both answers are clean, clear, and faithful to the document they were given. Graded against the current policy, both scored 0 out of 100, where 100 is an answer that fully matches the correct facts.

Two different models, the same wrong answer, for the same reason.

The matching failure is the clue. Two different models, given the same document, produced the same wrong answer, which points at the one thing they shared rather than at either model.

The diagnosis names what caused the low score

A score of 0 on its own tells you the answer is wrong and nothing about why. When you also supply the context, the evaluation returns a diagnosis alongside the score, a short finding that names which input caused the low score and backs it with evidence.

Here is that finding, as the evaluation reported it.

It can point this precisely because of what you gave it. The judge has the correct answer in front of it (the 4 and 20 you set as the standard) and the model’s answer in front of it (24 and 10), so it can see they conflict, trace that conflict back to the supplied context the answer was copied from, and name the exact values to change. It is not divining the current policy on its own. It is comparing the answer against the standard you supplied and following the mismatch to its source.

The finding named the supplied context as the source, not the model. Its reasoning, word for word from the run, was that the answer matches the source material exactly, but that material holds values that conflict with the correct answer. Its suggested fix was to update the context, correcting the 24 and 10 to the 4 and 20 from the standard.

A low score can come from any of the inputs you control, not just the model:

• the context you supplied could hold stale, ambiguous, or incorrect information,
• the prompt or system prompt could point the model the wrong way,
• the parameters could be set poorly, or
• the model itself could be the weak part.

A bare score does not separate these, so you check each by hand. The diagnosis names the one that failed, so you go straight to it.

The same check works on an agent

Everything above queried a model directly, but an agent is also just an endpoint that returns output, so the same measurement applies without change. You send the agent a task, take what it returns, and score that against your standard.

The one requirement is that the thing you want to judge comes back as output you can read. Much of what an agent does qualifies, and the rest usually can with a small ask:

• a chat agent returns its reply, so you score the reply,
• an agent that takes an action can be asked to return a record of it, the email it drafted or a summary of what it did, so you score that record, and
• the only thing out of reach is an action with nothing returned about it at all.

So “did the agent send an email” is the observability question, and observability answers it well. “Was the email the right email” is the evaluation question, and you answer it by having the agent return the email and scoring it against what a correct one should say. For an agent that works through many steps, you can also check the whole workflow: see where it wasted time or credits, step by step.

From a measurement to a fix

A score and a diagnosis are data and analysis. They tell you what is wrong and where, which is exactly what you need to act. The same agent that ran the evaluation can take the next step, because it now has the one thing it was missing, a specific finding with a specific fix.

On this run, the diagnosis pointed at the context and named the exact change. So the agent proposed it, waited for a person to approve, applied it, and re-ran the same evaluation on the same two models.

With the corrected context, both models scored 100 out of 100, pipeline clean, no findings. The answers that were wrong are now right, and the thing that fixed them was a measurement precise enough to act on.

The same two models, before and after the one change the diagnosis named.

That is what agentic optimization is. Give an agent the right measurement and the insight that comes with it, and it can close the loop itself:

1. measure the output,
2. diagnose what caused a low score,
3. propose a fix,
4. check with you,
5. apply it, and
6. measure again,

until the whole pipeline clears your bar.