Your AI answers customers. How do you know it answers well?

The first versions of the prompt were written and tuned by hand: read the rankings, change the wording, rerun, read again. That works, and it is slow. Once the ranked sheet existed, an AI coding agent took over the rewriting. It got the sheet (three answers per question, the ranking and the why) and one goal: match it. It changed the prompt, ran the 63 questions through the assistant, scored the new answers against the sheet, and went again. It took a couple of hours, and the prompt it produced went live.

The pattern comes from Andrej Karpathy's autoresearch, where an AI agent edits, runs, measures and keeps or discards a change with no person in the loop. His version measures a model against a benchmark. This one measured a prompt against the business's own rankings and reasons.

Two things make a loop like this safe to leave running. People do their part once, up front: the ranked rows and the why; the AI cannot invent those, and the loop is only as good as they are. And the loop gets a cap: a maximum number of rounds and a spending limit, so a run that stops improving also stops costing. Karpathy's loop runs until someone stops it. A loop that calls a paid model on a live business should not.

Most scoring sheets have a column for the score. Add one more: the why column. One sentence per answer, in the reviewer's own words, on what was right or wrong. The score tells you the rate. The sentence beside it tells you what to fix, and it is the part an engineer or a vendor can act on the next morning.

Others have names for the same thing. Hamel Husain calls it a critique, Shankar's work talks about notes, and some evaluation tools call it an explanation. "The why column" is just a name an owner would actually say. The idea belongs to all of them.

Keep the score itself simple. With one answer, it is like it or not: pass or fail. With two or three answers to the same question, rank them: 1 for the one you prefer, then 2, then 3. A 2 means there is something you like, but not fully. Two answers can share a rank (1 and 1) when each has something good in it. A fail is a zero, or simply left blank. The why then explains the ranking: why this one first, or why these two are equal.

Two answers side by side are easier to judge than one alone. You are not deciding whether an answer is good; you are choosing which is better, and saying why. The reason you write is the requirement. Often a third, better answer appears from comparing the two. Pass or fail still applies to each answer; the ranking adds the choice. Eugene Yan, who writes on product evaluation, allows both: "Focus on binary pass/fail or win/lose labels." What to avoid is a 1-to-5 quality scale, where nobody agrees on the difference between a 3 and a 4. The nuance goes in the why column, where it can be read.

So whoever builds the assistant should put two or three candidate answers in front of the business, not ten, and ask for a ranking and a why. A simple regression check that nothing broke only needs pass or fail. Improving the prompt, by hand or with the automatic loop above, needs the why: it is the only part of the sheet that says what better looks like.

Not every row will get a reason, and that is fine. On the real-estate site, 49 of the 63 ranked rows carried a written why. Rows without a reason still count in the score. Only the rows with a reason tell you what to change.

An answer that cites one of your approved pages can be checked in seconds: open the page, see whether it says what the answer says. An answer with no source cannot be checked at all, short of asking an expert. This is the practical value of answers drawn from your own content, an approach researchers at Facebook AI described in 2020 as retrieval-augmented generation, where the knowledge the model used "can be inspected and interpreted."

Citations let a reader check. They do not prove the answer right; the audit above shows a cited answer can still be wrong. So the why column applies here too.

On the real-estate site, the business side marked three refusals as wrong and, in the note, named the section of the site's guide that answered each question. One of them: the assistant declined to answer, and the note said "totally wrong" and pointed to the page. The fix was in the search index, not the prompt: the right pages were not being found. After the index change, all three came back as cited answers. A later spot-check found two of the three still fixed, which is one more reason to keep rerunning the rows.

One person owns what good looks like. Husain and Shankar call this person the "benevolent dictator": "one domain expert who understands your users". Committees average out the reasons until nothing is left to act on.

Scoring is the tedious part, and it can be shared, but only on the business side: people who know the customers and will judge the finished product. Write the guidelines down, and have the owner review the disagreements and any new kind of failure.

An AI checker can pre-sort answers at volume, but only after a person's labels exist to check it against. Shankar's study put it bluntly: AI evaluators "simply inherit all the problems of the LLMs they evaluate, requiring further human validation." Ask the checker to write its own reason as well, so when it disagrees with your reviewer, you can read why.

Fewer than you think, to start. Anthropic's engineers: "teams delay building evals because they think they need hundreds of tasks. In reality, 20-50 simple tasks drawn from real failures is a great start." Husain and Shankar suggest reviewing 20 to 50 outputs whenever you make a significant change, and say a set built for reruns "often grows to 100 or more examples." The real-estate site started with 51 questions, which is the start line, not the finish.

Building the set is easier than it sounds. Start from questions real visitors are likely to ask; if your search platform suggests follow-up questions, those are a quick source. Then add questions on purpose that the assistant should not answer well: off-topic ones, out-of-scope ones, and deliberately hostile ones. Sort them into a few classes so you can see the balance. The real-estate site's 51 fell into five: 10 covered by the site's own guides (home inspections, title fraud, condo reserve funds), 15 it could not answer from its content (such as which suburb is the better long-term investment), 10 ambiguous, 10 off-topic, and 6 edgy, such as a deliberately rude question or an attempt to make it misbehave. Six edgy questions is thin, and the set will grow there first.

Before you trust an AI checker on its own, you need more. Husain and Shankar plan 100 to 200 labelled examples for each kind of failure; Eugene Yan aims for 50 to 100 failures in the set, because "a dataset with hundreds of labels but only five failures isn't useful."

Be clear about what a small set can show. It catches the common failures. It cannot rule out rare ones. Yan works through the arithmetic: if you want to confirm a defect rate under 5 percent and you see 3 percent on 200 samples, the margin of error is about 2.4 points either way, too wide to confirm the target. Write down what you do not know yet, instead of claiming it.

Rerun the set whenever anything changes, and remember you are not the only one changing things. Vendors update and retire models on their own calendar, and an answer that passed last month can fail after an update you never saw. Pin the model version where you can, rerun on a schedule as well as after your own edits, and when a row goes from pass to fail, the why column tells you which rule broke. The tools move too: OpenAI's hosted Evals platform becomes read-only on 31 October 2026 and shuts down on 30 November 2026. Keep your rows somewhere you control.

"This is just standard error analysis." Yes, and that counts in its favour: it is a method that works. What changes here is the reader: the person who owns the answers and will never read an engineering blog.

"Our vendor's dashboard already does this." A dashboard counts what someone told it to count. The useful questions are who told it, in whose words, and whether those words came from looking at your real answers.

"Experts disagree with each other." They do. Anthropic's test for a good question is one where "two domain experts would independently reach the same pass/fail verdict." Where yours do not agree, that is a finding: the rule is not written down yet. It is also why one person is accountable and the guidelines are written.

"Twenty answers prove nothing." They prove the common failures, which are the ones customers meet most. Rare failures take hundreds. Start small and grow the set.

"An AI checker is cheaper than my time." At volume, it is. The order matters: your labels first, then the checker at volume, checked against them.