Google Cloud just moved agents out of notebooks and into your production runtime stack: the new Gemini agent is a persistent, cloud-hosted work agent (single API, retained context, personalization, code execution and multimodal output) and it’s already wired into Cloud Run, GKE, Vertex AI, and the Gemini Enterprise Agent Platform. That matters because persistence and code execution change the operational model — and the threat model — in ways most teams haven’t prepared for.
The technical bits you need to care about right now
- Gemini agent surfaces a unified agent API designed for persistent cloud execution. It keeps context across sessions, supports personalization, and can execute code and generate multimodal artifacts. This is not a one-off SDK; it’s a runtime primitive.
- Google’s Agent Development Kit (ADK) now scaffolds agent projects and provides SDKs and templates for common languages (Python, Java, Go, and TypeScript/Node.js). ADK includes agent-to-agent (A2A) plumbing and deployment templates targeting Cloud Run, GKE, and Google’s enterprise agent tooling so you don’t have to hand-roll the basic plumbing.
- Cloud Run integrates with Google Cloud developer tooling and AI Studio to deploy agent scaffolds; managed serverless is now a supported option for production agents and scaffolding can include common backends like Firestore and standard auth patterns.
- GKE is emphasizing isolation patterns and improved accelerator management for stateful, single-replica agent workloads, signaling that teams will need GPU scheduling, stateful isolation, and stronger node/tenant boundaries as agents scale.
- Google Cloud’s migration tooling is being extended to help move Kubernetes-hosted agent workloads from other clouds (including EKS) to GKE; some workflows are in preview as Google surfaces migration assists for agent workloads.
Why this is a platform problem, not just a developer convenience
Persistent agents with code execution are a new category of long-lived workload. They hold context (potentially sensitive), invoke external systems, mutate state, and may call other agents (A2A). Treating them like short-lived LLM requests is a category error. You now need proper lifecycle management: deployment patterns for single-replica stateful agents, RBAC for who can personalize or nuke an agent, audit trails for agent-initiated code execution, secrets management tied to agent identity, and accelerator allocation policies.
Google’s responses include GKE isolation features, tighter accelerator management, and Cloud Run integration. But they’re also pushing an expanded trust boundary. Persistent agent contexts are effectively new database rows with privileges. If you let agents execute code in your VPC or access internal APIs, you’ve created a programmable attacker if you don’t lock down who trains or personalizes them.
My take: this is overdue and inevitable. Platforms needed a first-class way to host agents — forcing teams to bolt agent behavior onto existing deploy targets was going to produce inconsistent, insecure setups. Google’s approach of providing scaffolding (ADK) plus managed deployment targets is the right call. That said, teams that treat agents as "just another microservice" will be bitten: observability, costing, and security are qualitatively different when your service holds persistent personae and executes code on behalf of users.
What to do next (quick checklist for platform teams)
- Treat agent instances like stateful services: run single-replica sandboxes or StatefulSet-like constructs and ensure safe snapshot/restore semantics.
- Enforce strict RBAC and separation between personalization, training, and execution paths; log personalization events separately.
- Require least-privilege secrets for agent code execution and instrument every outbound call from an agent for tracing and policy enforcement.
- Put accelerator quotas and scheduling policies in place now; GKE’s forthcoming patterns indicate agents will be GPU-hungry at scale.
If you want a head start, Google’s ADK scaffolding is a concrete place to begin — it codifies deployment templates and A2A plumbing you’ll need. For related operational primitives on Google Cloud, see our previous coverage of the ADK and how Cloud Run sandboxes are being positioned for agent workloads (Google Cloud ADK: five-language Agent Development Kit with A2A and Cloud Run/GKE scaffolding and Gemini 4 Argon on Google Cloud: model ID gemini-4-argon, pricing, and Cloud Run sandboxes).
Final thought: agents are becoming a first-class runtime, not a fancy UI. If your platform team ignores that, you’ll inherit brittle migrations, expensive mis-scheduled accelerators, and a security surface area you won’t like. Start treating agent instances like services with state, identity, and auditability — because that’s exactly what Google just did for you.