Why did the wrong specialist answer?
Routing decisions are made by an LLM looking at each specialist’s Scope, any explicit routing topics, and any orchestrator-level rules. When it picks the wrong one, the cause is almost always one of three things.
1. The Scope text is too vague
This is the most common reason. The router can’t pick a specialist whose responsibility is “Customer help” — every conversation matches that.
Fix: open the specialist on the Orchestrator canvas, look at its Responsibility (Scope) text on the Setup sub-tab. Make it specific. Compare:
- ❌ “Customer help.”
- ⚠️ “Billing questions.”
- ✅ “Billing, invoices, refunds, subscription changes.”
- ✅✅ “Refund processing for orders within 30 days, plus subscription cancellations and upgrades.”
The more specific each Scope, the better the router does. See Define routing topics.
2. An orchestrator-level rule is biasing routing
The orchestrator config has a free-form text box where you (or someone before you) may have added rules like “For refund questions, prefer Billing” — those rules persist and apply to every conversation.
Fix: open the Orchestrator tab, click the orchestrator node (top of the canvas, not a specialist), read the routing rules in the slide-out. Look for rules that might be causing the misroute. Either edit the rule, or click Clear saved rules to fall back to the inherited (tenant or global) default.
3. The orchestrator re-routed mid-conversation
The router picks a specialist on turn 1. If the conversation drifts to a different topic, the orchestrator can re-route mid-conversation — and from the customer’s perspective it looks like the original specialist “answered the wrong question.”
Fix: check the conversation timeline. If the topic genuinely shifted, re-routing did the right thing. If the topic didn’t shift but the orchestrator thought it did, that’s a stall-detection or re-triage tuning issue — flag a turn from that conversation in the Tuning panel with feedback like “this conversation was about billing the whole time, not tech support.”
Less common causes
- The specialist is disabled. Open it and check the
enabledtoggle on Setup. - The catch-all is set on the wrong specialist. When no specialist matches confidently, routing falls back to the catch-all. If your catch-all is the Tech Specialist, every ambiguous message will appear to come from Tech.
- A tenant or global routing rule overrides the stack. The orchestrator panel shows “Inheriting routing rules from the tenant default” when no stack-level override exists. Add stack-level rules to take precedence.
How to confirm what happened
The Testing tab shows the routing decision for every reply — which specialist was picked, plus (for Super Admins) the reason and confidence. Open the original conversation in Monitor to see the same information for live conversations. If the decision says “Catch-all (no match),” that’s a Scope problem on the other specialists.