Prompts / Instructions

Prompts generally tell the LLM what to do next. For instance, asking the user for specific information such as their name, insurance number, address/contact details, etc.

Prompts can either be static or dynamic.

Static/Plain Text Prompts

Example:

Greet the caller and ask for their name.

In static prompts, you can access all variables from the state using {{variableName}}.

Example: The following information is stored in state:

{
    companyName: "claiverly GmbH"
}

Prompt that uses this information:

Greet the caller with the following sentence: "Welcome to {{companyName}}".

Dynamic/Programmatic Prompts

Sometimes it is necessary to include dynamic information in the prompt that comes from an external source or from state and is not static.

Example: Your application needs the current date and time. LLMs are trained up to a certain point in time and are text-based, so they do not know the current date and time. If the application relies on time information, e.g. for scheduling appointments, the LLM can be informed about the current date and time.

Example of how to provide the current date and time to the LLM:

function prompt(params) {
    return ({ "prompt": "Today is " + new Date().toLocaleString() });
}

Example of how to include the current temperature at Berlin Alexanderplatz via a webhook query in the prompt:

function prompt(params) {
    const temperature = webhook("https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m", {}, {method: "get"});
    return ({ "prompt": `The temperature in Berlin is right now: ${JSON.stringify(temperature)}`});
}

How to write effective prompts

A good prompt makes the assistant’s goal, boundaries, and expected behavior explicit. Start with the outcome you want, then add only the context and rules needed to achieve it. Prompting is iterative: test a first version with realistic conversations, inspect the result, and refine the instruction that caused the undesired behavior.

Structure the prompt

Separate the prompt into short, clearly named sections. This makes it easier to maintain and helps the LLM distinguish the assistant’s role from the caller’s information.

## Role
You are the friendly receptionist for Acme Dental.

## Goal
Help callers book, change, or cancel an appointment.

## Conversation rules
- Greet the caller and ask how you can help.
- Ask only one question at a time.
- Use simple, natural language suitable for a phone conversation.
- Repeat the selected date and time and ask for confirmation before booking.

## Boundaries
- Never invent appointment availability, prices, or patient data.
- If the information is unavailable, say so and offer to transfer the caller.

## Tool use
- Use `find_appointments` after collecting the service, preferred date, and caller details.
- Use `book_appointment` only after the caller explicitly confirms the slot.

Useful sections include Role, Goal, Context, Conversation rules, Tools, Boundaries, Fallbacks, and Examples. For a multi-stage bot, keep each stage focused on one conversation state and describe clearly when the conversation should move to another stage.

Be specific about the desired behavior

Avoid vague instructions such as “be helpful” or “handle the call professionally”. State what the assistant should do, when it should do it, and what it should say or return.

When the caller wants to cancel an appointment:
1. Ask for the appointment date and the caller’s name.
2. Find the matching appointment.
3. Read back the appointment details.
4. Ask: “Should I cancel this appointment?”
5. Call `cancel_appointment` only after the caller confirms.

Use explicit conditions for important branches. Tell the assistant what to do when required information is missing, a tool returns no result, the caller disagrees, or the request is outside its responsibilities. Do not rely on the assistant to infer business rules from a short role description.

Design for spoken conversations

Phone assistants should sound natural when read aloud:

Keep responses concise and ask one question at a time.
Use short sentences and avoid long lists, tables, URLs, and technical terms.
Confirm important values such as names, dates, times, addresses, and amounts.
Define how numbers, dates, email addresses, and spelling should be read back.
Tell the assistant how to handle interruptions and uncertain answers.
Specify the exact language, tone, formality, and terminology for your audience.

For example:

Speak in formal German using “Sie”. Use 24-hour times and say dates in full.
After the caller gives a phone number, repeat it digit by digit and ask for confirmation.
If you did not understand an answer, ask one short clarification question instead of guessing.

Make tool calls predictable

Prompts should describe the purpose and timing of each tool. Include prerequisites, confirmation requirements, and the next step after success or failure. Tool descriptions and the prompt should not contradict each other.

Before calling `create_contact`, collect and validate the caller’s name and phone number.
Never call it with guessed values. If the tool fails, apologize briefly, explain that the
contact could not be saved, and offer to take a message or transfer the call.

In a single- or multi-stage bot, write the tool conditions explicitly. If a tool changes state, moves to another stage, sends a message, books an appointment, or transfers the call, say when that action is allowed. See tools and functions for the corresponding VoiceBooker configuration.

Use context and examples carefully

Include relevant business facts directly in the prompt or provide them through state, a knowledge base, or a dynamic prompt. Tell the assistant which source to trust and what to do when the information is missing. Never include secrets or credentials in a prompt.

Examples are useful when you need a consistent format, wording, or decision. Keep them short, realistic, and varied. Make sure the examples follow the same rules you expect in production; inconsistent examples teach inconsistent behavior.

Avoid common prompt problems

Conflicting instructions: review the complete prompt when adding a new rule; remove or reconcile contradictions.
Too many responsibilities: split unrelated tasks into stages or separate assistants.
Unclear fallbacks: define the response for missing data, tool errors, silence, and requests outside the bot’s scope.
Overlong instructions: remove rules that do not affect the desired outcome.
Unbounded answers: specify the required length, format, language, and tone.
Assumptions presented as facts: instruct the assistant to ask or escalate instead of guessing.

Test and improve systematically

Define what “working” means before optimizing the prompt. Test happy paths as well as interruptions, ambiguous answers, missing data, tool failures, repeated requests, and handoffs. Compare transcripts and function calls, then change one part of the prompt at a time. Re-test existing scenarios after every change so that fixing one behavior does not break another.

The debugging guide explains how to inspect state, stacks, function calls, and webhook results. For dynamic prompts, verify the generated prompt and the values passed into it rather than only reading the source code.

Prompts / Instructions

On this page