Tune routing without creating chaos

Continuity before cleverness

The best route is often “stay where you are”

Visitors answer in fragments: “Tuesday,” “the afternoon one,” “yes, that email,” or “actually use my mobile.” A router that treats each fragment as a new topic feels broken. SmartSite combines the active specialist, the newest message, explicit handoffs, scope, confidence, and your routing policy to preserve context while still allowing real topic changes.

Three movements that look similar in a log

Route, stay, and handoff
Event	When it happens	What it means	How it is counted
Route decision	Before the agent run starts for the newest visitor turn.	The runtime chooses Base or a specialist as the best owner for that turn, based on policy and the routing model.	Appears under Route Decisions and increases the route count. It does not increase handoffs.
Stay with current specialist	The newest message is a follow-up, correction, confirmation, missing detail, or still clearly within the active scope.	Ownership remains stable so context is not lost.	May be recorded as a route/stay decision; no handoff occurs.
Runtime handoff	A running agent invokes an available handoff because another owner should take over.	The receiving agent continues within the same run using its own instructions and tools.	Increases the handoff count and appears as a handoff event in the timeline.

This explains a common analytics result:

1 route / 0 handoffs / 0 tools
Active route: Appointments Agent -> De-escalation Agent
Workflow started: De-escalation Agent

The runtime selected De-escalation before starting the agent run. It routed from the prior conversational owner to the new one, then started De-escalation directly. Because Appointments did not start and invoke a handoff during that run, handoffs remains zero. The visible behavior can be correct even though the accounting categories differ.

Entry routing: who may receive the conversation first

Base Assistant is the general owner. Enabled handoffs from Base Assistant → specialist create explicit entry targets. If no explicit Base entries exist, all configured specialists can become generated entry targets based on their scope. Flow Checks labels that as generated activation so admins know the routing boundary comes from descriptions rather than a dedicated condition.

The Start Agent Workflow Basics field is separate. Choosing Auto / first agent lets the workflow use its normal entry design. Selecting a specialist intentionally makes that specialist the configured start. Use a fixed start only when the workflow itself is dedicated to one journey. A mixed public website usually benefits from Base handling broad questions and routing only clear specialist intentions.

Routing Mode: how much policy you want to control

Open Workflow Settings → Routing Policy.

Routing modes
Mode	What the interface does	Choose it when
Automatic	Uses SmartSite’s built-in defaults: Balanced stickiness, Medium confidence, automatic uncertainty handling, direct specialist switching on, and return to Base on.	You want sensible flexible routing and do not have evidence that a stricter policy is needed. This is the lowest-maintenance starting point.
Guided	Exposes Stickiness, Switch Confidence, and Return to Base Assistant.	Most production sites that need stronger continuity or a deliberate Base-return decision without tuning every control.
Advanced	Adds Uncertainty Fallback and Direct specialist switching to the Guided controls, plus the compiled Policy Summary.	Structured or carefully evaluated workflows where the team understands the consequences of restricting movement.

Changing from Guided or Advanced back to Automatic restores the built-in policy behavior at runtime. It does not delete agents or handoffs.

Stickiness: how strongly to prefer the current specialist

Stickiness choices
Setting	Practical behavior	Good fit	Risk
Balanced	Normal follow-ups stay, but clear topic changes can move.	General support, sales, and mixed-purpose sites.	Very short ambiguous topic changes may stay with the current owner—which is usually safer than bouncing.
Sticky	Prefers continuity and requires stronger evidence before switching.	Appointment intake, quote building, case triage, and multi-step detail collection.	A genuine new topic may take clearer wording or an explicit handoff.
Locked	Requires very strong evidence before implicit switching.	Highly structured processes where one specialist should normally finish its task.	Without explicit exits, the visitor can feel trapped with the wrong role. Flow Checks warns when a specialist has no policy escape path.

Stickiness adds to the switch threshold. It does not absolutely prohibit a configured explicit handoff. Think of it as resistance to generic model-driven switching, not a replacement for route design.

Switch Confidence: how certain a change must be

Low, Medium, and High represent increasing evidence required before switching. SmartSite internally combines this choice with Stickiness:

Effective switch thresholds
Switch Confidence	Balanced	Sticky	Locked
Low	38%	46%	54%
Medium	55%	63%	71%
High	72%	80%	88%

These percentages are routing thresholds, not guarantees that a classification is objectively correct. A model’s confidence is not the same as a measured probability of customer intent. Use them to tune behavior after a repeatable test set shows too many false switches or too many missed switches.

Start with Medium. Move lower only when visitors frequently change goals and missed switches are the main problem. Move higher when short follow-ups are being pulled away from an active process. Fix overlapping descriptions and conditions before adjusting thresholds.

Return to Base Assistant: the general-purpose escape path

When enabled, a specialist can release broad or unowned questions to the selected Basic Assistant. Base retains its own instructions, knowledge behavior, and any normal tools not owned by workflow specialists. This creates a strong principle: specialists own narrow jobs; Base owns the rest.

Turn it off only when a workflow must keep visitors inside a controlled specialist process and explicit handoffs cover every legitimate exit. If both Return to Base and Direct specialist switching are off, specialists may remain pinned unless explicit handoffs exist. Flow Checks warns about this shape because ambiguous topic changes have nowhere sensible to go.

Direct specialist switching: flexibility between specialists

When enabled, SmartSite can move directly from the active specialist to another specialist whose scope clearly fits. This feels natural on a service website where a visitor can shift from an appointment to a billing question.

When disabled, implicit direct movement is removed, but configured explicit specialist-to-specialist handoffs remain allowed. This is useful for a controlled process where Appointments may go to Billing only through a named condition, while arbitrary cross-specialist movement should not occur.

Flexible service site

Balanced · Medium · Return on · Direct on

Visitors can change topics naturally. Base catches broad questions. Explicit handoffs improve important routes but do not have to describe every possible transition.

Structured intake

Sticky · High · Return on · Direct off

The active specialist keeps partial answers and corrections. Only explicit cross-specialist routes are allowed; general questions can still escape to Base.

Locked process

Locked · High · Return off · Direct off

Use only with complete explicit exits and extensive testing. Otherwise the current specialist can keep questions it should not answer.

Uncertainty Fallback: what happens below the threshold

This control appears in Advanced mode.

Uncertainty fallback choices
Choice	Behavior	When it makes sense
Automatic	Uses stage-aware behavior: Base remains Base on uncertain entry; an active specialist normally stays active when a proposed switch is uncertain.	Recommended for most sites because it protects both broad entry handling and follow-up continuity.
Keep current specialist	Keeps the active specialist when a switch candidate does not meet the threshold.	Long multi-step processes where continuity is more important than reacting quickly to vague topic changes.
Return to Base Assistant	Sends uncertain active turns to Base, if Base return is allowed.	Specialists should release ambiguity quickly and Base is well prepared to clarify. Can feel jumpy if visitor replies are short.

If Return to Base Assistant is off, choosing a Base fallback cannot create an escape the policy has forbidden. Review the Policy Summary rather than reasoning from one field in isolation.

Read the Policy Summary as a promise

Advanced mode shows a compiled summary including continuity posture, switch threshold, fallback, direct switching, and Base return. Read it aloud as a user-experience promise:

“This workflow prefers staying with the active specialist, requires high evidence for a switch, keeps uncertain questions with the current specialist, allows only explicit specialist changes, and lets broad questions return to Base.”

If that does not describe the desired visitor journey, change the policy or design. Do not publish a combination simply because every individual setting sounds cautious.

A routing test set worth keeping

Create a small library of synthetic messages with an Expected handler. Reuse it after every Description, Condition, tool, model, or policy change.

Clinic routing test set
Test message	Expected owner	What it tests
I need to move my Tuesday appointment.	Appointments	Clear explicit entry intent.
Tuesday afternoon would be better.	Appointments	Short follow-up should remain with the active specialist.
Actually, use my mobile number.	Appointments	Correction should not be mistaken for a new topic.
Why did I receive two invoices?	Billing	Clear specialist topic change.
What services do you offer?	Base Assistant	Broad knowledge belongs to Base.
This is ridiculous. I have explained it three times and nobody helps me.	De-escalation	Clear frustration route, not a mere negative word.
How much is it?	Current owner or Base, according to context	Ambiguity and continuity policy.
Thank you.	Current owner	Closing language should not cause a specialist switch.

Do not judge routing from one successful dramatic phrase. Include paraphrases, typos, short answers, mixed intentions, topic changes, and messages that resemble a specialist but should stay elsewhere.

Common tuning errors

Change policy when

A repeatable test set shows too many false or missed switches.
Specialists are well-separated but multi-step follow-ups still bounce.
The business process genuinely permits only explicit transitions.
Base is deliberately prepared to clarify uncertainty.

Fix design first when

Descriptions all contain “general questions.”
Handoff Conditions repeat the same wording.
A specialist has no clear non-goals.
The wrong specialist owns the only relevant tool.
Admins cannot agree who should handle a test case.

Screenshot capture pending /images/screenshots/agentic-flows/routing.webp

Workflow routing policy controls and compiled policy summary

Capture: Open Workflow Settings for a synthetic active flow and select Advanced so every routing control and the Policy Summary are visible.
Show: Routing Mode, Stickiness, Switch Confidence, Return to Base Assistant, Uncertainty Fallback, Direct specialist switching, and Policy Summary
Viewport: Desktop, 1440 × 1000
Annotate: Group the controls as continuity, certainty, and escape-path decisions.
Redact: API keys, private URLs, personal data, real visitor messages, and production action details

After changing routing, run the same expected-handler set in the Simulator, then inspect real traces after publication. A green expected match proves only that one message reached the expected owner. The final reply, knowledge use, tool decision, confirmation, latency, and outcome still need review.