How Google Cloud Empowers Developers: Agent Platform and RAG

Agent Platform is Google Cloud's unified environment for building with generative AI: one place where developers discover and evaluate models, adapt them with company data, build gen AI agents, and deploy and manage everything with enterprise-grade security. Instead of stitching together separate products for model access, search, training, and deployment, a development team works inside a single platform where those capabilities are designed to fit together.

The exam highlights three capabilities inside it. Model Garden is where developers find and compare foundation models. Agent Search provides ready-made, Google-quality search and question answering over an organization's own content. Agent Platform AutoML lets teams train custom models through a guided workflow rather than hand-built training code. Around these sit the tools to build custom agents — defining goals, instructions, and the data an agent can use — and to run them in production.

The business value is threefold. First, speed: teams start from pretrained models and prebuilt components instead of building from zero, so pilots become products in weeks rather than quarters. Second, accessibility: capabilities like AutoML and low-code agent building mean useful AI is no longer gated on scarce machine learning specialists. Third, governance: because building, grounding, and deployment happen on one platform, security controls, access policies, and monitoring apply consistently — which is what makes gen AI acceptable to enterprise risk and compliance teams.

Model Garden is a curated catalog inside Agent Platform where developers discover, evaluate, and start using models. It brings together Google's own models — the Gemini family for language and multimodal tasks, Imagen for images, Veo for video, and the lightweight Gemma models — alongside popular open models and models from Google's partners, each with a model card describing what the model is for, its intended uses and known limitations, and how it can be used, so a team understands a model before committing to it.

Models in the catalog are offered in three different ways, and the difference decides what a team can do with them:

Two near-twins are worth keeping apart. Gemini Nano is the Gemini model that runs on device (on Android through the AICore system service); its weights are not released, so it is not a model a team downloads and self-hosts — Gemma is Google's open-weight family for that. And Google AI Studio is a developer tool for prototyping with Google's own models such as Gemini; it does not offer partner models such as Claude, and it is not the route for enterprise billing and governance — Agent Platform is.

The path from catalog to production is: read the model card, test candidate models on the team's own prompts, then call the managed API or deploy the model on Agent Platform, tuning it only if testing shows a gap. The business value is choice without fragmentation: Model Garden avoids betting everything on one model that later proves wrong for a workload, and avoids scattering teams across disconnected tools and vendor accounts with no shared governance. One catalog, many models, one set of enterprise controls.

The right model is the smallest one that does the job well enough: choose each workload's model on quality, latency, and cost rather than standardizing on the largest. A frontier model earns its cost on complex reasoning; simple, high-volume, or real-time work — classifying messages, returning short answers while a user waits — usually runs better on a smaller, faster model such as a Gemini Flash model, at a lower cost per request. Quality, speed, and cost trade against one another, so evaluate several model sizes on representative prompts and keep the smallest that meets the quality bar; Model Garden makes that comparison straightforward because the candidates sit in the same catalog.

Three other levers are often mistaken for fixes to speed or cost:

Provisioned Throughput suits steady, high-volume production traffic that needs assured capacity and predictable spend; pay-as-you-go suits pilots and variable traffic. Neither billing choice replaces picking the right-sized model.

Agent Search gives an organization Google-quality search over its own data, out of the box. Developers point it at their content — internal documents, websites, knowledge bases, structured records — and it delivers a search and question-answering experience that understands natural language, ranks results by relevance, and can generate conversational answers grounded in the indexed content, with references back to the sources it used.

Use cases cluster in two areas. Inward-facing: an employee help center where staff ask questions in plain language and get answers drawn from HR policies, IT runbooks, and internal wikis instead of hunting through folders. Outward-facing: product search and self-service support on a company website, where customers get direct, sourced answers rather than a list of links.

The business value is time to value. Building a modern retrieval system in-house means solving document parsing, indexing, ranking, and answer generation — deep specialist work. Agent Search packages that entire stack as a managed offering, so the work left for the team is curating the content, not engineering the search. It fits a company that wants trustworthy, sourced answers over its own information quickly and without a search engineering team.

Measure that value by outcomes, not activity. Outcome metrics show the business result the investment was meant to deliver: support contacts avoided because self-service resolved them, less time for employees to find information, higher self-service resolution rates. Activity metrics — raw usage counts and other measures of how much the system does — show the system is running and being used, but not whether it is paying off; a rise in searches can even signal that people are not finding answers.

Agent Platform AutoML trains a custom machine learning model on a company's own labeled data through a guided interface, without training code or model design. The team supplies labeled examples — today chiefly images (classification, object detection) and tabular records (classification, regression, forecasting) — and AutoML handles model building, training, and evaluation, producing a model specialized to that business problem. Text is no longer an AutoML case: the AutoML text objectives were deprecated in favor of tuning Gemini models, so a text task such as routing support tickets is handled by prompting or tuning Gemini instead.

It fits when the knowledge that matters lives in the company's own labels and general-purpose models do not have it. Typical examples: a manufacturer training an image model to spot defects unique to its production line, a recycler grading photos of incoming material into its own quality grades, or an equipment lessor predicting which leased machines will need early maintenance from years of labeled service records.

AutoML sits between two neighbors. A pre-trained API such as Cloud Vision label detection works immediately but returns general-purpose labels ("vehicle", "metal", "furniture"); it cannot learn a company's own categories, and no setting on the request teaches it new ones. Custom training — hand-written training code run on Agent Platform — gives full control but needs ML engineers to build and maintain it. AutoML gives a custom model from the company's labels without that team.

The business value is democratized model building: a project that once required an ML research team becomes one a capable developer or analyst can deliver, which lowers cost, shortens timelines, and lets the domain experts who understand the data drive the work.

Start with the least effort that can work: prompt a foundation model first, tune only when prompting falls short, and reserve custom training for when nothing packaged can do the job. Each step down this ladder adds data, skills, and cost that a specific requirement must justify.

1. Prompt a foundation model (Gemini) — for general tasks such as summarizing, drafting, extracting, or answering. It needs no training data and can work the same week. Add grounding (RAG) when the answer depends on company facts.
2. Supervised tuning — when prompting alone does not give the format or behavior needed and the team has example input/output pairs to learn from. Without examples, tuning is not available.
3. Agent Platform AutoML — when the task is recognizing the company's own categories in images or predicting from tabular records, labeled data exists, and there are no ML engineers.
4. Custom training — when requirements exceed what the managed options offer and the organization has ML engineers to own the code.

One workflow can use more than one rung. A logistics company might use an AutoML tabular model trained on its own shipment records to predict which deliveries will run late — a pattern only its data holds — and a prompted Gemini model to write the delay notice to the customer, which is a general writing task. Match each step to the cheapest tool that does it well.

Retrieval-augmented generation (RAG) is the technique of retrieving relevant information from a knowledge source at question time and supplying it to a model so the answer is grounded in current, company-specific facts rather than only the model's training data. RAG matters because foundation models have a knowledge cutoff, know nothing about your private data, and can hallucinate — retrieval addresses all three without changing the model's weights.

The alternatives do not fix those problems. Fine-tuning changes behavior and style but is a poor way to keep facts current — every policy change would need another tuning run, and the answer still cites no source. Lowering the temperature makes output more consistent, not more correct. A newer model has a later cutoff but still knows nothing about the company's internal data. Placing every document in a long-context prompt can work for a small, fixed set, but it has no retrieval step at all: the whole corpus is processed as input on every request (context caching can lower the cost of a repeated context, but not remove it), which limits scale and raises cost. RAG retrieves only the relevant passages each time.

Google Cloud offers two routes to RAG. Prebuilt RAG with Agent Search is the managed path: Agent Search handles ingesting documents, indexing them, retrieving the right passages, and grounding generated answers with citations as one packaged capability. RAG APIs are the component path: separate services for each stage of a retrieval pipeline, which developers wire into their own code.

Because the components are separate, a team does not have to adopt them all — it can add a single component to a pipeline it already runs. Ranking is the clearest case: it reorders whatever candidates an existing retrieval step returns, so adding it requires no re-embedding or re-indexing.

The decision rule mirrors build versus buy. Choose prebuilt RAG with Agent Search when the goal is grounded answers over company content with minimal engineering — fastest time to value, least to maintain. Choose RAG APIs when the team has requirements the packaged experience cannot meet — a custom retrieval strategy, unusual document formats, an existing pipeline to improve, or tight integration into its own application — and is prepared to own what it builds. Either way the outcome is the same: answers users can trust because they are grounded in the organization's own sources.

A grounded assistant is only as current as the content it retrieves from, so stale answers are fixed in the data store, not in the model. If an assistant built on Agent Search keeps returning outdated information and citing an outdated source, the cause is the index: the new source was never added, the old one is still there, or both.

• Add the new source to the data store (or make sure its location is one the data store syncs from). A document that is never indexed can never be retrieved.
• Remove or replace the superseded source. Adding the new page while the old file stays indexed leaves two conflicting answers to retrieve from.
• Don't reach for the model. Fine-tuning on the new text, switching to a bigger model, or adding prompt instructions about recency cannot help — the model can only use documents that are actually retrieved.

The ongoing practice is content ownership: someone owns each source, retires superseded versions, and keeps the data store's connections pointed at where current content now lives.

Agent Platform is also where developers build custom gen AI agents — systems that use a foundation model to reason about a goal, then take steps to achieve it, rather than only answering a single prompt. Building an agent means defining what it is for, writing the instructions that shape its goals, behavior, and tone, connecting the data stores that ground its answers in company information, and giving it tools so it can act — looking up an order, filing a request, or calling another system. The builder configures those three things; the foundation model's internals — its pretraining data, architecture, weights, and tokenizer — stay with the model provider.

Tools are what turn an answering agent into an acting one. An instruction alone cannot make an agent update a record or place an order in another system: without a tool connected to that system's API, the agent can only describe the steps for the user to follow. Adding more grounding documents or choosing a larger model does not change that either. Grounding is reusable, though: data stores already indexed for search can ground an agent too, so giving an assistant new abilities means adding tools, not rebuilding retrieval.

Use cases go beyond question answering. A customer service agent can check a delivery status and initiate a return, not just explain the returns policy. An internal operations agent can gather figures from several systems and draft the weekly report. The common thread is multi-step work: the agent plans, uses its tools, and carries a task through to completion.

The business value of building agents on Agent Platform, rather than assembling the pieces independently, is that grounding, model access, deployment, monitoring, and security controls are already integrated. Developers focus on what the agent should do; the platform supplies how it runs, scales, and stays governed. A need for an assistant that takes actions or completes workflows — not merely answers questions — calls for a custom agent with tools.

Each offering solves a different problem; the table matches them.

Notice the pattern: the offerings run from most packaged (Agent Search) to most flexible (RAG APIs and fully custom agents). Google Cloud's positioning is that a team should take the most packaged offering that meets the need — every step toward custom adds engineering cost that must be justified by a requirement the packaged option cannot satisfy.

Consider a mid-sized insurance company modernizing its customer and employee experience — a scenario shaped like the ones the exam presents. Its choices show how the offerings combine.

First, it deploys Agent Search over its policy documents, claims guidelines, and public help pages: customers get sourced answers about coverage on the website, and call center staff stop searching shared drives mid-call. This is prebuilt RAG — live in weeks because nothing had to be engineered. Second, its developers use Model Garden to select models: a frontier multimodal model for the complex claims assistant, and a smaller, cheaper model for high-volume email classification. Third, the claims team uses Agent Platform AutoML to train a custom image model on its own labeled photos of vehicle damage, producing a first-pass severity triage no general model could match. Finally, the company builds a custom claims agent on Agent Platform: grounded in the same policy data stores, able to check a claim's status, request missing documents, and draft the settlement letter — multi-step work, not just answers.

One platform carried all four projects, under one set of security and governance controls. When an exam question describes a business need, ask which layer it lives at — choosing a model, searching company data, training a custom model, or completing multi-step tasks — and the offering names itself.