skip to content

In Google ADK, where does the google_search built-in tool actually execute?

level: middleimportance: should knowfreq 50%

answer

  1. No Python function runs for it
  2. The provider does the retrieval
  3. Gemini-only capability
  4. Wrap it in its own agent to compose
  5. Citations arrive as grounding metadata

basics

~20 s

Not in your process. google_search is a declaration ADK passes to a Gemini model, which performs the grounded search on Google's side and returns results with grounding metadata. ADK never runs a Python function for it, which is why it is restricted to Gemini models.

solid answer

~50 s

`google_search` is not a Python callable ADK invokes; it is a marker that tells the framework to enable Gemini's built-in Search grounding on the model request. The search runs model-side, and the answer comes back already grounded, with grounding metadata and source references attached rather than a function response you wrote. Practical consequences: it only works with Gemini models — a model plugged in through ADK's other model integrations cannot use it — and using Search grounding carries Google's requirement to display the returned Search Suggestions in your UI. ADK also documents limits on mixing model-executed built-in tools with other tools in the same agent, and on using them inside a sub-agent; the standard workaround is to give the built-in tool its own dedicated agent and expose that agent to your main agent via `AgentTool`. Built-in code execution is configured separately, through the agent's code executor rather than as a tool.

code

python · 24 lines
python
from google.adk.agents import Agent
from google.adk.tools import google_search
from google.adk.tools.agent_tool import AgentTool

search_agent = Agent(
    name="search_agent",
    model="gemini-2.0-flash",
    description="Answers questions about current events using Google Search.",
    instruction="Answer the question using Google Search and cite what you used.",
    tools=[google_search],
)


def get_order_status(order_id: str) -> dict:
    """Looks up the shipping status of an order by its id."""
    return {"status": "success", "shipping_state": "shipped"}


root_agent = Agent(
    name="root",
    model="gemini-2.0-flash",
    instruction="Use search_agent for web questions and get_order_status for orders.",
    tools=[AgentTool(agent=search_agent), get_order_status],
)

go deeper

for a junior

Know that google_search is a built-in whose work happens on the Gemini side, that it needs a Gemini model, and that you never write a function body for it.

for a middle

Explain the split between framework-executed and model-executed tools, what grounding metadata gives you, and the pattern of isolating a built-in behind its own agent when it will not compose.

for a senior

Show the operational angle — swapping models breaks it, you cannot log or filter the retrieval, and the display obligations are part of shipping it — plus the extra latency of the wrapped-agent workaround.

for a principal

Decide when opaque provider grounding is acceptable at all versus a retrieval pipeline you own and can audit, and set the rule for your teams on citation and compliance surfaces.

## Two kinds of tool in one list Everything in an ADK agent's `tools` list looks alike from the outside, but there are two fundamentally different species inside. **Client-side tools** — your functions, OpenAPI-generated REST calls, MCP tools — are executed by ADK in your process: the model emits a function call, ADK runs code, ADK sends a function response back. **Model-side built-in tools** are executed by the model provider. `google_search` is the canonical example: ADK's job is only to flag the capability on the request it sends to Gemini. There is no Python function to run, no function response for you to shape, and no place for you to intercept arguments. Understanding that split explains every constraint that follows. ## What comes back With Search grounding enabled, the model retrieves and reads results itself and answers from them. Alongside the text you get grounding metadata: which queries were issued and which sources supported the answer. That metadata is the basis of citation UI, and it is also your only observability into what was retrieved — you cannot log the raw results the way you would log your own tool's return value. Google's terms for Search grounding require that you display the Search Suggestions that come back with the response. Teams miss this because it isn't a code-level failure — nothing breaks; you are simply out of compliance. It is worth naming in an interview because it shows you have read the product constraints and not only the API. ## Model coupling `google_search` requires a Gemini model. ADK can drive other model families through its model integrations, but a built-in tool is a provider capability, not a framework capability, so it does not travel with them. This is the first thing to check when a team says "we swapped the model and search stopped working." ## Composition limits and the AgentTool workaround ADK documents restrictions on model-executed built-in tools: how many may be attached to a single agent, whether they can sit beside other tools on that agent, and whether they can be attached to a sub-agent in a hierarchy. These limits are model- and version-dependent and have been relaxing over time, so the durable answer in an interview is the *pattern* rather than the exact rule of the week: > Give the built-in tool an agent of its own — an agent whose only job is grounded search — and expose that agent to your real agent with `AgentTool`. That pattern is worth understanding on its own merits, independent of any limit. It gives you: - **A clean boundary.** Your main agent sees one tool named for what it does ("search the web"), described in your words. - **Context isolation.** The search agent's retrieved material and reasoning stay in its own invocation; only its answer reaches the caller's window. - **Substitutability.** Swapping web search for an internal search backend later is a change to one wrapped agent, not to the main agent's prompt. The cost is the usual AgentTool cost: an extra nested agent run per search, so latency and tokens for two model loops instead of one. ## Code execution is not a tool any more A related trap: built-in code execution used to be expressed as a tool object in early ADK, and a lot of training-era material still shows it that way. In current ADK it is configured on the agent as a code executor — you set the agent's `code_executor` to a built-in executor instance rather than adding something to `tools`. If a candidate writes it as a tool import, that dates their knowledge. ## Other grounded tools in the family The same model-side pattern covers grounding against private corpora rather than the public web, exposed as its own tool type for Vertex AI Search. It behaves the same way — configured, not executed by you — and carries the same model coupling. ## When not to use it Search grounding is convenient but it is opaque: you don't control the query, the retrieval, the ranking, or the number of documents read, and you can't apply your own filters or reranking. When answer provenance must be auditable, when the corpus is private, or when retrieval quality has to be tuned, a retrieval pipeline you own — your own retrieval tool returning documents you selected — is the right call, and grounding is the shortcut you take when speed of delivery matters more than control. ## What interviewers listen for That you can classify tools by *who executes them*; that you know the Gemini coupling and the display requirement; that you reach for a dedicated agent plus `AgentTool` when built-ins won't compose; and that you know code execution moved off the tools list.

  • Why can't you use google_search with a non-Gemini model in ADK?
    Because it is a provider capability, not framework code. ADK does not implement a search function; it flags Search grounding on the request to Gemini, and Gemini performs the retrieval. A model reached through a different integration has no such flag to set, so there is nothing for ADK to enable. If you need search with another model, you write your own retrieval tool that ADK executes client-side.
  • How would you show citations for a grounded answer?
    Use the grounding metadata that comes back with the response — it reports the queries issued and the sources that supported the answer — and render those as citations. Note that Google's terms for Search grounding also require displaying the returned Search Suggestions, so a compliant UI shows both, not just your own citation list.
  • Where does built-in code execution live in current ADK?
    On the agent, not in its tools list. You configure the agent with a built-in code executor instance rather than importing a code-execution tool, which is how earlier ADK versions expressed it. Code samples that add a code-execution entry to tools are from the older surface and will mislead you on the current API.

saying these in an interview costs you the question

  • Thinks ADK runs a Python function for google_search
  • Assumes it works with any model ADK can drive
  • Expects raw search results as a normal function response
  • Adds built-in code execution to the tools list
  • Ignores the requirement to display Search Suggestions

context

resolving links…