Function calling in voice assistants: how state management reduces hallucinations

Summary

Large language models can hallucinate technical parameters such as product or tariff IDs during function calls, especially when several values must be passed at once. In complex ordering flows this can lead to incorrect or invalid backend requests. A much more reliable approach is to collect user decisions step by step and store each selection in a persistent state before executing the final transaction. VoiceBooker supports this approach with integrated state management and therefore makes it possible to build robust service bots with high reliability and a low error rate.

Introduction

Complex phone assistants for support hotlines often need to retrieve data from backend systems, identify customer data, or execute transactions on a user account. Modern LLM-based voice assistants enable natural conversations and can interact with external systems via function calling.

In practice, however, one challenge quickly becomes apparent: the reliability of function calls depends heavily on how information is collected and processed during the dialog.

The problem: hallucinated parameters and IDs

Consider a typical example from the telecommunications industry. A customer wants to purchase a mobile plan. The ordering flow consists of several decisions:

1. Choosing between prepaid and postpaid
2. If prepaid is selected: choosing a minutes package
3. Choosing an SMS package

Each of these options has a unique technical ID in the backend. For example, the available products might be modeled as follows:

A naive approach is to let the voice assistant collect all required information first and then execute a single function call:

{
  "product_type_id": 101,
  "minutes_package_id": 202,
  "sms_package_id": 302
}

At first glance, this approach seems reasonable. In practice, however, it often creates problems.

Large language models tend to hallucinate. That means they can invent information that does not actually exist. This becomes especially critical when technical IDs are involved. If a model has to fill in several parameters at once, the probability of confusing values or inventing one entirely increases.

Instead of using the valid ID 202, for example, the model might suddenly generate a non-existent ID such as 205. The more options and parameters need to be processed at the same time, the greater this risk becomes.

Why complexity grows exponentially

The underlying problem is the size of the search space.

If, for example, there are two product types, five minutes packages, and four SMS packages, this already results in:

2 × 5 × 4 = 40

possible combinations.

In real products, hundreds or thousands of valid combinations can arise quickly. The model then not only has to identify the correct option, but also select multiple correct IDs and combine them consistently.

This kind of combinatorial complexity significantly increases the likelihood of errors.

The better approach: state-based information collection

A much more robust strategy is to collect information step by step and store it in a central state.

The dialog could proceed like this:

Step 1: Choose the product type

{
  "product_type_id": 101
}

The value is stored in the state.

Step 2: Choose the minutes package

{
  "minutes_package_id": 202
}

The new value is also stored in the state.

Step 3: Choose the SMS package

{
  "sms_package_id": 302
}

This value is stored in the state as well.

At each step, the voice assistant only has to make a single decision. Instead of choosing from all possible combinations at once, it focuses on a limited set of options per step.

Only after all information has been collected is the final commit executed:

{
  "product_type_id": 101,
  "minutes_package_id": 202,
  "sms_package_id": 302
}

Since all IDs have already been validated and stored beforehand, the risk of hallucinations drops dramatically.

Why this approach is more reliable

The key advantage is the reduction in cognitive load for the model.

With a single function call containing many parameters, the LLM has to:

• Make several decisions at once
• Remember the correct IDs
• Form the correct combination
• Output all values in one step

With the state-based approach, by contrast, the model only has to:

• Make one decision
• Select one ID
• Store it in the state

This significantly reduces the probability of errors. Instead of one large combinatorial problem, several small and much simpler tasks are created.

VoiceBooker and integrated state management

VoiceBooker supports this paradigm through integrated state management.

Throughout the conversation, a JSON object is available that can be read and updated at every dialog step. Already collected information therefore remains persistently available and does not need to be reconstructed by the model.

A typical state might look like this:

{
  "customer_id": "12345",
  "product_type_id": 101,
  "minutes_package_id": 202,
  "sms_package_id": 302
}

Each new user decision simply extends the existing state. Only when all required information is available is the actual transaction triggered.

This pattern leads to significantly more reliable function calls and minimizes hallucinations for technical parameters.

Conclusion

Function calling is a central technology for modern voice and support assistants. The biggest challenge, however, is not the function call itself, but the reliable retrieval of the required parameters.

When multiple IDs and decisions are processed at the same time, the likelihood of hallucinations and incorrect function calls increases significantly. A state-based approach, in which information is collected and stored step by step, greatly reduces complexity.

With VoiceBooker’s integrated state management, exactly these kinds of dialogs can be implemented efficiently. IDs and other technical parameters are stored safely in the state during the conversation and can then be used reliably for the final transaction. This results in robust, scalable, and high-quality service bots that can reliably model even complex business processes.