Prompt engineering

A voice agent's prompt is read by the model on every turn, and everything the model writes is spoken aloud. Good phone prompts are short, sectioned and specific about what to say and when to call functions. This page covers structure, the speech conventions Tried's runtime understands, and how to debug.

A structure that works#

Use Markdown headings. The editor highlights lines that start with #, and section headings make it easy to see which rule the model broke.

## Identity
You are Ava, the front-desk receptionist for {{business_name}}, a dental clinic in Sydney.
The current time is {{current_time}}.

## Style
- One or two short sentences per turn. Ask one question at a time.
- Warm and plain. No lists, no markdown, no emojis: everything you write is spoken.
- Never make up information. If you do not know, offer to take a message.

## Task
1. Greet the caller and ask how you can help.
2. Answer questions about hours, location and services from the knowledge base.
3. If the caller wants to book, collect their name, preferred day and time, then call check_availability.
4. Confirm the details back to the caller before you call book_appointment.
5. When the caller is done, say goodbye and call end_call.

## Rules
- If the caller asks for a person, call transfer_to_front_desk.
- If the caller describes chest pain or trouble breathing, tell them to call 000 now and end the call.

Identity#

Say who the agent is, who it works for and what it can help with. Put the business name in a dynamic variable so one prompt serves several clients.

Style#

Phone replies must be short. Long answers cause callers to interrupt, and the interruption cuts the agent off mid-sentence. Tell the model to ask one question at a time and to avoid formatting, which would be read aloud.

Task#

Number the steps. Name the function to call at each step and what must be true before calling it. The model calls functions based on their descriptions and the prompt, so match the names exactly.

Rules#

Cover edge cases: requests for a person, out-of-scope questions, abuse, emergencies, and callers who want to stop.

Speech conventions#

The runtime processes the model's text before it reaches the voice. You can use these in the prompt, in static messages, and in replies the model writes.

Example instruction: "Read booking references with spell tags, for example <spell>HX4821</spell>."

NO_RESPONSE_NEEDED helps when the caller says something that needs no reply, such as "hold on a second" while they look for a card. Tell the model when to use it: "If the caller asks you to wait, reply with exactly NO_RESPONSE_NEEDED."

Numbers, dates and money#

With Normalize for speech on (the default), Premium and Standard voices expand numbers, dates and currency into spoken words. For other voices, or to control the wording, ask the model to write them as spoken: "Say prices in words, for example twelve dollars fifty." The Speech normalization option in the Agent Handbook adds that instruction for you.

For phone numbers, ask the model to read digits in groups: "Read phone numbers in groups, for example zero four one two, five five five, zero one nine."

Use the Agent Handbook for common behaviours#

Instead of writing the same rules in every prompt, turn on presets in Agent Handbook: personality, natural filler words, echo verification, NATO phonetic alphabet, speech normalization and AI disclosure. Tried appends them as a ## Handbook section. See Agent Handbook.

Keep the prompt focused#

• Move reference material out. Price lists, policies and FAQs belong in a knowledge base. Only the passages relevant to the current turn are added to the prompt.
• Move changing values to variables. Opening hours, staff names and phone numbers can be default dynamic variables or come from a pre-call workflow.
• Split stages. When the task list grows past a handful of steps with different rules, use multi-prompt states or a conversation flow.
• Mind the size. The maximum is 32,768 tokens, and prompts over 4,000 tokens increase the billed LLM cost in proportion. The editor footer shows an estimate.

Write good function descriptions#

The model reads each function's description to decide when to call it.

Describe each parameter too, including its format ("Date in YYYY-MM-DD").

Debug a prompt#

Common problems#