Eval systems are grown, not authored: meet the Evaluator agent

Eval systems are grown, not authored: meet the Evaluator agent

How an agent turns production traces and domain knowledge into a living eval system, and where it deliberately hands the judgement back to you.

The blank page is the wall

Most teams don’t skip evals because they’re undisciplined. They skip them because evaluation is the one thing you cannot write from a blank page.

You can’t define what “good” looks like for a feature until you’ve watched it fail in ways you didn’t predict. And “good” is domain-specific: the engineer shipping the feature often isn’t the person who knows what a correct answer even is. So “define your eval criteria first” asks for the hardest step before there is any signal to do it with.

It gets worse with speed. Every new AI feature drops you back at the same blank page. The cold start isn’t an event you cross once and move past. It’s a tax you pay again every release.

The Evaluator is the agent we’re building to remove that tax. Not by writing your evals for you, but by growing them from the one thing you already have: your traces. What follows is the concept, end to end, including the line it refuses to cross.

Criteria aren’t authored from a blank page. They’re derived from the failures already in your traces, and the set grows every cycle.

Eval-from-traces: the criteria are already in your data

The premise is that your production traces already contain your eval criteria. You just haven’t extracted them yet. Every failure is a criterion you didn’t know to write, sitting in the data, waiting.

The Evaluator works that data three ways at once, because no single pass is enough.

It clusters failures. Across a body of traces, the same failure shows up in many shapes. Group them, and each recurring cluster is a candidate criterion: not “this one run was wrong” but “this class of output keeps being wrong, and here is the shape of it.”

It diffs the good against the bad. Given a set of outputs marked acceptable and a set marked unacceptable, the most useful signal is the contrast between them. What is present in the failures that is absent in the successes? That delta is where a criterion lives. A criterion derived from a real contrast is sharper than one imagined at a desk, because it was forced to separate two piles of actual outputs.

And it lets a model propose. Reading the labeled traces, an LLM drafts candidate criteria in language: here is what seems to distinguish the outputs you accepted from the ones you rejected. These are proposals, not verdicts. The distinction matters, and we will come back to it, because proposing is exactly the part an agent should do and grading is exactly the part it should not.

None of this is the engineer staring at a blank doc trying to imagine every way a feature could break. The failures do the imagining. The Evaluator’s job is to turn them into criteria you can run.

Field-level and goal-level: the same idea at two altitudes

Here is the distinction that decides everything downstream: what are you actually evaluating, a prompt or an agent?

For a single-turn prompt, the unit is the output. The structured output has fields, and you can judge each field on its own. Did the extraction pull the right value? Is the classification correct? Is the format valid? These are field-level criteria, and they are granular by design. They catch individual output failures, the specific cell in the specific field that came out wrong.

For a multi-turn agent, field-level criteria are the wrong altitude. An agent doesn’t produce one output; it produces a trajectory: a sequence of tool calls, intermediate decisions, recoveries, and a final result. Judging the last field misses the point. What you care about is whether the trajectory reached the goal, whether the agent’s behaviour deviated from what the task required, and whether any catastrophic-failure signals appeared along the way. These are goal-level criteria. They are coarser than field-level criteria, and that coarseness is correct: you are detecting deviation and catastrophe across a path, not grading a cell in a form.

The same eval-from-traces machinery feeds both. The difference is altitude. Field-level criteria detect tool-output failures on single-turn work. Goal-level criteria detect trajectory deviation and catastrophic failures on multi-turn work. A real eval system needs both, applied where each belongs, and the most common mistake is using prompt-grade granularity to grade an agent, then drowning in field-level noise that says nothing about whether the agent actually did its job.

Calibrated, anchored rubrics: why a criterion can be trusted

A criterion is only as good as the rubric behind it, and most rubrics are vague enough that the judge slides around inside them. Two properties make a rubric trustworthy: it has to be anchored, and it has to be calibrated. They are not the same thing.

Anchored means each criterion is pinned to real example outputs. Not an abstract description of “good,” but concrete instances: this output passes this criterion, that one fails it, and here is the line between them. The examples are the anchors. A judge with anchors has a reference to point at; a judge without them is reasoning from a definition it is free to reinterpret on every run.

Calibrated means the rubric has been tuned until its verdicts agree with human judgement. Anchoring gives the judge references; calibration proves those references actually produce the verdicts a human would. The two compound: anchors without calibration are unverified, and calibration without anchors has nothing concrete to tune.

Calibration is a loop, not a one-time act:

1. Run the rubric across a labeled set.
2. Measure where its verdicts disagree with the human labels.
3. Where it disagrees, the human corrects it, and each correction becomes a new anchor. The disagreement is not noise to smooth over; it is the most valuable example you can add, because it is exactly where the rubric and a human part ways.
4. Variance-test the rubric: run it more than once and find the criteria whose verdict drifts between runs. A criterion that can’t agree with itself can’t agree with anyone.
5. Fix the drifting and disagreeing criteria. Repeat.

The output of that loop is a rubric you can defend: anchored to real outputs, calibrated against real judgement, and stable enough that it returns the same verdict twice. That is the difference between an eval you trust and a number you squint at.

Reliable scoring: passed over total, not a dangling score

Once the criteria are trustworthy, scoring is deliberately boring. Each criterion returns a binary verdict, pass or fail, and the score is passed over total across a defined criteria set. No 0.72 that you have to interpret. A count, over a set you can name.

This shape is chosen, not incidental, for two reasons.

It is stable. A raw continuous score from an LLM judge drifts run to run, because the judge is non-deterministic and a number is free to wander. A binary verdict over a defined set, built on anchored and calibrated criteria, doesn’t wander the same way. The denominator is fixed, so two runs are comparable: passed-over-total today means the same thing it meant last week.

And it is actionable, which is the part teams underrate. A dangling LLM score tells you the output was a 0.72 and leaves you to guess what to do about it. A binary criterion that failed tells you exactly what broke: this specific check, on this specific behaviour, did not pass. The feedback points at a fixable thing instead of a vibe. Fine-grained pass/fail criteria give you a punch list; a continuous score gives you anxiety.

The catch, and it is a real one: binary scoring is only as reliable as the rubric underneath it. A pass/fail verdict on an ambiguous criterion is worse than a continuous score, because it launders ambiguity into false precision. This is why the anchoring and calibration are not optional polish. They are the load-bearing wall. Reliable scoring is downstream of a well-defined, well-exampled rubric, and there are no shortcuts around that order.

The two-rule model: propose freely, anchor carefully

Everything above describes an agent doing a lot of consequential work: reading traces, deriving criteria, scoring outputs. That raises the obvious question, the one every engineer asks before they will trust a system like this: who decides what “good” means? If the agent both writes the criteria and sets the standard they are graded against, it is grading its own homework, and the whole thing is circular.

So the Evaluator runs on two rules.

Rule one: it proposes criteria freely. Deriving candidate criteria from traces is cheap, fast, and exactly the kind of work an agent should take off your plate. Propose away.

Rule two: by default, the human owns the calibration anchors. The anchors define what “good” actually is, and that is the judgement boundary. Proposing a criterion is cheap; deciding the standard it is measured against is the craft, and the craft stays with the human. The agent will not auto-fill the anchors out from under you. That refusal is the feature. It is the line that keeps the agent from grading its own homework, and it is what lets an engineer trust the output, because the part that encodes their judgement is the part they still own.

That boundary is the default, not a wall for its own sake. With a large enough sample, the agent can anchor directly from execution outcomes: when enough clear-cut successes and failures have actually run, those outcomes are ground truth, and the obvious, unambiguous cases can self-anchor without a human in the loop for each one. The borderline and ambiguous cases still escalate to the human, and where extra judgement is needed the agent proposes an anchor and the human confirms it. The principle holds across all of it: the agent does the volume, the human owns the judgement, and the boundary moves only where the data is unambiguous enough to move it safely.

The system grows every cycle

Put the pieces together and the shape of the thing changes. You are not authoring an eval suite up front and freezing it. You are growing one.

The first criteria come from a domain expert if the domain is known, or from the first traces if it isn’t. The feature goes live. Production starts producing failures you didn’t predict, and each one becomes a new criterion, anchored to the real output that exposed it, calibrated against how a human judged it. The rubric variance-tests itself and sheds the criteria that drift. The score stays comparable because the criteria set is defined. And the next failure mode that appears, the one you genuinely could not have written on day one, gets absorbed the same way.

That is the answer to the cold start. You never start from a blank page again, because after the first cycle there is no blank page, only a system that already knows most of what breaks and is learning the rest. The eval system stops being a prerequisite you dread and becomes a byproduct of running the agent at all.

02Mutagent Use CaseEvaluate Builds the evals and a calibrated judge that scores every change, aligned to your domain expert before it gates anything. IN dataset · expert labels    OUT calibrated judge · criteria Explore

This is what we’re building the Evaluator to do, and it is why we think it matters more than another dashboard or another scoring library. The teams that win the next phase of AI engineering won’t be the ones with the most evals written on day one. They’ll be the ones whose eval system grows faster than their failure modes do. Eventually the line between building the agent and building its eval system disappears, because they become the same activity.

Evals were never something you finish before you build. They’re something you grow while you do.