Google Cloud AI Offerings for Business Value: Agent Platform, Pre-trained APIs, AI Hypercomputer and BigQuery ML (Cloud Digital Leader)

Choosing a Google Cloud AI solution means trading off five considerations: how fast it can be delivered, how much development effort it takes, how much it can set the business apart, how much technical expertise it needs, and how much choice and flexibility it keeps. No single option wins on all five, so the right answer depends on which constraint matters most for the project in front of you.

Google Cloud's AI offerings sit on a ladder from ready-made to fully custom. The higher you climb, the more the result is shaped by your own data, and the more time, effort and skill it costs.

Read a scenario for its deciding constraint. A tight deadline, no training data or no ML staff point down the ladder, to pre-built tools and pre-trained APIs. A capability that is the company's competitive edge, built on years of proprietary data, points up the ladder to a custom model, which is worth the effort only when the organization has, or can hire, the skills to build it. A task that is the same in every company, such as transcribing a meeting, gains little from a custom build, because a generic model already does it well.

Organizations often split their portfolio. A hospital group, for example, might switch on a pre-built assistant for staff paperwork this month, while its data science team spends a year building a readmission-risk model on its own patient history. The quick win buys time and goodwill; the custom project is where the lasting advantage sits. The skill the exam rewards is placing each project on the ladder by itself rather than choosing one rung for everything.

Choice and flexibility means an organization can pick, compare and switch AI models without being tied to one provider, and on Google Cloud that choice comes from Model Garden. Model Garden is the model catalog in Gemini Enterprise Agent Platform. It offers Google's own models (such as Gemini and the Imagen image models), open models (such as Gemma and Llama) and partner models (such as Anthropic's Claude), all usable through the same platform.

Why this creates business value:

• Fit each task. Teams can choose the model with the best balance of quality, speed (latency) and cost for each use case, for example a small, cheap model for high-volume classification and a larger one for complex reasoning.
• Avoid lock-in. New and better models keep appearing. Because the applications are built and run on one platform, a team can adopt a newer model without rebuilding where its applications live.
• Compare before committing. Agent Platform includes evaluation tools, so a team can measure candidate models on its own test prompts and pick on evidence rather than reputation.

Do not confuse Model Garden with the Model Registry. Model Garden is where you find models others have built; the Model Registry is where an organization keeps and versions the models it has trained or tuned itself.

Example: a city council building a resident help line could start on a fast, low-cost model for routing simple requests and a more capable model for complex planning questions, then move to a newer model next year from the same catalog, keeping the rest of its application where it is.

Gemini Enterprise Agent Platform (Agent Platform for short) is Google Cloud's unified platform for building, deploying and managing AI models and agents. It is the developer platform in Google's AI stack (Google describes it as the evolution of Vertex AI, so earlier Vertex AI capabilities live on inside it), and it brings every stage of AI work into one place instead of a separate tool per stage.

The business value is consolidation: data science and development teams stop stitching together separate tools, which speeds up the path from experiment to production and makes governance easier. Keep the platform's scope in mind: it is where AI models and agents are built and run. Data storage and analytics, dashboards, end-user productivity assistants and security screening are separate Google Cloud products, covered in their own topics.

Agent Platform is the right choice when an organization needs a custom AI model or agent that uses its own data, connects to its own systems and runs in production. The more a use case depends on the company's private data, internal APIs or a customer-facing experience that must be reliable and monitored, the more it points to building on Agent Platform.

Typical use cases:

• Customer-facing agents that answer questions about the company's own offerings and act on a customer's records, such as a utility's agent that explains tariffs and books a meter reading.
• Process agents that work through a multi-step business task (gather information, check it against business rules and systems, prepare a result) and hand it to a person for sign-off, such as a hiring team's agent that screens applications and proposes interview slots.
• Custom predictive models trained on proprietary data, such as fraud scoring, equipment-failure prediction or demand forecasting.

What makes something an agent is that it reasons over several steps and takes actions through tools and APIs. A single-purpose AI service, such as one that only extracts fields from forms, can be one tool an agent calls, but on its own it is a capability, not an agent.

Pre-built app or custom agent?

Google also offers ready-made AI for employees, and choosing between that and building is a speed-versus-differentiation decision.

The audience is the first clue. If the users are the company's own employees and the need is generic, the pre-built apps are faster and cost nothing to build. If the users are the company's customers, or the AI must take actions inside the company's own systems, it is a custom build on Agent Platform. One organization often uses both, for different audiences.

A pre-trained API is a model Google has already trained for a common task, offered as a service an application calls; it needs no training data and no ML expertise, so it is the fastest route when the task is generic. The skill is matching the input type and the job to the right API.

Two near-twins catch people out. Speech-to-Text and Text-to-Speech run in opposite directions: speech in and text out is Speech-to-Text. And Translation converts text between languages, while the Natural Language API analyses text in its own language.

APIs can be chained when one task needs several steps, each with its own input type. A podcast network that wants written French transcripts of its German episodes would run Speech-to-Text first (German audio to German text) and then Translation (German text to French text). Work out the input and the wanted output, then list the conversions in between: each conversion is one API.

Pre-trained APIs know general categories only. They can say a photo shows a vehicle, but not which of a dealer's own trim levels it is, because that knowledge was never in the generic model. When a business needs its own categories, post-processing the generic output cannot add the missing detail; it needs a custom model trained on its own labeled examples (see the custom-models section).

Gemini is Google's family of multimodal foundation models, reached by developers through the Agent Platform API, and it fits open-ended tasks that create something new: drafting, summarizing, answering questions, reasoning and working across text, images, audio, video and code in one request. Because it is pre-trained on broad data, it needs no training data from the organization; prompts, and grounding in the company's own information, shape its output.

The rule of thumb: a purpose-built API is usually the better fit for a well-defined task with specific requirements (a glossary, a pricing model, a fixed output such as a transcript), and a foundation model is the better fit for open-ended generation. Real projects often combine them, using each for the part it does best, rather than forcing one tool to do everything.

Organizations build custom models with their own data when a generic model is not good enough, and Agent Platform offers two low-code routes: Agent Studio to adapt foundation models, and AutoML to train predictive models from labeled examples. Custom training with the organization's own code is the third route, for teams with ML engineers who need full control.

Agent Studio on Agent Platform

Agent Studio is the console workspace for generative AI on Agent Platform. Google describes it as a low-code visual canvas for designing and prototyping agents and their workflows, and it is also where teams try prompts on Gemini and other models, compare responses side by side, refine the prompt design and then tune a foundation model with the company's own examples, such as a bank's set of approved answers in its required compliance format. Tuning changes how the model responds: its style, format or behaviour on a specific task.

Tuning is easily confused with grounding, which also uses company data:

Diagnose the problem before choosing the fix: missing or stale facts call for grounding, while the wrong voice or format calls for tuning on examples of the output you want.

AutoML on Agent Platform

AutoML trains a custom model from the organization's labeled data without anyone writing training code. It covers image models (for example, a seed company sorting photos of seedlings by its own disease grades) and tabular models (predicting a value or category from rows of business data). The organization supplies labeled examples; AutoML handles model selection and training.

AutoML fits when two things are true: the categories are specific to the business, so a pre-trained API will not know them, and the team has the data but not the ML coding skills for custom training. Its cost is the work of collecting and labeling enough examples before any model exists. AutoML builds predictive models (classify, detect, predict); generating new text or images is the job of foundation models.

AI Hypercomputer is Google Cloud's integrated supercomputing system for AI workloads, made of three layers designed to work together: performance-optimized hardware, open software and frameworks, and flexible consumption models for paying for capacity. The value comes from those layers being designed and tuned together, so hardware, software and purchasing options each reinforce the others.

• Performance-optimized hardware. Accelerators — Cloud TPUs (tensor processing units, which Google designs specifically for machine learning) and NVIDIA GPUs — plus high-performance storage and networking that connect large numbers of accelerators. TPUs are built for strong performance per dollar on large-scale training and serving; GPUs are the widely used general-purpose accelerators.
• Industry-leading software and open standards. Support for open frameworks such as PyTorch, JAX and TensorFlow, and open tools for serving models. Teams keep the frameworks and skills they already have rather than learning a proprietary stack, which lowers the effort of adopting Google's accelerators and preserves portability. (Some code may still need adjusting for a particular accelerator, for example PyTorch on TPUs runs through PyTorch/XLA.)
• Flexible consumption. Several ways to pay for accelerator capacity, matched to the shape of each workload (next section).

The business benefit is performance and efficiency: accelerators handle the parallel maths of AI, so models train faster and serve with lower latency, shortening the time to results and lowering the cost of each training run or prediction. Faster hardware speeds up the computing part of AI work; the quality of the data and of the model design still decides how good the results are.

AI Hypercomputer is the infrastructure layer underneath Google's AI services. Teams training their own large models use it directly; teams using Agent Platform's managed services benefit from it without managing it themselves.

AI Hypercomputer controls cost by letting each workload use the consumption option that matches its pattern. Google's options include on-demand, Spot VMs, flex-start, standard reservations (often paired with committed use discounts) and future reservations, including calendar mode. Picking the wrong one either wastes money on idle capacity or risks the workload.

A video studio illustrates the mix: its rendering pipeline runs every day at the same load (a commitment pays off), its overnight re-encoding jobs can restart if cut off (Spot), and a one-off model training run is booked for specific dates in the spring (calendar mode). Two signals decide most scenarios: whether the work can survive an interruption, and whether capacity must be guaranteed at a particular time.

BigQuery ML lets users create, train, evaluate and run machine learning models inside BigQuery using standard SQL statements, so analysts can do machine learning with the skills they already have and without moving data out of the warehouse. A model is created with a SQL statement over a BigQuery table, and predictions come back as query results.

Its business value comes from two things the exam guide names:

• Standard SQL as the interface. SQL-fluent analysts can build models without learning Python or a separate ML tool, which widens who can use ML across the organization. BigQuery ML supports common model types, including linear and logistic regression, clustering, time-series forecasting (for example, daily energy demand) and classification (for example, whether a lead will convert).
• Flexibility to experiment with data. Models train where the data already sits, so teams can try and compare several models quickly. There is no export to another store, which shortens the experiment loop and helps meet policies that keep sensitive data inside the warehouse.

BigQuery ML is not limited to models it trains itself. A remote model over Gemini lets a SQL query send each row's text to Gemini and return the result, such as the sentiment of a review, as a column, again without exporting the data.

For the models BigQuery ML trains itself, the learning comes from the organization's data: a classification model needs historical rows where the answer is already known (labels), while unsupervised models such as clustering find groups without labels. A remote model works differently: the foundation model is already trained, and BigQuery ML simply calls it.

The benefit is clearest against the usual alternative: moving data out of the warehouse into a separate ML environment, which adds a copy of the data to secure and a programming language to learn. BigQuery ML is designed for analysts who want to stay in SQL and in BigQuery; data scientists who need full control still have Agent Platform.