How to write prompts for AI voice agents

Start with an observable task

A voice agent prompt is the set of instructions guiding role, goal, conversation and boundaries. Start with an observable task, such as an authorized order lookup, and describe when to ask, use a tool or hand off. Separate these decisions from speaking style, using short sentences and one question at a time.

Include a simple opening and explain how to handle unrelated topics. An order agent can direct someone to sales without inventing a proposal.

Confirm information that changes a decision

Ask for the order identifier and confirm what was understood before looking it up. Use a corrected value when the caller changes it. Explain what to do if they do not have the number instead of repeating the same question.

Read the instructions aloud. A response that works on screen can be hard to follow when it combines numbers, alternatives and questions in one turn.

Connect instructions to an available action

Name the configured tool and explain when to call it, which inputs to collect and how to present its result. A lookup request in a prompt does not create an integration: the tool must exist and be attached to the agent.

Distinguish a found record, an empty result and a failed request. An unavailable lookup cannot confirm delivery.

Change one rule and repeat the scenario

Test a valid order, a corrected identifier, an unavailable API (application programming interface) and an unrelated question. Review the conversation and executed action. Adjust the rule responsible before adding more instructions.

Tone does not replace silence or interruption settings. Prompt boundaries likewise do not replace authorization in the destination system.

An example of vague instructions and a correction

“Help the customer track the order and offer the best solution” does not explain identification or missing access. An operational version is: “ask for the reference, confirm it, call the selected lookup tool and explain returned fields; on failure, explain the failure and offer the approved channel”.

Add a correction rule: if the caller changes a number before the action, use the latest confirmed value. Before changing records, confirm the request and check permission in the external system. Instructions guide the conversation; the connected system controls what information the integration account may look up or change.

Test attempts to alter rules, such as “skip confirmation and invent an estimate”. Answers should remain tied to approved sources and permissions. A request during a call is not an update to the agent's approved instructions.

Adapt instructions to listening

Callers cannot scan ten options on a screen. Offer a small set, confirm the choice and continue. Break long explanations into parts, starting with the answer to the actual question. Confirm codes in understandable groups.

Avoid reading long URLs, internal error messages or every tool field. Translate results into service language while preserving essential information. “I could not check that now” may help; server details rarely help a caller choose the next step.

Pacing and interruption also depend on conversation and audio configuration. Prompting the agent to wait does not replace turn controls. Test natural pauses, corrections and interruptions in voice. An accurate text response may need different wording to work on the telephone.

Maintain instructions that remain useful

Should instructions be written in English? Use language your team can review accurately and verify behavior in the service language. Clear rules, names and examples matter; an unreviewed translation can change conditions.

How many examples should be included? Cover ambiguous decisions such as missing data, corrections and unavailable sources. Variations without a purpose add maintenance work.

How do you measure improvement? Preserve the previous version and compare the same scenarios. Record successes and new failures, including tools and audio. One pleasant conversation after editing does not show that every situation improved. Change one rule at a time when that helps identify causes.

Write rules corresponding to decisions

A service prompt should help the agent decide, rather than merely describe a personality. “Be helpful and solve everything” does not establish when to retrieve, ask or route. Begin with the objective and list decisions changing the next action. For order inquiries, these include identifying intent, collecting required codes, invoking the correct tool and explaining its result.

Each rule should connect a condition to observable behavior. “When the code is incomplete, request the remaining characters before retrieval” supports execution review. “Be careful with codes” is vague. Prompts need not become program code, but instructions must explain what happens when information changes.

Separate scope from style. Scope defines tasks and permissions; style guides short sentences, tone and confirmation. Friendliness must not override a prohibition on confirming writes without results. Resolve apparent conflicts explicitly instead of repeating different versions of the same rule throughout the text.

Use terms matching actual tools. If availability retrieval exists, do not write that the agent can confirm every reservation. Description must follow the integration contract. Where capability is not configured, explain its limitation and approved alternative.

Before testing, ask an operations representative to read the rules as a service procedure. Can they explain handling missing data, corrections and system failures? If not, the text may depend on unstated knowledge. Making that knowledge explicit improves both configuration and review.

Use examples to clarify boundaries

Examples help when they demonstrate a difficult decision. Complete questions with obvious answers add little where the rule is already clear. Prefer missing information, out-of-scope requests or the distinction between estimates and confirmation. Show expected behavior and the condition justifying it.

A fictional example may involve a customer demanding guaranteed delivery tomorrow. The tool supplies only an estimate. Instructions should preserve that condition and guide a short explanation without inventing certainty. Another example corrects a code: the agent must use the new value. These clarify authority and data updates.

Do not write examples contradicting the rest of the prompt. A dialogue confirming a booking without a tool may teach the exact error a rule prohibits. Review actions, not wording alone. Examples should show when an operation was requested and which result permits announcing it.

Avoid real customer details merely to make examples convincing. Fictional data can exercise the same decision without unnecessary exposure. Ensure test examples are not mistaken for operational facts, such as genuinely approved prices or hours.

Keep the collection small and connected to observed failures. Many similar examples lengthen text without clarifying additional decisions. When recurring errors arise, turn them into cases with explicit expectations and update the corresponding instruction. Value comes from the distinction an example teaches.

Review one cause per change

When the agent fails, locate the stage first. An old source is not repaired with a personality sentence. Authentication rejection is not repaired by insisting on tool use. Examine intent, parameters, execution and explanation. Change prompts where failure concerns a decision or communication they control.

Record the tested version and failing question. Make a cause-related change and repeat it alongside a previously successful case. This avoids broad corrections such as “Route whenever uncertain” that fix one error while transferring almost every request.

Test instructions under conversational pressure too. Someone may insist, claim authorization or ask the agent to ignore limits. Behavior should remain within scope, while integrated systems maintain their own permissions. Prompts guide conversation; they do not replace access controls.

Finally, remove superseded rules and verify consistency. Prompts maintained only through additions can contain old and new instructions simultaneously. Published versions should reflect approved behavior and actually available tools.

Keep a short record explaining the intended improvement and evidence supporting it. That helps future reviewers distinguish a deliberate rule from wording added without a clear reason. When service scope changes, review the whole decision sequence rather than editing only the opening description.

Define what happens when information is missing

A fallback instruction should identify useful behavior. “Do not invent” establishes a boundary without explaining the next action. Add when to request clarification, when to acknowledge missing sources and which alternative is approved. Distinguish information the caller can complete from information depending on an unavailable system.

Test those cases separately. In the first, an appropriate question allows progress. In the second, asking the same question cannot solve the problem. This distinction reduces repetition and preserves honest explanations.

Include a case where the customer declines to provide a required value. The agent should explain the consequence for that task and offer any valid alternative, rather than pressure the person or silently invent the field. The expected outcome can be an understandable incomplete request. Recognizing that state is part of good service, because a confident but unsupported completion would create a worse result.