Genesys Cloud Navigator

01 What is Navigator

Navigator is Genesys Cloud's conversational entry experience. It enables customers to express requests naturally at the start of an interaction and be routed to the most appropriate execution surface — without navigating rigid IVR menus or traditional flat intent structures.

Navigator is not a fulfilment surface. It is a conversational steering and routing capability. Once a customer's intent is understood and an execution path is selected, Navigator hands off to the relevant surface — an Agentic Virtual Agent (AVA), Bot Flow, or human-assisted queue — which then owns the task.

Guide is a planned fourth execution surface, not usable during Beta — see Known Beta Caveats.

Think of Navigator as a smart, conversational front door — it understands where you need to go, gets you there quickly, and carries your context with you.

Key Customer Problems Solved

Customers forced through rigid IVR menus or large flat intent trees
Intent ambiguity leads to misrouting and transfers
Context lost when moving between routing and execution surfaces
Authoring and maintaining large intent structures is complex and brittle
No reuse of intent definitions across different AI capabilities

Strategic Fit

Establishes Customer Intents as the shared intent taxonomy across the platform
Provides a conversational entry point that works alongside existing Architect investments, reducing the need for complex intent trees and menu-driven routing
Lays the foundation for future agentic orchestration capabilities

02 How Navigator Works

Core Components

Component	Role
Architect Bot Flow (Navigator type)	Authoring and deployment surface. Authors select Navigator at creation time, replacing legacy NLU with Customer Intent hierarchy.
Agentic Ask For Intent block	New Architect block that drives conversational intent classification and execution-path selection at runtime.
Quechua	Backend service (also powers Guides) that performs conversational intent classification using embeddings and a Bedrock LLM. Classifies intent, disambiguates when needed, or rejects if out of scope.
Cicero	Bot runtime. Initialises the session with Quechua, follows the path dictated by Quechua, and manages handoff to execution surfaces.
Customer Intents	Shared platform taxonomy of customer-goal definitions. Authors pull these into Navigator and tune them with runtime descriptions and keywords.
Conversation Custom Attributes (CCA)	The context store. Carries relevant interaction data across Navigator and participating execution surfaces (AVAs, Bot Flows — not Guide during Beta) so customers don't repeat themselves.

Runtime Flow

Customer enters the experience and expresses a request naturally
Quechua classifies the intent using the Customer Intent hierarchy
- If clear → routes directly without clarification
- If ambiguous → asks a targeted clarification question
- If out of scope → triggers fallback or escalation
Cicero routes to the configured execution surface (AVA, Bot Flow, queue — not Guide during Beta)
Relevant context is passed via CCA so the execution surface can continue without rediscovery
Execution surface fulfils the task
Agentic Anything Else re-invokes Navigator for subsequent requests (controlled re-entry)

Intent Classification — Under the Hood

At authoring time, the Customer Intent hierarchy is embedded via the Panini v2 Batch API into 384-dimensional vectors stored in S3. At runtime, the customer utterance is embedded and compared against cached intent vectors using cosine similarity. The top candidate intents are then passed to a Bedrock LLM, which makes the final routing decision, generates a clarification question if needed, or rejects the request if nothing matches.

Note: Output quality varies by language for the model classes Quechua relies on. This is being validated per language as part of the Tier 1 language support work now targeted for GA.

Context Continuity — CCA

Authors define a Conversation Custom Attribute (CCA) schema to carry context across surfaces. Quechua fills CCA attributes it detects in user input during classification. Cicero passes the CCA reference to the execution surface, which can read and update attributes as the conversation progresses. System-level context (detected intent, previous turns) is also passed to execution surfaces to create a cohesive experience.

03 Beta / GA Scope

✅ What is Included

Conversational intent classification and disambiguation
Hierarchical Customer Intent authoring in Architect
Customer Intent import, creation, and runtime mapping
Execution-path selection and handoff
Context continuity via CCA across Navigator and execution surfaces (AVAs, Bot Flows — Guide not usable during Beta)
Controlled re-entry via Agentic Anything Else
Surface-owned authentication and ID&V (Navigator does not perform these)
DTMF input support — authors can tag DTMF inputs to specific intents
Observability and diagnostics — invocation, routing outcomes, clarification, fallback, re-entry
Tier 1 language support — English and Spanish at Beta launch; full Tier 1 locale coverage (10 UI-localized + 5 voice-localized) confirmed for GA, final list pending per-language validation
Cross-session awareness of open intents — confirmed GA requirement
In-Architect Voice Preview — confirmed GA requirement
Baseline public API access to Navigator flow configuration — confirmed GA requirement; private/internal APIs may cover Beta
Architect-based authoring and deployment

🚫 Out of Scope for Beta / GA

Item	Notes
Multi-intent sequencing	Basic re-entry supported; proper sequenced multi-intent is fast follow post-GA
Digital Bot Flow support	Voice and messaging via Bot Flows only for MVP; digital experience is post-GA
Knowledge handling in Navigator	Knowledge must be handled by the execution surface; Navigator does not become a knowledge assistant
Intent switching during active fulfilment	Customers cannot switch intents mid-task; post-GA
Standalone Navigator authoring experience	Architect-only for MVP; AI Studio is a future direction
Agentic Orchestration-managed journeys	Navigator is compatible but does not require AO for MVP

04 Ideal Beta Customer Profile

Beta customers should be selected based on the suitability of their use case against MVP capabilities — genuine value from conversational routing and intent disambiguation, not capabilities that are explicitly out of scope.

👍 Strong Fit

Customers with complex IVR / intent structures they want to modernise
Customers experiencing high misrouting rates or excessive transfers
Customers already using or interested in Customer Intents
Customers with clear, action-oriented use cases (balance check, booking, account management)
Customers comfortable with English or Spanish for initial rollout
Customers with existing Architect investments they want to preserve

⚠️ Weaker Fit — Manage Expectations

Customers primarily interested in digital channels (post-GA)
Customers expecting knowledge-answering from the routing layer itself
Customers requiring languages beyond English and Spanish from day one
Customers expecting full multi-intent sequencing in MVP

05 PS Implementation Guide

1

Plan Customer Intents

Before building in Architect, work with the customer to define their intent hierarchy. Customer Intents is the source of truth for Navigator's understanding of customer goals.

Identify the primary intents the customer wants to handle (e.g. Check Balance, Book Appointment, Report Issue)
Organise intents into categories where logical groupings exist
Determine which intents already exist in Customer Intents and which need to be created
Note: Authors can create new Customer Intents directly from Architect if they don't exist yet

2

Create the Navigator Bot Flow in Architect

When creating a new Virtual Agent Bot Flow, select Navigator at creation time. This replaces legacy NLU with the Customer Intent hierarchy and makes the Agentic Ask For Intent block available.

Important: this cannot be changed after creation — Navigator vs standard VA is a creation-time decision
The flow will be flagged as Navigator in the flow definition; legacy NLU resources are not created
Existing Ask For Intent and traditional NLU actions are not available in Navigator flows

3

Configure the Intent Hierarchy

In the NLU Intents panel (now showing Customer Intents), pull in the relevant intents from the Customer Intent taxonomy or create new ones.

Runtime Description — additional context to help the classifier distinguish this intent
Keywords / Example Phrases — utterances that reliably trigger this intent; avoid duplicating across intents
DTMF mapping — optionally map keypad inputs (e.g. '1', '2') to specific intents
Note: runtime configuration is Navigator-specific and does not affect the Customer Intent definition itself

4

Build the Flow Canvas

Drop the Agentic Ask For Intent block onto the Architect canvas. This reveals the intent hierarchy with executable paths for each configured intent.

For each intent path, add the relevant execution surface action: Call AVA or Call Bot Flow (Call Guide is not usable during Beta)
For fallback and out-of-scope scenarios, configure the appropriate escalation path
To support re-entry (multi-request sequencing), add the Agentic Anything Else loop — this re-invokes Navigator after an execution surface completes
Note: do not loop directly back to the Agentic Ask For Intent block; use Agentic Anything Else

5

Configure CCA for Context Continuity Recommended

To carry context across Navigator and execution surfaces, create a Conversation Custom Attribute (CCA) schema in Conversation Schemas.

Define attributes that represent the context the customer might provide (e.g. account number, appointment date, product type)
Set all attributes as Optional — this prevents CCA record creation failures when not all fields are populated
In Bot Flow Settings, select the CCA schema and optionally set a record ID
In each execution surface (AVA, Bot Flow — not Guide during Beta), map CCA attributes to the relevant variables
Quechua will automatically fill CCA attributes it detects in user input during classification
Tip: A well-written CCA attribute description improves extraction accuracy.

6

Handle Knowledge

Navigator does not handle knowledge directly. If the customer has FAQ-type queries, create a dedicated intent (e.g. a 'General Knowledge' category) and route it to a knowledge-enabled execution surface.

The execution surface (AVA or Bot Flow during Beta) should have the relevant knowledge base connected
Do not expect Navigator to answer informational questions from its own surface

7

Test and Publish

Bot Preview is not available for Bot Flows. Testing should be done via a test org by connecting the Navigator Bot Flow to an Inbound Call or Messenger Flow.

Test direct routing, disambiguation, fallback, and re-entry scenarios
Validate CCA filling across execution surfaces
Guides and AVAs also support preview at a more granular level for testing CCA integration
Once validated, publish the flow to make it available for reference in production

06 Key Considerations for PS

What Navigator Is Not

Not a fulfilment surface — it does not execute tasks, call APIs, or handle business logic
Not a knowledge assistant — it does not answer informational questions from its own surface
Not a long-lived orchestration engine — it hands off and steps back
Not a replacement for AVAs or Guides — it works alongside them

Authentication and ID&V

Navigator does not perform authentication or ID&V. These remain owned by execution surfaces.

Authentication can occur before Navigator is invoked — context and auth state will be available
Authentication can occur within the execution surface after Navigator routes
For MVP, slot collection for IDV needs to happen in a separate execution surface, not inline in Navigator

Incremental Adoption

Customers do not need to redesign existing Architect experiences to adopt Navigator. It can be introduced incrementally:

Existing Architect flows remain supported and unchanged
Navigator is a new flow type alongside existing VA flows, not a replacement
Customers can begin with a subset of intents and expand over time

Billing

Navigator bills as a Virtual Agent (0.5 tokens per interaction). Where Navigator routes to an Agentic Virtual Agent, standard highest-tier billing applies (1.2 tokens per interaction).

No new SKU or entitlement is required — any customer with VA access can use Navigator.

07 Fast Follow Items — Post GA

The following capabilities are confirmed as post-GA fast follow items. PS should set expectations with customers accordingly.

Item	Priority	Notes
Multi-intent sequencing	High	Navigator will capture multiple asks from one utterance and support two author-configurable transition modes — a targeted confirm-and-continue, or a silent continue. Basic confirm/restate re-entry is available today.
Digital experience for Navigator	High	Scoping in progress. Quick Replies targeted as near-term increment; rich media (cards, images) further out. Distinct from Digital Bot Flow (DBF), which stays out of scope — Navigator already works over existing messaging channels today.
Analytics — Navigator visibility in reporting & dashboards	Medium	New. Direction is to surface Navigator activity in the Optimization Dashboard under its own label, alongside a related fix to the VA Performance Dashboard's Intent Performance chart.
Knowledge handling in Navigator	Medium	Under review; latency and scope implications to be assessed from field feedback.
Confirmation on every intent	Medium	Author-controlled setting to confirm intent before executing a path.
Spec-Driven Development (SDD) for Navigator	Medium	New. Applies the same API/skill pattern already shipped for AVAs — public CRUD APIs plus invocable agent skills for external coding agents — to Navigator's authoring model. Baseline public API access itself is GA-required.
Navigator in AI Studio	Strategic	Longer-term direction; Architect-based for MVP and foreseeable future.

08 Known Beta Caveats

Source: Patrick Buckley (Senior Director of Engineering, Conversational AI), Release Review readiness table ahead of September 24, 2026. Confirmed real by James Byrne, 2026-09-14 — treat as settled Beta limitations, not speculative risk. PS should set these expectations proactively rather than let a customer discover them.

Guide Is Not a Usable Execution Surface

A Navigator intent path cannot call a Guide during Beta.

Mitigation: use AVA or Bot Flow instead — both are fully available.

Agentic Anything Else Runs as a Scripted Flow, Not LLM-Based

The LLM-based "anything else?" capability (Quechua-generated question, semantic Yes/No/Yes+Intent interpretation) is not ready for Beta.

Mitigation: a switch-statement/directed-dialog approach instead. Customers still get a working re-engagement prompt — it just won't understand open-ended phrasing as flexibly as the version planned long-term.

CCA Sub-Features Not Ready Even for GA

Divisions, Execution Data, and Outer Limits on CCA will not be in production even by General Availability — not just Beta.

Note: Core CCA (schema, record ID, Optional attributes) is expected to be Beta-usable per Engineering's own assessment: "functionally complete enough to support Navigator use cases."

Two Observability Gaps for Beta

Agentic Ask for Intent execution data will not be surfaced in the Architect Replayer — no mitigation identified. A real gap for anyone debugging a customer's flow.

Agentic Ask For Intent Reporting Turns are at risk — intents and slots from this action may not appear in Utterance History for Beta. No mitigation identified.

These are also logged on the "Known Issues Entering Beta" tab of NAVIGATOR-BETA-BUG-TRACKER.xlsx.