Gen AI Agent Tooling: Extensions, Functions, Data Stores, and Plugins

Agents need tools because a foundation model on its own can only generate text from what it learned during training — it cannot check today's inventory, look up a customer record, book an appointment, or send a confirmation. Its knowledge is frozen at a cutoff date, it has no access to your private systems, and it cannot take actions in the world. Tools remove those limits: they are the agent's connection to the external environment, letting it retrieve live information and act on the user's behalf.

Conceptually, an agent runs a loop. It receives a goal, reasons about what is needed, decides whether a tool can supply missing information or perform a required step, uses the tool, observes the result, and continues until the task is done. The model provides the reasoning; the tools provide the reach. Without tools, an assistant can only explain your refund policy. With tools, it can find the order, check its eligibility, issue the refund, and confirm — the difference between describing work and doing it.

For business leaders, this is the central point of the objective: the value of an agent is set less by how clever its model is and more by which systems it is allowed to see and act on. Deciding which tools an agent gets — and under what controls — is therefore a business and governance decision, not only a technical one.

Google Cloud groups agent tooling into four types, and the exam expects you to tell them apart by what each connects the agent to and where the work happens.

A useful way to hold the distinction: extensions and plugins are about reaching out to external capabilities, functions are about keeping control of what actually runs, and data stores are about knowing your business. Exam scenarios usually hinge on which of those three needs is being described.

Extensions and functions both let an agent invoke capabilities beyond the model, and the exam-relevant difference is where execution happens. With an extension, the agent platform itself calls the external API in real time: the agent decides it needs, say, live shipping rates, the extension makes the call, and the result flows straight back into the agent's reasoning. Extensions are standardized and often pre-built, so developers connect proven integrations instead of writing plumbing for every API.

With a function, the model never touches the external system. Developers describe the available functions — their names, purposes, and parameters — and when the model judges that one is needed, it outputs a structured request: call this function with these arguments. Your application receives that request, decides whether and how to honor it, executes it in your own environment, and returns the result. Execution happens on the client side, under your code, your credentials, and your rules.

The business logic of the choice is control versus convenience. Extensions minimize engineering: the platform handles the call end to end, which suits low-risk, read-style interactions like looking up public information. Functions maximize governance: because your application sits between the model's intent and the real action, you can validate inputs, enforce approval steps, and keep credentials entirely out of the model's reach — the right posture for consequential actions such as placing orders, moving money, or changing customer records. When a scenario stresses that the company must control or review what the agent does before it happens, functions are the answer.

Data stores connect an agent to your organization's information — documents, website content, knowledge bases, and structured data — so its answers are grounded in what your business actually knows rather than in the model's general training data. When a user asks a question, the agent retrieves the most relevant content from its data stores and uses it to compose the answer, typically with references to the sources. This is retrieval-augmented generation applied to agents: the same grounding technique, packaged as an agent tool.

The decisive business property is freshness without retraining. When the returns policy changes, you update the document; the agent answers correctly from that moment on. No model retraining, no redeployment, no lag between what the business decides and what the agent says. Data stores also shrink hallucination risk, because the agent is drawing from real company sources instead of improvising from general knowledge.

The alternatives fail for facts that change often. Tuning bakes knowledge into the model at training time, so however often you repeat it, the model always lags the latest change — and tuning teaches style and behaviour better than it stores facts. Pasting content into the prompt (system instructions or few-shot examples) means someone must re-edit it by hand every time a fact changes, and a prompt cannot hold a large corpus such as thousands of manuals. The scalable pattern is to keep that corpus in Cloud Storage (or a website or database) and connect it to the agent through a data store, which retrieves only the passages each question needs.

A concrete example: a bank deploys a mortgage assistant grounded in data stores holding its current product sheets, rate documents, and eligibility rules. Customers get accurate, cited answers about the bank's actual offerings — not a plausible industry-average answer — and when rates change, the fix is a document update, not an engineering project. On the exam, scenarios about answering from company documents, keeping answers current, or citing sources point to data stores.

Plugins connect an agent to outside applications and services, extending what it can do by plugging external capabilities into its toolkit. Where a data store gives the agent knowledge and a function gives it a governed action, a plugin gives it entry into another application's world — a storefront, a scheduling system, a payments service, or a third-party product the business already uses.

The practical effect is that agents can meet users inside existing workflows rather than forcing new ones. A customer support agent with a plugin into the order management application does not just explain how cancellations work; it opens the cancellation in the system the operations team already runs. For the business, plugins are the reuse story: capabilities the organization has already bought or built become moves the agent can make, without rebuilding them.

Keep the boundaries crisp for the exam. Extensions are standardized bridges to external APIs, executed by the platform. Functions are actions your own application executes under its own control. Data stores supply grounded knowledge. Plugins extend the agent into external applications and services. Questions test these one-line distinctions far more often than any implementation detail.

Agent tools need infrastructure behind them, and a handful of Google Cloud services appear again and again as the backing for agent tooling. You need to recognize each service's role, not configure it.

Cloud Storage holds files and unstructured content — the manuals, policies, and reports that feed an agent's data stores, and any files an agent's work produces. Databases hold the structured, live records agents look up and update: customer profiles, orders, bookings, inventory. When an agent checks an order status through a function call, a database answers.

Cloud Functions runs small pieces of event-driven logic without any server to manage — a natural home for the code behind a function call, such as validating a request and writing it to a database. (Google now also offers it under the name Cloud Run functions; the exam guide keeps the name Cloud Functions.) Cloud Run runs containerized applications and APIs, fitting heavier services an agent calls: an internal pricing engine, a document generator, an integration layer in front of older systems. And Agent Platform is where the agent itself is built, grounded, deployed, and managed — the place the tools are attached and governed.

The serverless options differ in what you deploy and how it runs:

The Google Cloud API Library is the catalogue in the Google Cloud console where you discover Google APIs (Translation, Document AI, Vision, Maps and many more) and enable them for a project — enabling an API is the step before an agent's tool can call it. Keep it apart from two similarly named catalogues: Model Garden is where you discover, compare, and deploy models, and Agent Garden offers sample agents and tools to start building from. APIs, models, and agent samples: three different libraries.

The exam pattern is role recognition: files and documents point to Cloud Storage, live structured records to databases, lightweight event-driven logic to Cloud Functions, containerized services to Cloud Run, and the agent's own lifecycle to Agent Platform; finding and switching on a Google API points to the API Library.

Pre-built AI APIs are trained, ready-to-call services for common AI tasks — no training data, no model building, and no ML expertise required — and as agent tools they act as the agent's senses and voice, letting it work with speech, images, video, and documents rather than text alone.

Three pairs are easy to confuse. Translation versus Document Translation: text in and text out, versus a whole document translated with its layout kept — both come from the same Cloud Translation service, so the choice is about the input, not a different product. Cloud Vision versus Document AI: Vision's OCR returns the raw text it finds on a scanned page, whereas Document AI understands the form and returns labelled, structured fields — name, amount, date — ready to write to a system. Cloud Vision versus Video Intelligence: Vision treats each image in isolation, so running it on frames sampled from a video tells you nothing about what happens between them; Video Intelligence analyzes the footage as a sequence, detecting where shots change and following an object from frame to frame. Natural Language is different again: it analyzes free text for sentiment and entities rather than extracting fields from a form.

Picture an insurance claims agent handling a phone call: Speech-to-Text transcribes the caller, Natural Language detects distress and prioritizes the case, Document AI extracts fields from the photographed claim form, Cloud Vision labels the uploaded photos and reads text in them such as a registration plate, Translation serves a caller in another language, and Text-to-Speech reads the confirmation back. Each capability is a ready-made API — assembled, not built.

That is the business case, and it is clearest against the alternatives. Training a custom model (for example with AutoML) or tuning a foundation model both need labelled examples and ML effort before anything works; a pre-built API needs neither and delivers a proven capability through a single API call. The trade-off is customization: a pre-built API does the general task well, but a non-standard need — such as judging the severity of vehicle damage from a photo — is beyond the generic Vision labels and calls for a custom-trained model.

Agent Studio and Google AI Studio serve different jobs: Agent Studio is for building and running production gen AI agents on enterprise foundations, while Google AI Studio is a lightweight, web-based environment for quickly prototyping and experimenting with Gemini models. The exam tests whether you can pick the right one from a scenario.

The two are stages of one journey, not rivals. A developer might spend an afternoon in Google AI Studio proving that Gemini can draft compliant policy summaries from sample text — fast, free-form, no setup. When the company decides to turn that idea into a grounded assistant for two thousand employees, the work moves to Agent Studio, where data stores, tools, security, and deployment live. Scenario cue words resolve the question: experiment, prototype, try out a model point to Google AI Studio; production, grounded in company data, governed, at scale point to Agent Studio.