What is LLM Function Calling and How Does it Work? (2026)

LLM function calling has become one of the main ways developers connect large language models with the systems that actually hold data and perform actions.

Instead of relying only on what an LLM already knows, function calling lets an application give the model controlled access to external tools, APIs, databases, and business systems. That can mean checking an order, retrieving account details, updating a record, or triggering another approved action.

This guide is for developers, technical product teams, and anyone evaluating how LLMs can work with external systems in real applications. It explains what LLM function calling is, how it works, how it compares with tool calling, structured output, and the Model Context Protocol, and where it fits into AI agents.

You will also see practical examples, common use cases, limitations, security considerations, and best practices for using function calling in production.

TL;DR

LLM function calling lets a model request external functions, APIs, or tools when it needs current data or wants to trigger an action.
The LLM usually does not execute the function itself. It selects the function, generates the required arguments, and lets the surrounding application handle execution.
Function calling is a type of tool calling, while structured output is mainly about controlling the format of the model’s response.
MCP complements function calling by giving AI applications a standard way to discover and access tools exposed by external systems.
AI agents can use multiple function calls to complete complex tasks, evaluate results, and decide what action to take next.
Function calling still has limitations, including incorrect tool selection, bad arguments, failed APIs, excessive permissions, and prompt injection risks.
Reliable production use depends on clear function definitions, strict schemas, validation, limited permissions, useful error handling, logging, and approval controls for sensitive actions.

What is LLM function calling?

LLM function calling is a way for a large language model to interact with external tools, APIs, and software systems. Instead of only generating a text response, the model can identify when a task requires an external function, select the appropriate function, and generate the structured arguments needed to call it.

This is an important part of how modern AI agents move beyond basic question answering. An LLM can interpret what a user wants, while function calling gives the surrounding application a controlled way to retrieve information or take action.

AI Email Generator as an example of LLM function calling

For example, imagine a customer asks an ecommerce assistant, “Is this jacket available in size medium?”

The LLM cannot reliably answer that from its training data because inventory changes constantly. With function calling, the model can recognize that it needs current inventory information and request a function such as check_inventory, along with the relevant product and size.

The important distinction is that the LLM does not usually execute the function itself. Your application receives the requested function call, validates the arguments, runs the appropriate code or API request, then returns the result to the model.

Function calling therefore connects the language capabilities of an LLM with the systems where current business data and actions actually live. In customer service AI, that might mean checking an order, retrieving account details, or escalating an interaction to a human agent.

In 2026, function calling is also commonly discussed as part of the broader concept of tool calling. Custom functions are one type of tool an LLM can access, alongside capabilities such as search, retrieval, code execution, and MCP connections.

At its core, function calling provides the connection between natural language and executable software. The user explains what they want in ordinary language, the LLM determines which available function can help, and the surrounding application controls what happens next.

How function calling works

Function calling works by giving an LLM a defined set of functions it is allowed to request, along with instructions that explain what each function does. When the model receives natural language queries, it determines whether it can answer directly or whether it needs information or an action from another system.

The LLM generates the function request. The application executes it.

Here is what that process looks like.

1. Define the functions available to the LLM

First, the application tells the model which functions it can use and what information each function requires.

For example, a customer service application might provide a function called get_order_status. Its definition explains that the function retrieves the current state of an order and requires an order number.

This is closely related to the design principles behind an LLM toolkit, where clear contracts help control how a model interacts with business systems.

2. Send the user request to the model

The application sends the conversation to the LLM together with its available functions.

The model might also receive instructions through the system prompt that determine how and when those functions should be used.

For example, the system prompt could tell the model to retrieve live order information whenever a customer asks about a shipment rather than relying on information from the conversation.

A customer could then ask:

“Where is order 48392?”

The model interprets the request and determines that answering it requires information from an external system.

3. The LLM selects a function and generates the arguments

Instead of producing an ordinary response, the model can request the relevant function and generate the information that function needs.

Conceptually, that request could look like this:

{
  "name": "get_order_status",
  "arguments": {
    "order_id": "48392"
  }
}

At this point, the model has identified what needs to happen, but nothing has been executed yet.

The model interprets the request. The application decides whether the requested action is valid and carries it out.

4. The application executes the function

The application receives the function request, validates it, then runs the corresponding code.

In this example, get_order_status could query an ecommerce platform or order management system and return:

{
  "status": "shipped",
  "estimated_delivery": "September 16"
}

Keeping execution outside the model gives developers control over permissions, validation, and access to sensitive systems.

5. Return the result to the LLM

The application sends the result back to the model as additional context.

The LLM can then turn the structured information into a natural response:

“Your order has shipped and is expected to arrive on September 16.”

This is one of the mechanisms that allows AI automation to connect conversational interfaces with actual business processes instead of limiting the model to generating text.

6. Make additional calls when the task requires them

Complex tasks can require multiple function calls.

For example, a customer might ask:

“Has my order shipped, and can you change the delivery address if it has not?”

The model may first request the order status. Depending on the result, it could then request another function that changes the delivery address.

Some requests can also involve multiple function calls that do not depend on one another. Those operations may be handled in parallel rather than waiting for each previous call to finish.

This ability becomes especially useful in agentic AI orchestration, where agents may need to coordinate several tools or business systems to complete a larger task.

LLM function calling example

The easiest way to understand LLM function calling is to look at a simple customer service example.

Imagine a customer asks:

“Where is my order 48392?”

The model does not know the current status of that order. Instead of guessing, it can request a function that retrieves the information from an order management system.

A simplified tool definition could look like this:

tools = [
    {
        "type": "function",
        "name": "get_order_status",
        "description": "Retrieve the current status of a customer order.",
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "The customer's order ID"
                }
            },
            "required": ["order_id"],
            "additionalProperties": False
        },
        "strict": True
    }
]

The application then sends the customer’s request to the model together with the available function:

response = client.responses.create(
    model="your_model",
    input="Where is my order 48392?",
    tools=tools
)

Instead of answering the customer immediately, the model can return a request similar to this:

{
  "type": "function_call",
  "name": "get_order_status",
  "arguments": {
    "order_id": "48392"
  }
}

The application receives that request and executes its own code:

order_status = get_order_status("48392")

The function might return:

{
  "order_id": "48392",
  "status": "shipped",
  "estimated_delivery": "September 16"
}

That result is passed back to the model. The model can then generate a customer friendly response:

“Your order has shipped and is expected to arrive on September 16.”

The important point is that the LLM does not need unrestricted access to the order database. It only needs an approved function that gives it a controlled way to request the information.

The same pattern can support far more advanced agentic AI use cases. A customer service agent could retrieve an order, check eligibility for a return, or trigger an approved action in another system.

Function calling is what allows the model’s understanding of a conversation to connect with those external systems while the application maintains control over execution.

Function calling vs tool calling

Function calling and tool calling are closely related terms, but they do not always mean exactly the same thing.

Function calling usually refers to giving an LLM access to custom functions defined by an application. Each tool definition tells the model what the function does and describes the arguments it accepts.

For example, a function description for checking an order might say:

“Retrieve the current status of a customer order.”

The tool definition could also specify that an order_id must be provided as a string.

When the model chooses the function, it typically generates its arguments as a Json object:

{
  "order_id": "48392"
}

Your application receives those arguments, validates them, then executes the underlying function.

Tool calling is a broader concept.

A custom function can be a tool, but models can also use other types of tools. Depending on the platform, these might include web search, file retrieval, code execution, or connections to external systems.

This becomes especially relevant as LLM applications move toward AI agent frameworks that let models choose between different tools while completing larger tasks.

For example, an agent might first retrieve information from a knowledge source and then call a custom function that checks inventory. More complex requests can require multiple tool calls, with each tool contributing information or an action needed to reach the final outcome.

MCP has expanded this idea further by creating a standard way for applications to expose tools and other context to AI systems. Quiq covers the relationship between enterprise software and these connections in its guide to MCP connectors.

For most developers, the distinction is simple:

Function calling is a type of tool calling.

A function gives the model a structured way to request code defined by your application. Tool calling describes the broader pattern of allowing a model to access outside capabilities while completing a request.

Function calling vs structured output

Function calling and structured output both let developers control the format of information generated by an LLM, but they are designed for different jobs.

Function calling is used when the model needs to request an action or interact with another system. Structured output is used when the model itself needs to return data in a predictable format.

For example, imagine an application asks an LLM to analyze a customer conversation and return the customer’s name and reason for contacting support.

Structured output could require a response such as:

{
  "customer_name": "Sarah",
  "reason": "Order has not arrived"
}

Nothing needs to happen outside the model. The application simply needs the response to follow a defined structure.

Now imagine that Sarah asks:

“Can you check where my order is?”

The model needs information from another system. Function calling lets it request something like get_order_status, with the relevant order ID as an argument.

The application executes that function, retrieves the current information, then sends the result back to the model.

Function definitions tell the model what it can request

With function calling, developers provide function definitions that describe the operations available to the model.

Those definitions normally include the function name, its purpose, and the arguments it accepts. Function schemas then define the required structure and data types for those arguments.

For example:

{
  "name": "get_order_status",
  "description": "Retrieve the current status of an order",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string"
      }
    },
    "required": ["order_id"]
  }
}

This lets the model determine when the function is relevant and generate the arguments needed by the application.

The function does not have to map perfectly to a single backend method. As Quiq explains in its guide to building an LLM toolkit, tool contracts can be designed around the operations an AI system needs rather than exposing internal software exactly as it exists.

A content management agent, for instance, could have a copy page function that represents several operations behind the scenes. From the model’s perspective, it only needs to understand what the function does and which arguments it requires.

Structured output controls the model’s response

Structured output solves a different problem.

Instead of asking the model to select a tool, the developer specifies the structure that the model’s response should follow.

That is useful for tasks such as extracting information from conversations, classifying requests, generating data for another application, or producing predictable output that software needs to process.

Modern model APIs commonly use JSON Schema for this purpose. OpenAI’s Structured Outputs feature, for example, can constrain responses to a developer supplied schema rather than simply asking the model to produce valid JSON.

That distinction matters because valid JSON and structured output are not the same thing. JSON mode can produce a valid JSON object without guaranteeing that it contains the exact fields or data types your application expects. Structured output adds schema enforcement.

Function calling and structured output can work together

These concepts are not mutually exclusive.

Function calling often uses structured output internally to make the generated function arguments conform to the function schema.

With OpenAI, for example, setting strict: true on supported function definitions applies Structured Outputs to the generated function arguments. The arguments must then conform to the supported JSON Schema supplied by the developer.

The difference comes down to what the structured data is for.

Feature	Main purpose	Typical result
Function calling	Request an external operation	Function name and arguments
Structured output	Return predictable model generated data	Data matching a specified schema
Function calling with structured output	Request an operation with schema compliant arguments	Validated function arguments

In an AI agent, both may appear within the same workflow. Structured output can control how the model represents information, while function calling lets the agent use that information to interact with external systems.

For developers, the simplest distinction is this:

Use structured output when you care about the shape of the model’s response. Use function calling when the model needs to request something from outside itself.

Function calling vs MCP

Function calling and the Model Context Protocol both let LLM applications interact with external systems, but they solve different parts of the problem.

Function calling defines how a model requests a specific function. MCP defines a standard way for AI applications to discover and access tools provided by external systems.

With regular function calling, the developer usually defines each available function directly inside the application. The model receives those definitions, chooses the appropriate function, generates its arguments, then waits for the application to execute it.

For example, an ecommerce assistant could receive a function called get_order_status. When a customer asks about an order, the model requests that function, the application makes the necessary API calls, and the result is returned to the model before it produces its final response.

MCP adds another layer around this process.

MCP standardizes how tools are exposed

The Model Context Protocol is an open protocol for connecting AI applications with external tools, data sources, and services.

Instead of every application creating its own custom integration for every system, an MCP server can expose a collection of tools through a common protocol. An MCP compatible client can then discover those tools and call them without needing each integration to use its own proprietary interface.

The current MCP specification supports operations such as discovering available tools and calling them through standardized requests. The July 2026 specification also moved MCP to a stateless protocol core, making individual tool requests easier to handle across ordinary HTTP infrastructure.

This makes MCP especially useful when an AI application needs access to tools maintained outside the application itself.

Function calling defines the action

Function calling still plays an important role inside this setup.

Suppose an MCP server exposes a tool called search_customer_orders.

The model can decide that this is the correct tool for the user’s request and generate the required arguments. The MCP client then sends the request to the server, which executes the underlying operation and returns the result.

From the model’s perspective, this can feel very similar to ordinary function calling. The difference is in how the tool becomes available and how communication with the external system is handled.

OpenAI’s current Responses API reflects this distinction directly. It treats custom function calls and MCP tools as separate tool categories available to a model. Custom functions execute code defined by your application, while MCP tools connect the model with external systems through an MCP server.

Function calling and MCP often work together

MCP does not replace function calling.

Instead, it can provide a standard connection layer through which tools are discovered and accessed, while the model still needs to determine which tool to use and what arguments to provide.

A customer service agent might, for example:

Interpret a customer’s request.
Discover or select an appropriate MCP tool.
Generate the required arguments.
Send the tool request through the MCP connection.
Receive the tool result.
Use that information to generate the final response.

The same agent may interact with several systems during one conversation. One tool could retrieve an order, while another checks inventory or accesses customer account information.

This is one reason MCP has become increasingly relevant to agentic AI and AI agent frameworks. Agents often need access to multiple external capabilities rather than a fixed set of functions defined entirely inside one application.

Quiq covers this issue in more detail in its guide to MCP connectors, including why simply exposing tools through MCP does not automatically give an AI system everything it needs to work effectively across enterprise software.

The simplest way to separate the two concepts is:

Concept	Main purpose	Where tools come from
Function calling	Lets an LLM request a specific operation	Functions defined by the application
MCP	Standardizes how AI applications connect to external tools and systems	Tools exposed by MCP servers
Function calling with MCP	Lets a model select and request externally exposed tools	MCP connected systems

Function calling answers what operation should the model request?

MCP helps answer how can the AI application consistently access tools provided by other systems?

How function calling works with AI agents

Function calling becomes much more useful when it is part of an AI agent.

A standalone LLM can interpret a user message and generate a response. An agent can go further by deciding what needs to happen, choosing the right tools, calling external systems, evaluating the results, and continuing until it can complete the task.

Function calling gives the agent a controlled way to interact with those external systems.

A basic example is a customer asking:

“Can you check whether my order has shipped and change the delivery address if it has not?”

The user’s input contains a goal rather than a specific technical instruction. The agent needs to work out which actions are required to complete it.

A typical workflow might look like this:

The agent interprets the user message and identifies two possible actions.
It calls get_order_status to fetch data from the order management system.
It evaluates the returned order status.
If the order has not shipped, it calls update_delivery_address.
It receives confirmation that the address was changed.
It generates a final answer explaining what happened.

The important difference is that the agent is making decisions between function calls.

A basic function calling implementation might execute one predefined action and return the result. An agent can use the result of one function to determine what it should do next.

This is a central part of agentic AI orchestration. Once an AI system has access to several tools, it needs a way to decide which ones should be used, what context each tool receives, and how individual actions fit into the larger task.

Agents can combine several functions into one workflow

Consider a more involved customer service request:

“My package arrived damaged. Can I get a replacement sent to my new address?”

Completing that request could require the agent to check the original order, review the replacement policy, confirm inventory, update the customer’s address, and create the replacement order.

Each of those steps may involve a separate function.

The agent does not need the user to specify those individual operations. It interprets the user’s input, determines which information it needs, and selects the appropriate tools as the conversation progresses.

This ability is one reason modern customer service AI can handle more than simple question answering. An agent can fetch data from business systems and perform approved actions while maintaining the context of the customer conversation.

Function calling gives agents access to business systems

An LLM on its own does not automatically know what is happening inside a CRM, order management platform, billing system, or other private application.

Function calling gives the agent defined entry points into those systems.

A company might expose functions for checking an account balance, retrieving an order, processing a return, or creating a support case.

The agent can decide when those functions are required without receiving unrestricted access to the underlying systems.

This separation also gives the application control. Developers can decide which functions are available and validate requests before anything is executed.

Agents can adapt after every function call

Function calling also allows an agent to change its next action based on new information.

Suppose an agent checks an order and discovers that it has already shipped. It should no longer try to change the delivery address. Instead, it might check whether the carrier supports a delivery redirect.

If that fails, the agent could determine whether the conversation should be transferred to a human.

That ability to evaluate results and choose the next action is one of the key differences between an agent and a simple sequence of predefined function calls.

Quiq’s AI Assistants show how this kind of reasoning can also support human customer service agents. AI systems can use conversation context and connected business processes to suggest actions or execute approved workflows as an interaction develops.

Function calling does not create an AI agent by itself. It provides one of the core mechanisms an agent can use to interact with the systems around it.

The LLM interprets the request and decides what should happen next. Function calls give it controlled access to the information and actions needed to actually complete the task.

LLM function calling use cases

Function calling is most useful when an LLM needs information that is not already available in its context or when a user wants something to happen in another system.

That makes it especially useful for customer facing AI agents. Instead of only explaining what a customer should do, the agent can retrieve current information and request approved actions on the customer’s behalf.

1. Customer service

Customer service is one of the clearest LLM function calling use cases.

A customer might ask:

“Has my order shipped yet?”

Rather than relying on information from its training data, the LLM can call an order lookup function and retrieve the current status from the company’s backend system.

The same approach can support more involved customer service automation. An AI agent could check an account before deciding whether a request can be resolved automatically. If human help is required, another function could pass the conversation and relevant context to an agent.

Function calling turns the LLM from an interface that only talks about customer service into one that can interact with the systems used to provide it.

2. Ecommerce and retail

Function calling can connect a shopping assistant with live product and order information.

A shopper could ask:

“Do you have these shoes in size 10?”

The LLM can identify the product and call an inventory function to retrieve current availability.

A virtual shopping assistant could also use function calls during product discovery. For example, it could retrieve products that match the shopper’s requirements before presenting recommendations.

After a purchase, functions can connect the same conversation with order management systems. This allows the assistant to retrieve delivery information or initiate an approved post purchase workflow.

These capabilities are especially relevant to AI in retail, where useful customer interactions often depend on information that changes constantly.

3. Travel and hospitality

Travel requests frequently require access to current information rather than static answers.

A traveler could ask:

“Can I move my booking to Friday?”

An LLM can understand the request, but it needs access to the reservation system before it knows whether the change is possible.

Function calling can let the AI retrieve the booking and check the options available. If the customer chooses a new date, another function can request the change.

Similar workflows can support hotel reservations and other common requests in travel industry customer service.

The important part is that the model handles the conversation while functions connect it with the systems that contain the actual reservation data.

4. Financial services

Financial services provide another strong example because the model cannot safely rely on assumptions when dealing with customer specific information.

A customer could ask:

“Has my payment been received?”

The model can call an approved function to retrieve the current account information rather than attempting to infer an answer.

Function calls can also support processes such as document intake or payment related requests when the appropriate controls are in place.

Quiq covers more examples in its guide to financial services customer experience software, where access to verified information and controlled actions is especially important.

5. Business workflow automation

Function calling is not limited to customer facing requests.

An LLM can also use functions to interact with internal applications as part of a larger AI automation workflow.

For example, an employee could ask an internal assistant:

“Find this customer’s latest support case and add the conversation summary.”

The model could first call a function that retrieves the customer record. It could then request another function that adds the approved summary to the appropriate system.

This is also where function calling becomes useful for AI agents. Instead of requiring someone to translate every request into individual software commands, the agent can interpret the goal and decide which available functions are needed to complete it.

Across all of these examples, the underlying pattern is the same: the LLM handles language and decision making, while function calls connect it with the systems that hold current data or perform approved actions.

LLM function calling limitations

Function calling gives an LLM access to information and actions outside its own context, but it does not make the model infallible.

The application still needs to account for incorrect decisions, unavailable tools, bad arguments, and failures in the systems being called.

The model can select the wrong function

An LLM can misunderstand the user’s request and choose a function that does not match what the user intended.

This becomes more likely when several functions have similar names or overlapping purposes. Clear function descriptions and narrow responsibilities can help the model distinguish between them.

For example, separate functions for cancel_order and request_order_cancellation need descriptions that make the difference obvious. Otherwise, the model may select an action that has consequences the user did not intend.

Function arguments can still be wrong

A model may choose the correct function while supplying incorrect information.

Structured schemas can control the format of those arguments, but they cannot determine whether every value is factually correct.

For example, a valid function call could contain the wrong order ID. The JSON may be perfectly formatted while the requested action is still incorrect.

Applications should therefore validate function arguments against trusted data before execution.

External systems can fail

Function calling depends on systems outside the LLM.

An API may be unavailable. A request may time out. Authentication may expire. A tool can also return incomplete information.

The application needs to handle these failures instead of assuming every function call will succeed.

An AI agent may also need to determine whether it should retry the operation, choose another tool, explain the failure to the user, or transfer the conversation to a human.

Too many tools can make selection harder

Giving an LLM access to every possible function is rarely necessary.

A large collection of overlapping tools can make it harder for the model to identify the right action and can expose capabilities that are irrelevant to the current task.

This is especially important in agentic AI orchestration, where agents may have access to several systems during the same workflow.

Function calling does not replace application logic

The model should not become the only layer deciding whether an action is allowed.

Business rules, permissions, authentication, validation, and other controls should remain outside the LLM.

Function calling gives the model a way to request an operation. The surrounding application still determines whether that operation should actually happen.

Is LLM function calling secure?

LLM function calling can be used securely, but access to external tools creates risks that do not exist when a model can only generate text.

The biggest concern is that a model can request actions inside systems that contain customer data or other sensitive information. A mistaken tool call, manipulated prompt, or overly permissive function can therefore have consequences outside the conversation.

OWASP describes this problem as excessive agency. It occurs when an LLM application is given more functionality, permissions, or autonomy than it needs. OWASP recommends limiting available tools, restricting permissions, independently validating actions, and requiring approval for sensitive operations.

Keep authorization outside the LLM

The model should not decide whether a user is authorized to perform an action.

Suppose a customer asks an AI agent to change the email address associated with an account. The LLM may understand the request correctly, but the application still needs to verify the customer’s identity and confirm that the authenticated user has permission to make the change.

Authorization checks should be enforced by the application and downstream systems.

Give functions the minimum permissions they need

A tool that only needs to retrieve order information should not also have permission to modify or delete orders.

This limits the damage that can occur if the model selects the wrong tool or receives a malicious instruction.

The same principle applies when connecting agents through APIs or the Model Context Protocol. Access to a system should be restricted to the operations needed for the specific workflow.

Validate every function call

Function arguments should be treated as untrusted input until the application verifies them.

Schema validation can confirm that arguments have the expected format. Applications may also need to confirm that identifiers exist and check whether the requested operation is allowed.

OpenAI similarly recommends validation when model output must meet application requirements. JSON output alone does not guarantee that values match a required schema or that the requested action is appropriate.

Require approval for sensitive actions

Some functions should not execute automatically.

Operations involving payments, account changes, deletion of information, or other sensitive actions may require customer confirmation or human approval before execution.

OWASP specifically recommends approval controls for actions where excessive autonomy could cause meaningful harm.

Function calling is therefore not secure simply because the model produces structured arguments. Security comes from the controls around the model, including permissions, validation, authentication, and approval logic.

LLM function calling best practices

Good function calling design is less about giving an LLM access to as many tools as possible and more about giving it the right tools with clear boundaries.

The following practices can make function calling more predictable in production.

1. Give every function one clear purpose

Functions should represent specific operations rather than broad capabilities.

A function called manage_customer_account leaves the model with a lot to interpret. Separate functions such as get_customer_account and update_customer_address give it clearer choices.

Specific functions are also easier to validate and control.

2. Write clear function descriptions

The function description tells the model when a tool should be used.

Explain what the function does and when it is appropriate. If another function performs a similar operation, describe the difference clearly.

Good descriptions reduce ambiguity when the model has several tools to choose from.

3. Use strict function schemas where possible

Define expected arguments and data types rather than accepting loosely structured input.

Schemas make it easier for the application to reject malformed requests before they reach another system.

Where supported, schema constrained function arguments can also reduce formatting errors. OpenAI’s current function calling guidance distinguishes this from basic JSON output, which only guarantees valid JSON rather than adherence to a particular schema.

4. Validate arguments before execution

Do not execute a function simply because the arguments passed schema validation.

Check identifiers against trusted systems. Confirm that required resources exist. Apply the same business rules you would use for requests coming from any other application interface.

5. Limit the tools available for each task

An LLM does not need access to every function your organization has created.

Expose only the tools relevant to the current agent or workflow. This can make tool selection easier and reduces unnecessary access to sensitive capabilities.

OWASP recommends limiting both tool functionality and downstream permissions as a defense against excessive agency.

6. Design clear error responses

Functions should return errors in a form the model can interpret.

If an order cannot be found, tell the model that the order was not found rather than returning an ambiguous empty response.

Clear tool results help the model determine whether it should ask the user for more information, try another operation, or stop.

7. Keep sensitive actions behind additional controls

Some function calls should require confirmation before execution.

An AI agent can prepare a refund or account change, for example, while the application waits for customer confirmation before performing the action.

This lets the model help complete the workflow without giving it unnecessary autonomy.

8. Log function activity

Record which functions were requested and what results were returned.

Logs make it easier to investigate incorrect behavior and identify functions that regularly fail or get selected in the wrong situations.

This is especially useful for customer service AI, where tool calls may become part of longer customer conversations and business processes.

Function calling works best when the LLM is responsible for interpreting intent and selecting from controlled options, while the application remains responsible for permissions, validation, and execution.

How Quiq uses function calling for customer experience

Function calling becomes much more useful when it is connected to the systems customers already rely on.

Quiq’s AI Studio supports function calling for capable LLMs and gives teams ways to combine prompts, functions, API calls, search, and other actions inside customer experience workflows. AI Agents built in AI Studio can interact directly with customers, while AI Assistants can support human agents during live conversations.

That means an AI agent can do more than generate an answer. It can retrieve information from external systems, update conversation data, call APIs, route a customer, or trigger another approved action based on the context of the interaction. Quiq’s Flow Editor includes dedicated behaviors for API calls and functions, while its agent context can retain API results and other information throughout the workflow.

For customers, the difference is straightforward. They can ask for what they need in natural language instead of navigating a rigid set of predefined commands. The AI can interpret the request, access the right systems, and complete supported tasks such as bookings, returns, account updates, or other customer service actions.

Function calling is only one part of that process. Effective customer experience also requires context, business rules, access controls, reliable data, and a clear path to human support when automation should stop.

Quiq brings those pieces together so companies can build AI agents that do more than answer questions.

Book a demo to see how Quiq can connect conversational AI with your customer experience systems.

What is LLM Function Calling and How Does it Work?