Every dynamic variable in voice agent needs a fallback.

Follow me on LinkedIn - AI, GA4, BigQuery

I added a small section to a voice agent prompt last week. It looks like this.

## CRITICAL: Variable Failure Handling
Some lines in your context contain values wrapped in double curly braces 
(like {{example}}). These are dynamic variables that should be replaced 
with real data at runtime.
Before using any value, check it. If the value still contains curly 
braces ({{ or }}) or looks like a variable name (lowercase words 
connected with underscores), the variable FAILED to resolve. Treat that 
piece of information as UNAVAILABLE.
When information is UNAVAILABLE:
- NEVER say the variable name, the curly braces, or any part of the 
  unresolved placeholder out loud.
- NEVER mention that a variable failed or that there's a technical issue.
- Instead, respond as if you simply don't have that specific piece of 
  information to hand.
Default fallback responses when information is UNAVAILABLE:
- For time/date questions → "Could you remind me what time it is on 
  your end? Just want to make sure I note things accurately."
- For appointment/booking questions → "The team'll confirm that on 
  callback. What's the best number to reach you on?"
- For account/billing questions → "The team'll go through that with 
  you on callback."
- For any other personalised question → "The team'll confirm those 
  details on callback."
After delivering the fallback, continue with the next uncollected 
field. Do not return to the failed question.

The section sits in the prompt of an agent that uses several dynamic variables:

Current date and time.
The caller's next appointment.
The caller's account balance.

The agent's context looks something like this:

## Caller Context
Current date and time: {{currenttime}}
Caller's next appointment: {{next_appointment}}
Caller's account balance: {{account_balance}}

Each variable resolves at runtime to a real value. Usually.

Sometimes, for reasons that aren't always obvious, a variable doesn't resolve. The placeholder stays in the prompt as a literal string. The agent reads it as part of the prompt text and tries to act on it.

Without the fallback logic, the voice agent does one of three things. None of them is good.

The first failure mode is reading the placeholder literally.

The agent reads the variable name.
The caller hears something obviously broken.

The second failure mode is hallucinating a plausible-sounding value.

"Your current balance is one hundred and fifty dollars." This is worse than the literal reading, even though it sounds correct.
The caller might believe it. The caller might act on it. The agent has no idea whether that number is correct, but it confidently produces it.

The third failure mode is stalling or rambling.

The agent tries to make sense of the broken context, hesitates, repeats itself, and the call quality drops.
The caller notices something is off, but can't say what.

With the fallback logic, the agent recognises the broken pattern and pivots. "Could you remind me what time it is on your end? Just want to make sure I note things accurately." Or "The team'll go through your account balance with you on callback."

The call continues. The caller never knows anything broke.

What are dynamic variables and why do they fail?

Voice agent platforms like Retell let you embed dynamic variables in your prompt. At runtime, the platform replaces these variables with real values.

The standard syntax is two curly braces around a variable name.

The platform reads the prompt, finds the variables, substitutes the values, and passes the resolved text to the language model.

Substitution can fail for several reasons:

The variable name might be misspelt.
The variable might not be configured in the agent's settings.
The platform's variable resolver might be temporarily unavailable.
The value the variable points to might not exist for this particular call.
The version of the platform's runtime might have changed in a way that breaks specific variables.

When substitution fails, the variable name stays in the prompt. The language model treats them as regular text, to be read aloud, interpreted literally, or used as inspiration for a hallucinated value.

This is the worst possible failure mode.

The agent doesn't refuse to respond. It doesn't throw an error. It just confidently produces something wrong, and the caller has no way to tell.

The fallback handling does three things.

First, it gives the agent a recognisable pattern to look for.

Curly braces and underscore-connected lowercase strings are easy patterns to detect in text. The agent can identify these patterns without being told which specific variables might fail.

Second, it tells the agent what NOT to say.

"Never say the variable name, the curly braces, or any part of the unresolved placeholder out loud" is explicit.

Without this prohibition, the agent's natural instinct is to acknowledge the broken value in some way, thereby revealing the failure to the caller.

Third, it gives category-based fallbacks rather than variable-specific ones.

Time questions get one kind of response.
Appointment questions get another.
Account questions get another.
Any other personalised question gets a generic deflection.

This means the rule scales.

Adding new variables doesn't require adding new fallback rules, because they fit into existing categories.

A real caller hearing any of these fallbacks would notice nothing unusual. The responses sound like normal customer service.

"Could you remind me what time it is on your end?" sounds like a receptionist double-checking.
"The team will go through that on callback" sounds like a standard deferral.

The fallback is invisible to callers and visible to developers, which is exactly the right inversion.

Define one set of rules that handles any failed variable.

I used to write fallback rules for each variable separately.

Time variable failed? Here's the time fallback.

Appointment variable failed? Here's the appointment fallback.

Account variable failed? Here's the account fallback.

This works, but doesn't scale. Every new variable means a new rule. The prompt grows. Maintenance gets harder.

Some variables get fallbacks, others don't, and you can't always tell which is which.

The general approach is to define a single set of rules that handles any failed variable, organised by question category rather than by specific variables. Three or four category fallbacks cover most realistic cases. New variables get added to the context section without needing rule changes.

The token cost of the general approach is roughly fixed regardless of how many variables you have.

Adding a new variable costs one line in the context section. The failure handling rules stay the same.

Every dynamic variable in a production prompt is a potential failure point.

The substitution is silent when it works and silent when it fails. The agent has no built-in way to know whether the value it's reading is a real value or a literal placeholder.

The fallback pattern fixes this.

For every category of dynamic data your agent uses, include short instructions telling the agent what to do if the variables in that category don't resolve.

Use deflections that match the prompt's existing tone. Tell the agent to never read placeholders aloud. Tell the agent what to never say, not just what to say.

Most prompts I review don't have fallbacks for dynamic variables.

The assumption is that the platform will always resolve them correctly. When the platform fails, the agent fails publicly to the caller.

Sometimes it reads gibberish. Sometimes it hallucinates plausible-sounding wrong information. Sometimes the caller believes the hallucination and acts on it.

Defensive prompting is the discipline of writing prompts that degrade gracefully when something underneath them breaks. Dynamic variable fallbacks are one part of this.

The same principle applies to webhook timeouts, function call failures, knowledge base lookups, and any other runtime dependency that might silently fail.

Every place your prompt assumes a runtime value, ask yourself what happens if that value isn't there.

If the answer is "the agent reads a placeholder aloud," you need a fallback.
If the answer is "the agent invents a value that sounds plausible," you definitely need a fallback.
If the answer is "the agent stalls and the call quality drops," you need a fallback.