Tool Use in Agentic AI

Steroids for LLMs.

From Chatbots to Agents

A chatbot answers questions.

An agent can:

• Observe
• Reason
• Retrieve
• Decide
• Act

Tool use is the bridge between language understanding and real-world execution.

Without tools:

$$Agent \approx Chatbot$$

With tools:

$$Agent \approx Reasoning + Actions$$

And that is why tool use has become one of the foundational building blocks of modern Agentic AI systems.

How LLMs Interact with the Real World

Large Language Models are impressive.

They can write code, summarize documents, explain quantum mechanics, and generate human-like conversations.

But despite these capabilities, a standalone LLM has a fundamental limitation:

It cannot interact with the outside world.

An LLM does not know:

• Online information
• Database Items
• Calendar events
• Email status
• File contents

These limitations arise because the model can only reason over:

• Training data
• User prompts
• Provided context

Without tools, an LLM operates as:

$$Response = LLM(Prompt)$$

This is where Tool Use transforms an LLM from a chatbot into an agent.

With tools:

$$Response = LLM(Prompt + ExternalData)$$

The difference is profound.

The model no longer relies solely on its training data.

Instead, it becomes capable of:

• Retrieving live information
• Executing actions
• Interacting with enterprise systems
• Orchestrating workflows

---

What Is Tool Use?

Tool use is the ability of an LLM to request the execution of external functions.

Instead of answering directly, the model can decide:

"I need additional information before I can answer."

The Tool Calling Architecture

Consider a user asking:

What's the weather in Munich today?

The model cannot know the current weather.

However, we can provide a weather function.

The workflow becomes:

1. Tool Definition

LLM is given a set of tool definitions (as JSON schema in the system prompt or API parameters)

The block specifies the tool name and a structured input object.

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get current weather",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string"
                    }
                },
                "required": ["city"]
            }
        }
    }
]

The schema describes:

• tool name
• purpose
• parameters
• expected inputs

This information is provided to the model.

response = client.chat.completions.create(
    model="gpt-4.1",
    messages=messages,
    tools=tools
)

2. Tool Use

LLM can emit a tool_use content block instead of plain text.

The LLM does not execute functions.

The LLM only requests function execution.

For example, the model may return:

{
  "tool_calls": [
    {
      "function": {
        "name": "get_weather",
        "arguments": {
          "city": "Munich"
        }
      }
    }
  ]
}

This means:

Please call get_weather("Munich")

3. Tool Result

The calling application intercepts this:

tool_call = response.choices[0].message.tool_calls[0]

city = json.loads(
    tool_call.function.arguments
)["city"]

result = get_weather(city)

Then routes it to the real implementation to executes the function.

def get_weather(city: str):

    return {
        "city": city,
        "temperature": 21,
        "condition": "Sunny"
    }

The result is then returns as tool_result block into the next message.to the model.

messages.append(
    {
        "role": "tool",
        "content": json.dumps(result)
    }
)

4. Update Response

The LLM then continues generating with the result in context.

Finally:

final_response = client.chat.completions.create(
    model="gpt-4.1",
    messages=messages
)

Flow Diagram

Developer provides function, LLM decides to use it, LLM outputs request, developer’s system executes the function, result fed back to LLM

sequenceDiagram
    participant User
    participant LLM
    participant App
    participant WeatherAPI

    User->>LLM: Weather in Munich?

    LLM->>App: Call get_weather(Munich)

    App->>WeatherAPI: Request weather

    WeatherAPI-->>App: 21°C Sunny

    App-->>LLM: Tool Result

    LLM-->>User: It is 21°C and sunny.

The model now has access to live weather data.

---

Multi-Tool Agents

Real agents rarely use a single tool.

Consider a calendar assistant.

Available tools:

check_calendar()
create_meeting()
cancel_meeting()

User request:

Schedule a meeting with Alice on Thursday.

Execution plan:

sequenceDiagram
    participant User
    participant LLM
    participant CalendarAPI

    User->>LLM: Schedule meeting with Alice on Thursday.

    LLM->>CalendarAPI: check_calendar(Thursday)

    CalendarAPI-->>LLM: Available slots

    LLM->>CalendarAPI: create_meeting(Alice, Thursday 3pm)

    CalendarAPI-->>LLM: Meeting created

    LLM-->>User: Meeting scheduled for Thursday at 3pm.

The LLM decides:

1. Which tool to call
2. In what order
3. Which parameters to provide

This is where simple tool use evolves into an agentic workflow.

---

Tool Chaining

Advanced agents often perform multiple tool calls.

Example:

Find a free slot tomorrow and schedule a meeting with Alice.

The agent might execute:

sequenceDiagram
    participant User
    participant LLM
    participant CalendarAPI

    User->>LLM: Schedule meeting with Alice tomorrow.

    LLM->>CalendarAPI: check_calendar(tomorrow)

    CalendarAPI-->>LLM: Available slots

    LLM->>CalendarAPI: create_meeting(Alice, tomorrow 2pm)

    CalendarAPI-->>LLM: Meeting created

    LLM-->>User: Meeting scheduled for tomorrow at 2pm.

This creates a chain of actions.

Formally:

$$Task = {t_1, t_2, t_3, ..., t_n}$$

where each tool output becomes the input to the next step.

---

Security Considerations

Tool use introduces risk.

Consider:

Delete all customer accounts.

If a destructive tool is exposed without controls, the consequences can be severe.

A common pattern is:

graph TD

    A[Tool Request]

    A --> B{Safe?}

    B -->|Yes| C[Execute]

    B -->|No| D[Human Approval]

Production systems often require:

• approval workflows
• permission boundaries
• audit logging
• rate limiting

before allowing sensitive actions.

---

Tool Use vs Retrieval-Augmented Generation

Tool use extends beyond information retrieval. It enables action.

These concepts are often confused.

RAG:

Retrieve Information

Tool Use:

Retrieve Information
+
Take Actions

Difference

Capability	RAG	Tool Use
Search documents	✓	✓
Query databases	✓	✓
Create meetings	✗	✓
Send emails	✗	✓
Update records	✗	✓
Execute workflows	✗	✓

---

Enterprise Tool Use

Most production agents operate against internal systems.

Common tools include:

Tool	Purpose
CRM API	Customer lookup
Inventory API	Product availability
Billing API	Payment status
Search Engine	External information
Vector Database	Semantic retrieval
Calendar API	Scheduling
Ticketing System	Incident management
GitHub API	Repository operations

This is why tool use is foundational to enterprise AI.