ReAct, Function Calling, and Tool Use: How LLMs Learned to Do Things

LLMs Learned to Use Tools. That Changed Everything.

Language models are remarkable at reasoning but terrible at doing. Ask GPT-4 to calculate 7,392 times 8,451 and it might get the wrong answer. Not because it cannot reason about multiplication, but because it generates tokens, not computations. It predicts what the answer probably looks like based on patterns in its training data. For simple math, this works surprisingly often. For anything complex, it falls apart.

Ask it to check today's weather and it cannot. It has no internet access. Ask it to query your database and it has no idea your database exists. The model is trapped inside its own weights, limited to what it memorized during training and what you put in the prompt.

The breakthrough came from a simple but profound realization: what if the model could decide to call external tools instead of generating the answer directly? Instead of computing 7,392 times 8,451 by predicting likely-looking digits, it writes calculator(7392, 8451), a runtime executes the actual calculation, and the correct result gets fed back into the model. The model handles the reasoning. Tools handle the doing.

ReAct: Reasoning + Acting

The ReAct paper (Yao et al., October 2022) formalized this pattern into something elegant. Previous approaches either had models reason without acting (chain-of-thought prompting) or act without reasoning (simple tool calling). ReAct interleaved both. A ReAct agent alternates between three modes:

• Thought: the model reasons about the current situation and decides what to do next. This is visible reasoning, not just token generation.
• Action: the model calls a tool with specific arguments. This could be a search engine, calculator, API call, database query, or any other external function.
• Observation: the tool returns a result, which the model incorporates into its next thought. The observation grounds the reasoning in real data.

This loop continues until the model has enough information to produce a final answer. Here is a concrete example. A user asks: 'What was the GDP of the country where the 2024 Olympics were held?'

A ReAct agent would process this step by step. First, it thinks: 'I need to find where the 2024 Olympics were held.' Then it acts: search('2024 Olympics location'). It observes the result: 'Paris, France.' Then it thinks again: 'Now I need France's GDP.' It acts: search('France GDP 2024'). It observes: '$3.13 trillion.' Finally, it thinks: 'I have enough information to answer,' and produces: 'The 2024 Olympics were held in France, which had a GDP of approximately $3.13 trillion.'

The key insight from the paper is that reasoning and acting are synergistic. The reasoning step helps the model plan better tool calls (instead of blindly searching). The tool results ground the reasoning in verified facts (instead of hallucinating). Models using ReAct consistently outperformed both pure reasoning (chain-of-thought without tools) and pure acting (tools without reasoning).

Why ReAct Mattered So Much

Before ReAct, LLMs had a fundamental limitation: they could only work with information in their training data or the prompt. If you needed current information, precise calculations, or data from your own systems, the model was useless. ReAct broke that wall. An LLM with a calculator never gets arithmetic wrong. An LLM with a search engine never hallucinates dates. An LLM with database access can answer questions about YOUR data, not just general knowledge.

More importantly, ReAct made LLMs composable. You could add new capabilities just by adding new tools. Need the agent to send emails? Add an email tool. Need it to create Jira tickets? Add a Jira tool. The model figures out when and how to use each tool based on the user's request. This composability is what turned LLMs from text generators into general-purpose AI assistants.

Function Calling: Making It Production-Ready

ReAct was a research framework. It worked by prompting the model to output 'Action: tool_name(args)' in plain text, then parsing that text to extract the tool call. This was fragile. Models would format the action incorrectly, forget parentheses, or mix up argument order. Parsing free-text tool calls was a constant source of bugs.

Function calling (introduced by OpenAI in June 2023, quickly adopted by Anthropic, Google, and others) solved this problem at the API level. Instead of hoping the model generates tool calls in the right text format, you define available functions with typed JSON schemas:

{
  "name": "get_weather",
  "description": "Get current weather for a city",
  "parameters": {
    "type": "object",
    "properties": {
      "location": {"type": "string", "description": "City name"},
      "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
    },
    "required": ["location"]
  }
}

The model outputs structured JSON specifying which function to call and with what arguments. Your application parses the JSON, executes the function, and returns the result. No more brittle text parsing. No more formatting errors. The structured approach integrates cleanly with existing APIs and type systems.

Function calling turned LLMs from text generators into orchestrators. A single model can now coordinate between a database, a search engine, a calculator, an email API, and a calendar. It decides which tools to use, in what order, and how to combine the results. This is the foundation of every production AI agent.

Parallel and Sequential Tool Calls

Modern function calling supports parallel tool calls. If the user asks 'What is the weather in Tokyo and New York?', the model can emit two function calls simultaneously rather than calling one, waiting for the result, then calling the other. This significantly reduces latency for multi-tool queries.

Sequential tool calls handle dependent operations. 'Book the cheapest flight to Paris and then find hotels near the airport' requires getting the flight details first, extracting the arrival airport, then searching for nearby hotels. The model naturally handles this dependency chain through multiple rounds of function calling.

Function calling changed LLMs from 'things that write' to 'things that do.' The model reasons about what needs to happen, and tools make it happen. This shift is as significant as the transition from static web pages to interactive web applications.

Practical Challenges in Tool Use

Building reliable tool-using agents is harder than it looks. Several challenges consistently trip up teams in production:

• Tool definitions must be precise. Vague descriptions confuse the model about when to use each tool. 'Search for information' is too broad. 'Search the product catalog by name, category, or SKU' is specific enough for the model to know when this tool is appropriate.
• Error handling must be robust. Tools fail. APIs time out. Databases return empty results. The agent needs to handle these gracefully, perhaps retrying with different parameters or falling back to a different approach.
• Security boundaries are critical. An agent with database access could potentially execute destructive queries. An agent with email access could send messages on behalf of users. Every tool needs appropriate permission checks and action limits.
• Cost management matters. Each tool call adds latency and may incur API costs. An agent that makes 15 search calls to answer a simple question is wasting resources. Setting maximum tool call limits prevents runaway behavior.

What This Means for GenAI Engineers

Tool use is central to production AI systems. In the GenAI Pipeline Lab, Router and tool-calling components in Act 3 let you design systems where the LLM decides which pipeline path to take based on the query. A customer support agent might route product questions to a RAG pipeline, billing questions to a database query tool, and complaints to a human escalation workflow.

The design pattern to remember: narrow tools with clear descriptions outperform broad tools with vague descriptions. Give the model 5 focused tools rather than 1 tool that does everything. The model can reason about which focused tool to use. It cannot reason about the 50 sub-options of a mega-tool.

Try It in the Lab

Act 3 introduces agent patterns. When you add Router components and tool-calling nodes, you are building ReAct-style systems. Notice how the architecture score rewards proper tool integration and penalizes unbounded tool access. The scoring reflects the real-world principle: more tools without guardrails creates more risk.

Further Reading

• Yao et al. (2022): 'ReAct: Synergizing Reasoning and Acting in Language Models'
• OpenAI Function Calling documentation
• Anthropic Tool Use documentation
• Schick et al. (2023): 'Toolformer: Language Models Can Teach Themselves to Use Tools'
• Qin et al. (2023): 'Tool Learning with Foundation Models' (comprehensive survey)