Google just moved agent development out of toy examples and into platform scaffolding with real deployment targets. The ADK (Agent Development Kit) now generates language bindings in Python, Go, TypeScript, Java, and Kotlin, plus A2A endpoints and deployment manifests for private Cloud Run, Gemini Enterprise Agent Runtime, and GKE. The reference MCP pattern in the Gemini dev guide runs an MCP server on private Cloud Run exposing a JSONRPC /mcp endpoint not a demo, but a repeatable architecture.
That matters because this is a shift from "agent as client script" to "agent as networked service." The generated A2A endpoints and MCP JSONRPC surface create internal HTTP APIs that run long-lived or persistent agent workloads with shared context and cloud execution. Gemini's agent messaging is designed to support persistent cloud execution, shared context across tasks, and a unified API surface that spans knowledge work, media creation, and code execution. Combine that with Google's preview tooling to migrate agent workloads between Kubernetes environments and you can see the play: make agent runtimes a pluggable part of infra, not a one-off experiment.
Concrete bits you need to know:
- Languages: ADK scaffolds for multiple languages including Python, Go, and TypeScript (Node.js); templates include client and server pieces and A2A endpoint patterns.
- Network surface: the reference architecture shows an MCP-compatible server running on a private Cloud Run service that exposes a JSON-RPC endpoint (commonly /mcp) for tool integration and UI widgets.
- Deploy targets: Cloud Run (private), GKE, and integration points for Gemini Enterprise's managed agent runtimes plus preview tooling to help move agent workloads between Kubernetes clusters.
This is the right direction for platform teams: providing repeatable, deployable scaffolds is how you keep agent integrations auditable and operable. The alternative is a thousand bespoke connectors running with ad-hoc credentials in CI which is exactly how things get breached. But Google didn't eliminate the risk; it rehomed it. A private Cloud Run service with a JSON-RPC /mcp endpoint is convenient and it is now a new internal API that needs the same controls you apply to any microservice.
Operational implications you can't ignore
Treat agent endpoints like production APIs. That means:
- Strong identity and least privilege for A2A flows. Generated endpoints should be paired with a service identity (Workload Identity, Workload Identity Federation, or pod/service account patterns) and scoped IAM roles.
- Auditable invocation paths. JSON-RPC over HTTPS is simple; it's not inherently auditable. Add request tracing, structured logs, and an event stream for agent actions.
- Quotas and rate limits. Persistent agent runtimes amplify blast radius: one runaway tool can consume inference, network, or I/O budgets quickly.
If you let this be "just another Cloud Run service," you'll regret it. The fragmentation of agent runtime options Cloud Run, managed Gemini runtimes, and GKE is useful, but it also means teams will run a mix of managed and self-hosted agents with different observability and identity models. Google's preview migration tooling signals they expect multi-cluster adoption and want to be the integration point for GKE.
Two other useful signals in these announcements: first, Google is standardizing the developer experience across languages and deployment targets instead of shipping language-specific samples. That's overdue. Second, there's no evidence of immediate GCP pricing changes or discrete Vertex AI API version bumps tied to these agent features so this reads as a platform feature push rather than a pricing pivot.
If your team runs platform or cluster operations, start treating agent workloads like first-class services: wire up identity, tracing, quota, and deploy-time policies now. If you wait until agents are everywhere, you'll inherit a cross-team mess of secret scopes and unobservable RPCs.
Final thought: Google is sane to build scaffolds rather than ask every team to invent its own MCP server. But giving teams easy ways to spin up persistent agent runtimes without operational guardrails will create incidents. The interesting part isn't the ADK itself it's that agent runtimes are graduating into the same operational taxonomy as databases and message buses. That should make platform teams excited and nervous.