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.

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. 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. Google Cloud's broader API library rounds this out: any capability exposed as an API can, in principle, become a tool.

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.

Pre-built AI APIs are trained, ready-to-call services for common AI tasks — no model building 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.

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 assesses the damage photos, 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 assembly-over-building economics is the business value the exam wants you to articulate.

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.