Routing Logic
Who does the work — AI or human?
Routing is the leverage decision. Once a task exists, it is executed via auto, assist, or escalate depending on cost-of-error and competence boundary. How the task came into existence — manual create, AI auto-create, or AI proposed-then-approved — is a separate dimension, covered in §7.1.
6.1 The three tiers
AI handles the task end-to-end. No human gate after creation.
Use when: task is mechanical, has structured inputs, has a known correct answer, and cost of error is low.
v1 caveat: routing tier "auto" describes post-canonical execution. The pre-canonical approval gate is phased separately — see §7.1 Stage 3. Auto-tier tasks still need a human approval click at creation in v1.
AI proposes the action; a human reviews and approves before execution.
Use when: task has ambiguity, decision affects client perception, has financial commitment, or touches relationship trust.
Immediate human attention required.
Use when: time-sensitive, high-stakes (VVIP / >$X booking / safety), or AI confidence below a threshold.
6.2 Where AI is competent (rule of thumb)
- • Detection of known patterns (deal thresholds, expiring documents, departing trips)
- • Drafting templated communications (confirmations, polite follow-ups, reminders)
- • Mechanical lookups (find a hotel rate, check award availability)
- • Status updates (mark a task done when a confirmation arrives)
- • Pattern matching against historical context (a similar issue happened before; here's how we handled it)
6.3 Where humans are essential
- • Phone calls to suppliers — especially relationship-leverage moments (asking for an upgrade, securing a sold-out room)
- • Client-facing communication during conflict, complaint, disappointment, or loss
- • Financial decisions: committing > $X without explicit client approval
- • Relationship moments — birthdays, anniversaries, condolences. The TA's voice matters; the AI's doesn't.
- • Judgment calls where two valid options exist and the answer depends on the client's taste
6.4 Suggested default routing per origin bucket
A starting point for the alignment meeting — not locked. Expect pushback on several of these.
| Origin bucket | Suggested default | Rationale |
|---|---|---|
| Client-driven (explicit) | Assist | AI drafts the response; human approves the tone |
| Client-driven (implicit) | Assist | Misreading the client is expensive; human nuance needed |
| World-driven (compliance) | Auto | Mechanical detection, mechanical reminder |
| World-driven (disruption) | Escalate | Time-sensitive, client-facing, often a relationship moment |
| World-driven (vendor change) | Assist | Auto detect → Assist action. Detection is mechanical; the response (re-shop, re-quote) needs judgement |
| World-driven (loyalty) | Assist | Auto detect → Assist action. Detection auto; booking commitment human |
| Trip lifecycle (templated prep) | Auto | Pre-arrival checklists are routine |
| Trip lifecycle (client comms) | Assist | TA voice on every client-facing send |
| Relationship | Escalate | The whole point is the human voice |
| Internal ops | Auto | Self-monitoring is automation territory |
6.5 Mental model — analogy per origin
The 4-stage creation flow (Signal → Suggestion → Approval gate → Canonical task, §7.1) is the same everywhere. But how operators think about the flow varies by origin bucket — different mental models fit different work shapes. We use both deliberately.
Like a code pull request: AI drafts a proposed task; a human reviews the diff (rationale + evidence + proposed fields), edits if needed, approves or rejects. The proposal is persistent — it waits for review without time pressure. Closure is reviewed-then-merged.
Suits Client-driven and Relationship work because: tone matters, judgment matters, the suggestion is essentially a draft response that benefits from explicit review.
Like an on-call alert: a signal fires, the system creates or proposes an incident, operators acknowledge and respond. Time-sensitive (some suggestions expire if not acted on quickly). Correlated signals are grouped into a single incident-task (3 messages + 1 vendor email about the same hotel issue = one task, not 4). Escalation policies route to on-call.
Suits World-driven / Lifecycle / Internal ops because: time matters, signals can correlate, and operators need to triage by urgency rather than review in order.
Why both. Forcing PR-review semantics onto a typhoon alert produces dead suggestions that didn't make it through review in time. Forcing incident semantics onto a relationship-bucket task produces auto-resolution where the TA's voice was needed. The analogy that fits the work-shape produces better defaults; the doc uses each where it earns its keep.
Worked end-to-end examples of both analogies in action are in Appendix E.