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), the Knowledge categories available to that specialist, and any orchestrator-level rules. When it picks the wrong one, the cause is almost always one of four 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. The right specialist does not have access to the right Knowledge
Knowledge access is also a routing signal. If two specialists have similar Responsibility text, the router may prefer the one whose available Knowledge looks more relevant to the customer’s question.
Fix: open the specialist on the Orchestrator canvas, go to the Knowledge sub-tab, and confirm that the relevant KB category or subcategory is available to that specialist. Compare specialists that overlap: the one with full Knowledge access can answer from the whole KB, while a restricted specialist may be a poorer route for an answer outside its assigned categories.
If the specialist should handle that topic, either give it access to the relevant Knowledge category or subcategory, or sharpen the Responsibility text so the router understands when to choose it.
3. 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.
4. The orchestrator re-routed mid-conversation
The router runs on every turn, not just the first — by default it invokes 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 Off. An Off specialist stays visible on the Orchestrator canvas with an Off badge, but the router skips it. To turn it back on, open the specialist, go to the Setup sub-tab, and switch Active on. A stack must always keep at least one active specialist.
- 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.