Tool Use
≈ Adapter Pattern / Proxy Pattern / Dependency Injection
> Agentic Definition
Tool Use (or Function Calling) extends the capabilities of an LLM by allowing it to interact with the external world (APIs, databases, calculators, software environments) to perform actions or retrieve data that is not present in its parametric memory. This transforms the LLM from a text generator into a system controller.
> Description
Extends the capabilities of an LLM by allowing it to interact with the external world (APIs, databases, calculators, software environments) to perform actions or retrieve data not present in its parametric memory. Transforms the LLM from a text generator into a system controller.
Before: Hardcoded Integration
1def get_weather(city):2 # Developer decides this is always called here3 data = requests.get(f"api.weather.com/{city}")4 return parse(data)56def main():7 print(get_weather("Tokyo"))After: Agentic Tool Use
1# Tool Definition (The "Adapter")2weather_tool = Tool(3 name="get_weather",4 description="Get current weather for a city. Input should be a city name.",5 func=call_weather_api6)78# The Agent decides IF/WHEN to call it9agent = initialize_agent(tools=[weather_tool], llm=llm)1011# The user prompt triggers the tool usage implicitly12result = agent.run("What should I wear in Tokyo today?")13# Internal Logic:14# 1. Thought: "I need to know the weather in Tokyo."15# 2. Action: Call tool 'get_weather' with arg 'Tokyo'16# 3. Observation: "It is 15C and raining."17# 4. Final Answer: "Wear a raincoat."≈ Similarity
Just as the Adapter pattern wraps an incompatible interface (like a 3rd party API) to make it usable by a client class, Agentic Tool Use wraps an external API (like a weather service or SQL database) into a schema (JSON) that the LLM can "understand" and "call."
≠ Divergence
In SWE, the developer writes the code to call the API explicitly (service.call()). In Agentic Design, the developer defines the interface (the tool definition), and the Agent decides when and how to call it based on the conversation context. This is Inversion of Control at the logic level — the runtime decides the execution path, not the programmer.
> Production Considerations
- [01]Read-only tools (GET requests) are generally safe. Write-enabled tools (POST/DELETE, "Delete User", "Transfer Funds") require strict Guardrails (Pattern 18) and Human-in-the-Loop (Pattern 13) validation.
- [02]If the tool API changes, the agent breaks. Robust error handling (Pattern 12) is needed to inform the agent that the tool failed so it can try an alternative strategy rather than hallucinating a result.
> Key Takeaway
Unlearn: "I write the logic that calls the function." Adapt: "I write the function description so the Agent knows how to use it." You are writing API documentation for a machine reader. The quality of your tool description determines the reliability of the system.
Mission: Build a Data-Grounded Research Agent
Create an agent that can answer questions using real data by calling external tools (APIs, databases) instead of relying on its training data alone.
> Drag blocks to the canvas
Query Planner
Decides which tools to call based on the question
API Adapter
Translates LLM requests into structured API calls
Database Adapter
Translates LLM requests into SQL queries
Synthesis Agent
Combines tool outputs into a coherent answer
Access Guardrail
Validates tool calls are within allowed scope
Task Splitter
Splits input into parallel subtasks
Drop blocks here to build your agent pipeline
Arrange them in the correct order
Frequently Asked Questions
When should I use the Tool Use pattern?
Tool Use (or Function Calling) extends the capabilities of an LLM by allowing it to interact with the external world (APIs, databases, calculators, software environments) to perform actions or retrieve data that is not present in its parametric memory. This transforms the LLM from a text generator into a system controller.
How does Tool Use relate to Adapter Pattern / Proxy Pattern / Dependency Injection?
Just as the Adapter pattern wraps an incompatible interface (like a 3rd party API) to make it usable by a client class, Agentic Tool Use wraps an external API (like a weather service or SQL database) into a schema (JSON) that the LLM can "understand" and "call." However, there is a key divergence: In SWE, the developer writes the code to call the API explicitly (service.call()). In Agentic Design, the developer defines the interface (the tool definition), and the Agent decides when and how to call it based on the conversation context. This is Inversion of Control at the logic level — the runtime decides the execution path, not the programmer.
What are the production trade-offs of Tool Use?
Read-only tools (GET requests) are generally safe. Write-enabled tools (POST/DELETE, "Delete User", "Transfer Funds") require strict Guardrails (Pattern 18) and Human-in-the-Loop (Pattern 13) validation. If the tool API changes, the agent breaks. Robust error handling (Pattern 12) is needed to inform the agent that the tool failed so it can try an alternative strategy rather than hallucinating a result.