What We Knew We'd Need

I was catching up on the ecosystem radar this week — the one we built to watch Google's feeds and then made public — and found a post from the end of July: agent and model evaluations in Google's agent platform are now generally available. I read it twice. Not because it surprised me, but because it didn't. Stage by stage, it described the thing that has been running against our own platform at one in the morning since July 20.

This is not a post about who got there first. It is a look at what it means when a platform the size of Google ships the shape you had already arrived at — and at the two places where a Canadian clinic forces that shape to bend.

What Google shipped

The announcement is worth reading straight, without my gloss. Twenty-plus metrics, the interesting ones being what they call adaptive rubrics: a model that reads your test case, your agent's instructions and its tool declarations, and writes case-specific pass/fail tests on the spot. Issue clustering that groups failures into named piles. A simulated user so you can generate traffic before you have any. And the headline feature — online evaluation: “continuous evaluation on live production traffic,” with score-over-time charts and drift alerts.

A companion post from June lays out the loop this all serves, in five stages: prepare data, run inference, grade, analyze failures, optimize and iterate. Then it states the principle that holds the loop honest, and I want to quote it exactly, because it is the most important sentence in either post: “whatever proposes a fix — your coding agent, an automated optimizer, or you — never grades it.” The optimizer and the evaluator stay decoupled.

What had been running since July 20

Eleven days before that announcement I wrote about the system that checks itself: a nightly rehearsal on our own production stage, against two synthetic clinics — one in the United States, one in Montréal — graded by the platform's own audit trail. Two weeks later I wrote down what it had caught. Lay the five stages beside it and the mapping needs no imagination.

• Prepare data — every night the harness seeds fresh documents into both synthetic clinics through the real ingestion path, one of them deliberately broken so the escalation branch is exercised too.
• Run inference — then it drives the product end to end: retrieval, document creation on both residency paths, a real agent conversation, memory, and since last week, a dictated clinical note from recording to filed record.
• Grade — the pass/fail hinge is the audit trail itself. Every step must have left the cards it is supposed to leave, in the order it is supposed to leave them, under the trace of that night's run.
• Analyze failures — on a red night, a bounded diagnosis pass reads the failure record and drafts a narrative for the alert. On a green night it sends nothing at all.
• Optimize and iterate — the fix goes in the next morning, and the following night's run is its proof.

Their decoupling principle is one we had already written into our own rules in blunter language: never soften the canary. When the probe raised a false alarm in July, we recalibrated the alarm and left the probe intact. The thing that proposes fixes — me, or an agent working for me — is never the thing that decides whether the fix worked.

The first fork: who does the grading

In Google's loop, the grader is a model. An adaptive rubric is a language model judging a language model: it reads the trace, writes the criteria, and scores the result. That is genuinely powerful — it can answer a question our instrument cannot. Our nightly run asks did it happen: did the note get filed, did the audio get destroyed, did the cards land. A rubric asks was it good. This week our first live use of a new feature produced a reply that was entirely correct and nearly unreadable — internal identifiers, narration, the transcript pasted underneath. Every card was in place. No probe of ours would have blinked. A rubric would have.

So why is our grader mechanical? Because of the argument I made a week ago in The Human in the Loop Was the Target: the moment an agent's path to “done” runs through a judgment, that judgment becomes the thing to optimize for. A model grading a model can be argued with, can drift, can be persuaded by a well-phrased trace. A check that asks whether a specific record exists with specific fields cannot. In a clinic, the grade is not a quality score for a dashboard; it is the answer to whether the system did what the custodian of that record is accountable for. That answer has to come from something that cannot be talked into it.

We do use a model in the loop — on the interpreting side, not the deciding side. The diagnosis pass that drafts the alert narrative is a model, and its output is labelled as what it is: a hypothesis, sitting beside a mechanical result that stands on its own whether the hypothesis is right or wrong. That is exactly the division we want: the machine grades; the model explains; a person decides.

The second fork: where the grading happens

The online monitor is the feature I would most like to have. It grades live traffic — real conversations, as they happen, with scores over time and an alert when quality drifts. For a clinical agent that is the dream instrument.

Here is the documented list of regions where Google's evaluation service runs: seven in the United States, seven in Europe, and a global endpoint. Not one in Canada.

A clinic in Alberta is the legal custodian of its patients' health information. The custodian has to know, in writing, where that information goes and what is done with it there. Our answer for a Canadian clinic is one region: Google's Montréal region, northamerica-northeast1. The records live there. The nightly check runs against them there. The agreement the clinic signs names the one jurisdiction any model call is made in. Nothing about the loop leaves Canada.

An online monitor that grades live traffic would take those same conversations — the real ones, with patients in them — and send them somewhere to be marked. The nearest somewhere is Iowa. The feature that makes their product compelling is the exact feature a Canadian clinic cannot use on the traffic where it would matter most. That is not a flaw in Google's product; it is a general tool meeting a specific industry in a specific country, and the country wins.

What we will borrow

The quality axis is real and we want it. So we will add it where it is safe to add: to the two synthetic clinics, whose traffic contains no one, graded in the region where that traffic already lives. A model judging a model is fine as a second opinion on synthetic data; it will never be the hinge, and it will never see a patient.

What we knew we'd need

I want to be plain about the conclusion, because it is easy to misread a post like this as a scoreboard. When we designed the nightly check, we were not trying to anticipate Google. We were working backwards from what a Canadian clinic requires of a system that acts on its behalf: a record the clinic can read, a grader nobody can talk into a pass, and a border the data never crosses. The five stages fell out of that. They would fall out for anyone who took the same constraints seriously, which is why Google has them too.

What the GA announcement confirms is the loop. What it cannot supply is the adaptation — the two forks that healthcare in Canada makes non-negotiable. We didn't choose them because they were clever. We chose them because we knew we would need them, and this month a much larger company described the rest of the machine in enough detail that I could finally see, clearly, which parts were ours.

I have been adding to a list of questions any clinic should ask an AI vendor, ourselves included. Here is the sixth: when your system grades itself, where does the grading happen — and who does the grader work for?

---