I opened the Google Cloud console last week to spin up a demo, typed Vertex AI in the search bar, and the product that came back was called Agent Platform. Same APIs, same Model Garden, same billing lines, a new name over the door. If you learned this stack a year ago, half your bookmarks now redirect. So before this series builds anything, I want to lay out what the Google Cloud generative AI stack actually is in 2026, what each layer does, and where a real project plugs in.
Key takeaways
Vertex AI is now Gemini Enterprise Agent Platform. The APIs, Model Garden, and pricing carried over, so old code keeps working; only the branding and some console paths changed.
The stack has five layers: apps and agents on top, model access, the models themselves, platform services for retrieval and tuning, and TPU or GPU infrastructure at the base.
You do not adopt the whole thing. Most teams start at one of three entry points: Agent Studio in the console, the Gemini API from code, or Model Garden for a specific model.
What changed when Vertex AI became Agent Platform
Google announced the rename at Cloud Next in 2026. Vertex AI, the umbrella that held Model Garden, custom training, the Model Registry, endpoints, and pipelines, is now marketed as Gemini Enterprise Agent Platform. The official product page still says, in plain text, formerly Vertex AI. That matters more than a logo swap because the whole platform is being repositioned around agents rather than around a model API.
Here is what did not change. The Gemini API path, the aiplatform service, the SDK import, the billing SKUs, and the region names are the same. Code written against Vertex AI a year ago still runs. What did change is the console layout and the top of the funnel: Agent Studio replaced the older generative AI studio surface, Model Garden now advertises 200 plus models, and a separate product, the Gemini Enterprise app, handles registering and governing agents once you have built them.
My advice on the naming: treat Agent Platform and Vertex AI as the same thing when you read docs. Google is mid-transition, so you will hit both names in the same week, sometimes on the same page. Do not waste time deciding which is current. The service ID under the hood has not moved.
The five layers of the stack
Every managed generative AI platform, whether it is Google, AWS, or Azure, sorts into the same rough shape once you strip the branding: something to build in, a way to call a model, the models, the services that make a model useful on your data, and the silicon that runs it. Here is how Google Cloud fills those five slots.
The table below maps each layer to the product you would actually name in a design doc, and to the job it does. Keep it next to you for the rest of the series; every later part lives in one of these rows.
| Layer | Product | What it does |
|---|---|---|
| Apps and agents | Agent Studio, ADK, Gemini Enterprise app | Where you design, test, and govern agents |
| Model access | Gemini API, Model Garden | How code sends a prompt and gets a response |
| Models | Gemini 3, Gemma, Claude, Imagen, Veo | The weights that generate text, images, or video |
| Platform services | RAG Engine, Vector Search, tuning, evaluation | Ground, tune, and measure a model on your data |
| Infrastructure | TPUs, GPUs, GKE | The metered silicon underneath everything above |
Pick your entry point
You do not adopt a stack. You adopt a door into it. On Google Cloud there are three, and picking the wrong one wastes a week. Agent Studio is the console surface where you type a prompt, see a response, and tune settings without writing code. It is the fastest way to answer the question, is this model good enough for my task, before you commit engineering time.
The Gemini API in Agent Platform is the door for anyone shipping software. You authenticate with a service account, call one method, and get a response back. This is where production traffic goes. The third door, Model Garden, is for when you need a specific model that is not Gemini, an open model like Gemma you want to deploy on your own endpoint, or a third-party model like Anthropic Claude billed through Google Cloud. Model Garden is a catalog and a deploy button, not a runtime you code against directly.
My rule: prototype in Agent Studio for an afternoon, then move to the Gemini API the moment you write your second script. Do not build a product against the console. And do not reach for Model Garden endpoints unless you have a concrete reason to run a non-Gemini or open model, because a dedicated endpoint bills for uptime whether or not it serves traffic.
Models on the platform
Google splits its own models into two lines. Gemini is the proprietary, hosted family you call through the API and never see the weights for. Gemma is the open-weight family you can download, run anywhere, or deploy on a Model Garden endpoint. Around them, Model Garden lists more than 200 models, including Anthropic Claude and Meta Llama, so you can standardize billing and governance on one platform even when the model is not Google made.
Within Gemini, the split you care about on day one is Pro versus Flash. Pro is the high-accuracy reasoning tier for hard problems; Flash is the cheaper, faster tier tuned for high-frequency and agentic workloads. As of this writing the current generation is the Gemini 3 family, with Gemini 2.5 models still available and still showing up in Google code samples. Image and video generation live in separate models: Imagen for images, including the Gemini 3 Pro Image model Google nicknames Nano Banana Pro, and Veo for video. The table below is a first-day cheat sheet, not the full catalog, which Part 3 covers.
| Model line | Type | Reach for it when |
|---|---|---|
| Gemini 3 Pro | Hosted, proprietary | Hard reasoning, long context, quality first |
| Gemini 3 Flash | Hosted, proprietary | High volume, agents, latency and cost first |
| Gemma | Open weight | You need the weights, on-device, or full control |
| Claude, Llama | Third party, via Model Garden | One vendor is a hard requirement, billed on GCP |
| Imagen, Veo | Hosted, media | Image or video generation |
Silicon underneath the stack
This is the layer that makes Google Cloud different from its rivals. Google designs its own AI accelerators, the Tensor Processing Units, and rents them alongside NVIDIA GPUs. The current top TPU is Ironwood, sold as the TPU7x machine type and generally available since Cloud Next 2026. It is Google seventh TPU generation and the first the company positions squarely for inference at scale. Trillium, the sixth generation sold as TPU v6e, is the prior tier and still widely used.
The numbers are large. Google cites Ironwood at roughly 10 times the peak performance of TPU v5p, and more than 4 times the per-chip performance of Trillium for both training and inference. A single Ironwood superpod scales to 9,216 chips and, per Google, 42.5 exaFLOPS. You will rarely touch a full pod, but the point stands: if you train or serve very large models, TPUs are the reason teams pick Google Cloud over a GPU-only cloud. For most application work you never see this layer, because the Gemini API runs on it for you.
What does one request cost?
Pricing on Google Cloud generative AI is usage based: you pay for what a request consumes, plus any always-on resources like a deployed endpoint or a Vector Search index. The published floor rate for text, chat, and code generation starts at 0.0001 US dollars per 1,000 characters of input or output. That floor is a useful anchor for a back-of-envelope estimate, but read the next sentence carefully, because it is the one that trips people up.
Current Gemini 3 models are priced per token, not per character, and at rates above that floor, with Pro costing more than Flash. So use the floor for a sanity check, then price the real model on the calculator before you commit a budget. The worked example below uses the published floor rate purely to show the shape of the math.
Worked example
Say each request sends about 4,000 characters in and gets 1,000 back, so 5,000 characters, which is 5 units of 1,000. At the floor rate of 0.0001 dollars per unit that is 0.0005 dollars per request.
At 100,000 requests a month that is 50 dollars. At 1 million it is 500 dollars. At 10 million it is 5,000 dollars. Same rate, and the bill scales straight with volume. Swap in a real Gemini 3 per-token rate and the slope gets steeper, which is exactly why Flash exists.
Wire up your first call
Enough map. Here is the smallest useful thing you can run against the platform: a single call to Gemini through the Gemini API in Agent Platform, using the Google Gen AI SDK for Python. Install with pip install google-genai, set your project and region, and authenticate with application default credentials.
from google import genai
# vertexai=True routes through Agent Platform, not the public Gemini API
client = genai.Client(
vertexai=True,
project='my-gcp-project',
location='us-central1',
)
resp = client.models.generate_content(
model='gemini-2.5-flash',
contents='Name three Google Cloud GenAI services, one line each.',
)
print(resp.text)Expected output: three short lines naming services such as Agent Platform, the Gemini API, and Model Garden. Failure mode: a 403 PERMISSION_DENIED means the Vertex AI (aiplatform) API is not enabled on the project, or your credentials lack the Vertex AI User role; a 404 usually means the model ID is not served in the region you set. Enable the API and set a region where the model exists, then rerun.
How a real request flows through the stack
It helps to follow one request down the layers and back, because the five boxes stop being abstract once you watch traffic move through them. A user asks your support bot a question. Your application code, sitting in the apps layer, does not call a model blindly. It first hits a platform service, Vector Search, to pull the three or four most relevant passages from your own documentation. That retrieval step is what keeps the answer grounded in your data rather than the model general knowledge. Part 12 builds this properly; for now, note that it happens before the model sees anything.
Your code then calls the Gemini API in the model access layer, passing the user question and those retrieved passages together as one prompt. The request lands on a Gemini 3 model in the models layer, which runs on TPUs or GPUs in the infrastructure layer that you never provisioned or saw. A response comes back through the same path. From your code it was one function call. Underneath, it crossed four layers, touched your private data, and metered a fraction of a cent. That round trip is the shape of almost every generative AI feature you will build here, whether it answers questions, drafts text, or drives an agent.
Two things fall out of this. The model is rarely the hard part; retrieval and grounding are. And most of your cost and latency is set by how much text you stuff into that prompt, which is why the character and token math from the pricing section matters more than the model you pick.
Where I would start on Google Cloud GenAI
If you are standing at the edge of this platform with a real task, here is my recommendation, not a hedge. Open Agent Studio, test Gemini 3 Flash against your actual prompt for an hour, and only reach for Pro if Flash misses on quality. Move to the Gemini API the moment you write your second script, and pin the model ID and region in config from the first commit. Leave Model Garden endpoints, tuning, and TPUs alone until you have a concrete reason, because each one adds standing cost or operational weight you do not need to prove the idea.
That is the whole stack in one pass. The layers we named here are the spine of the next twenty-nine parts, and each one takes a single row of that first table and goes deep. Next up is the platform itself: what Agent Platform gives you that a raw model API does not, and how Model Garden fits in. Read Part 2 when it lands, and keep the five-layer picture handy while you do.
Start of the series | Series guide | Cross-series: AWS GenAI | Next: Part 2 »
References
- Gemini Enterprise Agent Platform (formerly Vertex AI), Google Cloud
- Ironwood TPUs and new Axion-based VMs, Google Cloud Blog
- TPU7x (Ironwood), Google Cloud Documentation
About The Author
DrJha