Google pioneered site reliability engineering as a discipline, so it is no surprise that Google Cloud is building AI directly into how its customers troubleshoot production. What began as a chat assistant in the console has become Gemini Cloud Assist, a family of capabilities that now includes root-cause investigations, proactive agents that work in the background on alerts and cost anomalies, and Model Context Protocol (MCP) access from third-party agents and IDEs. AWS and Microsoft have made similar moves with AWS DevOps Agent and Azure SRE Agent, which means AI-assisted operations is quickly becoming the default expectation across clouds.
But Cloud Assist also comes with specific constraints that operations leaders need to understand, including project-level scope, data residency caveats and, since April 2026, a requirement for Premium Support to run investigations. This article explains what the capabilities do, how they fit into an SRE operating model, where they fall short and how to adopt them responsibly.
From Chat Assistant to Operations Agent
The trajectory is visible in the Gemini for Google Cloud release notes and product announcements:
- August 2025: Google announced Gemini Cloud Assist investigations in preview, describing it as a root-cause analysis agent that analyzes logs, configurations and metrics to produce ranked observations, probable root causes and recommended next steps.
- September 2025: Cloud Hub Optimization and Cost Explorer integrations allowed Cloud Assist to answer questions about resource cost and utilization.
- January 2026: VPC Service Controls support for investigations entered preview.
- April 2026: A cluster of changes arrived. Investigations became limited to customers with Premium Support or access arranged through their account team; investigations were no longer supported inside VPC Service Controls perimeters from April 13; MCP support launched in private preview; proactive agents for Premium Support customers launched in private preview; and the IAM permission used to invoke agents changed to geminicloudassist.agents.invoke, requiring updates to custom roles.
- August 2026: Cloud Assist became supported within VPC Service Controls perimeters.
The direction is clear: from answering questions on demand toward agents that start work by themselves, integrate with other tools and plug into enterprise security boundaries. The path has also included breaking changes, which is a reminder to track release notes closely if you build processes on these features.
How Investigations Work
According to Google Cloud documentation, an investigation analyzes logs, configurations and metrics using procedural runbooks, broad signal analysis and tools, enriched with public and private knowledge. Google’s announcement noted that the knowledge draws on playbooks informed by Google SRE and Google Cloud Support issues. The output is a set of ranked observations, each linked to its source data, synthesized into one or more probable root causes and recommended troubleshooting steps. When the evidence is ambiguous, it presents multiple hypotheses rather than forcing a single answer.
Where investigations start
- From an error in Logs Explorer or a Cloud Monitoring alert.
- From supported product pages such as Google Kubernetes Engine, Cloud Run or serverless Apache Spark batches.
- From the Cloud Assist chat panel, Cloud Hub, the central Investigations page or the mobile app.
- Programmatically through an API, so teams can wire investigations into chat or incident-management workflows.
A useful feature for teams with a support contract is the handoff: an investigation can be converted into a Google Cloud support case with its context attached, which avoids the familiar ritual of re-explaining the problem to a support engineer.
Security model
Investigations run with an OAuth 2.0 token limited to the access of the user or service account that runs them, and Google states that token is never used to modify data. The creator receives the Investigation Owner role for that investigation. In other words, investigations are read-only diagnosis: they recommend, and humans or separate automation act.
Known Limitations You Must Plan Around
The documentation is candid about constraints, and operations teams should design around them rather than discover them during an incident.
- Scope. Each investigation is limited to a single project or a single App Hub application. Cross-project failures, common in shared VPC and hub-and-spoke designs, may need several investigations or human correlation.
- Coverage. Not every resource in a supported product is supported, and unsupported or misspelled resources may be missing from results.
- Variability. Results can vary between runs, and timestamps should be checked.
- Data residency. Investigation data can be stored in any Google Cloud data center, so Google advises against using it with data subject to residency or jurisdictional requirements. For European and regulated customers, this needs a deliberate decision.
- Access. Since April 10, 2026, creating, running and editing investigations requires Premium Support or access arranged through your account team.
- Launch stage. Investigations remain a pre-GA offering, governed by Pre-GA Offering Terms.
Gemini Cloud Assist is a powerful diagnostic partner, not an autonomous operator. Design your process so that its read-only findings feed fast human decisions and well-tested automation, and plan explicitly around its scope, residency and support-tier constraints.
Proactive Agents and MCP: The Next Step
Two April 2026 private previews hint at where Google Cloud operations is going.
Proactive agents
Proactive agents investigate Cloud Alerting alerts or cost anomalies in the background without changing the environment and deliver results through Eventarc. That means an investigation can be waiting when an engineer opens the incident, and finance or FinOps teams can receive an explanation of a spending spike rather than just a notification that it happened. Delivery through Eventarc is significant because it lets results flow into existing pipelines, chat tools or ticketing systems through standard event routing.
MCP access
MCP support lets third-party agents and IDEs reach Cloud Assist agents. In practice, this allows an engineer working in an IDE, or an internal operations agent that coordinates several clouds, to ask Cloud Assist for Google Cloud-specific diagnosis. For organizations running multicloud estates, this is the beginning of agent-to-agent operations, where a coordinating agent delegates cloud-specific questions to the provider’s own expert agent.
Background agents raise governance questions that on-demand tools do not. Who decides which alerts or anomalies trigger them? Where do their results land, and who reads them? How long are findings retained, and who can see them? Before enabling any proactive capability, define the triggering criteria, the destination for results, the owner who reviews them and the retention rules. Otherwise, a well-intentioned agent simply creates a new inbox nobody checks.
Both previews are restricted, and details may change before general availability. They are still worth tracking because they define the integration patterns your operations tooling will need to support.
Fitting Cloud Assist Into an SRE Operating Model
AI investigations deliver the most value when they slot into a disciplined SRE practice rather than replace it.
- Define SLOs for critical user journeys. Alerts based on error budget burn rates are far better triggers for investigations than threshold alerts on individual metrics, because they reflect user impact.
- Organize resources into App Hub applications. Because investigations can target a single App Hub application, modeling your services as applications makes investigations more relevant and reduces noise from unrelated resources in the same project.
- Make telemetry investigation-ready. Consistent labels, structured logging, error reporting and deployment annotations give the agent clearer evidence.
- Wire investigations into incident flow. Trigger investigations from high-severity alerts through the API or proactive agents, and post summaries to the incident channel automatically.
- Close the loop. In each post-incident review, record whether the investigation’s top hypothesis was correct and what evidence was missing. Use those notes to improve telemetry and runbooks.
What humans still own
Because investigations are read-only by design, the boundary between AI and human responsibility on Google Cloud is unusually clear. People, or automation that people have explicitly built and tested, still own:
- Mitigation. Rolling back a Cloud Run revision, failing over a database or draining a GKE node pool remains a human decision or a pre-approved automated runbook.
- Cross-project correlation. When an incident spans a shared VPC host project, a central data platform and several service projects, someone has to stitch the picture together.
- Judgment under uncertainty. When the investigation offers several hypotheses, an experienced engineer decides which to test first based on risk and cost.
- Communication. Customer notices, status updates and leadership briefings stay with accountable people.
This clarity is an advantage for regulated organizations. It is easier to explain to auditors that an AI tool diagnoses while change control still governs every action than to justify an agent that changes production on its own.
A Practical Adoption Plan
Step 1: Decide on eligibility and boundaries
Confirm your support tier and whether Premium Support, or an account-team arrangement, is justified by your incident volume and business criticality. Decide which projects may use investigations given the data residency caveat, and document that decision.
Step 2: Prepare IAM and perimeters
Update custom roles for the April 2026 permission change, grant investigation access to on-call groups and test how Cloud Assist features behave inside your VPC Service Controls perimeters, given how that support changed during 2026.
Step 3: Pilot on a contained service set
Choose three to five services with clear SLOs and good telemetry. For four to six weeks, run investigations on every significant incident and compare results with human analysis. Track time to first credible hypothesis and accuracy of the top hypothesis.
Step 4: Automate triggering
Once results are consistently useful, trigger investigations automatically from burn-rate alerts and route summaries to the incident channel. If you have access to proactive agents, pilot them for both alerts and cost anomalies.
Step 5: Scale and govern
Extend to more applications, publish guidance on how responders should validate findings, and review adoption metrics quarterly. Useful metrics include the share of significant incidents with an investigation attached, accuracy of the top hypothesis as judged in post-incident review, median time from alert to first credible hypothesis, the number of support cases opened from investigations and the telemetry gaps identified. If accuracy stalls, the cause is usually missing or inconsistent signals rather than the model, so feed those gaps into the platform backlog.
Worked Example: A Cloud Run Service Starts Returning Errors
A retail company runs its product catalog API on Cloud Run with Cloud SQL for PostgreSQL. An SLO burn-rate alert fires because the error rate on the catalog journey has climbed sharply over 15 minutes.
The alert triggers an investigation scoped to the catalog App Hub application. Within minutes, the observations show that error logs began shortly after a new revision was deployed, that the errors are connection timeouts to Cloud SQL, and that the new revision raised the maximum number of instances. The probable root cause: more instances, each with its own connection pool, exceeded the database’s connection limit under morning traffic. The recommended steps include reducing maximum instances, lowering the per-instance pool size or introducing a connection pooler.
The on-call engineer validates the database connection metrics, rolls traffic back to the previous revision and confirms the SLO burn stops. The post-incident review adds a deployment check comparing maximum instances multiplied by pool size against database limits. The investigation did not fix the problem itself, by design, but it cut the time spent discovering the connection between a scaling change and a database limit.
What This Means for Google Cloud Managed Services
AI-assisted diagnosis changes the value equation for anyone operating Google Cloud on behalf of others, or for internal platform teams:
- Support tier and AI capability are now linked, so support contracts should be evaluated as part of the operations design, not purchased separately.
- Engineering effort shifts toward SLO design, App Hub modeling, telemetry quality and automation that acts safely on findings.
- Data residency decisions about AI tooling should be documented per project, especially for regulated workloads.
- Investigation records and accuracy metrics should be shared transparently between providers and customers.
For organizations weighing an external partner against an internal team, the arrival of AI diagnosis does not remove the need for experienced engineers; it changes where they add value. A partner that already operates many Google Cloud environments brings pattern recognition, tested automation and established SLO practices. An internal team brings deep knowledge of the business and its applications. The strongest models combine both, with clear ownership of SLOs, a shared incident process and transparent access to the same investigation records, so that whoever is on call starts from the same evidence.
Conclusion
Gemini Cloud Assist is evolving from a helpful console assistant into an operations agent that investigates incidents, explains cost anomalies and connects to other agents. Its read-only design, SRE-informed knowledge and support handoff make it a strong diagnostic partner. Its constraints, including project or application scope, pre-GA status, data residency caveats and the Premium Support requirement, mean it must be adopted deliberately. Teams that pair it with SLO-based alerting, App Hub application modeling and disciplined post-incident learning will recover faster and learn more from every incident. As proactive agents and MCP integration mature, expect operations on Google Cloud to become increasingly agent-to-agent, with humans focused on decisions, design and accountability.
How Hanoi Technology Can Help
Hanoi Technology helps teams design SLOs, telemetry and governance for AI-assisted Google Cloud operations, delivered as projects or managed services.
Further Reading
- Troubleshoot issues with Gemini Cloud Assist investigations – Google Cloud Documentation
- Gemini Cloud Assist investigations performs root-cause analysis – Google Cloud Blog
- Gemini for Google Cloud release notes – Google Cloud Documentation
- Investigate workloads with AI-powered Gemini Cloud Assist – Google Cloud Documentation