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. 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.
- 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 work such as coded verbatims, a tested questionnaire script or a drafted report section, and anything else 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.
That absence is the whole difficulty. 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: by opening the first few rows and reading.
- The agent finishes and returns a file.
- The analyst opens it and reads the first twenty or thirty cases.
- Anything obviously wrong gets fixed by hand.
- If nothing looks wrong, the file is passed on as good.
- 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.
Consider the second version, which is worse: the agent is asked to check itself. It reports that the work is solid, and the report is believed because it 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. Agreement between the people doing that sorting came out at a kappa of 0.88, which is high for coding work. One of the three families is task verification.
Read that in research terms. 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, not now.
PERSONAL EXPERIENCE In the operations we see, the check exists in conversation and not on the plan. Every other stage has a name next to it. This one has a habit.
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 rules 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. 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.
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. Each fixes a specific failure.
- Generate with one model, judge with another, from a different maker.
- Split the cases into agreed and disagreed instead of producing one aggregate score.
- Give the human the full disagreement queue plus a random sample of the agreed pile.
- Write the result of the check somewhere the agent cannot rewrite.
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. A chat history is not something you hand a client during an audit.
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.
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. Getting a judge to where its verdict means something takes a sample size of roughly 200 to 500 cases labelled by a person. 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.
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. Neither will we, until somebody measures it. What carries over is the shape of the trade rather than the percentages.
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, since 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, working 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, 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. The support matrix for that extension came back empty, so no client can be claimed to implement it yet. The rest of what we build sits in the Cassi.ai 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.
A scan of GreenBook, ESOMAR, Quirk's and Research Live on 2 September 2026 turned up no study with a declared base on automated testing of an already programmed questionnaire. What the market shows is assistants that help write questionnaires, a different problem. 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.
| Decision | Do this | Because |
|---|---|---|
| Agent output feeds a client deliverable | Judge from another maker, then human queue | Self review rates mediocre work well |
| You want a single accuracy number | Report agreement and coverage instead | There is no answer key to compute accuracy against |
| Budget is tight and evaluation looks optional | Cost the calibration sample explicitly | Uncosted evaluation is uncompleted evaluation |
| Redundancy through three identical agents | Replace two of them with other makers | Copies of a model agree by construction |
| Regulated or legal submission | Full human read, agent as first pass only | Traceability outranks throughput |
Sources: the failure taxonomy and the judge literature. 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. The standing recommendation in the evaluation literature is that the judge come from another family, so it does not reward its own style. That removes self preference and leaves every other bias in place.
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.