Skip to lesson

Google CloudProfessional Agentic Architect2026-094.2 Deploying and scaling production workloads

Choose a production agent runtime

Completed by the knowledge check

Learning objective

Choose Agent Runtime, Cloud Run, or Google Kubernetes Engine (GKE) from an agent’s workload profile, control, isolation, scalability, and cost requirements. This lesson chooses where agent logic runs; it does not choose where the underlying model is served or size runtime capacity.

Core idea

Choose the highest-level managed runtime that satisfies every hard requirement. Moving from Agent Runtime to Cloud Run to GKE adds control, but also adds platform decisions and operational work:

managed agent abstraction -> managed container -> managed Kubernetes
Agent Runtime              -> Cloud Run         -> GKE

Start with constraints, not a preferred product. A required request interface, runtime contract, Kubernetes policy, hardware topology, or isolation boundary can eliminate an option. Then compare scalability and total cost of ownership.

How it works

Use the following decision sequence:

  1. Describe the workload. Record whether execution is request-driven, event-driven, batch, or continuous. Record duration, traffic variability, state placement, language, dependencies, and hardware.
  2. Apply control constraints. Decide whether the team needs an agent-level deployment, a custom container, or Kubernetes objects and node control. An existing Cloud Run or GKE operating model can reduce support cost, but it does not override a hard requirement.
  3. Define isolation precisely. Separate code-execution isolation, tenant isolation, network reachability, workload identity, and placement. “Must be secure” is not a usable requirement.
  4. Match the scaling model. Decide whether managed autoscaling is enough or the team must control replicas, placement, node pools, or cluster capacity. Account for state that must survive compute replacement.
  5. Compare total cost. Include runtime resources, idle or minimum capacity, storage, networking, observability, cluster charges, and engineering operations. Model inference and tool calls remain separate costs.

The following table summarizes the fit of each runtime:

RuntimeStrongest workload fitControl and isolationScaling and cost shape
Agent RuntimeContainerized agents that fit the managed agent lifecycle and runtime contract and benefit from managed sessions, memory, and observabilityGoogle manages an opinionated runtime. Use managed Code Execution when the agent must run generated or untrusted code. It is a weak fit when the compute environment, request surface, networking, or non-agent workloads need deep customization.Automatically scales the agent. Runtime compute and memory, plus used platform services, are consumption costs; reduced platform work can lower total ownership cost.
Cloud RunContainerized, stateless, request- or event-driven agents with variable traffic and language or framework flexibilityThe team controls the image and application configuration while Google manages servers. Cloud Run isolates container instances, but durable state belongs in an external service.Services automatically scale with traffic and can scale to zero. Request-based or instance-based billing and minimum instances change the idle-cost and latency trade-off.
GKEContainerized, complex or stateful systems that need Kubernetes APIs, custom scheduling, specialized hardware, sidecars, or fine-grained networkingThe team can configure Pods, policies, node pools, and workload placement. GKE Sandbox can add a boundary for untrusted code. This flexibility creates more security configuration and operational responsibility.Kubernetes autoscaling can act at workload and node levels. Autopilot reduces node management; Standard exposes more infrastructure control. Cluster, workload, and operations costs favor GKE when its control is necessary or shared capacity is well utilized.

Agent Runtime supports any language and framework when the application is containerized and follows the runtime contract. Agent Development Kit (ADK) agents in Python and Go have the deepest integration. Other languages and frameworks can deploy from a Dockerfile or a container image in Artifact Registry. The Agent Platform SDK, source-file, and Developer Connect deployment paths are Python-only. A custom container must listen for HTTP on 0.0.0.0:8080. For full query and streaming integration, it also exposes /api/reasoning_engine and /api/stream_reasoning_engine.

Cloud Run services use disposable instances, so local memory and files cannot be the system of record. Scaling to zero reduces idle compute cost but can add startup latency; see What is Cloud Run. GKE also has two operations levels: Google recommends Autopilot for most workloads and Standard when granular infrastructure control is required; see GKE modes.

Key distinctions and trade-offs

Agent runtime versus model runtime: The agent runtime executes orchestration and business logic and calls a model endpoint. Selecting GKE for the agent does not mean the model must run on GKE. The two placement decisions can differ.

Stateful behavior versus stateful compute: An agent can remember a conversation while its compute remains disposable. Agent Runtime can use managed Sessions and Memory Bank. Cloud Run and GKE can use external state services; GKE also supports Kubernetes persistent storage. Do not select GKE only because the agent has conversational state.

Managed isolation versus configurable isolation: Cloud Run provides a managed sandbox boundary around instances. GKE gives the team controls such as GKE Sandbox and Network Policies, but those controls must be designed and operated. Scheduling Pods onto separate nodes alone is not a primary security boundary. See GKE Sandbox and workload separation.

Unit price versus total cost: Scale-to-zero compute can favor Cloud Run for bursty traffic. GKE can be economical for predictable, highly utilized shared capacity, especially with commitments. Agent Runtime can have a lower total ownership cost when its lifecycle, state, and observability features replace custom integration. Validate the architecture against the official Agent Platform, Cloud Run, and GKE pricing pages.

Architecture / decision scenario

A claims-support agent uses Python and the Agent Development Kit. Traffic is quiet overnight and bursts after severe weather. Compute can be replaced because claims remain in an external system, but the application needs managed sessions, long-term preferences, traces, and a service identity. It needs no custom kernel features, hardware, or Kubernetes policies.

Agent Runtime is the best fit. It supplies the required agent services with the least platform work. Cloud Run would add state and lifecycle integration without a required benefit. GKE would add unused controls and cluster work.

If the workload later stops being a single agent endpoint and requires full control of its HTTP surface, request concurrency, and timeouts under the team’s existing Cloud Run operating model, reevaluate Cloud Run. If it adds Kubernetes admission policies, custom node placement, and an in-cluster stateful service, reevaluate GKE. Runtime selection changes with the constraints; it is not a permanent product ranking.

Common exam traps

  • Choosing GKE whenever a scenario says “enterprise” or “secure,” without a requirement for Kubernetes-level controls.
  • Treating conversational memory as proof that the compute itself must be stateful.
  • Assuming that Cloud Run’s local memory or file system survives instance replacement.
  • Choosing only by scale-to-zero or compute price and ignoring minimum capacity, external state, cluster charges, and operational labor.
  • Confusing the agent runtime with the model runtime and assuming they must use the same product.
  • Assuming Agent Runtime is limited to Python, or assuming it can absorb a workload that does not fit its opinionated managed model and runtime contract.

What to remember

  • Choose the highest-level managed runtime that meets every hard constraint.
  • Use Agent Runtime for an agent that fits its managed lifecycle and runtime contract and benefits from integrated state and observability.
  • Use Cloud Run for serverless custom containers and variable request- or event-driven traffic.
  • Use GKE when Kubernetes-level state, scheduling, hardware, networking, or isolation control is a requirement.
  • Compare total ownership cost, and revisit the choice when workload constraints change.

Knowledge check

References