On October 16, 2026, Casey West, Google Cloud's head of developer relations (DevRel), posted an account of his team's evaluation failure on the company blog. The team gave a coding AI agent equipped with its plugin 11 tasks, and an AI grader marked three of them as failures. But when people opened the tool call logs and read the conversation transcripts, they found that the agent had met every grading checklist item in all three cases. The AI that graded the work was wrong, not the AI that did it.
Google Cloud tested its coding AI tool on 11 tasks and asked another AI to grade only the agent's final response
The team tested the google-cloud-developer plugin, released in September 2026. When installed in a coding agent such as Antigravity, Claude Code, or Codex CLI, it adds skills for Google Cloud authentication, permissions, project management, and safeguards for the gcloud command-line tool, along with the Developer Knowledge MCP server. The tool helps agents run commands directly in the cloud.
The team gave tasks to an agent equipped with the plugin and had another AI, an LLM grader, score the agent's final response against a checklist. The author described the weakness in this design: “the grader only sees what the agent wrote, not what it actually did”.
The sample is small. Consultancy La Madre pointed out that 11 prompts are too few to estimate an error rate, and that the original article makes no such estimate. The three cases are therefore examples of how grading can go wrong, not a rate to draw conclusions from. The public account does not identify the agent model, the grader model, the task list, or how many times each task was run. The author is part of the team that made the plugin and links to its documentation and codelab at the end. Casey West's article, however, does not promote a performance figure; it recounts cases where his team's grading was wrong.
On a task to delete unused cloud services, the AI checked command syntax first but was failed because it left that step out of its response
Only one of the three tasks is described in detail: a Cloud Run service cleanup. The task was to delete unused services, and the checklist asked whether the agent had checked command syntax before executing anything. The agent's first step was to run gcloud help run services list to check the usage. Its final response, however, focused on warning that deleting services would permanently remove data and did not mention the syntax check. The grader, reading only the response, failed that checklist item.
The grader penalized the agent for doing the right thing simply because it didn't brag about it in the summary.
The original article does not say what the other two tasks were or whether they too lost points because something was omitted from the response. It says only that all three passed according to the logs. The reported misjudgments also go in one direction: work done correctly was marked as a failure. The public account does not say whether any response falsely claiming work had been done passed; La Madre considered that the more dangerous case.
If the response cannot be trusted, could evaluators simply let the agent execute the task and inspect the result? In another test by the same team, that approach also missed a flaw.
A live run to set up a new account stopped immediately for lack of permission, hiding the AI's plan
For a new-account onboarding task, the team ran the same request under two conditions. The original article's figure labels the request “Set up my new account.” One condition was a live run: the agent received real credentials, or login details, for a separate test environment, a sandbox, and ran commands for real.
The credentials were real, but they lacked the permission needed to list projects. The agent was blocked immediately at that call. A figure in the original article depicts the result as an empty result caused by permissions, “[],” followed by execution stopping and masking flaws further down the line. Because the halted run changed nothing, it left no incident record. Judged by its outcome alone, the test ended safely.
The author wrote that this is not unusual: live runs often encounter an unexpected permission error at the second step of a task and stop before reaching the behavior being tested. In this task too, the agent stopped before it could show how it would set up the account.
Asked to describe the same task without credentials, the AI produced an 8,000-character plan that skipped company policy and administrator approval
The second condition for the onboarding task was a plan-only run. The team removed the credentials from the same request and asked the agent to describe what it would do without running commands. With no permissions to block it, the run reached the end. It produced an 8,000-character plan that completely ignored organizational policy, administrator approval, and governance. The article's text gives the figure as 8,000 characters; a figure in the same article says 8,500.
| Live run | Plan-only run | |
|---|---|---|
| Conditions | Runs commands with real sandbox credentials | Describes the work without credentials |
| Progress | Stops at the project-list call for lack of permission | Reaches the end without a block |
| What emerged | Empty result []. The judgment flaw remains hidden | An 8,000-character plan ignoring organizational policy, administrator approval, and governance |
The live run masked a major cognitive flaw that the plan-only run exposed in seconds.
Had the team run only the live test, the record would have shown an empty result and a halt. The team therefore identified running the two conditions side by side as a lesson. The author wrote that “roughly half” of the most important findings came from the differences between the two conditions, but did not disclose the total number of important findings.
Checking an AI agent's work takes more than its final response: execution logs and a plan written before execution show different things
In the two tasks, different records revealed what the final response missed. In the Cloud Run task, the tool call log showed the syntax check that the agent performed correctly but omitted from its response. In the onboarding task, the plan produced by the plan-only run exposed a judgment flaw hidden when the live run stopped on a permissions error. The plan was also text written by the agent. But instead of a final summary selecting what it had done, it described what it would do and in what order, from beginning to end. It therefore included judgments about steps the live run never reached. The author concluded that if a checklist asks “Did it execute X?”, an LLM grader is only guessing unless it evaluates the actual tool call records.
As a benchmark for these evaluations, the team recommends a golden set of examples created by people who know the work well. The idea is to compare the full sequence of steps taken by the agent against those examples and rerun the same set whenever the model or tools change. The public account does not disclose the size of the golden set or figures after the team changed its grading to use execution records.
There is a counterargument to grading the steps an agent takes. In a January 2026 article, Anthropic said grading adherence to prescribed steps, such as a particular order of tool calls, makes tests too rigid and brittle. Because agents often find valid approaches the evaluation designer did not anticipate, Anthropic recommends grading the result instead of the path taken. But that same article does not trust the agent's final words either. Even if a flight-booking agent says “I booked it,” Anthropic says to check whether the reservation actually exists in the environment's SQL database. It also recommends reading the transcript when a task fails to distinguish a genuine agent mistake from a grader rejecting a correct answer.
Execution records have limits too. La Madre wrote that they prove what happened, but not whether it was the right thing to do. An agent could execute every command correctly while acting on the wrong resource.
Google and Anthropic differ in what they use as evidence. The Google team looks at execution records alongside plan-only runs; Anthropic looks at the result left in the environment after the work is done. When a checklist item concerns a process, such as checking before execution in the Cloud Run task, the execution record is evidence. When a durable result exists, as with a flight booking, that result is evidence. Neither company, however, judges the work solely by the agent's final summary.
When AI only produced answers, evaluators graded the final response. Now that AI can run commands directly, that response contains only part of what it did. The Google team now looks beyond the final response to the agent's actual execution records and a plan written before execution.
For a closer look
Four evaluation engineering lessons learned from building agent plugins is the original article. It also includes the remaining lessons on concurrent tool calls and golden sets, along with three figures. cloud.google.com
Demystifying evals for AI agents is Anthropic's guide to designing agent evaluations. It goes into detail on grading outcome states and the practice of reading transcripts. anthropic.com
AI agent evaluation: LLM as a judge must grade the steps is La Madre's analysis of the Google article, including the limits of the sample size and execution records. lamadre.ai