Production AI on Google Cloud: from Vertex AI to Gemini Enterprise Agent Platform

If you searched for Vertex AI lately and landed on something called Gemini Enterprise Agent Platform, you are not lost: Google renamed it on 22 April 2026. The building blocks for a production agent are still there, many with new names. This is the setup I would build today: separate projects and agent identities, a VPC Service Controls perimeter, RAG Engine on your own data, Model Armor in front of every model call, evaluations on real traces and provisioned capacity only when the numbers say so. Every claim links to Google's documentation.

Dominik Heinrich

November 7, 202611 min read

1. When Google Cloud fits, and how the names changed

Google Cloud is a strong home for AI when your analytics already sit in BigQuery, your company runs on Google Workspace, or you want Gemini models close to your data with Google's search technology for retrieval. Model Garden also offers third-party and open models, for example Anthropic's Claude and Google's open Gemma family, so you are not locked into one model family.

The renaming is the first thing to understand, because half of the tutorials online use the old names. In the release notes of 22 April 2026, Google lists every change from Vertex AI to Gemini Enterprise Agent Platform: Vertex AI Studio became Agent Studio, the Vertex AI API became the Agent Platform API, Vertex AI Agent Engine became Agent Runtime, its Memory Bank and Sessions became Agent Platform Memory Bank and Sessions, and Vertex AI Search became Agent Search. RAG Engine, Vector Search and Model Garden keep their names. Google also notes that bookmarked links keep working through redirects.

Technically little breaks: the VPC Service Controls documentation still protects the service as aiplatform.googleapis.com, and existing projects keep running. But new features ship under the Agent Platform names, so use them in your documentation and runbooks from now on.

What is Gemini Enterprise Agent Platform?, Google Cloud Tech (YouTube). Loads from YouTube only after you click.

2. Projects, IAM and Agent Identity

Use separate Google Cloud projects for non-production and production, ideally in a folder with organisation policies that restrict which regions and services may be used. Quotas, model access, logs and safety settings then differ per project, and a test can't reach production data.

Agents need their own identity, not a shared service account that can do everything. Google's Agent Platform overview describes Agent Identity as the way to grant granular permissions to agents, and the documentation covers authenticating to Google Cloud with an agent's own identity as well as to external services through an auth manager with OAuth flows. Give each agent only the roles it needs: read one Cloud Storage bucket, query one dataset, call the models it uses.

For people, use groups and predefined roles instead of individual grants, and keep the ability to deploy agents to production with a small group or your CI/CD pipeline. Review IAM bindings before go-live; over-broad roles on an agent are the most common finding in a security review.

3. A private perimeter: VPC Service Controls and Private Service Connect

On Google Cloud, the strongest data-exfiltration control is a VPC Service Controls perimeter. You put the projects with your agent, data and models inside, and list the APIs as restricted services, for example aiplatform.googleapis.com and storage.googleapis.com. Calls to those APIs from outside the perimeter are then blocked unless they meet an access level you define. Google's Agent Runtime documentation states support for VPC Service Controls, and that a deployed agent keeps secure access to Google APIs such as BigQuery inside the perimeter.

For private connectivity from your own networks, the Google Cloud Architecture Center's guide on private connectivity for RAG-capable generative AI applications is the blueprint: a routing project with a Private Service Connect endpoint, connected to your on-premises or other cloud networks through Cloud Interconnect or Cloud VPN, with DNS pointing to that endpoint, and data engineers uploading RAG data privately to Cloud Storage.

Roll the perimeter out in dry-run mode first. It logs what would be blocked without blocking it, so you find the forgotten service account in a CI pipeline before it breaks a release.

bash

# Dry-run perimeter around the AI project (POLICY_ID = your access policy)
gcloud access-context-manager perimeters dry-run create ai_perimeter \
  --policy=POLICY_ID \
  --perimeter-title="AI production perimeter" \
  --perimeter-type=regular \
  --perimeter-resources=projects/PROJECT_NUMBER \
  --perimeter-restricted-services=aiplatform.googleapis.com,storage.googleapis.com,bigquery.googleapis.com

# After the dry-run logs are clean, enforce it
gcloud access-context-manager perimeters dry-run enforce ai_perimeter --policy=POLICY_ID

Tip from practice

Check that every service your agent needs is supported by VPC Service Controls before you promise an airtight perimeter. Google keeps a supported-products list with limitations per service.

Reference setup on Gemini Enterprise Agent Platform (formerly Vertex AI): everything inside a VPC Service Controls perimeter, Model Armor in the request path, evaluations on Cloud Trace data.

4. Models and capacity: pay-as-you-go first, Provisioned Throughput later

Model Garden gives access to Google's Gemini models, third-party models and open models; the Agent Platform overview speaks of more than 200 foundation models. As on every cloud, choose per step: a fast, cheap model for routing and extraction, a stronger one for complex answers, and an embedding model for retrieval.

For capacity, the default is pay-as-you-go. Provisioned Throughput is a fixed-cost subscription that reserves throughput for supported generative AI models in the locations you choose. It is measured in generative AI scale units (GSUs), and Google positions it for real-time production applications such as chatbots and agents where a predictable experience and fixed costs matter. If a request exceeds your reserved quota, it is processed as pay-as-you-go; if you configure Provisioned Throughput only, such requests return an HTTP 429 error instead.

That choice between overflow and hard limit is an architecture decision, not a billing detail. Overflow protects the user experience but makes cost less predictable; a hard limit protects the budget but needs retries and a fallback in the application.

5. Your data: RAG Engine, Vector Search and Agent Search

Google offers several ways to ground an agent in your own data. RAG Engine connects private enterprise data to models to improve answer accuracy and reduce hallucinations, and it can use different vector stores. Vector Search is the AI-native search engine for storing and searching embeddings at scale. Agent Search, formerly Vertex AI Search, gives you Google-quality search over your documents and websites as a managed service.

The Architecture Center lists reference designs for several combinations, for example RAG infrastructure with Agent Platform and Vector Search, with AlloyDB, or with Spanner Graph for graph-based retrieval. My default for a first release is the most managed option that meets your data residency and access requirements, because the hard part of RAG is rarely the index. It is keeping documents current, respecting who may see which document, and testing with questions where you know the right source.

Put the raw documents in Cloud Storage inside your perimeter, encrypt with customer-managed keys where policy requires it (RAG Engine documents CMEK support), and give the ingestion job its own identity that can read only the source buckets.

6. Build and run the agent: ADK, Agent Studio and Agent Runtime

For building, Google offers two paths. Agent Studio is a low-code canvas for designing agents and their workflows. The Agent Development Kit (ADK) is a modular, model-agnostic framework for code-first agents with reasoning and tool use. The documentation also covers other frameworks on the runtime, such as LangChain, LangGraph, AG2 and LlamaIndex, and the Agent2Agent protocol for agents that talk to each other.

For running, Agent Runtime (formerly Agent Engine) is the managed, scalable environment for deploying and operating agents, including long-running ones. Around it sit Agent Platform Sessions for state within one interaction, Memory Bank for memory across sessions, and Code Execution, which runs generated Python code in a sandbox. For governance, Google describes Agent Gateway together with Model Armor as the layer that secures agent interactions and enforces runtime policies.

My recommendation: write the agent in ADK if you have developers, because code is testable and reviewable, and keep Agent Studio for prototypes with business teams. Deploy to Agent Runtime through your pipeline, with revisions and traffic splitting for a careful rollout, not from a laptop.

Tip from practice

Use revisions and traffic splitting on Agent Runtime like a canary: send a small share of traffic to the new revision, compare its online evaluation scores with the old one, then shift the rest.

7. Model Armor in front of every model call

Model Armor screens prompts and responses before they reach the model or the user. Google lists the main use cases: redact sensitive data such as PII or intellectual property using Sensitive Data Protection, block prompt injection and jailbreak attempts, filter malicious URLs, and apply responsible AI filters for categories such as hate speech, harassment or sexually explicit content. It works for applications on Google Cloud and on other clouds, which helps if your agents are spread across providers.

You configure Model Armor with templates: one template per risk profile, for example a strict one for a customer-facing agent and a lighter one for an internal research assistant. Each template sets the filters, their confidence levels and the error code and message your application receives when something is blocked, so the app can answer politely instead of failing.

Treat templates as code. Create them from your pipeline, review changes like any other security rule, and keep a test set of attack prompts per template, including instructions hidden inside documents your agent retrieves.

bash

# Strict template for a customer-facing agent (values from Google's example)
gcloud model-armor templates create support-agent-strict \
  --project=PROJECT_ID --location=LOCATION \
  --rai-settings-filters='[
    {"filterType": "HATE_SPEECH", "confidenceLevel": "MEDIUM_AND_ABOVE"},
    {"filterType": "HARASSMENT", "confidenceLevel": "MEDIUM_AND_ABOVE"},
    {"filterType": "SEXUALLY_EXPLICIT", "confidenceLevel": "MEDIUM_AND_ABOVE"}
  ]' \
  --basic-config-filter-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-confidence-level=HIGH \
  --malicious-uri-filter-settings-enforcement=enabled

8. Evaluate on real traces, observe, control cost, then compare the clouds

Agent and model evaluations in Gemini Enterprise Agent Platform became generally available on 31 July 2026, according to Google's announcement. The service ships more than 20 pre-built metrics for quality, safety, grounding, tool use and trajectory, plus adaptive rubrics and your own code-based or LLM-as-a-judge metrics. Offline evaluation measures agents on historical data and requires the agent to export OpenTelemetry signals; with Agent Runtime, Cloud Trace has to be enabled. Online monitors sample live traces and logs, run the metrics, write results to Cloud Logging and numeric scores to Cloud Monitoring, where you can alert on them.

This is a big practical advantage: the same traces you use for debugging become your quality data. Set up tracing on day one, run offline evaluation as a gate in CI, and keep online monitors on production with an alert when a score drops.

For cost, label resources per agent and team, watch token usage per model, move to Provisioned Throughput only for a proven steady load, and review the setup each quarter. Pitfalls I see most: an agent running as a broad service account, no perimeter, Model Armor only on the user prompt but not on retrieved content, and tracing switched on only after the first incident. The same setup on Microsoft Azure is in /blog/azure-ai-foundry, and on AWS in /blog/aws-bedrock.

Takeaway
On Google Cloud, the production recipe is a VPC Service Controls perimeter, agents with their own identities, RAG on your own data, Model Armor as the safety layer and the evaluation service reading the same traces you debug with.

Real projects behind this

Try it yourself

Production readiness

Want this in your company? Let's talk mail@dominikheinrich.ch

Sources and official guides