Tools should return only the minimum amount of data required to complete a task. The response should contain only information that the user is allowed to see or is already aware of.

LLMs should not be trusted to safely ignore sensitive fields in an API response. Any data returned by a tool could potentially be exposed in the model’s output, so responses must be carefully restricted.

Responses should be structured in a way that is simple and easy for the model to interpret. If structured data must be returned, ensure the prompt clearly instructs the model how to interpret it.

Where possible, provide clear, human-readable responses rather than raw structured data.

For example, instead of returning:

return something clearer such as:

This reduces ambiguity and helps the model produce more accurate responses.

LLMs have limited context windows, meaning they can only retain a certain amount of the conversation at any given time.

Tool responses are added to this context. Returning large amounts of unnecessary data will:

For best results, responses should be kept concise and relevant.

Empty results can confuse the model. APIs should provide a clear indicator explaining why no data was returned.

For example, instead of returning a plain 404, return a 404 with a response body such as:

This helps the model distinguish between:

You should also provide prompt guidance on how the model should communicate failed searches to users.

For example, if a lookup requires both a member ID and date of birth, the model may incorrectly respond with:

In reality, the model cannot know which value was incorrect. This can mislead the customer and potentially introduce a data leakage risk, as a malicious user could attempt to brute-force valid data combinations.

APIs should include a unique identifier for each request, ideally using the interaction UUID. This allows requests to be traced back to their originating interaction.

Where possible, APIs should also implement rate limiting based on the interaction ID. This helps prevent brute-force attacks against backend services.

Business hours defined within prompts are often unreliable. LLMs are not dependable when performing tasks such as:

Where possible, provide a dedicated tool to handle time calculations and availability checks rather than relying on the model to infer them.

Whenever the model generates a response, it evaluates the tools available to determine whether any are relevant to the user’s request.

For example, if a user asks to check their bank balance, the model recognises that it cannot access that information directly. It will then examine the available tools to determine whether a suitable tool exists to retrieve the data.

The model evaluates the tool description and parameter definitions each time it decides how to respond.

If you are writing a prompt for a bot that will eventually use tools, but those tools are not yet available, it is generally best to delay writing the prompt.

Tools can significantly influence how the bot behaves.

For example, consider a tool that retrieves a customer’s bank balance:

The prompt would describe the parameters:

The tool description might then say:

💡 Important:

You do not need to explicitly instruct the model in the main prompt to collect these values. The model can infer the required information based on the tool parameters.

If a customer asks:

the model will identify the tool, review the required parameters, and ask the user for the necessary details.

Additional prompt instructions are useful when you want the model to follow a specific workflow, especially when multiple tools depend on one another.

For example, if a bank transfer tool exists, the prompt might include instructions such as:

If you design and test conversation flows before tools are implemented, you will likely need to simulate the workflow manually in the prompt.

Once tools are later added, the bot’s behaviour can change significantly, which may invalidate previously tested flows.

For this reason, it is generally best to finalise prompts after tools have been implemented, whenever possible.

The tool label in Talkative exists only for internal reference. The model does not see this label.

Instead of referring to a specific tool name, prompts should describe the action required.

For example:

or simply:

If stronger instruction is required, you might write:

Prompts often refer to a “knowledge base”, but the model has no inherent understanding of what this means.

Every time a tool is called, its output is added to the prompt context. For this reason, it is more effective to instruct the model to:

Default prompts often assume UK date and time formats. Ensure these match the expectations of the customer’s region.

The way the prompt describes dates and times influences how the model:

When using S2S, the prompt affects both how the model interprets information and how it interacts during speech.

Although prompting accents rarely works reliably, S2S prompts can guide behaviour during tool usage. For example:

This works because S2S can execute tools while speaking and adapt the response dynamically.

With S4TS, this is not possible. The model does not know a tool is being executed until it begins execution, and speech is generated only after the tool response has been processed.

For clarity:

Instructions such as “speak more slowly” will therefore have no effect.

While you cannot directly control the TTS voice through the prompt, you can influence how the LLM formats the text that will be spoken.

For example, when returning codes such as:

you might instruct the model:

This may produce output such as:

This approach may reduce transcript readability, but it often improves the clarity of spoken responses.

Interaction data can still be post-processed into a more readable format for storage.

Smart formatting can improve transcript readability for human review. However, when using Voice AI, it is often better to disable it.

Smart formatting may:

Disabling it may make transcripts slightly less readable, but it ensures the LLM receives the full and accurate input, improving reliability.