Fallback
Fallback controls what your bot does when it can't handle a request - a question that's clearly out of scope, gibberish it can't parse, or input that fails validation one too many times. Because fallback lives under Configuration, it's a project-level setting: the recovery behaviour you define here applies to all your agents, both conversational and guided.
A good fallback turns a dead end into a next step. A bad one - the default apology string - leaves the customer stuck and reaching for a human.
Step 1: Open the Fallback page
In your bot, click AI Agent → Configuration, then open Fallback (under Agents in the left menu).
This sub-page has two controls:
- Next steps after failure - how the bot recovers when it can't answer.
- Retries for information validation failures - how many times to re-ask when a user's input doesn't validate.
Step 2: Write the fallback instruction (Instruct mode)
In Nexus, fallback uses Instruct - a prompt fragment you write that defines how to recover when a request can't be handled. Instead of returning a fixed apology, the bot uses your instruction to compose a helpful, in-context response that offers the user a real way forward.
Write the instruction the way you'd brief a support agent on what to do when they're stuck:
You couldn't handle the user's request. Apologise briefly, then offer
concrete next steps: ask them to rephrase, point them to the FAQ, or offer
to connect them to a human via the Escalate-to-Agent tool. Never invent an
answer. Keep it to two short sentences.
Tip -
@-mentions. Type@in the Instructions editor to insert a live reference to an agent, workflow, or tool - for example@escalate-to-agentso the model knows exactly how to hand off. The chip stays linked to the target's slug, so it won't break if the target is renamed.
Step 3: Set retries for validation failures
Below the instruction, set Retries for information validation failures - how many times the bot re-asks the user when their input doesn't pass validation (for example, an order ID in the wrong format, or an unparseable date). The default is 3.
Once the retry budget is exhausted, the bot stops re-prompting and falls back to the Instruct behaviour above - so the two controls work together: retries handle the recoverable case (the user just needs to try again), and the instruction handles the give-up gracefully case.
| Control | What it does | Default |
|---|---|---|
| Next steps after failure (Instruct) | Prompt that defines how the bot recovers when it can't handle a request | - |
| Retries for information validation failures | How many times to re-ask when input doesn't validate before falling back | 3 |
Best practices
- Don't leave fallback as the default apology string. Use the instruction to offer concrete next steps - rephrase the question, browse FAQs, or escalate to a human via the Escalate-to-Agent tool.
- Always give the customer somewhere to land. Pair the instruction with an explicit handoff path so a stuck user is never left at a dead end. This matters most in regulated industries (finance, healthcare), where the safe fallback is often a human.
- Keep retries low. Re-asking more than 3 times reads as nagging; if a user can't pass validation after a few tries, falling back to a human is usually kinder than another retry.
- Test it. Send obvious gibberish and questions clearly outside scope to confirm the fallback fires the way you expect. Run these checks in the Testing Lab before each release.
Next: Conversation rules - the always do / never do guidelines applied to every reply.