Tool use patterns: how agents run external code

By late 2025, action-enabling tools shifted to represent the majority of use cases among the 177,000 AI agent tools tracked by the UK AI Safety Institute. The Tool Use Design Pattern serves as the critical architecture allowing Large Language Models to transcend static training data by executing external code. This mechanism transforms agents from passive text generators into active participants capable of manipulating real-world systems through set function calls.

You will learn how to define the specific building blocks required for function calling, ranging from simple calculators to complex third-party API integrations. Finally, we address the severe risks associated with autonomous code execution and how to implement trustworthy agents. The discussion covers necessary safeguards for preventing unauthorized actions when agents interact with databases or email services. By understanding these constraints, developers can build systems that reliably fetch stock prices or analyze SQLite databases without compromising security protocols.

Defining the Tool Use Design Pattern for Autonomous Agents

Defining the Tool Use Design Pattern and External Tool Interaction

Static training data creates a hard ceiling on what a model knows. The Tool Use Design Pattern breaks that ceiling by letting Large Language Models run external code. Instead of stopping at the edge of pre-trained knowledge, an agent using this pattern touches databases and APIs in real time. This architectural shift turns a passive text generator into an active participant. The core mechanism is function calling, which enables flexible information retrieval. An agent can now fetch current stock prices or query SQLite databases on demand rather than hallucinating based on outdated weights.

A tool schema dictates the rules of engagement. It defines the precise signature, parameters, and description required for the model to invoke functions correctly. Tools are simply code executed by an agent to perform actions, ranging from a basic calculator to complex third-party API calls. While a standard interface generates text, an agent equipped with tool use capabilities solves multi-step problems by observing action results. This design prioritizes expanded capability over the safety of a closed system, demanding robust error handling. Builders must focus on defining narrow, high-utility tools rather than exposing broad system access.

Executing the Thought, Action, Observation Loop for Flexible Information Retrieval

Thought, Action, and Observation form a repeating triad that drives agent behavior. This cycle iterates until the system declares a goal complete, enabling Flexible Information Retrieval that static training sets cannot match. During the Thought phase, the model plans its next step based on context. The Action phase involves invoking a specific tool, such as a calculator function or an external API for weather data. Finally, the Observation phase captures the tool's output, feeding it back into the model for further reasoning.

Passive architectures generate text solely from input patterns. This design ensures the model never holds raw access to tools. It operates within a controlled interface where callable functions bridge external systems like databases. This separation prevents unauthorized execution while allowing complex task completion through iterative refinement.

Tool schemas provide the detailed definitions necessary for the LLM to understand available tools and construct valid requests. Moving from conversational chat to active execution requires strong error handling to manage failed API calls without breaking the loop. Implementing this pattern transforms static models into adaptive systems capable of real-time problem solving.

Enforcing Deterministic Boundaries to Prevent Raw LLM Access to Tools

Direct tool access remains forbidden for the Large Language Model. The model must operate within a strict deterministic boundary to prevent uncontrolled execution. A critical security specification in this design is that the Large Language Model is never granted raw access to tools; instead, it operates within a deterministic framework where the infrastructure executes the actual code.

This architectural constraint ensures that external systems like databases remain secure behind callable interfaces rather than direct model interaction. By treating tools as bridged services, developers enforce a schema where the agent requests actions but never executes code directly. This separation is vital. Agents function through a controlled loop where the model proposes and the infrastructure executes callable functions. This design prevents the LLM from bypassing validation logic or accessing unauthorized network resources during Workflow Automation tasks.

Building effective tools for agents requires re-orienting development practices to accommodate non-deterministic outcomes. For builders, this means prioritizing infrastructure that isolates tool execution from the inference engine. The cost of failing to enforce these boundaries is potential data exposure or unintended state changes in connected systems. Mechanisms to handle failures in tool execution, validate parameters, and manage unexpected responses are necessary components of the Tool Use Design Pattern.

Mechanics of Function Calling and Schema Execution

Schema-Driven Function Selection and Argument Construction

Matching user intent against function descriptions inside a schema forces the model to pick the right tool name and arguments before any code runs. Guessing parameters fails here because the system demands an exact match to provided definitions. This strict contract turns a standard language model into an autonomous agent that solves multi-step problems without drifting off course. Required inputs and data types sit inside the schema to stop invalid execution before it starts.

Three specific components enable this workflow for developers:

1. An LLM model with native function calling support.
2. A JSON schema containing precise function signatures.
3. The executable code for each described function.

A request for the current time in San Francisco triggers a specific chain reaction rather than immediate text generation. The system returns a tool call object with a unique ID like `call_pOsKdUlqvdyttYB67MOj434b` plus the extracted `location` argument. Application logic then invokes the `get_current_time` function using the `2024-05-01-preview` API version.

Large Language Models never receive raw access to the tools they invoke. Implementation complexity rises because developers must write parsing logic to handle the intermediate tool call object before generating the final response. AI Agents News recommends validating all extracted arguments against the schema before execution to maintain system integrity.

Data Flow Between LLM Responses and External API Outputs

External API outputs arrive as structured messages so the LLM can formulate the final user response. This return path converts raw data into conversational context. Groq describes this tool use as the mechanism transforming static models into autonomous agents capable of solving multi-step problems. The workflow begins when the model returns a tool call object containing the function name and arguments. Application logic executes the code and captures the result. The system then appends a new message with the role tool and the content of the execution result. This history is sent back to the model for a second inference pass.

Raw access to external systems remains off-limits to the Large Language Model. Tools operate as callable functions invoked through a controlled interface, ensuring safety and determinism in execution. This architecture prevents the model from bypassing validation layers or accessing unauthorized resources.

The data flow follows a strict sequence:

1. The model outputs a function call rather than text.
2. The application executes the function and captures the return value.
3. The system injects the result as a tool response message.
4. The model processes the injected data to generate the final answer.

Flexible information retrieval happens within this cycle while keeping reasoning separate from action. Latency becomes the constraint since every tool invocation adds network round-trip time to the response generation. Designing timeouts handles slow external dependencies without stalling the agent. AI Agents News recommends implementing retry logic for transient failures in the tool execution layer.

Required Components for Implementing Function Calling Logic

Autonomous systems need an LLM model with native support for function calling capabilities. The system remains a static conversational interface rather than a flexible problem solver without this core support. Evidence for current tool usage trends includes an analysis of approximately 177,000 distinct AI agent tools, providing a large-scale dataset for understanding adoption patterns. This volume confirms that schema definition is the primary bottleneck in agent deployment.

A detailed schema containing function descriptions serves as the second mandatory component. This document acts as a strict contract, defining parameter types and validation rules to prevent incorrect execution. The Large Language Model is never given raw access to the tools; instead, it invokes callable functions through a controlled interface ensuring safety. Builders must provide the actual code implementation for each described function.

Schema presence alone fails to guarantee successful execution if the underlying code lacks error handling. Any mismatch between the schema description and the actual code behavior causes silent failures during runtime. Function execution logic must strictly mirror the schema constraints to avoid these issues. Versioning the schema alongside the codebase becomes non-negotiable for engineers. AI Agents News recommends treating schemas as critical infrastructure rather than optional metadata. Neglecting this alignment breaks the agent's ability to complete multi-step problems reliably.

Implementing Trustworthy Tool-Integrated Agents

Microsoft Agent Framework @tool Decorator Mechanics

The @tool decorator turns plain Python functions into serialized schemas that large language models invoke as actions. This mechanism removes the need for manual JSON definition by automatically extracting function signatures, docstrings, and parameter types into a format the model understands. Developers write logic using native Python syntax while the framework handles conversion to the required function calling protocol.

1. Import the @tool decorator from the Microsoft Agent Framework library.
2. Apply the decorator above a Python function to mark it for agent access.
3. Include a detailed docstring to describe the tool's purpose and arguments.
4. Pass the decorated function to the agent configuration for automatic registration.

Boilerplate code disappears while strict type safety remains intact during execution. Unlike passive architectures where the model only generates text, this setup creates an active loop where the LLM triggers external code through a controlled interface active tool-use architectures. The framework ensures the model never receives raw access to the underlying system, preserving security boundaries. Complex parameter validation presents a constraint; automatic serialization assumes standard types and may require manual schema overrides for nested structures. Operators must verify that function docstrings are precise because vague descriptions directly degrade the model's ability to select the correct tool. This mechanic shifts the development burden from schema maintenance to code quality and documentation clarity. AI Agents News recommends testing decorated functions individually before integrating them into multi-step workflows to prevent cascading execution errors.

Building a TimeAgent with AzureAIProjectAgentProvider

Constructing a TimeAgent requires initializing the AzureAIProjectAgentProvider to manage communication between the language model and external execution environments. This provider enables access to pre-built utilities like File Search and Code Interpreter without manual schema serialization. Developers define the agent with specific instructions, such as "Use available tools to answer questions," allowing the system to autonomously select appropriate functions. The framework automatically converts decorated Python functions into schemas that the model uses for function calling.

1. Import the @tool decorator to Python functions for agent exposure.
2. Initialize the AIProjectClient with enterprise security configurations.
3. Define a ToolSet containing both FunctionTool instances and CodeInterpreterTool resources.
4. Deploy the agent using a model like `gpt-4o-mini` to handle multi-turn reasoning tasks.

Development focus shifts from parsing logic to defining precise tool behaviors. Data from late 2025 indicates a majority shift toward downloading action-enabling tools that execute code rather than retrieve static information. Server-side automatic tool calling introduces latency during complex multi-step orchestration. Operators must balance the convenience of managed services against the need for low-latency, custom execution paths in high-frequency trading or real-time control systems. AI Agents News recommends validating tool schemas rigorously to prevent parameter injection attacks.

Validating Function Schemas and Execution Logic

Schemas must define strict parameter types to prevent invalid function execution. Developers implement a verification workflow where the system rejects requests missing required fields before the model attempts invocation. This approach stops malformed data from reaching the execution layer, maintaining system stability during autonomous agent operations.

1. Define function schemas with explicit data types for every argument.
2. Validate user inputs against the schema prior to calling the tool.
3. Catch execution errors and return structured feedback to the model.
4. Log failures to refine future prompt engineering strategies.

A key architectural constraint is that the large language model never holds raw access to underlying systems. Tools operate as callable functions through a controlled interface, ensuring determinism. Increased latency is the cost; every validation step adds milliseconds to the response time. Builders must balance strictness with performance since overly rigid schemas can cause valid user intents to fail unnecessarily. AI Agents News recommends testing edge cases where optional parameters are omitted to verify graceful degradation.

Operational Risks and Best Practices for Agent Security

SQL Injection Risks in Dynamically Generated Database Queries

Malicious input manipulation thrives when SQL queries are generated dynamically, creating openings for attackers to drop tables or tamper with data records. A primary concern with dynamically generated SQL by LLMs is security, specifically the potential for injection attacks when agents interact with external systems. Without strict boundaries, an agent might construct a query that bypasses intended logic. The core Thought → Action → Observation loop must never grant the model raw access to database execution engines.

• Hidden costs include unmonitored write operations that corrupt production state.
• Malformed inputs can trigger cascading failures across dependent microservices.
• Lack of parameterization leads to full database compromise rather than simple data leakage.

For services like PostgreSQL or Azure SQL, the application should strictly assume a read-only SELECT role. This configuration ensures that even if an injection occurs, the damage remains limited to data exfiltration rather than destruction. However, enforcing read-only access restricts legitimate workflow automation where updates are required. The constraint is operational friction: developers must implement separate, highly vetted pathways for any write operations. Most enterprise scenarios extract data into a dedicated warehouse with a user-friendly schema to mitigate these risks while maintaining performance. Developers must treat every generated query as untrusted code.

Implementing Read-Only Database Roles for Agent Safety

Assigning PostgreSQL connections a SELECT-only role prevents the agent from executing destructive `DROP` or `UPDATE` commands during unexpected Action phases. Traditional systems rely entirely on static knowledge, whereas autonomous agents dynamically interact with external databases, creating unique injection vectors if permissions are not strictly bounded. In enterprise scenarios, data is typically extracted into a dedicated read-only warehouse to isolate the production environment from agent errors.

A hard limitation is that read-only roles restrict the agent to observation, requiring a separate, highly audited pathway for any necessary state changes. The Thought, Action, Observation loop functions safely only when the Observation phase cannot inadvertently modify the source of truth. Namespace strategy implementations further reduce risk by ensuring tools are namespaced by service, preventing cross-contamination between distinct database contexts. Without this separation, a single hallucinated function call could corrupt entire tables. The cost of this architecture is increased complexity in managing dual-database workflows for read versus write operations. Developers must accept that trustworthy agents require an architectural shift where the LLM is never given raw access to underlying execution engines. This constraint forces a design where data extraction happens in a sandboxed replica, preserving the integrity of the primary system. AI Agents News recommends this isolation as a baseline requirement for any production deployment.

Validation Checklist for Secure Agent Tool Boundaries

Validate that the Large Language Model lacks raw access to execution environments before any deployment proceeds. Unlike static conversational interfaces, autonomous agents require strict schema enforcement to prevent unauthorized state changes. Developers must confirm the following boundaries:

• The agent operates within a deterministic Thought, Action, Observation loop without direct shell access.
• Database roles are restricted to SELECT only, preventing destructive writes or schema modifications.
• Tool parameters undergo rigorous type validation prior to invocation.
• External API calls route through a controlled gateway rather than open network paths.

Shifting to non-deterministic development introduces complexity where output variability can bypass logical guards. A hard limitation is that strict schema validation may reject valid but unusually formatted user requests, requiring careful tuning of error handling logic. AI Agents News recommends isolating the agent in a secure container to mitigate risks associated with unexpected tool behaviors.

References

• AI Agent Tools : Tutorial & Examples: AI agent
• How are AI Agents used? Evidence from 177,000 AI
• Multi-Agent Orchestration: How to Coordinate AI Agents at: A