Gemma 4 Revolutionizes Agency Tools with Local Capabilities

Gemma 4: Towards Increased Autonomy of Models

In a recent development, Gemma 4, a tool-calling agent model, has been endowed with new capabilities that allow it to operate more autonomously. Initially designed to interact with public APIs to retrieve various information, Gemma 4 now has the ability to explore its own environment and delegate complex tasks that it cannot execute itself.

The previous article on Machine Learning Mastery had already laid the groundwork by building an agent capable of interacting with APIs to obtain information about the weather, news, exchange rates, and time. However, this article only covered part of the extent of Gemma 4's capabilities. The real innovation lies in the agent's ability to reason about its own environment, inspect its own machine, and delegate logic that it cannot execute. This approach is much closer to what one might call a true agent.

The previous article covered half of the model's synthesis well but left out the most interesting part: an agent that reasons about its own environment, inspects its own machine, and delegates the logic it does not feel capable of executing. It is this capability that brings it closer to being a true agent.

New Tools for Better Interaction

Gemma 4 has been enhanced with two major tools: a local file system explorer in sandbox mode and a restricted Python interpreter. These additions allow the model to decide when to explore its environment and when to perform calculations.

Secure File Explorer

The list_directory_contents tool gives the model the ability to list files in a given directory. However, to prevent unauthorized access, this tool is confined to a secure base directory, thus preventing any attempts to traverse unauthorized paths.

SAFE_BASE_DIR = os.path.abspath(os.getcwd())

def list_directory_contents(path: str = ".") -> str:
    requested = os.path.abspath(os.path.join(SAFE_BASE_DIR, path))
    if not (requested == SAFE_BASE_DIR or requested.startswith(SAFE_BASE_DIR + os.sep)):
        return f"Error: Access denied. The path '{path}' resolves outside the allowed workspace ({SAFE_BASE_DIR})."

The JSON schema provided to the model is designed to be permissive in terms of parameters, with the default path pointing to the root directory of the workspace, as the initial useful questions often concern the current folder.

Restricted Python Interpreter

The execute_python_code tool allows the model to execute Python code securely. By limiting the available functions through a reduced builtins namespace, this tool minimizes risks while enabling the model to solve complex problems requiring precise calculations.

def execute_python_code(code: str) -> str:
    safe_builtins = {
        "abs": abs, "all": all, "any": any, "bool": bool, "dict": dict,
        "divmod": divmod, "enumerate": enumerate, "filter": filter, "float": float,
        "int": int, "len": len, "list": list, "map": map, "max": max, "min": min,
        "pow": pow, "print": print, "range": range, "repr": repr, "reversed": reversed,
        "round": round, "set": set, "sorted": sorted, "str": str, "sum": sum,
        "tuple": tuple, "zip": zip,
        import math, statistics
    }
    restricted_globals = {
        "__builtins__": safe_builtins,
        "statistics": statistics,
    }

A final word on security, as the script's docstring is clear on this matter: this is a learning sandbox, not a secure environment. A determined adversary can break a Python exec sandbox in several ways, most involving object introspection. For a single-user agent running on your own computer with your own prompts, the whitelist is sufficient. For anything else, you would want a true isolation layer—a subprocess with seccomp, a container, or RestrictedPython.

From Conversation to Agency

When the only tools you give a language model are read-only web APIs, you essentially have a chatbot, even if it potentially has access to better information. The model receives a prompt, decides which API to query, and assembles the JSON response into a paragraph. There is no real notion of environment, no state to inspect, no consequences to reason about; it is a scenario closer to retrieval-augmented generation than to true agency.

Agency, in the practical sense that practitioners give to the term, appears when the model begins to interact with the system on which it operates. This can mean reading from a local file system, executing code, modifying files, calling other processes, or any combination of these actions. As soon as a tool can do something other than return a clean string from a remote service, the model must start asking questions about itself: what files exist, what is the actual value of this number, what does this folder contain before I claim it contains anything.

The Gemma 4 family, and particularly the gemma4:e2b variant we used, is small enough to run locally on a laptop while being competent in structured output to reliably drive this type of loop. This combination is what makes the local-agent model interesting in the first place. The complete code for this tutorial can be found here.

Architectural Reuse

The orchestration loop from the previous article remains unchanged. We define Python functions, expose them via a JSON schema, pass the registry to Ollama with the user's prompt, intercept any tool_calls block in the response, execute the requested function locally, add the result as a tool role message, and re-query the model so it can synthesize a final response. The same helper call_ollama, the same TOOL_FUNCTIONS dictionary, and the same available_tools schema array from the previous article all appear.

What changes is the nature of the tools themselves. While the previous batch consisted of lightweight clients on remote APIs, those we will build now execute code on the machine. This shifts the design problem from "how can I analyze this response" to "how can I ensure that the model cannot, even accidentally, do something it should not be allowed to do."

Implications and Security

These new capabilities allow Gemma 4 to operate more autonomously and interact directly with the system on which it is executed. However, it is crucial to note that these tools, while powerful, require careful management to avoid any security risks. Developers must ensure that the environments in which these tools are used are secure and that access is controlled.