How Teams Actually Agree a Prompt Got Better

Picture a support team shipping a rewritten prompt for a refund-eligibility assistant. The automated evaluation run says the new version regressed. Its pass rate on the golden dataset dropped three points. The support lead who reads transcripts every day disagrees. She says the new responses are calmer, shorter, and easier for a customer to act on, and she recommends shipping the new version.

Nothing about this scenario is unusual, and it did not happen at Klu. It is representative of what happens on any team that ships prompts to production and takes evaluation seriously. An automated score and a domain expert's judgment point in different directions, and someone has to decide what "better" means before the team can ship anything.

This article covers the decision process through one mixed-team evaluation session that ends with a written decision, an updated test set, and a plan for watching the prompt once it is live.

Generative output does not have one correct answer

Generative tasks can have several correct answers. Two well-written responses to the same input can differ in tone, length, structure, and emphasis. That is why a single universal metric cannot tell you whether a rewritten prompt is better.

The criteria have to come from the task. A refund-eligibility assistant needs different checks than a code-review assistant or a lesson-writing assistant. Teams that skip this step reach for generic scores that sound rigorous and measure very little. The fix is to build criteria from what the model actually gets wrong in your product, for your users.

Start from real production traces

Open the traces you already have. Pull a sample of real conversations or generations from production, or from whatever test runs you have on hand. Do not start from a hypothetical list of things that might go wrong.

Read a representative sample manually before you write a single automated check. This step is unglamorous and teams skip it constantly, which is exactly why it matters. Hamel Husain's field guide to improving AI products makes the same point directly: the checks worth automating come from failures you have actually observed.

As you read, write down what goes wrong in specific terms. Replace a vague note like "quality is off" with "the response cites a policy that does not apply to this account type" or "the tone reads as accusatory when the customer made an honest mistake." Each specific failure becomes a candidate criterion.

Turn failures into checkable criteria

A criterion is useful only if two people looking at the same output would reach the same verdict. "Is this a good response?" leaves too much room for interpretation. "Does the response state the refund amount in dollars?" is precise. "Does the response avoid blaming the customer for the error?" becomes checkable when you add one or two examples of what blaming language looks like.

Write the criteria down as a list, attach a short definition to each one, and keep the list next to the dataset it applies to. This list is what a code check, a model-based judge, or a human reviewer will actually apply. Vague criteria produce inconsistent judgments no matter who or what applies them.

Choose the right method deliberately

Once you have criteria, decide how each one gets checked. Three methods cover almost everything, and most real evaluation setups use all three side by side.

Code checks are cheap and deterministic. Use them for anything with a mechanical answer, like whether a JSON field is present or a response exceeds a length limit. Do not ask a code check to judge tone or correctness of reasoning.

LLM judges scale to volumes a human reviewer cannot cover, and they are the right tool for subjective criteria once calibrated. Calibration remains required.

Human review is the most expensive method per case and the only one that can catch a failure mode nobody wrote a criterion for yet. Reserve it for disputed cases and for periodically sampling what the other two methods miss.

Calibrate LLM judges against human labels

An LLM judge is not trustworthy until someone checks it against human judgment on the same cases. Have a person label a sample of outputs using the same criteria you gave the judge, then compare. Evidently AI's guide to aligning LLM judges with human labels lays out the process: label a sample, compare judge output to human output, and treat the gap as information worth acting on.

Chasing perfect agreement produces a judge tuned to one reviewer's quirks and stops generalizing to new cases. When the judge and the human disagree, look at the specific case. Sometimes the criterion was ambiguous and needs a sharper definition. Sometimes the human reviewer missed something the judge caught correctly. Either way, refine the criteria based on what the disagreement reveals, and keep the disputed cases in your dataset. They are exactly the cases most likely to trip up the next prompt version too.

Re-run this calibration check periodically. A judge that agreed well with your reviewers six months ago can drift as your product and your criteria change.

Resolve disputes by giving someone ownership

Automated evaluation and human judgment will disagree sometimes, as in the refund-assistant example above. When they do, the team needs a rule for who breaks the tie, decided before the dispute happens.

The rule that works is simple: the person closest to the actual outcome for the customer owns the call on disputed cases. For a support prompt, that is the support lead or the person who handles escalations. For a coding assistant, that is usually the engineer, because engineers are typically the domain experts for their own output. For a medical or legal use case, that is a licensed domain expert, full stop.

Giving that person real authority matters, regardless of what the org chart implies. If the domain owner's call gets overridden by whoever ran the eval script, the team quietly reverts to trusting the automated score over the person who understands the task, and the eval stops earning its keep.

Run the whole loop as one workflow

Individually, none of the pieces above are new ideas. The value comes from running them as one connected loop every time a prompt changes.

1. Pull real production traces.
2. Review failures manually and write specific, checkable criteria.
3. Decide which criteria get a code check, an LLM judge, or human review.
4. Compare the candidate prompt against the current one on the same dataset.
5. Escalate any case where automated and human judgment disagree to the domain owner.
6. Record the decision and the reasoning behind it, in writing, next to the prompt version.
7. Update the golden dataset with any new failure mode the session surfaced.
8. Ship the prompt and monitor production output.
9. Feed new production failures back into the dataset so the next comparison catches them too.

Step six is easy to skip and expensive to skip. A decision without a written rationale disappears the moment the person who made it moves to something else. The next person to touch the prompt reruns the same debate from scratch. Write down what changed, why the team judged it better, and which cases were disputed. That record becomes the reference the next evaluation session starts from.

Two teams that gave domain experts real ownership

Two public examples show direct prompt ownership by domain experts.

At Twain, linguists directly owned prompt engineering. They wrote and revised prompt language themselves. Humanloop's case study estimates this setup saved the team around $70,000 a year, because the person who understood language quality could iterate directly on the prompt.

At Duolingo, curriculum and content experts define course structure and the learning material itself, while AI supports content production. The experts keep authority over what counts as a correct lesson. AI speeds up production of material the experts have already framed.

In each case, AI experts remain involved. The person who can judge the actual outcome, language quality in one case, pedagogical soundness in the other, directly controls the prompt and the criteria that judge it.

Academic work is catching up to this pattern. Recent research on domain-expert and developer collaboration treats it as an open problem, which matches what these two examples suggest: the handoff between the person who understands the domain and the person who can implement the prompt is still where most of the friction lives.

Where this workflow breaks down

A few failure modes show up often enough to name directly.

A perfect pass rate on the golden dataset. This almost never means the prompt is flawless. It usually means the dataset stopped growing and the criteria stopped catching real failures. A healthy golden dataset keeps finding new ways for a prompt to fail as your product changes.

Treating the LLM judge's score as ground truth after calibration. Calibration expires as prompts, models, and the product itself change. Recheck periodically.

Skipping the written rationale because everyone remembers the reasoning right now. They will not remember it in three months, and the next person on the team was never in the room.

Letting the domain owner's call get overridden informally. If this happens even once without a documented reason, the team learns that the automated score is what actually decides, and the domain expert's judgment stops being worth collecting.

Where Klu fits

Klu gives a team a place to keep prompt versions shared across roles, run this evaluation workflow against a common dataset, and track production feedback in the same system where the prompt lives. Engineers connect that workflow to the live product through the Klu SDK, so the version being evaluated is the same version running in production.

A prompt is better when the people who understand the task agree it is better, and when that agreement is written down somewhere the next person can find it. The workflow above is how you get there. Run it once, on the next prompt change you were already planning to make.