Google's Gemini docs say the model proposes a call, code executes it

The conversation

Google documents function calling in the Gemini API as a way for a developer to describe a function to the model and receive a structured request to call it. As Google's current documentation, retrieved 16 September 2026, states in plain terms: 'The model doesn't execute the function itself. Extract the name and args and execute in your application.' Separately, Google Cloud documents a different, higher-level product at cloud.google.com/products/agent-builder, now folded into what the page calls the Gemini Enterprise Agent Platform, for assembling grounded, tool-using assistants rather than calling the Gemini API's function-calling feature directly.

What the documents show

The Gemini API documentation describes a four-step sequence: a developer defines a function's name, parameters and purpose in a structured schema; sends a prompt together with the declarations; the model returns either ordinary text or a distinct 'function_call' step naming a function and its arguments; and the developer's application runs that function and sends the result back so the model can produce a final response. The documentation states the model chooses, in its default automatic mode, whether a request needs a function call at all or can be answered directly. The Agent Builder page describes a separate, enterprise-oriented product for assembling agents against a company's own data and tools, distinct from the raw API surface.

The system boundary

The function-calling documentation is direct about where responsibility sits: the model's output is a proposal to call a specific function with specific arguments, and 'your application' is named as the party that executes it, handles errors and decides what happens next. This is the same boundary Google draws for the Gemini API generally: the model reasons about intent and shape, and the calling code is where any actual read or write to an external system occurs.

Where it fails

Because a function's description is what steers whether and how the model calls it, an ambiguous or incomplete description is a documented source of the model either skipping a needed call or filling in arguments the prompt did not actually supply. The documentation places the burden of designing a clear schema, and of validating the arguments a model returns, on the developer, not on the model self-correcting. Conflating this feature with Google's differently scoped Dialogflow product, built for structured dialogue rather than open function schemas, is a documented category error to avoid when evaluating either one.

• Does the application validate a function call's arguments against the schema before executing it?
• What happens when the model's automatic mode chooses not to call a function that the application expected?
• Is the enterprise Agent Builder layer being evaluated for its own guardrails, separate from the underlying API's function-calling behavior?

Google's own documentation is consistent that the model's role ends at proposing a call; the application remains the only party that executes one.