The Orchestrator
The orchestrator is the front door of an Agent Stack. There is no separate router: on every customer turn the orchestrator reads the message together with the conversation so far, decides which specialist owns the topic, and hands the question to it. The specialist’s reply comes back to the orchestrator, which returns its substance to the customer.
You can think of it as the person on the desk who knows who does what, except it never gets tired and it makes the same call every time.
What it actually does
It runs once per customer turn, and it has exactly three moves:
- Invoke a specialist — The default. It picks the one specialist whose scope covers the message and passes it the question plus the details the customer already gave (country, product, order or serial number). One specialist per turn.
- Hand over to a human — The orchestrator’s escalation move — a specialist cannot transfer anyone itself, though it can ask for a handover with its own
request_handovertool, which the platform then runs through the same flow. Available only when handover is enabled for the stack. - Reply directly — Reserved for greetings, social pleasantries, asking what the customer needs, and out-of-scope deflection. Substantive questions must go to a specialist.
Because it re-decides every turn, a topic that shifts mid-conversation moves to the specialist that now fits — see Re-routing without the customer noticing below.
What you can configure
From the Orchestrator tab, click the orchestrator node on the canvas. The slide-out lets you append routing rules to the built-in default prompt — anything you write here augments the defaults; the built-in actions and core rules always stay in effect. Use it for team-specific guardrails like:
- “For refund questions, prefer the Billing specialist over the Tech specialist.”
- “If the customer mentions delivery delays of more than 14 days, hand off immediately.”
- “Always confirm the customer’s order ID before responding about an order.”
Clear saved rules drops your override and falls back to the inherited default (tenant or global), and {{TENANT_NAME}} is replaced at runtime with your team’s name.
These routing rules are the only orchestrator setting a stack owns. The model the orchestrator runs on is set by Atender per feature, not per stack, and there is no check interval or stall threshold to tune. Whether and where the stack hands over is set on the Handover tab.
When it escalates
Escalation is a decision the orchestrator makes in the moment, from the rules in its prompt, not a background risk score. A bare “I want a human” with no stated problem is not enough on its own — it asks what the customer needs first. Once the issue is known it attempts help, and escalates after a help attempt, when the request is business-adjacent but unsupported by the AI or specialists, when the customer is hostile or abusive after two attempts, or when your own handover policy says so.
Unrelated or off-topic messages are handled differently. Jokes, small talk, trivia, role-play, personal advice, and other non-business chat are redirected by the orchestrator, not handed over to a human. On Web Chat and email, repeated off-topic drift can also cause the conversation to be automatically archived. If the same sender repeatedly triggers email archives, they may temporarily receive no further AI email replies, while their messages remain visible to the human team.
On stacks where handover mode is never, the orchestrator keeps the AI engaged and must not offer human transfers; switching between specialists remains silent internal routing.
Re-routing without the customer noticing
If the orchestrator sent the first message to the Billing specialist but the customer’s next question is about returns, the following turn goes to the Returns specialist instead. The customer doesn’t see the change — specialists are internal, so the orchestrator is told never to ask permission to switch or to “connect” the customer to one. This is what stops a single mis-routing decision from turning into a long, frustrating thread with the wrong agent.
What a handover actually does
There is one handover flow, not two styles. When the orchestrator calls the tool it passes an internal reason, one sentence on what it already tried, and a one-paragraph summary written for the teammate, and routes the conversation to a team. The conversation is then queued in the same thread — the customer keeps typing where they are, and a colleague picks it up when one is free.
Whether the customer is asked first depends on the stack’s Ask the customer to confirm before handing over checkbox on the Handover tab. With it off (the default) the transfer commits the moment the tool succeeds — unless Check opening hours before handing over finds the team closed or a handover prerequisite is still missing — and the AI’s reply states it as done. With it on, the platform asks first: on Web Chat it puts its own question under the AI’s answer (with any transfer claim taken out) and adds Yes, transfer me / Not yet chips, and on other channels it asks the question in text and the customer answers in free words.
Either way it is a queue, not a live transfer. The AI must never promise “one moment,” “connecting you now,” or any time frame.