In brief: A quality gate is only as good as the evidence it rests on, and agents now generate most of that evidence — so the Tester’s job has moved from running checks to designing what would count as proof. This briefing is for quality, service and operations leads, and for the leaders who sign off releases they cannot inspect themselves. Two things travel to any firm: an evaluation set is a collection of past cases where you already know the right answer, and outside software it is what makes agent output systematically verifiable; and a model grading its own kind of output is a consistency check, not independent assurance.
Every other role in this Path makes something. This one decides whether it is allowed to exist — and that decision got harder the moment the evidence behind it started being produced by the same kind of system it is meant to judge.
The system passed every test. That is what worries Ronja Fink.
She is the release gate at Bruns & Lehmann — the firm this Path follows, a family-owned Mittelstand manufacturer of dosing pumps in northern Germany, around 420 people, customers across Europe. What reaches her in September is the thing the firm has spent the year building: a troubleshooting assistant for the engineers who run its pumps on customer sites, who describe a fault to it and get proposed next steps back. It was designed in the Creator briefing, built in the Implementer briefing, and it carries one promise that everybody has now repeated so often it sounds settled. When it is unsure, it stops and says so.
That promise is the part carrying weight. A technician somewhere in Europe will describe a fault at three in the morning, alone beside a chemical dosing pump, tired, and the system will answer. If it is right, the plant runs by breakfast. If it is confidently wrong, someone opens the wrong valve.
The tests are green. But the tests were written by an agent working from the specification, and the system was built by an agent working from the same specification. Green proves the two of them agree. It does not prove either is right.
What a Tester actually holds
The Compass groups the delivery roles of a transformation as Transformers — people, not the neural-network architecture; the difference is exactly the accountability gap this series works. The Tester holds confidence: the definition of what good enough means, the judgement on defects that are arguable rather than obvious, and the decision that something is or is not ready.
Notice what that is not. It is not finding bugs. Finding things is the part agents are now good at.
Two questions stay human, and they are not the same question. The first comes before any testing starts: what would have to be true for us to release this? That one is Ronja’s. The second comes at the end, when the testing is done and some risk is always left: is this a risk the firm will carry? That one is not hers. It goes back to Frauke, the Owner who funded the work in the opening role briefing. Accepting a risk is a decision that needs a name attached to it.
Who actually does which testing
Many leaders still picture a separate department at the end of the line: software arrives finished, someone clicks through every screen, defects go back. That stopped being true long before agents, and the outdated picture has a practical cost — people ask the wrong person for the wrong thing, then conclude the quality function is slow.
Roughly who owns what now:
- Unit and integration tests — the Implementer. Engineers write these while they build, and the pipeline runs them on every change. They check that the parts behave as intended. Nobody in a quality role writes them, and agents now draft most of them.
- End-to-end tests — shared, and the split matters. The Tester decides which customer journeys are worth protecting. The Implementer builds the automation that runs them. Asking the Tester to deliver these alone is asking for a script with nothing to run it.
- A/B tests — not this role at all. An A/B test asks which version customers respond to better. It belongs with the Owner, the Creator and whoever owns the analytics. It answers a commercial question, not a correctness one, and treating it as testing confuses two different kinds of evidence.
- Performance, load and security scanning — mostly automated, mostly engineering. The Tester reads the results and decides whether they are acceptable, which is a different act from producing them.
- Exploratory testing, acceptance criteria and the release decision — the Tester. This is the part that never automated, because it is judgement about what nobody thought to specify.
One correction for firms of Bruns & Lehmann’s size: “the Tester” is often not a job title. It is a hat, worn by an engineer, a service lead or a quality manager with other duties. Knowing who is wearing it matters more than having a department.
What agents change for this role
Test cases became cheap, but most of that windfall lands on the Implementer. An agent drafting hundreds of unit tests from a specification is doing engineering work; it speeds up the build, not the gate.
What agents change here is narrower and more useful: they make it affordable to build cases from what actually happened rather than from what was specified — reading years of closed service records for their known outcomes, writing the adversarial cases nobody enjoys, re-scoring the whole set on every change. Ronja could always have done that by hand. Never at a scale worth trusting.
That difference is the briefing in one line. The Implementer’s agents ask whether the parts behave as designed. The Tester’s ask whether the design was right — and those questions diverge precisely when it matters, which is whenever the specification was wrong.
Two things arrived alongside that gain. The work being tested is now largely agent-produced too, so more reaches Ronja’s gate each week while her week stays the same length. And the evidence about quality is increasingly agent-generated as well — the cases, the failure summaries, the board report, and in many teams the marking itself.
The failure mode follows: the evidence and the thing being evidenced come from the same source, so agreement gets mistaken for correctness. An agent writing tests from a specification and an agent writing code from it will agree whenever they read it the same way — including when both read it wrongly.
A second failure surfaces later. Pass rates rise and everyone notices; whether the system improved or the tests got easier to pass is a different question, because the same acceleration that produces more changes produces more tests, and a suite nobody curates drifts towards the cases convenient to write.
Both failures have one root and one fix. Evidence produced by the same source as the work has to be re-anchored to something neither of them wrote: what actually happened, in cases whose outcome is already known, chosen by someone who did not build the system. The rest of this briefing builds that — why a non-software department has to construct the check itself, what it consists of, and what an automated grader can be trusted to do inside it.
The evaluation set: what replaces the test suite
Software has an advantage nobody outside it notices: it verifies itself. A test suite runs and returns green or red, the same way every time, for free, forever. Almost no other department has that. Whether an order was classified correctly, or a service instruction was safe, is settled by a person looking. That is the practical reason the published evidence for agents is nearly all from software firms, and why an operations manager who asks “is it working?” gets an anecdote rather than an answer. The Tester outside engineering has the harder job: building the checking machine engineering was simply given.
It is less exotic than the problem suggests. An evaluation set is a collection of real past cases where you already know what the right answer was. You run the agent against them and count.
For Ronja, that is service history. Bruns & Lehmann has years of resolved fault reports: what the customer said, what the engineer found, what fixed it. That archive was rejected as a knowledge base months ago because it is inconsistent, badly tagged and full of shorthand. It does not matter. An evaluation set needs only the question and the outcome, not tidy structure in between. The data too messy to teach the system is clean enough to test it.
What makes an evaluation set worth trusting
One label before the detail. What follows is PathPatron’s prescription, not a published standard: no firm outside software has yet documented an evaluation set for agent output in an operational department, which is the gap this Path exists to close. Treat it as a considered starting point and argue with it — the evidence standard sets out how this publication marks the difference between what is proven and what is proposed.
Four things, and each is a decision a person makes before anything is measured.
- It is built from outcomes, not opinions. A case counts as correct because the pump was fixed that way, not because a reviewer thought the answer read well.
- The acceptance criteria are written first — not only the headline number but the shape of the failures. Ninety-five per cent correct with errors scattered is a different system from ninety-five per cent where every error sits on pumps built before 2010, and only one of those is releasable.
- It is deliberately loaded with cases where the right answer is to stop. Teams skip this. A set made only of answerable faults measures nothing about the promise the whole design rests on. Roughly a fifth of Ronja’s cases are ones where refusal is correct — symptoms too ambiguous, a pump model the documentation no longer covers, a description that contradicts itself. A system that answers those is failing, however good the answer sounds.
- Nobody who built the system chooses the cases. Not out of suspicion. Because the person who built it knows which examples it handles well, and will pick them without meaning to.
That last point answers the question leaders ask here: who actually does this? Not engineering. The set is assembled by the people who know the outcomes — service engineers, the service lead, Ronja — because only they can say what the right answer was. Agents do the mechanical part: reading the archive, drafting candidates, flagging near-duplicates. Deciding what belongs is not delegable, and it is roughly two weeks of real work by people who already have jobs. Budget it or it will not happen.
This is not only a large-firm discipline. Arden Dies, a family-owned die-maker in Stockport, built an agent to pull structured orders out of customer emails — and then did not switch it on: “Rather than implementing a live solution immediately, the project focused on structured evaluation, allowing the business to explore options safely while assessing accuracy, scalability and compatibility with existing systems” (Made Smarter, May 2026 — programme-reported; a three-month internship at evaluation stage, not a deployment).
Read that as the decision it was rather than a delay. Proving it came first; going live was what had to be earned. Most firms run that order backwards and call the result a pilot.
The order-intake system in the Organizer briefing sorts orders green, yellow or red by confidence, the way EMES Kabelbaum Konfektion, a Saxon switchboard manufacturer introduced in full in the opening briefing, set the levels for its own order capture. Nobody asks where those lines came from. They are not settings — they are the output of exactly this exercise, run once against known cases. A confidence threshold anyone can change in an afternoon is a threshold that was never measured.
In my work, the checking is reliably the slow part, and it is the part that matters. Every claim in these briefings is traced back to its source before it publishes — unglamorous, repetitive work, and the whole reason the series can be trusted. No agent has taken it off me.
The harder version of the problem showed up on an assessment I helped build in the sovereign-AI space. Building the thing was quick, and it was the easy half. Agreeing what a good answer looked like took far longer, because the subject was new enough that no archive existed — nobody had a body of past cases already settled as right or wrong. Several experts had to sit down and construct the standard before anything could be measured against it.
That is the honest limit on everything above. An evaluation set assumes a history to draw on. Where there is none, the answer is often that the work is not ready for an agent yet — not because the technology cannot do it, but because nobody can yet say what right looks like.
A model grading itself is not assurance
Two weeks of experienced people’s time is exactly the cost that sends a leader looking for a way round it, and there is an obvious one: let a second agent mark the first one’s work. It is fast, it scales to any volume, and it is common enough now to have a name — LLM-as-a-judge. It is worth knowing precisely what it buys and what it does not.
Researchers at UC Berkeley ran the largest systematic test of the practice to date: twenty-one judge models from nine providers, roughly 541,000 judgments across three benchmarks. The title is the finding — Reliability without Validity (Norman, Rivera and Hughes, June 2026 — preprint). Two judges they tested, both already in production systems, returned the same verdict on repeat more than 95% of the time while showing severe bias towards whichever answer appeared first. Consistent and correct are different properties, and the first is easy to mistake for the second on a dashboard.
One number is worth carrying into any meeting where somebody reports how well a grader agrees with human reviewers. Across every judge in the study, raw agreement overstated real agreement — corrected for how often two raters coincide by luck — by between 33.8 and 41.3 percentage points. “It matched our reviewers eight times in ten” can be close to a coin toss.
A subtler failure matters more for a firm running several agents together, and the bias is not vanity. A study measuring self-preference found that models rate text higher than humans do when it is familiar to them — smooth, predictable, the kind of thing they would have produced — whoever actually wrote it (Wataoka, Takahashi and Ri — preprint, revised 2025). Your grading agent does not prefer itself. It prefers text that reads as fluent and predictable — which is a fair description of what the rest of your suite produces.
That is correlated error, and it is why independence has to be designed rather than assumed. Two agents from the same family are one opinion stated twice. The full treatment of how challenge is made real rather than theatrical comes later in this Path.
None of this makes automated grading useless. It is a good smoke detector: cheap, fast, worth running on every change to catch the obvious. It is not the gate. The gate is the evaluation set, scored against known outcomes, with a person reading the failures.
The Tester’s suite
Her agents are separated by purpose, and every one produces material she checks rather than conclusions she accepts.
- A case builder — reads the service archive and drafts candidate evaluation cases with their known outcomes, which she and the service lead accept, reject or correct.
- An adversarial agent — writes the cases nobody enjoys writing: the contradictory symptom, the customer who names the wrong pump model, the description from someone frightened and in a hurry at 3am.
- A regression runner — re-scores the whole set on every change, so a fix to one behaviour cannot quietly break another.
- A data-quality watcher — flags when incoming service records drift away from what the set was built on, the early warning that the evaluation is going stale.
- An evidence collector — assembles what the release decision rests on into one document: which cases were run, which failed, what changed since last time.
- A triage agent — orders the week’s queue by what a failure would cost rather than by how confident the system was: which pump families are actually in the field, which faults sit close to safety, what is new since the last run. It ranks; it never removes. The criteria are Ronja’s, written down and changeable.
Deliberately absent is an agent that decides the system is ready — not because it could not produce that sentence, but because “ready” is the judgement the role exists to hold, and a signature has to belong to someone who can be asked why.
The triage agent is the one that could quietly become the gate, so it carries a discipline. If Ronja only ever reads the top of the list, the ranking has decided what gets scrutinised and what ships unexamined, and nobody chose that. So she reads a sample from the bottom every cycle. It costs her twenty minutes, and it is the only way the ordering can ever be caught being wrong.
Cost note: six agents is six briefs, six sets of permissions and six things to re-verify whenever the model changes — and the evaluation set is not a build cost but a standing one, because a set that is not maintained slowly stops describing the work it was drawn from.
Where the wall bites this role
The access problem the Organizer briefing sets out in full has a particular shape here: a Tester is usually given a clean environment with invented data, which is precisely the condition under which nothing interesting fails. The manual start that works is unglamorous — take a hundred real closed cases out of the archive by hand, redact what must be redacted, score them in a spreadsheet. A hundred real cases answer more than ten thousand synthetic ones.
The questions that travel
Four questions any leader can ask before agreeing that something is ready, and the answers to listen for.
- What did you test it against, and who chose those cases? “Real closed cases from last year, chosen by service, not by the build team” is an answer. “A comprehensive test suite” is a description of effort.
- What does it do when it should not know? If nobody can say what proportion of the tests were unanswerable on purpose, the stopping behaviour is untested, whatever the design document says.
- Who or what marked the results? If the answer is another model, ask what it was checked against. An automated grader is evidence about consistency; the evaluation set is evidence about correctness.
- What are we knowingly accepting? Every release carries residual risk. If the honest answer is none, the testing was not thorough enough to find any — and the person accepting that risk should be named in the same sentence.
If the Tester is on your team
Most readers of this briefing will never assemble an evaluation set. The job is to make sure one exists and that it is allowed to say no. Three checks.
- Ask to see a failure. Not the pass rate — an actual case the system got wrong, and what was done about it. A team that cannot produce one has either a perfect system or a test set too easy to be informative, and only one of those is common.
- Protect the gate from the date. The pressure on this role is never to test less; it is to test faster, which becomes the same thing. If the release date is fixed and the evidence is not ready, someone is about to decide by default. Make the decision explicit and put a name on it.
- Watch what happens to the set over time. An evaluation set that has not changed in a year is measuring last year’s work. Whose job is it to add the new cases, and does that person have the hours?
Leading people who work with agents — the checks, the warning signs, the review cadence, for all six roles — is covered in its own briefing later in this Path.
What Ronja hands over
She signs, with two conditions written into the release note: the system goes live for three pump families rather than all eleven, and the stopping rate is reported weekly. Neither is caution for its own sake. Both say that the evidence supports this much and not more, which is a more useful sentence than yes.
What she hands the Maintainer is not a green dashboard. It is the evaluation set itself, the list of cases the system currently fails, and the number below which somebody must be told. Those three things are what let a person six months from now answer the question that ends every incident review: did this always do that, or did something change?
That is the Tester’s version of the series’ claim. Agents made evidence cheap to produce and easy to mistake for proof, which does not remove the quality job so much as move it earlier: deciding what would count as proof, before anything is measured. That decision was always the work. It was simply easier to skip when the checking was slow enough to feel like rigour.
Related reading
- The AI-Enabled Teams Path — all fourteen briefings in reading order; previous: the Implementer, who built this system; next: the Maintainer, who runs it six months from now.
- One Agent, a Suite, or an Agentic Workflow? — the three shapes, and why verification is the category of failure that only appears once agents check each other.
- The PathPatron Evidence Standard — how this publication labels what is proven, what is practice and what is prescription.