AI Agent Evaluation: There Was No Answer Key. So the Agent Marked Its Own Work.

The first coding job I handed to an agent came back the way every coding job comes back: a file with a few hundred open ended answers, one code per row, and no way to tell whether it was right. There was no marked up version to compare against, because if one had existed nobody would have needed the agent. So I did what every analyst I have ever supervised does with a junior coder's file. I opened it, read the first twenty rows, fixed what looked wrong, and moved on. Nobody wrote down how many rows I read or what I found.

That is the ordinary shape of AI agent evaluation in a research operation, and after twenty years of watching quality control happen by habit, I can tell you it is the step with no owner on the plan.

What evaluating an agent means in a research operation

Agent evaluation is the work of deciding whether an automated step produced output a senior researcher would sign: coded verbatims, a tested questionnaire script, a drafted report section, anything an agent hands back as done.

A gold standard is a set of cases where the right answer is already known, so a score can be worked out by comparison. Most research tasks do not have one. The codeframe is argued about, two good coders disagree, the tabulation plan changes after the client sees the first run. With no answer key you cannot compute accuracy, so evaluation becomes a design question: who checks what, against which reference, on how many cases.

How teams check an agent's output today

Answer first: somebody opens the first few rows and reads.

The agent returns a file. The analyst opens it, reads the first twenty or thirty cases, and fixes anything obviously wrong by hand. If nothing looks wrong, the file passes as good. Nobody writes down how many cases were checked, or what was found.

That last part hurts later. The client asks how the coding was checked, and the honest answer is that somebody looked. Looking is not a method anyone can repeat. The second version is worse: the agent is asked to check itself, reports that the work is solid, and is believed because the report arrived fast and in whole sentences.

The step that nobody owns

A study of multi-agent failures from Berkeley and coauthors read more than 1,600 execution traces across 7 frameworks. It sorted what went wrong into 14 failure modes in 3 families, with agreement between the people doing that sorting at a kappa of 0.88. One of the three families is task verification, and that is the one I keep meeting.

My reading is that the failures are mostly not the model being wrong about the world. They are chains where nothing checked the previous link.

In the operations I sit in, the check lives in conversation and never lands on the plan. Every other stage has a name next to it. This one has a habit, and habits do not survive an audit.

Why the agent cannot mark its own work

Answer first: because it likes what it produced.

Anthropic reports, from its own observation, that agents rate their own output well even when quality is poor. That is a maker reporting on its own agents, with no sample published, so read it as a warning from inside rather than an independent measurement. It is still enough to rule out self assessment as the last check. It does not rule out agents reviewing. The problem is reviewing yourself, which is just as true of people.

The same team names a second trap. In one measurement of agents working in parallel, 18 of 30 agents on the same model produced the identical branch name. That is one measurement, on one narrow output, so it gives a direction and not a general rate of agreement between copies. The direction is enough. Low variance is the point of a good model, and it is what makes copies useless as a second opinion. Consensus counts only when the things agreeing were built apart. I think that is the whole test.

The route an evaluated agent actually takes

The route has four properties, and each fixes a failure you can name back.

1. Generate with one model, judge with another, from a different maker. This is the part that stops a model rewarding its own house style.
2. Split the cases into agreed and disagreed instead of producing one aggregate score. A single number tells nobody which rows to open.
3. Give the human the full disagreement queue plus a random sample of the agreed pile. The sample is the only part that catches an error both models made, and those are the ones that reach the client.
4. Write the result of the check somewhere the agent cannot rewrite. Skip it and the answer to how the coding was checked is somebody's memory of a session that has since been compacted.

Point four is not decoration. Anthropic's engineering material argues that a durable record has to live outside the execution loop, since compacting context is a one way decision. A chat history is not something you hand a client at an audit. I have tried.

Using a model as a judge, and what that costs

Answer first: it works, it has literature behind it, and it needs calibration before anyone trusts it.

A judge model is a second model asked to score or check what a first model produced. The practice was measured rather than assumed in the work behind MT-Bench and Chatbot Arena, which scored model answers to questions rather than coded verbatims, so the move onto a research deliverable is ours to defend. One rule comes out of it: the judge should come from a different maker than the generator, so it does not reward its own house style. That removes self preference. Every other bias stays put.

Calibration is the part teams skip, and I have skipped it. Getting a judge to where its verdict means something takes roughly 200 to 500 cases labelled by a person, and the running check samples 1 to 10 percent of what went through. Those are practice ranges rather than constants, because a task whose answers vary a lot needs more, and three hundred open ended answers vary a lot. Evaluation is a project item, and uncosted, it is not done.

Agreement between makers, read carefully

Agreement between separately trained families has been measured as a calibrated signal rather than a show of hands. Work presented at MLCAD 2026 reports 94.7 percent precision at 27 percent coverage with four families, and 87 percent at 33 percent with three, across 78 tasks. Coverage here is the share of cases the setup will rule on at all. The rest go to a person.

That is a real result with a hard edge, measured on hardware tasks where a formal checker decided correctness, which is a setting nothing in qualitative research resembles. I think what carries over is the shape of the trade rather than the percentages: supervising each step beats supervising only the final answer.

Newer work adds a second edge. Models from different makers share many of their errors: across more than 350 models, two that got the same item wrong gave the same wrong answer 60 percent of the time on one leaderboard dataset, per Correlated Errors in Large Language Models. A panel of nine frontier models from seven families carried about two independent votes’ worth of information, per Nine Judges, Two Effective Votes. The judge from another maker still removes self preference. It does not stand in for independence, which is why a person reads a sample of the cases the models agreed on.

What still has no published evidence

On questionnaire testing there is no literature to cite. We would rather say that than dress up a vendor page as a finding. I scanned GreenBook, ESOMAR, Quirk's and Research Live on 2 September 2026, and nothing came back with a declared base on automated testing of an already programmed questionnaire. What the market shows is assistants that help write them, which is a different problem. Writing one is not checking one.

• Agent output feeds a client deliverable. Do this: Judge from another maker, then human queue. Because: Self review rates mediocre work well.
• You want a single accuracy number. Do this: Report agreement and coverage instead. Because: There is no answer key to compute accuracy against.
• Budget is tight and evaluation looks optional. Do this: Cost the calibration sample explicitly. Because: Uncosted evaluation is uncompleted evaluation.
• Redundancy through several agents voting. Do this: Do not count the votes as checks; keep a human reference sample. Because: Copies agree by construction, and other makers share many errors too.
• Regulated or legal submission. Do this: Full human read, agent as first pass only. Because: Traceability outranks throughput.