A traditional program that breaks looks broken. An alert lands in Slack, an error bar on a dashboard goes red. An AI assistant that is wrong looks almost exactly like an AI assistant that is right: same tone, same polish, same air of authority. The mistake is invisible until someone who knows the real answer happens to look.
And when someone does look, it always ends the same way. The answer feels off, they dig in, and they come away calling the system a liar, whether it lied or just lacked the context to know better. Either way, the trust is gone.
is the discipline of answering "is this system actually doing its job?" systematically and continuously, instead of by spot-checking and hoping. This guide walks that practice in stages, from one person reading transcripts to a system that hunts down its own hidden failures, each stage opening on the general lesson it taught. The ending up front: maturity is not about removing humans. It is about aiming scarce human judgment at exactly the things that need it, and letting AI carry everything else.
The stages ahead follow one team, the engineers who built the assistant and own its quality. Their journey is told in the vocabulary of Working with Robots, Go Between's framework for how an engineering org decides where to invest in AI: four domains of work, divided into disciplines, each with an investment tier that describes how deep a team has gone. Every stage ahead closes with a readout of where this team's investments sit. One principle runs under everything that follows. Polish is not evidence, so every stage adds a way to check the output against something outside the system. The framework names this principle , and the framework itself is the place to go deeper.
General lessons
The whole guide in miniature: skim the lessons without the story, or follow one into its stage.
Every evaluation practice starts with no way to answer whether the system is doing its job, and for a prototype that is fine. The moment real decisions start riding on the output, shipping and hoping is the biggest risk you have.
1. Mechanical checks and human review
You cannot judge what you did not record, so evaluation starts in . Then cheap, deliberately dumb checks ask whether the machine behaved on every run, and human judgment is only required on the few runs worth further investigation.
Whether an answer is actually any good is a judgment call, so scale it with an AI grader: write the standard down, put the grader on live traffic immediately, and treat everything it says as noise until its agreement with the human verdicts clears a bar. Even then a person keeps arbitrating where the graders disagree, and each verdict sharpens both the system and its judges.
3. Agents propose, humans decide
To make the whole system better faster, point AI at improving it. Make its restraint structural: it proposes, never applies, and every change clears evaluations the proposer cannot edit, plus a human decision.
4. Finding the failures nobody reports
The most dangerous failures are the ones that look right. Check answers against facts the answers cannot fake, and mine recorded behavior for the dissatisfaction that never reaches a feedback button.
Followed to the end, the lessons build a steady state that spans all four domains of the framework.
- Context
What the hunting surfaces gets written down: vocabulary and boundaries the agent reads instead of guessing.
- Control
Agents propose improvements and humans decide what ships, behind an automatic gate.
- Observability
Every run leaves a record, queryable enough to mine for behavior and to reconstruct any single run end to end.
- Improvement
Cheap mechanical checks read every run and pre-filter what humans see.
Calibrated graders score quality at scale; a judge over them routes disagreements to the standard-setter for arbitration.
The system hunts its own hidden failures, and human attention is aimed at the runs with the most to teach, never flooded.
An approved improvement becomes team practice everywhere it applies.
Stages
Every evaluation practice starts with no way to answer whether the system is doing its job, and for a prototype that is fine. The moment real decisions start riding on the output, shipping and hoping is the biggest risk you have.
The starting state is the same everywhere: the system is live, and the only quality signal is complaint. Nobody can say whether it is doing its job except by waiting for someone to notice that it is not. Efficacy is a gut feeling, and nobody stops to check the gut.
The system's work is a black box the team pays for monthly, and when someone asks what it did last week, the honest answer is that nobody knows.
- Human judgment
- The firefighter. Quality problems reach them after a customer has already found one.
- AI labor
- Nothing yet. Every check that happens is a person reading output by hand.
Framework investments
Nothing funded yet. Every discipline sits at , which is a posture, not a grade: the tier you invest your way out of.
Techniques
None yet. Manual and ad hoc.
You cannot judge what you did not record, so evaluation starts in . Then cheap, deliberately dumb checks ask whether the machine behaved on every run, and human judgment is only required on the few runs worth further investigation.
is a discipline of the domain, and someone on the team will want to start with the discipline itself. The temptation is to go straight to AI graders. But a grader needs something to read and a way to know whether to believe it, and this team has neither yet. Both start with the record, so the journey starts in Observability. Every run has to leave a record: what the system was asked, what it did, what it answered, what it cost. And the record has to land somewhere the team can query, not in a vendor console nobody opens.
With the record in place, the first checks are deliberately dumb. Before you judge whether an answer is good, you can cheaply check whether the machine behaved: did it finish at all, or time out and return nothing? Did it do the work its answer claims, or answer without doing it? Pure rules, no model involved, instant and perfectly repeatable. Checks this dumb still catch real failures.
On their own these checks cannot tell you whether an answer is right. Their real job is to be a pre-filter. Execute them on every run and nobody has to read thousands of transcripts. Instead, one person on the team reads the few hundred the checks flagged. They record a verdict on each with a reason. The reasons matter as much as the verdicts: writing one forces the reviewer to say why the system worked or broke, and read in aggregate they are where the failure patterns first show up. The verdicts become the standard everything later is measured against, one the system cannot generate for itself.
The team also drew its first delegation boundary. Machines flag, a person judges. Nobody wrote that rule down yet, but Stage 3 will build it in.
- Human judgment
- The grader. Reviews the flagged runs and sets the standard, one verdict at a time.
- AI labor
- The sifting. Cheap checks read every run and decide which few deserve a person's scarce attention.
Framework investments
- . The first real investment. Every run leaves a raw record, because nothing downstream works without one.
- . The record lands where the team can query it. Capture and Availability climb toward before Evaluation has properly begun.
- . Moves from to . One person carries the read, and the read is real.
- . The first boundary is drawn without ceremony: machines flag, a person judges.
Techniques
- . Deterministic checks pointed at agent runs: did it finish, did it look up the account, did the plumbing hold. Rules that read every run before a person does.
- . Hooks that record each run as it happens, so the record the checks read is complete without anyone choosing to log.
- . An append-only, queryable log of runs and verdicts. The store the review reads from, and the evidence base every later stage builds on.
Whether an answer is actually any good is a judgment call, so scale it with an AI grader: write the standard down, put the grader on live traffic immediately, and treat everything it says as noise until its agreement with the human verdicts clears a bar. Even then a person keeps arbitrating where the graders disagree, and each verdict sharpens both the system and its judges.
Plumbing checks cannot say whether an answer was helpful, well-caveated, and plausible. That is a judgment call, and judgment is exactly what does not scale when a human has to make it on every run. This stage has a model grade the output against a written rubric.
The trap is obvious the moment you say it out loud. Why would you trust one AI to grade another? You would not, and you should not. So the defining discipline of this stage is calibration. A new grader starts life as an untrusted opinion. Put it on live traffic immediately, because nothing exposes where it is deficient faster, but expect the early scores to be noisy and treat them as exactly that: nothing it says counts toward evaluating the system until it has been checked against the human verdicts from the last stage and its agreement with the expert clears a bar.
This is what the hand review was building. Those verdicts are the training signal that makes automated judgment trustworthy. Humans are not replaced by the graders; humans are what make the graders worth trusting, and the standard still lives outside the model.
Human judgment does not retire when the graders arrive; it moves up. The mechanically flagged runs from Stage 1 still get read, even as their causes get fixed and that pile shrinks. And the graders open a new queue of their own: set a judge over the judges, a stronger model or one from a different family, so its blind spots are not their blind spots. Every disagreement on the bench goes to the standard-setter for arbitration, along with a random sample of the unanimous calls, because the whole bench can still be wrong together. Each arbitrated verdict does double duty, a quality read on the system and fresh calibration that sharpens the graders themselves. For now the team runs that refinement loop by hand; making it run itself is the next stage.
Writing the standard down pays a second dividend: the team has agreed what good means before any single piece of work gets argued about, and a junior engineer can push back on a senior's call by pointing at it. It is also the first glimpse of shared vocabulary the org never had, a gap the journey returns to later.
- Human judgment
- The standard-setter. Their verdicts arbitrate grader disagreements, calibrate the graders, and recalibrate them when the system shifts underneath.
- AI labor
- The judging. One expert's calibrated taste, applied to every run, at no marginal human cost.
Framework investments
- . Climbs from to . The rubric writes the expert's standard down, and calibrated graders apply it to every run. waits until the graders themselves are maintained by the system.
Techniques
- . Graders and deterministic checks that score every run against the written standard, so efficacy is measured continuously instead of argued after the fact.
- . A stronger model, or one from another family, reads the graders' calls and flags the disputes; the standard-setter arbitrates those plus a random sample, and each ruling recalibrates the graders.
- . The recorded verdicts read back as a calibration set, the proof a new grader agrees with the expert before it counts.
To make the whole system better faster, point AI at improving it. Make its restraint structural: it proposes, never applies, and every change clears evaluations the proposer cannot edit, plus a human decision.
By now the team can measure quality well. The next frontier is improving it, and there are a lot of levers: the system's prompts, the tools it is given, the way the work is orchestrated, even the graders' own instructions. Hand-tuning all of that is slow, and it does not scale past the one person who knows where the knobs are.
The answer is a system whose job is improving another system, what some teams call a meta harness. It reads the record of how the work has actually been going and drafts candidate changes across every lever, including the standard itself. It emits proposals, never edits.
What makes that safe is . The meta harness's gates are built in, not left to restraint the proposing agent is trusted to show, and every proposal has to clear two of them before it ships: an automatic evaluation gate, "does it improve the measured scores without breaking anything?", and a human approval. Nothing applies itself, and that rule is deliberately absolute. An auto-applied change is a vibes-based change, and "but I told it not to make mistakes!" is not a gate. The delegation boundary drawn casually back in Stage 1 is now written down and built in: agents propose, humans decide. Building that enforcing machinery is its own journey; the sibling harness field guide walks it.
The same stage attacks another human bottleneck: attention. The arbitration queue the standard-setter curated by hand in Stage 2 is now the system's job, and it surfaces the dozen runs that will teach it the most. The case where two graders disagreed, the random sample that keeps the review honest, the run a user reacted to. And when a proposal is approved, it does not land in one engineer's setup and leave when they do. It lands in the shared configuration every run reads.
- Human judgment
- The decider. Approves or rejects proposed changes, and labels a curated few high-value cases instead of a firehose.
- AI labor
- The drafting and the triage: reading everything, proposing the improvements, ranking the mountain down to a dozen.
Framework investments
- . Finishes the climb to . The graders and the standard are now maintained by the improvement loop itself, not one person's hand-tuning.
- . The propose-and-decide rule stops being a habit and becomes structure: to Structural, baked into the tooling.
- . The evaluation gate joins the checks a change must clear before it lands.
- . Lights up for the first time. What deserves attention next is chosen by written criteria, not the loudest voice.
- . An approved improvement becomes team practice everywhere it applies, instead of staying in the one setup where it was tried.
Techniques
- . The do-not lines that keep a proposer a proposer: nothing it drafts applies itself.
- . The harness carries every proposal to a human, instead of trusting the agent to ask.
- . The written criteria that rank candidate changes and pick the handful of runs worth a human's label.
- . An approved change propagates from one place to everywhere it applies, so a win ships once and sticks.
The most dangerous failures are the ones that look right. Check answers against facts the answers cannot fake, and mine recorded behavior for the dissatisfaction that never reaches a feedback button.
Calibrated graders still miss a whole class of failure: the wrong answer that looks good. A confident, plausible, well-formatted answer that happens to be wrong sails past a plausibility grader the same way it sails past any reader who does not know the business deeply enough for their intuition to trip. An attentive user might feel something is off, but the feeling never reaches the team: no error, no complaint, no thumbs-down. Just a wrong answer someone is now acting on.
The first counter is deterministic: find a fact outside the answer that can contradict it. "Is this grounded in reality?" breaks down into checks that run even when eyeballing the answer tells you nothing. A failure class is real when a check catches it on a real run, not when a reader gets a suspicion. Run those detectors across the whole corpus and they surface the silent failures, the ones no reviewer would ever have been pointed at.
The second counter starts from an uncomfortable fact about feedback: the thumbs-down button lies by omission. Most dissatisfaction never touches it. It shows up as behavior in the conversations themselves. The user pushes back in words, retries the question, or abandons the thread. Mining the record for that behavior yields far more signal than the button ever will. Run it on a cadence so the result is a trend, and a trend only means something if every month is scored by the same definition of dissatisfaction: when the team sharpens the definition, it rescores the old months under the new one. That is the Stage 1 investment in paying out a second time, because you can only re-mine what you captured.
The hunting turns up more than wrong answers; it turns up work for disciplines well outside . Each find is tagged by what it needs and routed to the right expert. A term the system keeps reading differently from run to run is missing shared vocabulary, a gap closed by writing the term down where the agent reads it. A boundary that keeps getting crossed needs a rule. And each detector that proves itself gets ported back into the cheap, always-on checks from Stage 1, where it runs forever.
- Human judgment
- The expert. Makes the subtle correctness calls, the ones that require knowing the business, not just reading the transcript.
- AI labor
- The hunting. Detectors and miners rank a haystack of thousands down to the needles worth an expert's time, including the ones nobody knew to look for.
Framework investments
- . Runs at as a steady state, and starts generating work for disciplines outside its own domain.
- . The subtle calls need a single run reconstructed end to end, with the reasoning alongside the decisions.
- . Evaluation surfaces the missing shared vocabulary; gathering it and writing it where the agent reads it is Collection's work, a Context investment.
- . The proven detectors come home as inline checks: the gate a change must clear just grew a new layer.
Techniques
- . The mining's raw material. Months of recorded conversations, queryable enough to read for behavior instead of button presses.
- . Where a term that needs defining lands. Canonical vocabulary the agent reads instead of guessing.
- . Where a boundary that needs a rule lands. The ruling written down once, with the anti-patterns to avoid.
- . The port-back target. A detector proven in the hunt reruns forever as a cheap deterministic check.
The human’s responsibility climbs
Step back from the stages and one thing is constant: the human never leaves the loop. The human's job changes. At every stage, AI absorbed the work below and the human moved up to something only a person can do.
The responsibilities form a ladder: grader, standard-setter, decider, expert. Each is harder to replace than the one below it, and the journey shows it from the bottom. Stage 2 automated the grader's work, Stage 3 drafts what the standard-setter used to hand-tune, and no stage touched the decider or the expert.
The decider stays human because of the rule built in Stage 3. Nothing applies itself, so every change that ships still passes through a person. The expert stays human because the hardest correctness calls rest on knowing the business, and that knowledge is not in the system: a model can read every conversation ever recorded and still not know which promises the company cannot afford to keep.
That is what maturity actually means here. It was never automation replacing judgment. It is automation concentrating judgment onto the decisions that need a person, and multiplying each of those decisions across the entire system.
The one true ladder here is the human's. The stages themselves are a loop that runs continuously, the later stages feeding the earlier ones: the detectors Stage 4 invented to catch plausible-but-wrong answers were ported back into the always-on pre-filter from Stage 1, a discovery made in the last stage becoming a permanent part of the cheapest, earliest one. That is the framework's principle at practice scale, exploring at the edge and folding what proves out back into shared practice. In steady state all of it runs at once, and no domain sits downstream of another.
Put it to work.
Feel these trade-offs for yourself on a worked example, or take the framework, this guide included, to the agents your team already uses.
Feel it in play.
The game hands you a hypothetical: your team is shipping an authentication service with AI in the loop, and you have eight chips of investment to spread across the twelve disciplines. Place them and you get back a memo reporting how the next six months went under those bets. Move a chip and the memo rewrites, so you can feel exactly where the trade-offs live.
Take it with you.
The bundle is the whole framework in files your agent can read. Give it to Claude, Cursor, or whatever you already use, then ask where your own org stands. It is plain reference material: no code, nothing that runs.
Or install it with one line
mkdir -p ~/.claude/skills && curl -fL https://gobetweenlab.com/working-with-robots/working-with-robots-framework.tar.gz | tar -xz -C ~/.claude/skillsOther field guides
Browse the framework
The agent has what it needs to act.
- CollectionGetting context in: gathering the artifacts an agent needs to orient.
- ManagementKeeping the context your agents read current as decisions and conventions change.
- DisclosureFeeding context in efficiently: routing the agent to the slice it needs, not a data dump.
The agent can only do what it should.
- CapabilityWhat the agent can do: the tools you connect, and the ones you deliberately withhold.
- DelegationWhat the agent should do: the responsibilities you hand over, and the ones you reserve.
- EnvironmentThe system the agent works within: the tests and gates its work must clear, and the points where a human takes over.
The human can see what happened.
- CaptureMaking sure every run leaves a raw record.
- AvailabilityPutting the record of agent work where your team can query and review it.
- TraceWalking back through a single run, end to end, with the reasoning alongside the decisions.
The team gets better over time.
- EvaluationMeasuring whether your processes work, by the numbers and by gut-check.
- PrioritizationChoosing what to change and where to invest next.
- ConvergenceMaking a change stick across the team.