Open Doors: Designing AI Engagement Tools for an Unpredictable World

Abstract

An AI agent built to book spa treatments took a fire alarm call and sent it to the people who could act on it. Nobody wrote a rule for that call, and nobody could have. This paper uses that single interaction (a real call to a resort spa's voice agent) to argue for a design discipline we call open escalation: agents whose scope tells them where to focus, while their escalation paths and fallback prompts tell them what to do when the world ignores that scope.

The argument is simple. Real callers bring problems the build team never imagined. A rule set tight enough to prevent every mistake will also prevent the agent from doing the right thing in the moments that matter most. A layered design works better. It pairs a clear center of gravity with explicit routes out and a default for the unknown that leans toward getting a human involved.

---

The call

The caller reached the spa's virtual receptionist and asked for a real person. They reported a fire alarm at the resort's lodge, said authorities had already been notified, and wanted to confirm that the person in charge at the lodge knew about the dispatch.

The agent recognized a lodge safety matter, not a spa matter, and transferred the caller straight to the lodge team. No booking was attempted. No spa questions were asked first.

Element	What happened
Agent's designed job	Spa concierge: treatment questions, booking links, callback intake
What the caller brought	A fire alarm at a different building on the same property
Caller's real need	Make sure the responsible person at the lodge was in the loop
Agent's move	Identified it as a lodge safety issue and routed to the lodge team
Result	The caller reached people who could act, with no detour through spa intake

The spa agent was built as an intake and concierge tool. It has no booking system access, and its brief centers on treatments, not on alarms in other buildings. It still produced the right outcome because its design left a door open.

---

The counterfactual

Picture the same call reaching an agent built on hard scope rules. Its prompt says something like "You only discuss spa services. For anything else, say you can only help with spa questions." That rule looks responsible in a design review. It keeps the agent on brand and stops it from inventing answers about places it knows nothing about.

On this call, that rule produces one of three outcomes, all bad.

1. The polite wall. "I'm sorry, I can only help with spa services." The caller hangs up and dials again, losing minutes during an active alarm.
2. The forced fit. The agent tries to turn the call into its own workflow and offers callback intake. A safety message sits in a queue until someone checks it.
3. The confident guess. The agent, told never to transfer outside the spa, improvises reassurance about a building it cannot see.

None of these is a malfunction. Each is the agent doing exactly what it was told. The failure belongs to the design, and it stays invisible until the one call that exposes it.

---

Why rigid rules fail

Build teams write rules from the calls they expect. Callers bring the calls they have. On any line that is public, those two sets never match.

A resort phone line is a good example. The spa number sits on a property with a lodge, restaurants, trails, a front desk and a security team. Guests do not know which number belongs to which department, and in a stressful moment they dial whatever number they saw last. The agent behind that number becomes a front door for the whole property, whether its builders planned for that or not.

Three forces make the long tail of odd calls permanent.

• Callers route by proximity, not by org chart. They call the number they have, then ask for what they need.
• The rare calls carry the highest stakes. Safety, medical, legal and urgent guest issues are uncommon by volume and costly when mishandled.
• Rules multiply but never close the gap. Every new exception added to a prompt narrows the next unknown without removing it.

The better model treats scope as a center of gravity. Scope tells the agent what it is good at and where to spend its effort. It does not tell the agent to refuse everything outside that circle. A fence keeps the agent in. A center of gravity pulls it home after it has helped the caller get where they need to go.

---

Principle one: open escalation

Escalation should be a planned outcome with real destinations, never a failure state the agent avoids. On the spa call the agent had somewhere to send the caller, and it treated sending them there as success.

Open escalation has four parts.

1. Named destinations. The agent knows the humans and teams it can reach (front desk, lodge team, security, a manager line) and what each one handles. A transfer tool with no map of who sits behind it is half a tool.
2. Intent over keywords. The trigger is the caller's need, judged in context. "Fire alarm" is easy to catch. "Something smells like smoke near the pool" or "my mother fell in the parking lot" are not, and a keyword list will miss them.
3. Permission to leave scope. The prompt says plainly that helping a caller reach the right team counts as doing the job well, even when the subject has nothing to do with the agent's own venue.
4. Speed proportional to stakes. Routine off-topic requests get a friendly redirect. Safety and urgent matters skip intake and go straight to a person.

The tool description matters as much as the prompt. Agents decide whether to call a tool largely from how that tool describes itself. A transfer tool described as "for spa booking questions only" will not fire on a fire alarm, whatever the prompt says elsewhere.

---

Principle two: fallback prompting

Fallback prompting gives the agent a default for the call nobody wrote down. Instead of one rule ("stay in scope"), the agent works through a short ladder of questions, and every rung ends with a person or a plan.

The order of the rungs is the design decision that matters most.

• Risk comes first. A safety question is asked before a scope question, so an urgent call never waits behind intake. On the spa call this is the rung that fired.
• Scope comes second. Most calls land here, and the agent does its normal job well.
• Routing comes third. For off-topic but ordinary requests, the agent names the right team and offers to connect, so the caller leaves with a path instead of a refusal.
• The honest default comes last. When the agent has no route, it takes the details and tells the caller plainly what will happen next and when. It never promises a callback it cannot guarantee.

A ladder like this is short enough to live in a prompt and general enough to cover calls nobody has seen yet. It replaces a growing list of special cases with one ordered habit.

---

Guardrails that bend

Open escalation has real failure modes, and a fair design admits them. An agent with permission to leave scope can leave it too often, transfer too eagerly, or treat every raised voice as an emergency. The goal is guardrails that shape judgment without replacing it.

Risk	What it looks like	Guardrail that bends
Over-escalation	Routine questions get transferred, and staff lines fill with calls the agent could have handled	Transfer by default only on the risk rung; on the routing rung, offer first and connect on a yes
False urgency	Callers learn that saying "emergency" skips the queue	Judge the described situation, not the word; a stated emergency with no safety content gets routed, not rushed
Scope creep	The agent starts answering for departments it knows nothing about	Route to the team instead of answering for it; the agent connects, the team decides
Dead-end transfers	The destination line goes unanswered after hours	Keep destinations time-aware, and name a backup line for each one
Silent failure	Nobody notices the odd calls, good or bad	Tag off-scope and escalated calls in post-call data and review them on a schedule

Notice the pattern in the right column. Each guardrail narrows how the agent escalates, never whether it can. The door stays open, and the hinges get tuned.

---

Design checklist

Use this list when building or reviewing any customer-facing agent, voice or chat.

• The prompt describes scope as a focus area, and says plainly that helping a caller reach the right team is part of the job.
• A safety check runs before any intake or qualification questions.
• Every transfer destination has a name, a purpose, hours, and a backup line.
• Transfer tool descriptions state when to fire in terms of caller need, not department name.
• Urgent routing skips intake; routine routing offers first and connects on a yes.
• The agent has an honest default for calls with no route, and it never promises what the team cannot deliver.
• Test suites include calls that belong to a neighbor department, a safety event, and a request nobody planned for.
• Post-call data flags escalations and off-scope calls, and someone reviews them on a fixed schedule.
• Each odd call that goes well or badly feeds back into destinations and tool descriptions, not into a longer list of refusals.

---

Conclusion

A spa receptionist that handled a fire alarm well is a small story with a large lesson. What made the difference was permission to put the caller's need ahead of the agent's own job description, plus a route to the people who could help. A fire protocol was never part of it.

The world will keep sending AI agents calls their builders never pictured. Teams can respond by writing more rules, each one closing a door. Or they can design agents with a clear center, open exits, and an honest default, so the next unexpected call ends the way the spa call did: with the caller connected to someone who could act.

---

Header photograph by Alfo Medeiros on Pexels.