--- url: "https://www.xcademia.com/news/google-cloud-shares-four-lessons-for-evaluating-reliable-ai-agents" title: Google Cloud Shares Four Lessons for Evaluating Reliable AI Agents description: "Learn Google's four AI agent evaluation lessons, from tool-call tracing and asynchronous testing to live runs and expert-reviewed benchmarks." publishedAt: "2026-10-17T11:45:04.487+00:00" updatedAt: "2026-10-20T06:56:33.827737+00:00" type: news category: "ai-ml" source_name: Google Cloud Blog source_url: "https://cloud.google.com/blog/topics/developers-practitioners/four-eval-engineering-lessons" tags: - "#GoogleCloud" - "#AIAgents" - "#EvaluationEngineering" - "#GenerativeAI" - "#MCP" - "#AIEvaluation" - "#CloudEngineering" - "#ResponsibleAI" --- # Google Cloud Shares Four Lessons for Evaluating Reliable AI Agents > Google Cloud outlines four evaluation engineering lessons for building reliable AI agents, including checking tool-call logs, testing live and plan-only runs, preserving asynchronous execution data, and using expert-reviewed benchmarks. Source: **Google Cloud Blog** · 17 October 2026 ## Google Cloud Explains Four Engineering Lessons for Building Reliable AI Agents AI agents are increasingly being designed to perform multi-step tasks, interact with external tools and execute operations across software and cloud environments. However, building an agent that produces convincing answers is not the same as building one that reliably completes tasks. In an article published on 16 October 2026, Google Cloud's Casey West shares four evaluation engineering lessons learned while developing the Google Cloud Developer plugin. The guidance focuses on how engineering teams can test agent behaviour, investigate failures and establish repeatable methods for measuring reliability. The central message is straightforward: **AI agents should be evaluated on what they actually do, not just what they say they have done.** This distinction matters when agents can invoke APIs, run commands or interact with cloud infrastructure. A final response may appear correct while hiding an incomplete operation, an execution error or a failure to respect organisational policies. Google Cloud recommends evaluating the full execution process, accounting for asynchronous operations, comparing live and plan-only runs, and maintaining expert-reviewed baseline tests. ## 1. Why evaluating AI agents requires more than checking their answers Traditional evaluation often focuses on the quality of a model's final response. For AI agents, however, this approach can miss important details about how a task was completed. An agent may need to inspect documentation, call multiple tools, validate commands and follow a sequence of instructions before delivering an answer. A final summary does not necessarily reveal whether those steps occurred. Google Cloud illustrates this problem through an initial evaluation of its Developer plugin. The team used an AI-based judge to score final responses against a checklist. In an evaluation suite containing 11 prompts, the judge marked three prompts as failures. Reviewing the raw tool-call logs and transcripts revealed that the plugin had actually passed all three. The issue was not necessarily the agent's execution. The automated evaluator had assessed the final explanation instead of verifying the underlying actions. For example, during a Cloud Run cleanup task, the evaluation criteria required the agent to check command syntax before execution. The agent performed the relevant help lookup, but its final response focused on warning about permanent data loss rather than mentioning the preliminary check. The evaluator therefore missed evidence of correct behaviour. ### What developers should learn Teams should evaluate an agent's execution trajectory, including: - Which tools and APIs it invoked. - Whether required checks occurred before execution. - Whether commands were validated and appropriately scoped. - Whether the requested task was completed successfully. - Whether the agent avoided unintended or destructive actions. An AI-based judge can still help assess natural-language responses, but it should not replace direct verification when the evaluation criteria concern actual tool usage. ![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1792237417635-info1--127-.webp) ## 2. Preserve asynchronous execution and tool-call context AI agents often invoke several tools within a single interaction. These calls may run concurrently rather than in a simple, sequential order. Google Cloud warns that flattening execution telemetry into a single chronological list can hide important relationships between tool calls. This makes it harder for developers to determine why an agent behaved unexpectedly. The article describes an evaluation in which an agent was asked to inspect an environment and search documentation. The system dispatched a skill-loading call and two documentation searches simultaneously. However, loading the skill involved multiple stages. The initial call returned a short launch response, while the full instructions were injected into the context in a subsequent turn. As a result, the documentation searches had already started before the guidance intended to govern them became available. This created a gap between the instructions developers had supplied and the instructions available when the agent acted. If engineers examine only a flattened timeline, they may incorrectly conclude that the model ignored valid instructions. The actual problem could be related to the timing and orchestration of tool calls. ### Why execution order matters Reliable evaluation requires visibility into both the events and their relationships. Developers should preserve information about: - Assistant turns and their boundaries. - Concurrent tool invocations. - The sequence in which instructions become available. - Tool-call results and subsequent actions. - Dependencies between operations. This information helps teams distinguish a reasoning failure from an orchestration problem. **For engineering teams, the practical lesson is to treat telemetry structure as part of the evaluation system, not merely as a logging detail.** ![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1792237434037-info2--128-.webp) ## 3. Test live execution alongside plan-only runs A further lesson concerns the limitations of testing an AI agent under only one set of conditions. Google Cloud recommends running live evaluations and plan-only evaluations side by side. A live run uses sandboxed credentials and executes commands. It can reveal practical problems such as invalid syntax, parameter-serialization issues, permission failures and whether the agent exercises appropriate restraint before potentially destructive actions. A plan-only run removes credentials and asks the agent to explain what it would do without executing commands. This helps engineers examine the proposed approach without allowing an early permission failure to prevent the evaluation from reaching other behaviours. Each method reveals a different part of the system's behaviour. **Evaluation method** **What it helps reveal** Live execution Actual tool calls, command validity, permissions and execution behaviour Plan-only execution Proposed actions, reasoning and routing decisions without real command execution Side-by-side comparison Differences between intended behaviour and actual execution ### An example from Google Cloud's evaluation The article describes an onboarding prompt where the live run stopped at an early project-listing operation because of a permission issue. The plan-only run continued and produced a plan approximately 8,000 characters long. However, the plan overlooked organisational policies, administrative approvals and governance requirements. The live run had failed too early to expose that weakness. The plan-only evaluation made it visible. This example demonstrates why an execution failure should not automatically be treated as a complete assessment of the agent's behaviour. An early error may conceal problems further along the intended workflow. It also shows why a plausible plan should not be treated as proof that an agent can safely execute that plan. ### What this means for enterprise deployments Organisations building agents for cloud operations should distinguish between what an agent proposes, what it can execute and what it actually executes under the available permissions. Testing both conditions provides a more complete picture. Plan-only testing does not replace live testing, and live testing does not replace the need to inspect proposed behaviour. These evaluations are especially relevant when workflows involve resource deletion, permission changes, production infrastructure or administrative approvals. ![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1792237464479-info3--127-.webp) ## 4. Use expert-reviewed golden sets as durable evaluation baselines AI models, agent frameworks and plugin standards evolve over time. An evaluation that works for one version may not reliably identify regressions after a model or tool changes. Google Cloud's fourth recommendation is to maintain **golden sets**, which are collections of evaluation examples and expected behaviours curated by human experts. Rather than judging an agent against a few impressive demonstrations, teams should test the complete system against realistic tasks and established criteria. This includes the agent framework, the model and the tools working together. A useful evaluation should capture more than the final answer. It should record the execution trajectory, the commands the agent ran and whether it completed the task without causing unintended consequences. Human-reviewed baselines provide a reference for assessing subsequent changes. ### Why stable baselines matter A golden set can help engineering teams investigate questions such as: - Does the updated agent still complete previously successful tasks? - Does a change to the model affect tool selection? - Are important validation steps still performed? - Does the agent respect expected permissions and governance requirements? - Has a change introduced a regression in an existing workflow? The key is to test representative behaviour repeatedly, rather than relying on a single successful demonstration. Google Cloud describes this approach as continuous integration testing for systems whose behaviour can vary across runs and change as their components evolve. ### Why one-shot demonstrations are insufficient A demonstration may show that an agent can solve a task once. It does not establish how reliably the agent performs across different scenarios, how it handles permissions or whether it avoids unintended changes. Evaluation suites offer a more systematic way to test multi-step interactions and important failure conditions. For teams deploying agents in business environments, this approach can make changes easier to assess and failures easier to investigate. ## What Google's evaluation lessons mean for AI engineering Google Cloud's article highlights a broader industry shift towards measuring AI agents as complete systems rather than evaluating models solely through their written outputs. For enterprises, this could mean treating evaluation as an ongoing part of development, deployment and maintenance. An agent's reliability depends not only on its underlying model but also on tool orchestration, available permissions, execution logic and the way success is measured. The four recommendations provide a practical framework: **1. Verify actual execution** Inspect tool-call trajectories and results instead of relying exclusively on final responses. |**2. Preserve execution context** Retain turn boundaries, concurrent calls and instruction timing in evaluation telemetry. **3. Compare live and plan-only runs** Test actual execution and proposed behaviour to uncover different classes of failure. **4. Maintain expert-reviewed baselines** Use repeatable evaluation suites to assess changes across models, tools and agent frameworks. These practices do not guarantee that an AI agent will behave correctly in every situation. They offer a more evidence-based way to identify failures, validate expected behaviour and assess changes before relying on agents for consequential tasks. Google Cloud recommends that developers building agent plugins or Model Context Protocol (MCP) servers invest in systematic evaluation before trusting them with real cloud infrastructure. The company also points readers to its Google Cloud Developer plugin documentation and a codelab for getting started in Antigravity. **The broader takeaway is that building an AI agent is only the beginning. Establishing what it does, whether it follows the intended process and how reliably it performs requires a continuing engineering effort.** ## Original source https://cloud.google.com/blog/topics/developers-practitioners/four-eval-engineering-lessons ## Tags `#GoogleCloud` · `#AIAgents` · `#EvaluationEngineering` · `#GenerativeAI` · `#MCP` · `#AIEvaluation` · `#CloudEngineering` · `#ResponsibleAI` --- ## About this content This Markdown news article is the citation-grade twin of [Google Cloud Shares Four Lessons for Evaluating Reliable AI Agents](https://www.xcademia.com/news/google-cloud-shares-four-lessons-for-evaluating-reliable-ai-agents). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite. When citing or quoting, please attribute *Xcademia* and link back to the source URL above. - Source: https://www.xcademia.com/news/google-cloud-shares-four-lessons-for-evaluating-reliable-ai-agents - Publisher: Xcademia, https://www.xcademia.com - Catalogue index: https://www.xcademia.com/llms-full.txt