AI Agent Evaluation Without an Answer Key

AI agent evaluation in research has no gold standard to score against. What the failure taxonomy shows, and how a judge from another maker is calibrated.

An agent reads three hundred open ended answers and puts a code on each one. Somebody now has to say whether it did that correctly. There is no marked up version to compare against, and none was ever made. If one existed, nobody would have needed the agent. That is the ordinary shape of AI agent evaluation, and it is the step with no owner on the plan.

Key Takeaways

  • A study of more than 1,600 execution traces across 7 frameworks sorted multi-agent failures into 14 modes and 3 families, with annotator agreement measured at a kappa of 0.88. One of the three families is task verification.
  • Anthropic reports that agents rate their own output well even when the quality is mediocre, so self review does not replace an outside read.
  • In one Anthropic measurement, 18 of 30 agents running on the same model produced the identical branch name. Copies of a model are not independent opinions.
  • Using a model to judge another model's output is documented practice, and the standing recommendation is that the judge come from a different maker than the generator. That removes self preference, not shared errors: models from different makers often get the same items wrong in the same way.
  • Calibrating a judge against human judgment takes a sample size in the range of 200 to 500 labelled cases, and production keeps sampling 1 to 10 percent of what runs.

What evaluating an agent means in a research operation

PERSONAL EXPERIENCE Agent evaluation is the work of deciding whether an automated step produced output a senior researcher would sign. It covers coded verbatims, a tested questionnaire script, a drafted report section, anything an agent hands back as done. I have watched that decision get made standing at somebody's desk, by whoever was nearest the screen, on a file of three hundred rows nobody had time to open twice. Nobody wrote down what was checked.

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. That is normal, and it is also the problem.

That absence is the whole difficulty, because with no answer key you cannot compute accuracy. Evaluation stops being a calculation and becomes a design question: who checks what, against which reference, on how many cases.

How teams check an agent's output today

PERSONAL EXPERIENCE Answer first: somebody opens the first few rows and reads. That is the whole method.

  1. The agent finishes and returns a file.
  2. The analyst opens it and reads the first twenty or thirty cases.
  3. Anything obviously wrong gets fixed by hand.
  4. If nothing looks wrong, the file is passed on as good.
  5. Nobody writes down how many cases were checked, or what was found.

Step five 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.

There is a second version, and it 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

The verification step is missing from most arrangements, and there is now published work saying so.

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, grouped in 3 families, with agreement between the people doing that sorting at a kappa of 0.88, which is high for coding work. One of the three families is task verification. That is the one I keep meeting.

Read that in research terms. 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. The study carries a date, so it describes those frameworks then and not the ones running now.

PERSONAL EXPERIENCE 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. It always does.

Anthropic reports, from its own observation, that agents rate their own output well even when quality is poor. Take the limit with it. This is a maker describing its own agents, with no sample published, so it lands as a warning from inside and not as 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 you 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 of it useless as a second opinion. They agree because they are the same thing.

This is the working half of the argument in [one model, one blind spot](/blog/single-model-bias-market-research). Consensus counts as evidence only when the things agreeing were built apart. I think that is the whole test.

The route an evaluated agent actually takes

Where the check sits when there is no answer key

A flow in five stages, read left to right and then down. Stage one, the generator: an agent from one maker codes the three hundred open ended answers. Stage two, the judge: a second model from a different maker reads each coded case against the codeframe and marks agree or disagree, never seeing that it was the first model's work. Stage three, the split: cases where the two agree go to the accepted pile, and cases where they disagree go to a review queue. Stage four, the human: a senior researcher reads the whole disagreement queue plus a random sample of between one and ten percent of the agreed cases, which is what catches the errors both models share. Stage five, the record: what was checked, by whom, on which date and with what result is written outside the agent's own session, because a conversation history is not an audit trail. A note at the bottom says the calibration that makes this work needs a sample size of roughly two hundred to five hundred cases labelled by a human before the judge is trusted at all.

The judge exists to make the human queue small enough to read. Removing the human is not a later phase of this design.

The route has four properties worth naming, and each one 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, which is what self review does.
  2. Split the cases into agreed and disagreed instead of producing one aggregate score. A single number tells nobody which rows to open, and opening rows is the only work that changes anything.
  3. Give the human the full disagreement queue plus a random sample of the agreed pile. The sample is the only part of the design that catches an error both models made, and those are the errors 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. Compacting and pruning context are one way decisions, and once the context is gone it is gone. A chat history is not something you hand a client during 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 compared machine judgment against human judgment directly. What that work scored were model answers to questions. Nobody in it was checking a coded verbatim against a codeframe, so the move onto a research deliverable is ours to defend and not theirs.

Two rules come out of that work, both cheap to follow. The judge should come from a different maker than the generator, so it does not reward its own house style. And a judge from another maker does not remove bias in general. It removes self preference. Everything else stays put.

Calibration is the part teams skip, and I have skipped it. Getting a judge to where its verdict means something takes a sample size of roughly 200 to 500 cases labelled by a person, and once the system is running the check continues by sampling 1 to 10 percent of what went through. Those are practice ranges rather than constants, because the sample a task needs depends on how much its answers vary. Three hundred open ended answers vary a lot.

In a budget: evaluation is a project item. Uncosted, it is not done.

Agreement between makers, read carefully

Precision rises with more independent makers, and coverage falls

Two paired horizontal bars comparing agreement between three independently trained model families against agreement between four. With three families, precision is 87 percent and coverage is 33 percent, meaning the arrangement gives a confident verdict on a third of the cases. With four families, precision rises to 94.7 percent while coverage falls to 27 percent, so the verdict is more reliable and covers fewer cases. Below the bars, a caveat panel states that these numbers were measured on 78 hardware generation tasks checked by a formal equivalence verifier, and that the paper does not demonstrate the same behaviour for qualitative synthesis of open text. A second panel states that agreement among copies of one model is not the same signal: in one measurement 18 of 30 agents on the same model produced the identical branch name.

The trade is explicit: adding an independent maker buys precision and gives up coverage. The numbers come from hardware tasks with a formal checker, which is a long way from a codeframe.

Agreement between separately trained model 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. It was measured on hardware tasks, with a formal checker deciding correctness, which is a setting nothing in qualitative research resembles. The paper does not show the same for synthesis of open ended text, and neither will we until somebody measures it. I think what carries over is the shape of the trade, and that the percentages do not travel.

Updated 15 September 2026. Work published in 2025 and 2026 puts a second hard edge on that trade: models from different makers share many of their errors. Across more than 350 models, when two of them got the same item wrong they gave the same wrong answer 60 percent of the time on one leaderboard dataset, and the larger, more accurate models were the most correlated, across providers and architectures, per Correlated Errors in Large Language Models. A panel of nine frontier models from seven families carried about two independent votes' worth of information, and the best single judge matched or beat the full panel, per Nine Judges, Two Effective Votes.

Consistency does not rescue it either. In a small study, two open weight judges gave the same score 92 to 97 percent of the time and correlated only 0.28 to 0.34 with the average of nine human raters, per When Consistency Does Not Mean Reliability. Across 21 judges and about 541,000 judgments, exact agreement overstated quality by 33 to 41 points against Cohen's kappa, per Reliability without Validity.

So the judge from another maker keeps its job, which is removing self preference. What it cannot do is stand in for independence. The human sample of the agreed pile is the part of the route that catches what the models got wrong together, and agreement with that sample should be reported as kappa rather than as a raw match rate.

A related idea is worth borrowing. Supervising each step of the reasoning beats supervising only the final answer, which argues for checking the chain rather than the deliverable. Moving that to research text takes adaptation, because the original work sits where every step has a checkable form.

Where Cassi.ai comes in

Cassi.ai is a software engineering company specialized in the pains of market research, innovation and insights. We work with research agencies and corporate insights teams. Two products sit on this route.

Survey QA tests a programmed questionnaire before it goes to field, walking every path the script allows, and the read that confirms a finding comes from a different maker than the one that produced it. The QualiLab does the same for depth interviews and focus groups: the first pass proposes, a judge from another family checks, and the moderator reads the queue. The matching discipline for source material is in [the evidence chain in qualitative coding](/blog/qualitative-coding-evidence-chain), and the field version is in [testing the survey before fieldwork](/blog/survey-testing-before-fieldwork).

The human stop is not a courtesy we invented. The Model Context Protocol revision of July 2026 added durable execution identifiers and a state that asks for human input mid task, with approval gates listed as a use case. It is written into the protocol. I went looking at the support matrix for that extension, and it came back empty, so no client can be claimed to implement it yet. The rest of what we build sits in the cassiai.com portfolio.

What still has no published evidence

UNIQUE INSIGHT 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 questionnaires, which is a different problem. Writing one is not checking one. Absence of publication is not absence of practice, so this says nothing about what teams do quietly. The evidence is simply not there to quote.

DecisionDo thisBecause
Agent output feeds a client deliverableJudge from another maker, then human queueSelf review rates mediocre work well
You want a single accuracy numberReport agreement and coverage insteadThere is no answer key to compute accuracy against
Budget is tight and evaluation looks optionalCost the calibration sample explicitlyUncosted evaluation is uncompleted evaluation
Redundancy through several agents votingDo not count the votes as checks; keep a human reference sampleCopies agree by construction, and other makers share many errors too
Regulated or legal submissionFull human read, agent as first pass onlyTraceability outranks throughput

Sources: the failure taxonomy, the judge literature and the work on correlated errors. The mapping onto research deliverables is ours.

FAQ

What is AI agent evaluation?

Deciding whether an automated step produced output a senior researcher would sign. Most research tasks have no correct answer recorded in advance, so evaluation becomes a design question: who checks what, against which reference, on how many cases.

Can an agent evaluate its own output?

No. Anthropic reports that agents rate their own work well even when quality is poor. Agents review each other usefully. Reviewing yourself is what fails, which is just as true of people.

Does running the same agent three times give a second opinion?

No, and this one is expensive. In one Anthropic measurement, 18 of 30 agents on the same model produced the identical branch name. Low variance is what a good model is for, and it makes copies agree by build rather than by being right.

How many cases do I need to calibrate a judge model?

Practice puts it around 200 to 500 cases labelled by a person, then 1 to 10 percent sampling once it is running, per the judge literature. Treat those as ranges rather than constants, because a task whose answers vary a lot needs more.

Should the judge model come from a different company than the generator?

Yes, for one reason. The standing recommendation in the evaluation literature is that the judge come from another family, so it does not reward its own style. It does not buy independence: models from different makers share many errors, so the human reference sample stays in the route.

An agent whose output nobody checked is an unreviewed step wearing the word automated. The difference shows the first time a client asks how a finding was checked, and the answer has to be a procedure rather than a memory.

If you have an agent running now, pick fifty cases at random, have a person read them cold, and count the disagreements. That number is your starting calibration. It also tells you whether the check was ever really happening.

Published by Cassi.ai. Read the full article at https://www.cassiai.com/blog/ai-agent-evaluation-without-an-answer-key.