Google and Gemma 4: how to run tool calling locally with Python and Ollama

Machine Learning Mastery has published a detailed walkthrough on building a local AI agent with tool calling on top of Gemma 4. The code itself matters less than the signal it sends to the market: Google's open-weight models are pushing ever more confidently into scenarios that cloud APIs used to dominate with almost no alternative.

What the article covers

In the April 14 piece, the author lays out a practical stack for a local agent: Python, Ollama and the `gemma4:e2b` model. The idea is simple. Instead of a regular chatbot that answers only from its weights, the developer gives the model a set of functions along with descriptions of their parameters. When a request needs external data, the model doesn't make up an answer. It produces a structured call to the right tool, receives the result and only then writes the final response.

Against the backdrop of the Gemma 4 release, this is especially telling. Google shipped the open model family under the Apache 2.0 license and put the emphasis on agentic use cases: structured JSON, function calling, system instructions and support for a wide range of hardware, from mobile devices to workstations. Officially, the company is positioning Gemma 4 as a foundation for local and on-device workloads, and Ollama is among the tools it lists as supported from day one. For developers, that means a clearer path to private assistants without a mandatory dependency on an external provider.

How the agent works

The example's architecture avoids heavyweight frameworks entirely. The author deliberately sticks to Python standard libraries such as `urllib` and `json` to show that a basic tool-calling agent can run without LangChain, without orchestrators and without a thick layer of abstractions. The key component is a tool registry written as JSON Schema. It tells the model which functions are available, which arguments they accept and which fields are required.

• The developer writes local Python functions that serve as tools
• Each function gets a strict parameter schema
• The user's request is sent to Ollama together with the list of tools
• The model returns `tool_calls` when it needs external data
• The application runs the function and sends the result back to the model

Then comes a second pass. The host application appends the tool's response to the message history with the `tool` role and calls the model again. At this step, Gemma 4 stops guessing and works from live data. In the example, this cleanly ties the model's reasoning and ordinary Python code into a single working loop with no cloud layer in between. In effect, the author presents a minimal agent runtime that you can take apart and adapt to your own needs in an evening.

Which tools the demo uses

For the demo, the author first builds a weather function on top of Open-Meteo, then adds three more tools: news, current time and currency conversion. The result is a small but illustrative agent that can handle not just a single fact but a compound request. For example: get the weather in Paris and the current time, convert Canadian dollars to euros, and pull in fresh news on a topic, all at once.

The article puts particular emphasis on the `gemma4:e2b` model. It's an edge variant of Gemma 4 with an effective 2-billion-parameter footprint during inference, designed to save memory and keep latency low. The article stresses that this setup can run locally, without a GPU and without API rate limits. For small teams and solo developers, this matters: agentic workflows stop being a costly experiment and become a routine engineering task. The author says he ran hundreds of queries through the system over a weekend and saw no failures in the basic tool-calling logic.

What it means

The takeaway isn't yet another Python tutorial but a lower barrier to entry. If Gemma 4 really does handle structured output and function calling reliably even in lightweight edge configurations, the market for local agents will grow quickly: expect more offline use cases, more private enterprise deployments and fewer reasons to jump straight to expensive cloud stacks.