Why did the wrong specialist answer?
Routing decisions are made by an LLM looking at each specialist’s Responsibility, its routing topics (generated from that same text when the specialist was added), 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 runs on every turn, not just the first — it invokes exactly one specialist per turn. So if the conversation drifts to a different topic, a later turn can land on a different specialist, 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 is a prompt problem, not a setting: flag the turn in the Tuning panel with feedback like “this conversation was about billing the whole time, not tech support,” or sharpen the two specialists’ Responsibility texts so they stop overlapping.
Less common causes
- The specialist is disabled. A disabled specialist is dimmed on the Orchestrator canvas and carries an “off” badge (the hover card and the slide-over header spell it “Disabled”). There is no toggle in the app to flip it back — that is an API change.
- On a voice stack, the catch-all answered. A spoken turn the router didn’t decide goes to the stack’s catch-all specialist. If your catch-all is the Tech Specialist, every undecided call turn will appear to come from Tech. Chat has no such fallback — there the orchestrator answers directly instead.
- A tenant or global routing rule is in effect. The orchestrator panel shows “Inheriting routing rules from the tenant default” when no stack-level override exists. Saving stack-level rules replaces the inherited text rather than adding to it.
How to confirm what happened
The routing decision — the specialist picked, its confidence and the router’s one-clause reason — lives in the debug panel under each AI reply, and that panel renders only for Super Admins. In the Testing tab it appears automatically for them; on a live conversation (from Monitor or the inbox) a Super Admin must also switch debug on from the command palette (“Debug: On”). Without that role there is no in-app view of the routing decision.