How to Change What Your Voice Agent Says During an Outage

To change what a voice agent says during an outage without a dev project, build a slot for the message into the agent once, then change the value of that slot when something happens, so the update is a configuration edit with a one-move rollback instead of a release. How fast your operations team can make that edit safely is what buyers call content agility, and it belongs on any voice AI evaluation list.

This article covers outages, launches, and service updates on your side. If you want to know how Retell keeps its own platform running, that is covered in how Retell handles outages and uptime.

Why does outage messaging matter more with a voice agent?

Because a voice agent will answer every call with its current configuration until someone changes it. A human team gets a briefing at the start of a shift. An agent gets whatever its prompt and opening message say.

When a billing portal goes down or a delivery partner misses a day, callers want three things: confirmation that you know, what they can do now, and when to check back. If the agent cannot say that, every caller explains the problem from scratch, asks for a person, and adds load to the queue you were trying to protect.

What should your team be able to change without a release?

Four things cover most incidents and launches:

• The opening message, so callers hear the notice before they explain anything.
• A notice the agent can discuss mid-call, so it can answer "is it fixed yet?" consistently.
• Where transfers go, so escalations can reach an overflow team.
• Reference facts for a launch or policy change, such as new plan details or holiday hours.

In Retell, dynamic variables work in all of these places: the opening message, agent prompts, Conversation Flow static sentences, transfer destination numbers, and SMS text. That is what makes a no-release change possible.

How do you set up an agent so a notice can be switched on in one change?

Do this once, before you need it.

Add a notice variable. Put {{service_notice}} in the custom welcome message, for example: "Thanks for calling. {{service_notice}} How can I help today?" Add a matching line to the prompt, such as "Current service notice: {{service_notice}}. If it is not empty, mention it once near the start and answer questions about it using only this text."

Give it an empty default. In Retell, a variable with no value stays in the message as raw {{service_notice}} text, while an empty string replaces it with nothing. Set an agent-level default of "" under Security & fallback settings so the agent reads normally on an ordinary day.

Point production numbers at the prod tag. Retell environment tags are names that point to an agent version, and phone numbers assigned to a tag follow it. Numbers assigned directly to a version stay on that version, so check every production number now.

Test the notice path. Retell simulation test cases let you preset dynamic variables. Keep one test case with a sample notice filled in and confirm the agent reads it and still completes the call.

How do you switch the message on during an outage?

Set the notice on the tag, not in the agent. In the agent header, open Environment, then Configure Tags, choose prod, and set service_notice to your approved text. Retell supplies tag values when a call uses the tag, and tag values take precedence over agent defaults. Before you rely on this in an outage, place a test call to confirm the new value is picked up on the next call.

The same pattern handles routing. If your transfer destination is a variable, set it on the tag to send escalations to an overflow line, then set it back afterward.

For calls already in progress, a developer can use Retell's Update Live Call API, which overrides dynamic variables on an ongoing call and takes effect immediately.

To roll back, clear the value on the tag. The empty agent default applies again on the next call.

When should a change be a new version instead?

When you are changing behavior, not just words. A product launch that adds new questions, a new tool, or a different call path is a version change.

The Retell flow:

1. Create a draft from the version prod points to. Drafts are editable copies that do not touch the source.
2. Edit and test it with a test call or your simulation test cases.
3. Open the version comparison from the publish dialog. The semantic diff lists every changed field and highlights the exact words added or removed in long text.
4. Publish, which makes the version read-only, then move the prod tag to it.

To roll back, move prod back to the previous version. Numbers on the tag follow it.

Can your own systems trigger the message automatically?

Yes, if you build it once. Retell's inbound call webhook is set per phone number and calls your endpoint when a call arrives. Your response can set dynamic variables, or override the opening message and the linked knowledge bases, for that call only. Overrides do not persist to the saved agent.

That means an incident flag in your own status tooling can decide what callers hear, with no dashboard edit during the incident. Keep a default inbound agent on the number: if your endpoint fails all three attempts, Retell tries to connect the call to that agent, and without one it disconnects the call.

Where does the knowledge base fit?

Use it for launch and service-update details, not for live incident status. A knowledge base suits facts the agent looks up, such as plan details or a list of affected regions, and Retell's docs recommend keeping instructions in the prompt rather than the knowledge base.

Two cautions. URL and synced-document sources auto-refresh every 24 hours, which is too slow for a status that changes hourly. And knowledge bases are linked to agents as separate objects, so check which agents use one before adding a temporary notice to it. For structure, see how to structure a voice AI knowledge base.

What does a good outage message playbook look like?

Write and approve these before an incident, then fill in the brackets on the day.

Keep each notice to one or two short sentences. Say what is affected and what the caller can do. Give a restore time only if engineering has confirmed it.

Who should be allowed to change it, and how do you know it worked?

Limit edit rights by role. Retell's access control lets Admin and Developer roles edit agents and knowledge bases, while the Member role is read-only. Retell's docs do not describe an approval step inside the product, so put the approver for each trigger in your incident runbook, as in the table above.

Then check the result. Live Monitoring lets a supervisor listen in on calls in progress, so you can hear the first few callers get the notice. Retell alert rules can email or call a webhook when success rate drops or API errors rise, which helps with both spotting an incident and confirming recovery. Add the notice to your voice agent QA scorecard for the incident review.

What should you ask a voice AI vendor about content agility?

Ask them to show each of these live, not describe them:

• Can a non-engineer change the opening message and a mid-call notice without a release?
• Do production numbers follow a pointer, so publish and rollback are each one move?
• Can you test a change against saved scenarios before callers hear it?
• Can you see a word-level diff of what changed between versions?
• Can your own systems set the message per call from an incident flag?
• Can you update calls that are already in progress?
• Which roles can edit, and which are read-only?

Then time the loop yourself during the pilot. Our guide to evaluating a voice agent platform before go-live covers the rest of that test.

Retell gives contact center teams versioned agents, environment tags, per-tag variables, and per-call overrides, so the people running the queue can change what callers hear and undo it in one move. See how it fits your operation on the Retell enterprise platform page.