The classic decision about how to operate Google Cloud workloads, whether to build an internal operations team or hire a managed service provider (MSP), used to turn on a fairly stable set of factors: the cost of round-the-clock coverage, access to scarce skills and how much control the business wanted. In 2026, a new factor has entered the equation. AI agents that investigate incidents, explain cost anomalies and suggest fixes are now part of every major cloud platform, including Gemini Cloud Assist on Google Cloud, and they are changing what operations work actually consists of.
That does not make the decision simpler. It makes it different. Some tasks that once justified an MSP, such as eyes-on-glass monitoring and first-level triage, are increasingly handled by agents. Other tasks, such as designing service level objectives (SLOs), governing agent access and turning incident learning into engineering change, become more important. This guide offers a structured way to choose between an MSP, an in-house team and a hybrid model for Google Cloud in the AI era.
What AI Is Changing About Cloud Operations
Across the three hyperscalers, the pattern is consistent. Google offers Gemini Cloud Assist investigations, which analyze logs, configurations and metrics to propose probable root causes, and in April 2026 introduced private previews of proactive agents that investigate alerts and cost anomalies in the background, along with MCP access for third-party agents and IDEs. AWS made AWS DevOps Agent generally available in March 2026, and Microsoft made Azure SRE Agent generally available the same month. The details differ, but the effect on operations work is similar:
- Triage compresses. The first hour of most incidents, spent gathering context across logs, metrics and deployments, shrinks when an agent assembles a first hypothesis in minutes.
- Knowledge becomes reusable. Runbooks, playbooks and past incidents feed directly into agent reasoning, so documented knowledge pays off on every incident.
- Telemetry quality becomes decisive. Agents can only reason about signals they can see, so structured logging, consistent labels and deployment markers directly determine results.
- Governance work grows. Someone must decide what agents can access, what they may do, where their data is stored and how their output is reviewed.
There is also a commercial twist. On Google Cloud, creating and running Cloud Assist investigations has required a Premium Support contract, or access arranged through an account team, since April 10, 2026, and the proactive agents preview is aimed at Premium Support customers. On AWS, support plan customers receive monthly credits toward DevOps Agent usage. AI operations capability is becoming tied to support relationships, which means the support tier is now part of the operating model decision, not a separate procurement line.
The Three Operating Models
In-house operations
Your own platform or SRE team owns monitoring, incident response, change management, cost management and reliability engineering. You may still buy Google Cloud support and use partners for projects, but day-to-day operations are internal.
Strengths: deep business context, direct control over priorities, close collaboration with product teams and full ownership of knowledge. Weaknesses: the cost and difficulty of staffing round-the-clock on-call, key-person risk in small teams, and the challenge of keeping skills current across a fast-moving platform.
Fully managed by an MSP
A provider operates the environment under a contract with defined service levels, typically covering monitoring, incident response, patching, backup oversight, security posture and cost reporting.
Strengths: immediate coverage, access to engineers who have seen many environments, predictable costs and mature processes. Weaknesses: less business context, risk of ticket-driven rather than outcome-driven work, potential lock-in to the provider’s tooling and knowledge, and contracts that may lag behind how AI changes the work.
Hybrid or co-managed
Responsibilities are split. A common pattern is that the internal team owns architecture, SLOs and product-facing reliability decisions, while a partner provides after-hours coverage, platform operations, automation engineering and specialist depth. Another pattern is a dedicated partner team embedded in the customer’s processes and tools.
Strengths: combines business context with scale and specialist skills, and allows gradual capability transfer in either direction. Weaknesses: requires clear ownership boundaries and disciplined handoffs, or incidents fall between the cracks.
A Decision Framework With Eight Criteria
Score each criterion for your situation, then look at where the weight falls. No single criterion should decide on its own.
- Business criticality and SLO strictness. Revenue-critical, customer-facing services with tight SLOs need fast, context-rich response. That favors strong internal ownership of SLOs, with either internal or partner on-call.
- Scale and complexity. A handful of projects and services may not justify a full internal SRE function. Hundreds of projects, GKE fleets and data platforms may justify an internal core plus partner scale.
- Coverage requirements. True round-the-clock coverage needs enough people for sustainable rotations. Small teams struggle to provide it without burnout; partners with follow-the-sun delivery can.
- Skills availability. Assess whether you can hire and retain people with Google Cloud networking, GKE, data platform, security and SRE skills in your market at a sustainable cost.
- Regulatory and data constraints. Data residency, sovereignty and audit requirements affect which people, locations and AI tools may touch your environment. Cloud Assist investigations, for example, may store data in any Google Cloud data center, which Google advises against for data with residency or jurisdictional requirements.
- Pace of change. Teams that deploy many times a day need operations deeply integrated with engineering. That favors internal ownership or an embedded partner team rather than a ticket-based service.
- Support tier and AI access. Determine whether your support contract enables the AI capabilities you plan to use and who holds that contract: you or your provider.
- Strategic intent. Is cloud operations a capability you want to own long-term, or a utility you want delivered reliably? The answer should shape everything else.
In the AI era, the question is less “who watches the dashboards” and more “who owns SLOs, telemetry, agent governance and the engineering backlog that prevents incidents.” Decide that first, and the right operating model usually follows.
How AI Shifts the Economics
Traditional MSP pricing often scaled with the number of resources, servers or tickets. As agents absorb first-level triage, that model becomes less aligned with value. Watch for these shifts when evaluating providers or building an internal business case:
- Labor for monitoring and triage should fall. If a provider’s proposal still prices large teams for round-the-clock dashboard watching, ask how agents and automation are used.
- Engineering work should rise. SLO design, App Hub application modeling, telemetry improvements, runbook automation and prevention work deliver the long-term gains. Budget for them explicitly.
- Tooling and support costs matter more. Premium Support, agent consumption on other clouds and observability costs become a larger share of total operations spend. Make sure the model accounts for who pays.
- Outcome-based terms become feasible. Faster, more consistent diagnosis makes it reasonable to tie part of the commercial model to SLO attainment, mean time to restore and repeat-incident reduction.
For in-house teams, the same logic applies. AI tools may not reduce headcount, but they should change the mix of work, shifting senior engineers from repetitive diagnosis toward reliability engineering that reduces incident volume over time.
Designing a Hybrid Model That Works
For many mid-sized and large organizations, a hybrid model is the practical answer. Making it work requires explicit design across five areas.
1. Ownership matrix
Create a responsibility matrix covering SLO definition, alert design, incident command, mitigation approval, change management, security posture, cost management, backup oversight and post-incident review. For each, name who is responsible, who is accountable, who is consulted and who is informed. Ambiguity here is the most common cause of hybrid failure.
2. Shared tooling and evidence
Both parties should use the same observability, incident and ticketing tools, and the same AI investigation records. If your partner runs investigations in projects you cannot see, or vice versa, you lose the shared evidence that makes collaboration efficient.
3. Agent governance
Agree on which AI capabilities are used, under whose identities, with what IAM permissions and in which projects. Document data residency decisions per project. Ensure custom roles are maintained when providers change permissions, as Google did in April 2026 when the permission for invoking Cloud Assist agents changed.
4. Learning loop
Hold joint post-incident reviews and maintain a shared prevention backlog with owners and due dates. Measure how many prevention items are closed each quarter and whether repeat incidents decline.
5. Exit and knowledge portability
Make sure runbooks, automation code, infrastructure-as-code, dashboards and agent configuration live in repositories you own. A hybrid model should make you stronger over time, not more dependent.
Questions to Ask a Google Cloud MSP in 2026
- How do you use Gemini Cloud Assist and other AI tools in incident response, and how do you validate their findings?
- Who holds the Google Cloud support contract, and how does that affect access to AI investigation features?
- How do you handle data residency for AI tooling in regulated projects?
- How do you define and report SLOs, and will you commit to SLO-based outcomes?
- What share of your effort goes to prevention and automation versus reactive work, and how do you report it?
- Where do runbooks, automation and infrastructure-as-code live, and who owns them?
- How do you manage IAM for your engineers and any agents, including break-glass access?
- What happens to our knowledge and tooling if we end the contract?
A 90-Day Transition Roadmap
Whichever model you choose, changing how operations is delivered is itself a risky project. A phased transition reduces the chance of a gap in coverage.
- Days 1–30: Baseline and design. Inventory projects, services, alerts, runbooks and on-call arrangements. Record current metrics such as incident volume, time to restore, after-hours pages and SLO attainment where SLOs exist. Draft the ownership matrix and confirm support-tier and AI-tool decisions, including data residency choices per project.
- Days 31–60: Shadow and harden. If a partner is joining, run a shadow period in which they observe incidents and changes alongside the current team. Fill the most important telemetry and runbook gaps, organize key services into App Hub applications and define SLOs for the top customer journeys. Pilot AI investigations on a contained set of services.
- Days 61–90: Cut over in waves. Transfer responsibilities service group by service group, starting with lower-risk workloads. Hold a joint review after each wave. Switch reporting to outcome metrics and start the shared prevention backlog.
Plan for a short period of overlap in which both the outgoing and incoming arrangements are active. The cost of a few weeks of overlap is small compared with the cost of a major incident during a handover that nobody fully owns.
Worked Example: A Scale-Up Choosing Its Model
Consider a software scale-up with a platform team of four engineers running about 60 Google Cloud projects: a GKE-based product, Cloud SQL and BigQuery for analytics. Customers are in North America and Europe, the product has a contractual 99.9 percent availability commitment, and on-call is wearing the team down. The company is also preparing for a security audit.
Scoring the criteria, business criticality is high, scale is moderate, round-the-clock coverage is required but the internal team cannot sustain it, skills in GKE and security are thin and European customers raise data residency questions. Pace of change is high, with daily deployments.
A fully outsourced model would solve coverage but risk losing product context at a time of rapid change. A purely internal model would require hiring at least three or four more engineers to sustain rotations. The company chooses a hybrid: the internal team keeps ownership of architecture, SLOs and release decisions; a partner provides after-hours on-call, GKE and security posture operations and an automation engineering stream. The ownership matrix assigns mitigation approval for customer-facing services to the internal incident commander during business hours and to the partner’s incident lead after hours, within pre-agreed runbooks. AI investigations are enabled for non-regulated projects under the company’s Premium Support contract, with results visible to both teams, while projects processing European customer data are handled with conventional diagnosis until residency questions are resolved. Commercial terms include a component tied to SLO attainment and a quarterly target for closed prevention items.
Six months in, the measures that matter are on-call load for the internal team, SLO attainment, time to restore and the size of the prevention backlog. Those, not the number of tickets closed, tell the company whether the model is working.
Conclusion
AI-assisted operations does not make the MSP-versus-in-house decision obsolete, but it changes what each side should bring. Agents increasingly handle the repetitive diagnosis that once filled operations rotas. What remains, and grows, is the work of defining SLOs, building investigation-ready telemetry, governing agent access and data, making mitigation decisions and turning every incident into lasting improvement. Choose the model that puts clear ownership on those responsibilities, factor support tiers and AI access into the economics, keep knowledge in repositories you own, and measure outcomes rather than activity. Whether you build, buy or blend, that is how Google Cloud operations stays reliable as the tools keep changing.
How Hanoi Technology Can Help
Hanoi Technology supports Google Cloud operations as a project, a dedicated team or a co-managed service, with clear ownership, SLO reporting and shared tooling.