How to Structure a Voice Agent System Prompt

We wrote four production system prompts for four different trades over a fortnight, without a shared template: a restaurant, a plumber, a dental practice, an electrician. Going back through them to write this piece, they had converged on the same skeleton and, in three of the four cases, on the same three-tier precedence ladder. Nobody designed that. The calls did.

The tier that emerged on top is not the guardrails block. It sits above it, and the vendor prompting guides do not have it.

This is the canonical structure the industry prompts on this blog all use. It covers which blocks are universal, which ones a vertical has to earn, how to declare precedence so the model actually honours it, and where the published vendor guidance runs out.

Key takeaways

• Six blocks appear in every production prompt we run. Five more appear only where the calls demand them.
• Guardrails are the second tier, not the first. Any vertical with a life-safety path needs a SAFETY block that outranks them, declared in the heading text.
• Vapi's guide documents two tiers and Retell's documents none. Neither has a safety tier.
• Models restate constraints they are simultaneously breaking, so asking your agent to recite its rules proves nothing.
• Instruction following degrades as a call goes on, so restate a rule at the point of use rather than only at the top.
• Write rules as actions. A prohibition list can prime the phrases you banned.

The skeleton, before any industry touches it

Start from the block order below and delete what your calls do not need. Every heading carries its own precedence statement, because the model reads the heading as part of the rule.

# IDENTITY
Who the agent is, which business it answers for, and what it is allowed to be.

# CONTEXT (injected at call time)
Today's date and time with an explicit timezone. Caller number. Opening hours.
Anything that changes between calls goes here, never in prose above.

# PERSONALITY AND TONE
How it sounds. Two sentences maximum per turn. One question at a time.

# RESPONSE RULES
Spoken-form numbers, prices and dates. No markdown, no lists read aloud.
Confirm by paraphrasing before any write.

# DECISION ORDER
The branch order, numbered. What it checks first, second, third.
Only needed where a call can be more than one kind of call.

# TASKS AND WORKFLOWS
One subsection per job the agent actually does, each with its own steps.

# TOOLS
Exact tool names, when to call each, what to say while waiting.

# ESCALATION
Who gets the call, on which trigger, and what the agent says as it transfers.

# GUARDRAILS (these override everything above)
What it must never assert, quote, promise or diagnose.

# EXAMPLES
Three transcripts minimum: happy path, edge case, recovery from a failed tool call.

Everything in that skeleton is reusable. Everything that makes a prompt work for a specific business is the content inside the blocks, which is why the industry guides on this blog carry their prompts in full rather than describing them.

Six blocks are universal, five are earned

Comparing our four production prompts block by block, six appear in all of them and the rest track a property of the vertical rather than a preference.

Block	Restaurant	Plumber	Dental	Electrician
IDENTITY	Yes	Yes	Yes	Yes
CONTEXT (injected at call time)	Yes	Yes	Yes	Yes
RESPONSE RULES	Yes	Yes	Yes	Yes
TASKS AND WORKFLOWS	Yes	Yes	Yes	Yes
GUARDRAILS	Yes	Yes	Yes	Yes
EXAMPLES	Yes	Yes	Yes	Yes
TOOLS	Yes	Yes	Yes	No
DECISION ORDER	No	Yes	Yes	Yes
SAFETY	No	Yes	Yes	Yes
PERSONALITY AND TONE	Yes	Yes	No	No
Scope-negation block	No	Yes	Yes	Yes

Three of those rows carry the actual information. DECISION ORDER and SAFETY are present in every trade prompt and absent from the restaurant one, because a restaurant call has one shape and no life-safety path. TOOLS is missing from the electrician prompt because that agent books through escalation rather than writing to a diary itself.

The scope-negation row is the same idea wearing three names: PRIORITY CALLERS in the plumbing prompt, THE BOUNDARY in the dental one, NOT OUR JOB in the electrician one. Different wording, one job, covered further down.

Guardrails are not the top tier

Any vertical where a caller can be in physical danger needs a block that outranks the guardrails, and the ranking has to be written into the heading rather than implied by position. Our three trade prompts all landed on the same wording pattern, independently.

Prompt	Tiers	The precedence declared in the headings
Restaurant	2	GUARDRAILS (these override everything above)
Plumbing	3	GUARDRAILS (these override everything above; only SAFETY outranks them) and SAFETY (these override every other rule in this prompt)
Dental	3	GUARDRAILS (only SAFETY outranks these) and SAFETY (these override every other rule in this prompt)
Electrician	3	GUARDRAILS (only SAFETY outranks these) and SAFETY (overrides every other rule here)

The distinction matters because the two tiers pull in opposite directions on the calls that matter most. Guardrails are mostly refusals: do not quote a price, do not diagnose, do not promise a time. Safety rules are mostly instructions to act: say the words, give the number, stop taking details and get them off the phone. A single flat rule list makes the model choose between "never give advice" and "tell them to call 999", and it will resolve that conflict by whichever rule reads as more emphatic.

Tier count is a property of the trade, not a style choice. Ask one question: can a caller be in danger while on this call? If yes, you need the third tier.

Where the vendor guidance stops

Vapi's prompting guide is the most complete published structure we found, and it documents six sections in order: Identity & Personality, Response Guidelines, Guardrails, Context, Workflow / Use Cases, Examples. It states the precedence explicitly, that "Guardrails override all other instructions", and adds a silent pre-response safety check.

Retell's prompt engineering guide covers Identity, Style Guardrails, Response Guidelines, Tool Usage Instructions, Task Instructions and Objection Handling. Useful sections, and no precedence statement between them at all.

Two gaps, and the second is the expensive one.

First, both guides put context fourth or later. All four of our prompts put it second, directly after identity, and the long-context research below is the reason. Second, neither guide has a tier above guardrails. On a restaurant line that is fine. On a line where somebody might be describing a burning smell, a flat guardrails tier is the wrong shape, and no amount of prompt polish inside it fixes the ordering problem.

Why the ladder has to be spelled out

Write the precedence down because the model does not infer it. OpenAI's work on the instruction hierarchy starts from exactly this observation: models tend to treat instructions as equal priority regardless of where they came from, and the fix was to train an explicit hierarchy of system over user over third-party content. That hierarchy governs sources. Inside a single system prompt, nothing ranks your own rules against each other unless you do it in the text.

Three findings from the instruction-following literature bear directly on phone calls.

SysBench (Qin et al., 2024) built 500 system messages across six constraint types and named three failure modes: constraint violation, instruction misjudgement, and multi-turn instability. That third one is the phone-call problem. A call is many turns, and adherence to a constraint stated once at the top decays as the conversation lengthens.

DriftBench (Kruthof, 2026) found the dissociation worth pinning to the wall. Across 2,146 runs on seven models, constraint recall stayed near-perfect, meaning models could restate the rules they were given, while the rate at which they violated a rule they had just correctly restated ranged from 8% to 99% depending on the model. The paper calls it "knows-but-violates". Its domain is scientific ideation rather than voice, so treat the transfer as an argument rather than a measurement, but the practical consequence is not domain-specific: asking your agent what its rules are tells you nothing about whether it will follow them. Test the behaviour, as in the evaluation guide.

The operational answer to multi-turn decay is repetition at the point of use. A rule that must hold at the moment of a booking write belongs in the booking workflow as well as in the guardrails block, not only at the top of a prompt that was read forty turns ago.

Position still matters, and our own prompts disagree

Put the blocks that must not be missed at the start or the end. Liu et al.'s "Lost in the Middle" established the U-shaped curve that later work has reproduced and explained mechanistically: models attend most strongly to the beginning and end of a long input and least to the middle. A rule buried mid-prompt is the rule most likely to be skipped.

Our four prompts do not agree on where safety goes. In the electrician prompt SAFETY is the third block. In the dental prompt it is sixth. In the plumbing prompt it is the eleventh of twelve, immediately after the guardrails.

By the U-shape argument, the electrician placement is the strongest and the dental one is the weakest, sitting nearest the middle. The plumbing placement is defensible, since being near the end is the other strong position. Declared precedence does real work here, which is why all three behave correctly in testing, but the honest reading is that we got to the right answer three different ways and only one of them was deliberate. If you are writing a prompt today, put the safety tier first or last and say in the heading that it outranks everything.

Write rules as actions, not prohibitions

Phrase every rule as the thing you want said or done. Negation is a documented weak point: models are measurably worse at "do not X" than at "do Y", and Anthropic's own prompt engineering guidance advises telling the model what to do instead of what to avoid.

Vapi's guide goes further with a claim worth taking seriously, that verbose negative banlists "can prime the banned phrases as high-activation tokens". Treat that as vendor guidance rather than a measured result, but it matches the failure we see: a prompt with a long list of forbidden phrases produces an agent that reaches for them.

This creates real tension with a guardrails block, which is a refusal list by nature. The way out is to pair each refusal with the sentence you want instead.

# GUARDRAILS (these override everything above)
- Prices: say "I can't quote for that, but I'll get someone to call you with a
  price today." Never state, estimate or range a price.
- Diagnosis: say "I'm not able to advise on that, but I'll get an engineer to
  look." Never name a cause or a fix.
- Availability: say "Let me check the diary." Never promise a slot before the
  tool returns.

Each rule now has a positive default the model can reach for, and the prohibition is the second clause rather than the whole instruction.

The block that decides what the agent refuses

Give scope negation its own block. Deciding which calls the agent will not handle is a structural decision, not a footnote inside the guardrails, and all three of our trade prompts ended up giving it a dedicated section.

The three names are the three shapes the decision takes. NOT OUR JOB in the electrician prompt is a work-type filter: calls the business does not do at all, checked before anything gets booked. THE BOUNDARY in the dental prompt is a competence line: what the agent may say versus what only a clinician may say, and it sits before the response rules because it governs them. PRIORITY CALLERS in the plumbing prompt is the inverse, a list of callers who skip the normal flow entirely and go straight through.

The common property is that each one is checked before the task workflows run, not during them. A scope rule that fires after the agent has already started booking is a scope rule that arrives too late.

Every token reloads on every turn

Keep the prompt short because a voice agent re-sends the whole thing on every exchange, and the input tokens land directly on time-to-first-token. A prompt is not a document you pay for once. It is a per-turn cost on a channel where the caller hears the delay.

That changes what belongs in the prompt. Facts that change per call go in the CONTEXT block as short lines. Facts that are large, numerous, or change independently of the prompt belong in a knowledge base the agent queries, which is the trade-off worked through in the RAG guide. The full accounting of where response time actually goes is in the latency budget.

Vapi's turn budget guidance, roughly seven to nine turns for a complete call, is a useful constraint to design against. It forces the workflows in the prompt to be short paths rather than interview scripts.

How much of this changes by trade

The skeleton is shared. What fills it is not, and the four prompts on this blog exist to show that rather than describe it.

The restaurant prompt is the two-tier case, built around bookings, covers and a fully-booked path, with a homophone list for menu items. The plumbing prompt is built around triage rather than booking, with an on-call rota as a prerequisite and priority callers routed straight to dispatch. The dental prompt leads with a competence boundary and carries two separate escalation lists, because a dental emergency splits by where the patient should actually go. The electrician prompt carries the longest safety block of the four and a work-type filter that a plumbing prompt does not need.

Read the one nearest your trade and lift its shape, not its wording.

Before it answers a real caller

1. Every block heading that constrains another block states the precedence in the heading itself.
2. Runtime facts appear only in CONTEXT, with an explicit timezone on any date or time.
3. If a caller can be in danger, SAFETY exists, sits first or last, and outranks the guardrails in writing.
4. Scope negation has its own block and is checked before the task workflows.
5. Every guardrail carries the sentence to say instead, not only the thing to avoid.
6. Rules that must hold during a write are restated inside that workflow, not only at the top.
7. At least three example transcripts, including one recovery from a failed tool call.
8. No markdown, no bullet characters and no digit strings that the agent might read aloud verbatim, per the pronunciation guide.
9. The prompt has been tested by behaviour on live-shaped calls, never by asking the agent to recite its rules.

One question the skeleton does not answer is whether it should be one prompt at all. Retell documents single prompts, multi-prompt trees and conversation-flow agents as three separate architectures, and the choice is about determinism rather than prompt quality. A single prompt with a clear DECISION ORDER handles most SMB call shapes; reach for a flow when a branch must be guaranteed rather than likely.

And a prompt is not enough on its own, however well structured. It cannot enforce what it cannot check. Prices, availability and identity need a tool that returns the answer, which is the argument in the hallucination guardrails guide, and dates need resolving outside the model entirely, as in the relative dates guide.

If you would rather start from a prompt built for your trade than from a blank skeleton, see DeskCaller for plumbers.