4.2 Deployment Runtimes: Agent Runtime, Cloud Run & GKE Agent Sandbox

Rosku Bank’s platform architects must deploy three very different AI agents into production:

The Retail Loan Orchestrator: Built in Python ADK. The team wants zero Dockerfile or Kubernetes overhead and wants managed SessionService and Memory Bank wired up automatically out of the box.
The Spiky Tax-Season Bot: Packaged as a custom container alongside a lightweight Node.js PDF parser. Traffic is zero at night and spikes to 5,000 concurrent users at 9:00 AM—requiring fast serverless scale-to-zero!
The Quant Code-Execution Agent: Executes untrusted, user-submitted Python and C++ quantitative models and requires dedicated GPU node pools plus strict kernel-level sandbox isolation (gVisor / microVMs) so malicious code can never escape the container!

1. Key Concept Definitions: The 3 Production Agent Runtimes

Select your Google Cloud hosting target based on operational overhead, state integration, and isolation requirements:

1. Managed Agent Runtime

The turnkey runtime on the Gemini Enterprise Agent Platform. Wrap your ADK agent in AdkApp for zero-Dockerfile hosting with auto-wired managed Sessions, Memory Bank, and Cloud Trace.

2. Serverless Cloud Run

Deploys custom Docker containers (any language or OS binary) with fast scale-to-zero cost efficiency, high async I/O concurrency per instance, and built-in revision traffic splitting.

3. GKE with Agent Sandbox

Provides Kubernetes hardware control (custom GPU/TPU node pools for self-hosted open models) and per-execution kernel isolation (gVisor / Kata microVMs + warm pools) for running untrusted code safely.

2. Interactive 3-Runtime Architecture Switcher

Switch between the 3 Production Runtimes below and step through the 3 architectural layers (Packaging & Compute, State & Memory Wiring, and Scaling & Isolation) to compare how each environment operates:

AGENT RUNTIME: TURNKEY PACKAGING

1. Wrapping Your Agent in AdkApp (Zero Container Boilerplate)

Architectural Behavior

Developers wrap their root ADK agent in AdkApp and specify Python dependencies. The platform builds, secures, and hosts the runtime automatically.

Architecture Decision Rule

Select Agent Runtime whenever the goal is lowest operational overhead and native integration with managed Sessions and Memory Bank!

3. Production Runtime Selection Matrix

Compare the three Google Cloud hosting environments across five architectural dimensions:

Architectural Dimension	Agent Runtime (Gemini Enterprise Agent Platform)	Cloud Run (Serverless Containers)	GKE with Agent Sandbox (Kubernetes)
Operational Overhead	Lowest (Turnkey): No Dockerfiles or cluster management; deploy Python `AdkApp` directly.	Low (Serverless): Manage your Dockerfile; Google manages infrastructure and scaling.	High (Cluster Control): Manage node pools, Pod specs, networking, and sandbox policies.
Session & Memory Integration	Built-in & Auto-Wired: Automatically connects to managed `SessionService` and `Memory Bank`.	External Wiring Required: Must configure external `SessionService` (or `DatabaseSessionService`).	External Wiring Required: Must configure external `SessionService` / Cloud SQL / Spanner.
Scaling Profile	Managed horizontal autoscaling tuned for agentic workloads.	Fast Scale-to-Zero (cost-optimal for spiky/idle workloads) + configurable `min-instances`.	Pod/Node autoscaling + pre-warmed Agent Sandbox pools for sub-second sandbox startup.
Untrusted Code Isolation	Standard managed container isolation (use Built-In Code Executor for simple Python).	Standard gVisor container isolation per service revision.	Per-Execution Kernel Sandbox (`Agent Sandbox`) with gVisor / microVMs and ephemeral filesystems.
Primary Architectural Trigger	“Fastest path to production for ADK,” “minimal ops,” “managed sessions & Memory Bank out of the box.”	“Custom container/OS packages,” “scale to zero during off-hours,” “serverless REST/MCP microservice.”	“Execute untrusted user/LLM code safely in Kubernetes,” “custom GPU/TPU node pools,” “self-hosted open models.”

4. Real-World Deep Dive: Stateful Scaling & Sandbox Mechanics

Architect Question	How It Works Under the Hood in Production
“Why does enabling load-balancer Sticky Sessions (Session Affinity) fail to fix `InMemorySessionService` state loss on Cloud Run or GKE?”	Containers Are Ephemeral! Session affinity only attempts to route a user to the same container while that container stays alive. As soon as Cloud Run scales down an idle instance, crashes, or rolls out a new deployment revision, everything in local container RAM (`InMemorySessionService`) is wiped permanently. Always externalize state to managed `VertexAiSessionService` or `DatabaseSessionService` (Cloud SQL / AlloyDB / Spanner)!
“Why should Cloud Run container concurrency be set higher than 1 for most ADK agents?”	Agents Are Network I/O-Bound, Not CPU-Bound! An ADK agent spends over 90% of its turn waiting on network responses from the Gemini API and remote MCP tools. Using `async def` tools and allowing a single container to handle 50–80 concurrent requests slashes compute costs and avoids cold-start storms!
“How does GKE Agent Sandbox execute untrusted code in milliseconds without cold-booting a VM every time?”	Pre-Warmed Sandbox Pools & Snapshot Restore: GKE maintains a warm pool of pre-initialized gVisor/microVM sandbox pods. When an agent tool call arrives, it attaches to a warm sandbox in milliseconds, runs the untrusted binary in an isolated kernel/filesystem, and destroys/resets the snapshot immediately afterward!