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.

The building blocks are small: a function calling schema, the executable code behind each described function, and a model able to pick between them. The hard part is the boundary. Trustworthy agents never hold raw access to the tools they invoke, so an agent that fetches stock prices or analyzes SQLite databases proposes the call while the infrastructure executes it, ideally through a read-only database role.

Defining the Tool Use Design Pattern for Autonomous Agents

How Function Calling Breaks the Static Training Ceiling

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 dynamic 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 Dynamic 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 Dynamic 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.

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. It names the function it wants, and the infrastructure executes the actual code inside a deterministic framework.

The constraint keeps external systems like databases behind callable interfaces, so the agent requests actions while validation logic and network scope stay outside its reach 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.

Implementation complexity rises because developers must write parsing logic to handle the intermediate tool call object before generating the final response. Any mismatch between the schema description and the actual code behavior causes silent failures at runtime, so versioning the schema alongside the codebase becomes non-negotiable. AI Agents News recommends treating schemas as critical infrastructure rather than optional metadata.

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.

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.

Dynamic 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.

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. 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.

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. Apply 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.

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.

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.

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 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.

Developers must treat every generated query as untrusted code, which means the mitigation belongs in the database permissions rather than in the prompt.

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. AI Agents News recommends this isolation as a baseline requirement for any production deployment.

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