Agents on Google AI: the agent development kit

• Gems in the Gemini app: saved personas and instructions. Zero code, no tool loop.
• Gemini API function calling: you wire the loop yourself.
• ADK: the loop, state, multi-agent orchestration, and deployment handled for you.
• Vertex AI Agent Engine: where ADK agents run in production.

If you only need the model to call one function once, you do not need ADK. ReachReachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → for it when the task is multi-step.

When an agent beats a single call

A single Gemini call (even with function calling) is the right tool when the work is one step: classify this email, extract these fields, draft this reply. Gemini's long context and native multimodality already let one call do a lot.

An agent earns its keep when the number of steps is unknown in advance and depends on what intermediate results come back. Signs you have crossed that line:

• The model needs to search, read what it found, then decide whether to search again.
• Each step's input depends on the previous step's output.
• The task spans multiple tools (search, then a calculator, then a database write).
• You want the agent to retry or change strategy when a tool fails.

A "research and summarize this topic" task is the canonical example. You cannot know up front how many searches it will take to cover a topic well. The agent decides that at runtime. That dynamic, data-dependent looping is exactly what a single call cannot do and what ADK exists to manage.

The cost is real: more latency, more tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Voir la définition complète →, more ways to fail. Use Flash for the loop where you can (it is fast and cheap), reserve Pro for the steps that need deep reasoning, and never reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → for an agent when a single structured call would do.

A concrete research-and-summarize agent

Let's build one. The agent takes a topic, uses Google Search grounding to gather current information, loops until it has enough, then writes a structured summary.

First, set up the environment. You need the SDK and a Gemini APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → key from Google AI Studio (or Vertex AI credentials if you deploy to Cloud).

Now the agent. ADK ships a built-in google_search tool that grounds responses in live Google Search results, so you do not write the search plumbing yourself.

That instruction is doing the heavy lifting. Notice it tells the agent *when to loop* ("run multiple searches if the first results are thin") and *when to stop* ("when you can cover the topic accurately"). Vague stop conditions are the number one cause of agents that loop forever or quit too early.

Running it locally

ADK gives you a dev UI to watch the loop, including every tool call and the model's reasoning between steps. From the folder containing your agent:

This opens a local browser UI where you type a topic and watch the agent search, observe, search again, and write. Seeing the intermediate steps is how you debug instructions. If the agent searches once and stops, your stop condition is too loose. If it searches eight times for a simple topic, tighten it.

To run headless instead, ADK exposes a Runner you can call from your own code or wrap in an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →.

Why grounding matters here

The google_search tool is not just "search." It is grounding with Google Search, which feeds real results into the model and returns source metadatametadataDonnées sur les données, informations décrivant le contexte, la structure, la provenance et les caractéristiques d'un asset de données (auteur, date, format, source, définition).. For a research agent this is the difference between a confident summary and a *correct* one. Without grounding, the model writes from training data that has a cutoff. With it, the agent reads today's web. Always ground agents that make factual claims about the current world.

Adding a custom tool

The built-in search is fine, but real agents need *your* tools: a function that hits your database, posts to Slack, or writes to a Google Sheet. In ADK a tool is just a typed Python function with a clear docstring. The docstring is not documentation for you, it is the description the model reads to decide when to call it.

Add it to the agent's tools list alongside google_search. Now the agent can research *and* archive in one loop. Write tool docstrings like you are explaining the function to a smart new hire: what it does, what each argument means, what it returns. Sloppy docstrings cause the model to call tools at the wrong time or pass garbage arguments.

One important constraint: ADK's built-in tools like google_search have rules about combining with custom tools depending on the model. When in doubt, split responsibilities across multiple agents.

Multi-agent: when one loop is not enough

ADK's real power shows up with multi-agent systems: one coordinator agent that delegates to specialist sub-agents. For our example you might have a researcher agent (search only) and a writer agent (formatting and archiving), with a coordinator that routes between them.

This matters because each agent stays focused. A focused agent with three tools behaves far more reliably than one agent juggling ten. You define sub-agents and hand them to a parent via the sub_agents parameter; the parent decides who handles what. Start with a single agent, and split only when one agent's instructions get long and conditional.

Taking it to production on Vertex AI

Local adk web is for building. Production is Vertex AI Agent Engine, a managed service that hosts your agent, handles sessions, scales, and integrates with the rest of Vertex AI. The same agent code deploys with minimal changes; you mostly flip from APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →-key auth to Vertex AI auth and point ADK at your Google Cloud project.

What you get by deploying to Agent Engine instead of running your own server:

• Managed sessions and state: conversation memory persists without you building a database for it.
• Scaling and monitoring: it runs as a managed endpoint with built-in observability.
• Enterprise controls: it lives inside your Google Cloud project, under your IAM and VPC rules, which matters when the agent touches internal data.

For agents that act on company data, that last point is the whole reason to be on Vertex rather than calling the raw Gemini APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → from a script.

Evaluation: the step people skip

An agent that works in a demo and an agent that works on real inputs are different things. ADK includes an evaluation capability: you define test cases (input plus expected behavior or expected tool trajectory), and ADK runs the agent against them and scores both the final response and *which tools it called in what order*.

This trajectory check is specific to agents and crucial. A single call you evaluate on output alone. An agent you also evaluate on its *path*, because an agent that gets the right answer by accident (or burns twenty tool calls to get there) is not production-ready. Build a handful of eval cases before you deploy, and rerun them every time you change an instruction.

A realistic mental model

Think of ADK as the layer that turns Gemini from "a model that can suggest a tool call" into "a process that drives a task to completion." The model is still the brain. ADK is the loop, the memory, the routing, the deployment, and the test harness around it. You bring three things: sharp instructions (especially stop conditions), well-described tools, and eval cases. ADK and Vertex handle the rest.

Key Takeaways

• Reach for an agent only when steps are dynamic. If the work is one step, use a single grounded Gemini call. Agents add latency, cost, and failure modes; earn them.
• Stop conditions live in the instruction. Most runaway or lazy agents are fixed by telling the model explicitly when to keep going and when to finish, not by changing the model.
• Tool docstrings are prompts. The model picks tools and arguments from the docstring. Write each one clearly, with typed args and a described return value.
• Ground anything factual with the built-in google_search tool so summaries reflect the live web, not the training cutoff.
• Develop with `adk web`, deploy to Vertex AI Agent Engine, and gate deploys behind ADK evals that check the tool trajectory, not just the final answer.