Building agents with Google Cloud tools

"A chatbot answers," Farah said at the start of the seventh session. "An agent does." She wrote the shopping assistant's hardest customer question on the board: "Is the 40-litre dry bag in stock near me, and can you hold one until Saturday?" To answer the first half, the assistant must look up the customer's nearest stores and check live stock. To do the second half, it must place a hold in the store system. No amount of prompt writing can do either; the model has to use tools. That makes it an agent.

GCP-110 explained what agents are and how they reason. This lesson covers the Google Cloud tools for building them: the kinds of tools an agent can use, the Google Cloud services and prebuilt AI APIs it can call, the ways to build an agent from no code to full code, and the controls that keep an agent safe. The exam guide lists all of these under the developer tools and agent tooling sections.

What makes an agent

An agent combines a model with instructions, memory and tools. The model reads the goal, decides what to do next, calls a tool, reads the result, and repeats until it can answer or must hand over to a person. This loop is often described as plan, act, observe. Agents can be simple, such as a helper that looks up one record, or complex, such as several agents that each handle one part of a process and pass work between them.

The four kinds of agent tools

The exam guide names four types of tools an agent can use. The names come from Google's agent documentation; what matters is the job each type does.

Function calling deserves special attention because it explains how an agent stays under the company's control. The model does not run the function itself. It produces a structured request saying which function it wants and with which values; the application decides whether to run it, runs it with its own permissions, and returns the result. That gives Birchline a place to enforce rules, such as refusing to place more than two holds per customer per day, regardless of what the model asks for.

# Illustrative function calling: the model proposes, the application decides.
import json
stock = {("DRYBAG40", "S014"): 3, ("DRYBAG40", "S022"): 0}
holds = []

def check_stock(product_id, store_id):
    return {"in_stock": stock.get((product_id, store_id), 0)}

def hold_item(product_id, store_id, customer_id):
    if sum(1 for h in holds if h["customer"] == customer_id) >= 2:
        return {"ok": False, "reason": "two holds per customer per day"}
    if stock.get((product_id, store_id), 0) < 1:
        return {"ok": False, "reason": "out of stock"}
    holds.append({"customer": customer_id, "product": product_id, "store": store_id})
    return {"ok": True}

allowed = {"check_stock": check_stock, "hold_item": hold_item}
# Requests a model might produce, as structured data:
proposed = [
    {"name": "check_stock", "args": {"product_id": "DRYBAG40", "store_id": "S014"}},
    {"name": "hold_item", "args": {"product_id": "DRYBAG40", "store_id": "S014", "customer_id": "C77"}},
    {"name": "hold_item", "args": {"product_id": "DRYBAG40", "store_id": "S014", "customer_id": "C77"}},
    {"name": "hold_item", "args": {"product_id": "DRYBAG40", "store_id": "S014", "customer_id": "C77"}},
    {"name": "cancel_order", "args": {"order_id": "10482"}},
]
for call in proposed:
    fn = allowed.get(call["name"])
    result = fn(**call["args"]) if fn else {"ok": False, "reason": "tool not allowed"}
    print(call["name"], json.dumps(result))

check_stock {"in_stock": 3}
hold_item {"ok": true}
hold_item {"ok": true}
hold_item {"ok": false, "reason": "two holds per customer per day"}
cancel_order {"ok": false, "reason": "tool not allowed"}

The last proposed call shows why the application, not the model, holds the keys. GCP-102 recorded Birchline's decision that the shopping assistant would have no permission to change orders. Here that rule is enforced simply: cancel_order is not in the list of allowed tools, so the request fails whatever the model says.

Google Cloud services and prebuilt AI APIs as tools

Agents often use other Google Cloud services as tools. The exam guide lists a set that a leader should recognize.

These prebuilt AI APIs are an important idea in their own right. They give ready-made machine learning for common tasks, such as reading text from a receipt or translating a sentence, through a simple API call. No training is needed. Before 2023 they were how most companies used AI on Google Cloud; today they are often tools inside agents. For a returns agent, Document AI could read a photographed receipt and pass the date and store number to the agent, which then checks the returns policy.

Ways to build an agent

Google offers several ways to build an agent, suited to different people and needs.

The Agent Development Kit is open source and works with models beyond Gemini, which fits the open approach the exam guide stresses. Agents built with it, or with other open frameworks, can run on the platform's managed agent runtime, which handles scaling, session memory and monitoring. Agents can also talk to other agents and tools through open protocols; Google has backed an agent-to-agent protocol, and many tools now expose themselves through the Model Context Protocol. Leaders do not need protocol details for the exam, only the idea that agents from different builders can work together.

For Birchline, the choice followed the stack logic from lesson 1. The returns helper, which only reads policies and drafts replies, could be built by the returns lead in Gemini Enterprise's designer. The shopping assistant, which calls store systems and faces customers, would be built by developers with the ADK, tested in Agent Studio and run on the platform's agent runtime.

Keeping agents safe and under control

Because agents act, mistakes can have consequences beyond a wrong sentence. Teresa insisted on five controls for any agent that took actions, and they mirror good practice that exam scenarios reward.

• Least privilege for tools. The agent's service account can call only the functions it needs, here check_stock and hold_item, and nothing that changes orders or payments.
• Rules in code, not only in prompts. Limits such as two held items per customer per day are enforced by the application around each tool, because a prompt instruction can be ignored or manipulated.
• Human hand-off. The agent passes to a person when it is unsure, when a customer is upset, or when a request falls outside its tools.
• Screening inputs and outputs. Prompts and responses pass through Model Armor, covered in lesson 10, to catch prompt injection attempts and unsafe content.
• Logging and review. Every tool call is logged with its inputs and result, and a sample of conversations is reviewed weekly.

Testing an agent before customers meet it

Agents need more testing than chat assistants, because they act. Farah's test plan for the shopping assistant had four parts. Happy-path tests check that ordinary requests work: finding a product, checking stock, holding an item. Edge-case tests cover unusual but legitimate situations: a store that has just closed, a product with no stock anywhere, a customer who asks for three holds. Adversarial tests, sometimes called red teaming, try to make the agent misbehave: asking it to cancel an order, to reveal another customer's details, or to ignore its instructions. Load tests check that it stays fast during a sale.

Every tool call in testing is logged with its inputs and outputs, so the team can see not just what the agent said but what it did. A test passes only if both are right. One early test showed the agent calling check_stock eleven times for a single question, once for every store in the region; the team added a function that searched nearby stores in one call and set a cap on tool calls per question.

Owen noticed that the plan said nothing about which model the agent used. "That's deliberate," Farah said. "The tests describe what the agent must do. If we change the model, the same tests tell us whether it still does it."

The plan also covered what happens when a tool fails. If the store system does not respond, the agent should say that stock information is unavailable right now and offer a link to the store page, rather than guessing. Failure behaviour is easy to forget in a demonstration, where every system works, and it is often what customers remember.

Owen asked whether the shopping assistant could also answer the phone. Farah said yes, in principle: Speech-to-Text and Text-to-Speech could turn it into a voice agent. "But customer service on the phone is its own product family," she said. "We'll look at it in lesson 11."