---
title: Function Calling — The Breakthrough That Enabled Agents
description: "Before function calling, getting an LLM to invoke an API meant regex hacks and prayer. Structured tool invocation changed everything."
canonical: https://nowah.xyz/blog/function-calling-breakthrough-enabled-agents
lastModified: "2026-08-07T08:06:17.569Z"
---

# Function Calling — The Breakthrough That Enabled Agents

Before function calling, getting an LLM to invoke an API meant regex hacks and prayer. Structured tool invocation changed everything.

There is a single technical capability that separates the "AI assistants" of 2022 from the AI agents of 2025. It is not a bigger model. It is not more training data. It is not a better algorithm.

It is function calling: the ability of a language model to invoke external tools with structured parameters as a native output type.

This sounds mundane. It is arguably the most consequential capability addition in the LLM era. Without it, LLMs are text generators. With it, they are action systems. The entire category of AI agents, including AI travel booking, became viable because of this one breakthrough.

## The before times

![Illustration for this section](https://pics.nowah.xyz/website-media/ai-research-032-img-1.webp)

In 2022, if you wanted an LLM to call an API, the process looked like this:

1. Describe the desired JSON output format in the model instructions
2. Ask the model to generate a response that includes a JSON blob
3. Parse the model's text output with regex to extract the JSON
4. Hope the JSON is valid
5. Hope the field names match your schema
6. Hope the values are reasonable
7. Call the API with the extracted parameters
8. If anything failed, retry from step 2

The success rate was roughly 60%. Four out of ten attempts produced invalid JSON, missing fields, hallucinated parameter names, wrong value types, or responses that ignored the formatting instructions entirely.

Building on this foundation was like building on sand. You could make it work for demos and prototypes. You could not make it work for production systems that handle real money. A 40% failure rate on [structured output](/blog/structured-output-making-llms-speak-json) means 40% of flight searches use wrong parameters. In a booking system, wrong parameters mean wrong flights, wrong dates, wrong prices. Unacceptable.

Some engineers built elaborate parsing layers. Extract text between curly braces. Try JSON.parse. If it fails, try to fix common errors (missing quotes, trailing commas, unescaped characters). If that fails, re-prompt the model with the [error message](/blog/anatomy-of-perfect-error-message) and ask it to fix its output. The resulting systems were fragile Rube Goldberg machines that required constant maintenance.

## The paradigm shift

When major model providers introduced native function calling in 2023, the paradigm changed.

Instead of asking the model to generate text that looks like a function call, you define tools as structured schemas. The model is trained to produce function calls as a dedicated output type, separate from text generation. The output is guaranteed to be valid against the schema (correct field names, correct types, required fields present).

The accuracy jumped from roughly 60% to over 95% for well-defined schemas. That 35-percentage-point improvement was the difference between "interesting research" and "production-ready system."

Here is what changed technically:

**Schema definition.** You provide the model with a structured definition of each tool: name, description, parameters (with types, descriptions, and constraints). The model uses this schema to guide its output.

**Native output type.** The model can produce two types of output: text (for conversation) and tool calls (for action). Tool calls are structured objects, not text that happens to contain JSON. The distinction eliminates parsing entirely.

**Type safety.** The schema enforces types. If a parameter is defined as a date string in ISO 8601 format, the model produces a date string in ISO 8601 format. Not "April 3rd" or "4/3/26" but "2026-04-03." This eliminates an entire category of parsing and normalization code.

**Required vs optional.** The schema specifies which parameters are required. The model reliably includes required parameters and omits optional ones that the user did not specify. This is something regex parsing could never reliably enforce.

## Parallel and sequential patterns

![Supporting diagram](https://pics.nowah.xyz/website-media/ai-research-032-img-2.webp)

Function calling opened two execution patterns that are critical for agents.

**Parallel calls** invoke multiple tools simultaneously when there are no dependencies between them. "Find me flights and hotels in Tokyo" triggers a flight search and a hotel search at the same time. The results return independently and the agent synthesizes them.

This matters for latency. If a flight search takes 3 seconds and a hotel search takes 3 seconds, sequential execution takes 6 seconds. Parallel execution takes 3 seconds. For a conversational product where perceived speed matters, cutting [response time](/blog/ten-second-rule-ai-response-time) in half is significant.

**Sequential chains** invoke tools in order when later calls depend on earlier results. "Find me flights, then find a hotel near the airport I'm arriving at." The hotel search depends on knowing the arrival airport, which comes from the flight search results.

The agent decides which pattern to use based on the dependencies between tool calls. Independent tasks run in parallel. Dependent tasks chain sequentially. The model handles this routing as part of its reasoning process.

The production average is 3-7 tool calls per complex query. A multi-step booking flow might involve 7+ calls: [search flights](/blog/launching-[tool-calling](/blog/tool-calling-at-scale-ai-travel-search)-layer-ai-agent-search-flights), rank results, present options, confirm selection, collect passenger data, process payment, confirm booking. The reliability of each call compounds. At 95% per call, a 7-call chain succeeds 70% of the time. At 99% per call, it succeeds 93% of the time. The push from 95% to 99% accuracy is where most of our engineering effort goes.

## Reliability in production

Ninety-five percent accuracy is a starting point, not a destination. In production, we focus on several dimensions of reliability.

**Schema design quality.** Better schemas produce fewer errors. Clear parameter descriptions, tight type constraints, and unambiguous tool names all improve accuracy. A well-designed schema can push accuracy above 98% for that specific tool.

**Error detection.** When a function call fails (invalid parameters, API error, unexpected response), the agent needs to detect the failure and recover. This means parsing error responses, understanding what went wrong, and either retrying with corrected parameters or selecting a fallback approach.

**Self-correction.** The most advanced pattern is the agent recognizing that its own tool call produced unexpected results and adjusting. The flight search returned no results because the agent passed the wrong airport code. The agent examines the empty result, hypothesizes that the airport code might be wrong, and retries with a corrected code.

**Cost management.** The cost of inference dropped roughly 10x per year since 2023, making multi-call patterns economically viable. But cost still scales with the number of tool calls. We optimize for minimum necessary calls rather than exhaustive exploration.

## What function calling unlocked

The downstream consequences of reliable function calling are enormous.

**AI agents became possible.** An agent is an LLM that acts in the world, not just talks about it. Function calling is the mechanism of action. Without it, there are no agents. Just chatbots.

**AI travel booking became possible.** You cannot book a flight with text generation alone. You need to search live inventory, process payments, and confirm reservations. Each of these requires structured interaction with external systems. Function calling enables all of it.

**Real-time data grounding became possible.** LLMs trained on stale data should not state current prices. Function calling lets them query live APIs instead of relying on training data. This eliminates hallucination for factual queries.

**Complex workflows became possible.** Multi-step processes (search -> rank -> present -> confirm -> book -> deliver) require orchestrating multiple tool calls in sequence. Function calling makes each step reliable enough to chain them.

## The next frontier

Function calling is still evolving. Several developments are on the horizon.

**Dynamic tool generation.** Instead of defining all tools upfront, the agent generates [tool schemas](/blog/tool-schemas-llms-actually-understand) on the fly based on the task at hand. This enables handling novel tasks without pre-defined tools.

**Tool learning.** Agents that learn from failed tool calls and improve their schema usage over time. The agent remembers that a certain parameter format works better and adjusts future calls.

**Self-describing tools.** APIs that include their own schemas in a format LLMs can read directly, eliminating the need for manual schema definition.

Function calling is the foundation that made AI agents real. It took LLMs from "interesting text generators" to "systems that do things." For AI travel booking, it is the capability that turned "here are some nice flights" into "your flight is booked, here is your confirmation." The best travel app could not exist without it.

---

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).