Google's grader failed three agent runs that had passed. It was reading the summary, not what the agent did
Google published four evaluation lessons from building an agent plugin: grade the execution trajectory, keep turn structure, compare live and plan-only runs, and baseline on expert golden sets.
Listen to this article · 5 min
AI-generated narration of the full article.
An agent is asked to clean up Cloud Run services. The task requires it to check the command syntax before running anything. Its first step is exactly that: gcloud help run services list. Its final message, though, dwells on warning the user about permanent data loss. The automated grader reads the final message, does not find the syntax check, and marks the run as failed.
The agent passed. The evaluation failed.
That is the first of four lessons Casey West, who leads developer relations for AI infrastructure at Google Cloud, published on October 16 from building the Google Cloud Developer plugin for coding agents. In the initial suite of 11 prompts, the LLM judge marked three runs as failures that the raw tool-call logs showed were passes. Eleven prompts is far too few to estimate an error rate, and the post does not try. Its value is in naming four ways agent evaluations mislead, each with a concrete mechanism.
The summary is the agent’s opinion of its work
An agent’s final message is a report written by the party being evaluated. It can understate work it did, as here, or describe work it never did, which is the more dangerous case. A judge that grades the summary is grading the agent’s narrative skills.
Google’s fix is to score the trajectory: which commands ran, with which arguments, in which order, whether checks came before destructive steps and whether actions stayed in scope. This is not new as an idea; Microsoft’s agent experience playbook used trajectory analysis too. What is new is a clean, documented example of the summary-based judge producing false failures on a small suite, which is exactly where teams tend to trust it.
Parallel calls hide ordering bugs
The second lesson is subtler. The harness sent a skill-loading call and two documentation searches in a single batch of tool calls. Skills load in stages, so the skill’s instructions arrived after the searches had already run without them. Telemetry flattened into a simple event list made the calls look sequential and hid the problem.
For anyone building evaluation pipelines: keep the turn structure in your traces. An agent that does the right things in the wrong order, or in parallel before its guidance arrives, will pass a checklist and fail in production.
Run it live, run it as a plan, compare
The third lesson is the most practical. Run each evaluation prompt twice: once live, with real but sandboxed credentials, where the agent executes commands, and once plan-only, with credentials stripped, where it explains what it would do. Live runs test syntax, parameter handling and restraint before destructive actions. Plan-only runs expose intent that permission errors would otherwise hide.
In one onboarding prompt, the live run stalled on a blocked project listing; the plan-only run produced an 8,000-character plan that ignored organization policies, admin approvals and governance entirely. According to the post, roughly half of the most important findings came from the difference between the two conditions.
| What it catches | What it misses | |
|---|---|---|
| Final message, graded by a judge | Wrong conclusions in the answer | Work done but poorly described; work described but never done |
| Execution trajectory | Wrong commands, skipped checks, scope drift | Whether the action suited the business situation |
| Live run, sandboxed credentials | Syntax, parameters, restraint before destructive steps | Intent hidden behind permission errors |
| Plan-only run, no credentials | Reasoning gaps, ignored policies and approvals | Anything that only breaks on execution |
| Expert golden set | Regressions when the model or harness changes | Cases nobody has written down yet |
Golden sets test the system, not the model
The fourth lesson treats evaluation as continuous integration for a non-deterministic system. Runs are scored against golden sets curated by human experts that capture what the agent should think, which commands it should run and whether it solved the problem without breaking anything. The baseline is the whole stack, harness, model and plugins, because any of them can change.
Where this leaves enterprise teams
AWS’s account of its sales agents, published the same day, reached a compatible conclusion from a different direction: deterministic checks for known answers, judges only for the rest, evaluation built into every release. Google adds the execution side: for an agent that acts, the record of what it did is the primary evidence and its own account of what it did is secondary.
One limit is worth keeping in mind. A trajectory proves what happened, not that it was the right thing to do. An agent can run every command correctly against the wrong resource. Trajectory grading answers “did it do what we specified?”; the question “was this the right action here?” still needs reference cases written by people who know the business, and, for consequential actions, someone who approves before execution.