← Back to blog

Field notes · LangGraph in Production

Gemini Enterprise Agent Platform: What It Is and What You Need to Know

August 16, 2026

Gemini Enterprise Agent Platform is a stack, not one agent product. Google frames it as an evolution of Vertex AI, four pillars: Build, Scale, Govern, Optimize. The rename is documented: Vertex AI Platform → Gemini Enterprise Agent Platform; Vertex AI Studio → Agent Studio. Agent Runtime was already named Agent Runtime; it now sits under that umbrella.

The useful question is the same as on AWS: where the loop lives, and which platform pieces you actually compose. (AgentCore is the AWS counterpart — substrate, not wizard.)

LayerWhat it isWho owns the loop
Model Garden200+ foundation models (Gemini, partners, open)You, or a product on top
Agent StudioLow-code canvas for prompts, agents, workflowsGoogle's UI; you still own tools and ops
ADKOpen-source, code-first framework (Python, TypeScript, Go, Java)You
Agent RuntimeManaged host: deploy, sessions, Memory Bank, tracingYour framework; Google owns the substrate
Managed Agents APIConfig-driven REST agents in a sandbox — Pre-GAGoogle's harness; not for production

Do not treat Studio, ADK, and Runtime as one SKU. Unconstrained Studio is how agent sprawl starts. Runtime without Gateway and identity is an ungoverned fleet.

Build: three ways to make an agent

Agent Studio is the low-code path. Agent Garden is sample agents. Fine for prototypes. The console is not supported on jurisdictional multi-region endpoints — if data residency is why you are on GCP, the builder UI is not the control plane.

ADK is the code-first framework: workflow agents (predictable pipelines) or dynamic routing; native multi-agent; evals; run local, Runtime, Cloud Run, or GKE. That last list matters. ADK is four languages. Agent Runtime deployment is Python-only. If the team writes Go or Java agents, Cloud Run / GKE is the documented scaled path, not Runtime.

Managed Agents API is a config-driven control plane (Agents API) plus a data plane (Interactions API). Each agent gets an isolated sandbox; network and credentials are off until you turn them on. Google is explicit: Pre-GA, not for commercial or production use, do not put proprietary data in it. Treat it as an eval, not the fleet.

Knowledge is a separate product, not a checkbox on the agent. RAG Engine ingest → chunk → embed → corpus → retrieve → generate. Vector Search is the sibling retrieval product. Security is not uniform: RAG Engine supports VPC-SC and CMEK; data residency and Access Transparency are not. Several US regions are allowlist for new projects. Check the matrix before you promise "enterprise RAG on GCP."

Scale: Agent Runtime is the host

Deploying puts a Python agent on a managed substrate. Five documented methods: in-memory object (Colab), local source files, Dockerfile (must honor the runtime contract), Artifact Registry image, or Git via Developer Connect. Agents CLI is an official deploy path.

Frameworks Google documents on Runtime: ADK, LangGraph, LangChain, LlamaIndex, AG2, custom, A2A (Preview). Same pattern as AgentCore: keep the framework; rent the host, sessions, and ops.

What Runtime actually adds:

In-memory session stores that die on restart are a local-dev default, not a production backend. Use the managed Session service (or your own store) on purpose.

Quotas are real. Defaults (agent quotas): 100 Runtime resources per project per region; 90 Query/StreamQuery per minute; 300 session-event appends per minute. Google's own example: 250 concurrent users × 2 req/min = 500 QPM — you are already over the default, and a multi-tool turn multiplies session events. They tell you to request quota with a buffer or you will 429. Model RPM/TPM is a separate ceiling.

Enterprise security is a table, not a slogan. From the scale page: Runtime, Sessions, and Memory Bank list VPC-SC, CMEK, DRZ-at-rest, HIPAA. Access Transparency is Yes for Runtime/Sessions/Memory Bank, No for evaluation and Code Execution. Example Store does not get VPC-SC or CMEK. Read the row for the service you are buying.

Govern: Gateway is the enforcement point

Agent Gateway is the network entry/exit for agent traffic: Client-to-Agent (ingress) and Agent-to-Anywhere (egress). It talks MCP, A2A, REST, gRPC. Agent Registry is the catalog of approved agents, tools, and MCP servers. Unregistered MCP is blocked by default. One gateway instance: up to 5,000 Registry resources.

Policies are delegated, not prompt-shaped:

  • IAM via IAP — which agent identity may call which tool (SPIFFE). Egress. IAP is default-on; dry-run exists.
  • Model Armor — inspect and/or block on ingress and egress (prompt injection, leakage). Templates; optional. The Gateway integration is Preview.
  • Semantic governance — "toxic combinations" of tools, intent vs. what IAM already allowed.

Limits to actually design around. Gateway does not support VPC Service Controls; Google's workaround is org-policy constraints that bind Runtime/Gemini Enterprise to approved gateways. No self-signed destination certs. Gemini Enterprise — the employee assistant product, not this stack — does not get Client-to-Agent mode; Agent Runtime gets both. IAM on the gateway is egress-only in the comparison table.

If tools bypass the gateway, you do not have a platform. You have N agents with N secret stores.

Optimize: traces and evals, or you are flying blind

Observability is traces (span DAGs per session) plus topology (inbound/outbound deps; Preview). Gateway also emits network-layer telemetry. Green dashboards and wrong answers still coexist; this is the inspection plane, not a quality guarantee.

Agent evaluation covers offline traces/sessions, simulated multi-turn personas, and online scoring of live traffic. There is a path to rewrite system instructions from failure patterns. The evaluation service (SxS) has no plan for jurisdictional endpoints — same class of constraint as Studio.

How you actually compose a system

A GCP-standardized platform team is not "turning on Vertex." It is picking owners:

  1. Models from Model Garden. RAG Engine / Vector Search if private data must ground answers — with the residency/AXT caveats above.
  2. Loop — ADK if you want Google's harness; LangGraph if you already trust graphs and checkpointing. Host Python on Agent Runtime. Other languages → Cloud Run or GKE, still behind Gateway.
  3. Builder surface — Studio for domain prototypes, then export/hand-off to ADK. Do not let Studio become the production fleet. Stripe already ran that experiment.
  4. Tool path — Registry + Gateway + IAM + Model Armor. Approve a tool once. Audit who called what.
  5. Identity — per-agent IAM, not a shared service account in a prompt.
  6. Evals / traces before the second team ships. Quota increases before the first load test, not after the first 429.

Hybrid is normal: Runtime for the fleet you can live with as Python APIs; Cloud Run/GKE when you need a custom UI, A2A exposure, or a non-Python ADK; deterministic orchestration (your workflow engine) when the business process must not be improvised.

When to use it

Use this stack if you are already on Google Cloud and you want a managed Python runtime, a governed MCP/A2A tool path, agent identity, and Cloud Trace next to the host — without rebuilding that substrate per team.

Do not pick Agent Runtime to paper over missing tool owners, missing evals, or no on-call model. The platform will host the mess at scale. Do not put production data on Managed Agents API while it is Pre-GA. Do not assume Studio, RAG Engine, Gateway, and Code Execution share one compliance matrix; Google publishes different rows for each.

Agent Platform will not write a correct agent for you. It will stop you from rebuilding isolation, session storage, and tool auth while you still fight tool semantics, quota, IAM for upstreams, and silent wrongness — the same gap every serious agent stack hits.

Primary docs

More on this topic