skip to content

How do you choose between Vertex AI Agent Engine and Cloud Run for an ADK agent?

level: principalimportance: should knowfreq 38%

answer

  1. what do you want to own
  2. managed sessions and memory versus a container
  3. coupling buys you the stateless problem solved
  4. networking and system deps decide it fast
  5. embedding into an existing service is a third option

basics

~20 s

Choose Agent Engine when you want the platform to own sessions, memory and tracing and you accept Vertex coupling. Choose Cloud Run when you need control of the container, dependencies and networking, or the agent must live inside an existing service. Both are one adk deploy command.

solid answer

~50 s

ADK targets both, so the decision is about what you want to own. `adk deploy agent_engine` publishes to Vertex AI Agent Engine, a managed agent runtime: it packages the agent (wrapped as an `AdkApp`) with its requirements through a staging bucket, and gives you managed session and memory services plus built-in tracing, so the statelessness work a self-hosted deployment demands is already done. The cost is coupling — Vertex regions, its packaging model, less control over the runtime. `adk deploy cloud_run` gives you a container: any system dependency, your own VPC egress and IAM, your existing logging and dashboards, and the option to mount the ADK FastAPI app inside a service you already run. You pay for that by owning session persistence, memory and ops. In practice: managed memory and no platform team pushes you to Agent Engine; existing container platform, private networking or an agent that is one feature of a larger service pushes you to Cloud Run.

code

bash · 13 lines
bash
# managed runtime: packaging + staging bucket, sessions and memory handled
adk deploy agent_engine \
  --project=my-project \
  --region=us-central1 \
  --staging_bucket=gs://my-staging-bucket \
  ./agents/weather

# container: you own the image, networking and state backends
adk deploy cloud_run \
  --project=my-project \
  --region=us-central1 \
  --service_name=weather-agent \
  ./agents/weather

go deeper

for a junior

Know that ADK can deploy to a managed Vertex AI agent runtime or to a container on Cloud Run, and that both are single deploy commands over the same agent code.

for a middle

Explain the concrete difference: the managed target supplies session and memory backends and tracing, while the container target gives you dependency, networking and image control but leaves persistence to you.

for a senior

Reason from constraints — private networking, system dependencies, existing observability, traffic shape — and mention embedding the ADK FastAPI app inside an existing service as a real third option.

for a principal

Own the tradeoff explicitly: what the organization can operate today, whether managed cross-session memory is core to the product, and what exit from each option costs. Keep the coupling confined to state backends so the decision stays reversible.

## Two supported targets, one CLI ADK deliberately ships deployment as part of the framework, and it offers two first-class targets. `adk deploy agent_engine` publishes to Vertex AI Agent Engine; `adk deploy cloud_run` builds a container and deploys a Cloud Run service. The agent code is the same in both cases. This is a judgment question, so an interviewer is listening for the axes you reason along, not a winner. ## What Agent Engine takes off your plate Agent Engine is a managed runtime for agents. You point the deploy command at the agent, a project and region, and a staging bucket it uses to package the code and its `requirements`; programmatically the same thing happens by wrapping your `root_agent` in an `AdkApp` and creating an agent engine resource. What you get back is a hosted agent with: - **Managed sessions and memory.** The single largest source of self-hosted agent bugs — conversations lost because state lived in a process — is handled by the platform's session service and memory backend. - **Built-in tracing.** Turn-level observability arrives without wiring an exporter. - **No container to own.** No Dockerfile, no base image CVEs, no scaling knobs. The price is coupling and control. You are inside Vertex's model of what an agent deployment looks like: its regions, its packaging step, its runtime environment. Dependencies that need system-level packages, unusual network egress or a sidecar are awkward-to-impossible. And the abstraction is a product commitment — migrating away later means rebuilding session and memory storage you never had to think about. ## What Cloud Run gives back Cloud Run is a container. That single sentence contains the whole argument: - Any dependency you can install in an image, including native libraries a parser or PDF tool needs. - Your networking: VPC connectors to reach private databases, egress controls, existing ingress and identity-aware proxying. - Your operations: the logging, metrics, alerting and deployment pipeline the rest of your services already use, rather than a second observability story. - Portability: the same image runs on any container platform, so a later move to GKE or elsewhere is a scheduling change, not a rewrite. - Composition: with `get_fast_api_app()` you can mount the ADK app inside an existing FastAPI service, so the agent becomes one route of a product rather than a separate deployable. And you own what Agent Engine managed: durable session storage, memory, and enough tracing to debug a turn you did not run. ## The axes to reason along 1. **Who runs infrastructure?** A team with no platform capacity gets more from managed sessions and memory than it loses to coupling. A team with a mature container platform is adding a second deployment model for one workload. 2. **Does the agent need managed memory across sessions?** If long-term memory is core to the product, the managed backend is real leverage. If the agent is stateless request-response, that advantage largely evaporates. 3. **Network and data-residency constraints.** Private databases, VPC-only egress, or regional requirements often decide it outright. 4. **Runtime shape.** System dependencies, long-lived connections, or unusual resource profiles favour a container. 5. **Composition.** If the agent is a feature inside an existing service, embedding the FastAPI app avoids a network hop, a second auth surface and a second deploy pipeline. 6. **Cost profile.** Low, spiky traffic is cheap on scale-to-zero Cloud Run; the managed runtime's pricing and idle behaviour need checking against your actual traffic shape rather than assumed. 7. **Exit cost.** Ask what a migration off each option costs before you need it, not after. ## A defensible default A reasonable answer: prototype and evaluate locally with the dev UI and eval sets, deploy the first production version to whichever target your organization can operate today, and let managed-memory needs or networking constraints — not novelty — force the switch. Where a team already runs Cloud Run and has session storage solved, the marginal value of the managed runtime is small. Where a team is starting from nothing and the agent's value depends on remembering users across sessions, the managed path removes months of undifferentiated work. Saying that tradeoff out loud, with the axes attached, is what the question is testing.

  • Your agent's tools need a private Postgres reachable only inside a VPC. Does that settle the target?
    Largely yes — it pushes you to a container deployment where you control egress and can attach the service to your VPC, alongside the rest of your infrastructure's networking and secret handling. Fighting a managed runtime's network model for a single workload is rarely worth it, and the same constraint usually implies you already run container infrastructure and can operate it.
  • What do you actually give up by choosing Cloud Run?
    The managed session and memory backends, and turnkey tracing. You take on durable session storage, artifact storage, memory if the product needs it, and wiring spans somewhere you can query them. None of that is hard, but it is real work that has to be maintained, and it is exactly the work teams skip and then ship an agent with amnesia.
  • Is there a third option beyond these two deploy commands?
    Yes — mount the ADK FastAPI app inside a service you already run, using `get_fast_api_app()`, and ship it in your own image. That makes the agent a feature of an existing product rather than a separate deployable, inheriting its auth, networking and pipeline. It is often the right answer when the agent is one capability among many.
  • How would you keep the choice from becoming irreversible?
    Keep everything the framework already isolates isolated: agent definition, tools and callbacks are target-independent, so the coupling lives in how sessions, memory and artifacts are backed. Configure those through service URIs rather than assuming a platform, and keep the eval sets and deploy pipeline target-agnostic, so switching is a redeploy plus a state migration, not a rewrite.

saying these in an interview costs you the question

  • Choosing the managed runtime purely because it is newer
  • Ignoring that the container option means owning session persistence
  • Assuming the managed target supports arbitrary system dependencies
  • Deploying a separate service when the agent belongs inside an existing one
  • Treating the decision as permanent rather than pricing the exit

context

resolving links…