Function Calling and the Agent Loop

Function calling (also called tool calling) is the technical mechanism through which an LLM-based agent invokes external tools. Understanding this mechanism is essential for judging how an agent reaches its results, where it can fail, and how to make it reliable.

What Is Function Calling?

Function calling enables an LLM to invoke external functions, APIs, or knowledge bases when needed, rather than relying solely on its training knowledge. The model decides independently when such a call is necessary and generates a structured request with the required parameters.

A simple example: the question “What is the weather in Paris?” cannot be answered accurately by an LLM alone. With function calling, the model recognises the need, calls a weather API with the parameter Paris, and formulates a response based on the returned data. Without tools, the model is confined to outdated training knowledge; function calling removes exactly this constraint.

The Flow: Step by Step

1. User query
   "What is the current weather in Paris?"

2. Context assembly
   System message + tool definitions + user message

3. Tool decision
   LLM: "I need get_current_weather(location='Paris')"

4. Tool execution
   Code calls the weather API

5. Observation
   API returns: { temp: 18 C, condition: 'Cloudy' }

6. Response generation
   LLM formulates an answer based on the observation

A key point: at every step the model receives the complete prior context, all messages, all tool calls, and all observations. This context continuity is the foundation for intelligent follow-on decisions.

Tool Definitions: the Most Critical Factor

How well an agent uses tools depends less on technical implementation than on the quality of the tool definitions. They are the only source of information from which the model infers which tool to use and when.

A complete tool definition contains:

Name: A clear identifier for the function
Description: An explanation of what the tool does and when it should be used
Parameters: Input values with types, descriptions, and constraints

The description field is particularly important. When multiple tools are available, the precision of each description determines whether the model selects the right one.

{
  "name": "get_current_weather",
  "description": "Returns current weather for a location. Use when the user asks about current weather conditions in a specific place.",
  "parameters": {
    "location": {
      "type": "string",
      "description": "City and country, e.g. 'Paris, FR'"
    },
    "unit": {
      "type": "string",
      "enum": ["celsius", "fahrenheit"]
    }
  }
}

Note

Tool definitions consume tokens on every LLM call and therefore affect cost and latency. Concise but unambiguous descriptions matter in practice.

The Agent Loop

The agent loop is the fundamental execution principle. It consists of repeating cycles:

Action

The agent decides to call a tool.

Environment response

The external system (an API, a database, or another agent) returns a result.

Observation

The result is processed as part of the context.

Decision

The agent checks: is the task complete? If not, another action step follows.

A concrete example of a simple research request:

User:   "Latest news from OpenAI"

Agent:  I need current information.
        --> web_search("OpenAI latest news 2025")

Observation: [search results with recent articles...]

Agent:  I have enough information to answer.
        --> Output: "Here are the latest updates from OpenAI..."

For more complex tasks, several tool calls may be needed before a question can be answered. Each call extends the context and gives the agent more basis for subsequent decisions.

Common Failure Modes and Debugging

When building agent systems, characteristic errors arise that can be analysed systematically:

Error type	Symptom	Cause
Wrong tool selected	Agent uses the wrong tool	Unclear or too-similar descriptions
Bad parameters	Tool call fails	Incomplete parameter definition
Misinterpreted result	Response ignores tool output	Unclear output format of the function
Skipped steps	Agent responds without full research	Too vague an execution instruction in the system prompt

Many agent frameworks offer the option to log intermediate steps: which tools were called, with what arguments, and what came back. This transparency is indispensable for understanding and improving an agent.

Recommendations for Practice

Sharpen descriptions: Instead of “Search the web”, use “Search the web for current information. Use this when the user asks about events that may post-date the model’s training cutoff.”

Make tool selection explicit in the system prompt: Additional guidance in the system prompt about which tool to prefer for which purpose improves decision quality, especially with multi-tool setups.

Anticipate failure cases: Tools should return informative error messages that allow the agent to try an alternative approach rather than failing silently.

Constrain parameter values: Use enum fields where possible to avoid hallucinated parameter values.

Last updated on 22. September 2026

Architecture and Components Deep Agents