Gemini API combined built-in tools with custom functions

Google updated the Gemini API so one interaction can expose built-in tools and developer-defined functions together. Its March 17 announcement also introduced context circulation across built-in tool calls and extended Google Maps grounding to the Gemini 3 family. Google framed the change as a way to reduce application-side orchestration for multi-step agents.

Tool selection moved closer to the model

Previously, an application often decided whether to invoke Search, Maps or a private function before making the next model call. Allowing the model to choose among both classes in one interaction can shorten that loop and preserve more of the working context. It also enlarges the control surface: a public lookup and a state-changing internal function can now be adjacent choices.

Developers should treat circulated tool responses as typed, provenance-bearing data rather than an undifferentiated prompt transcript. The source, freshness and authorization context of a Maps result differ from those of an internal inventory lookup. Those differences should survive into logs and policy checks.

What to test before enabling writes

Start with read-only functions and record the selected tool, arguments, response identifier and final answer for each step. Add tests for an unavailable built-in tool, conflicting public and private data, repeated function calls, and a user who lacks permission for the requested action.

The API change can simplify the happy path, but production safety still belongs to the surrounding application. Validate arguments, enforce authorization outside the model, make mutations idempotent and place explicit confirmation or policy gates around consequential operations.