Conversational navigation models for LLM voice agents

Which established dialogue-management architectures let a voice agent run a navigable, consultative conversation instead of a rigid linear sequence of gates, each of which must be completed before the next? AR Labs researched that question in June 2026 to ground a redesign of Salesbot, our sales-discovery voice agent. It bears on our approach to structured conversation, in which the model talks and code tracks what is collected and when to move on. The report surveys forty years of task-oriented dialogue research (RavenClaw, Information State Update, BDI and HTN planning, POMDP state tracking) alongside current LLM frameworks and 2024–2025 papers.

Method: standard depth, two passes (breadth reconnaissance, then pathway exploration); 12 searches; about 28 sources analysed, about 20 with CRAAP scores of 4.0 or above; major claims (RavenClaw architecture, ISU model, decoupled extraction) triangulated across 3+ independent sources.

Summary

The problem in view is rigid linear gate-completion dialogue: a sales-discovery voice agent that walks the SPIN stages (Situation, Problem, Implication, Need-payoff) as a fixed sequence of gates, where each gate must capture its data before the conversation can move on. Five findings bear on it:

1. The rigid gate problem is 40 years old and solved. Finite-state and pure slot-filling dialogue managers suffer exactly these symptoms: they cannot accommodate user initiative, handle topic shifts, or re-prioritise goals. The field converged on agenda-based, hierarchical, and ISU approaches specifically to escape this trap. These patterns can be adopted rather than re-discovered.

2. RavenClaw's agenda + execution stack is the closest classical match. It explicitly separates a task-tree (the plan) from a runtime dialog stack (where we are now) and an expectation agenda (what the system is ready to hear). Sub-dialogues push onto the stack and automatically pop back to the parent plan. The LLM never "sees only the current node"; it always operates against the full agenda. This is the architecture to borrow.

3. ISU (Information State Update) gives the theoretical glue for decoupled capture. In ISU, the "information state" (a structured record of what is known, what is pending, what has been committed) is maintained as a first-class object, updated by update rules that fire on dialogue moves. This update layer is orthogonal to the conversation layer. This maps directly to the hypothesis: let the LLM converse freely, while a background ISU layer extracts structured slot values from the transcript.

4. Modern LLM frameworks have not solved this. pipecat-flows, Rasa CALM, and Dialogflow CX all suffer a version of the same problem: they couple conversation to data capture inside node/flow transitions. The LLM cannot navigate freely because the node boundary is the data-capture gate. The "LLM as policy over a goal tree" pattern exists in academic literature (2024–2025 papers) but has not yet crystallised into a production framework.

5. The recommended architecture is: LLM with a held agenda + background ISU extraction + stack-based sub-dialogue management. Concretely: represent the SPIN stages as a goal-tree (not a sequential gate); let the LLM hold the entire tree and navigate it with agency (follow a volunteered need, develop it, return); have a separate extraction layer observe the transcript and fill slots asynchronously; and use a stack to manage sub-dialogue excursions and returns.

1. Classical task-oriented dialogue management

1.1 Finite-state and frame-based approaches

The earliest practical dialogue systems (1990s–early 2000s) represented conversation as a finite-state machine (FSM): each state maps to a system prompt, and user intent matches trigger transitions (MIT's JUPITER weather system, 1997; early VoiceXML IVRs). Frame-based / slot-filling systems (Allen et al.'s TRAINS; the CMU Communicator, 1999) replaced FSMs with a flat frame of named slots, and the dialogue manager's sole job was to find the next empty slot and ask for it.

Known limitations, which match the gate-completion problem: no mixed initiative (volunteered information that doesn't match an expected slot is ignored or treated as an error); no sub-dialogue (pursuing a sub-topic loses the main slot-list's place); no prioritisation (every slot is equally "next"); and conversation coupled to capture (the dialogue IS the slot-filling). Bohus & Rudnicky (2009) explicitly position RavenClaw as solving these FSM/frame-based limitations.

1.2 Agenda-based dialogue management: RavenClaw

The most directly relevant classical architecture. Developed by Dan Bohus and Alexander Rudnicky at CMU, first presented at Eurospeech 2003, with the full framework paper in 2009. Three data structures work together:

1. The Task Tree: a static, hierarchical plan for the dialogue domain. Each node is a "dialogue agent" (a small object with an execute() method). Leaf nodes are individual turns (ask a question, execute a backend call); non-leaf nodes are compound plans (e.g., a discovery topic containing "ask about current tools," "ask about pain points," "ask about budget"). The tree is authored once per domain.

2. The Dialog Stack: the runtime execution state, reflecting what the system is doing and what it will return to. A sub-dialogue (a clarification, or a volunteered need) is pushed onto the stack; when it completes it pops automatically and execution resumes at the parent. This gives automatic backtracking: the system always knows where it came from.

3. The Expectation Agenda: generated each turn from the active agents on the stack. It captures everything the system is "ready to hear": the current leaf's expected input, inputs relevant to parent and sibling nodes, and meta-inputs ("start over," "go back"). This enables mixed initiative: if the user answers a question belonging to a later node, the agenda accepts it and skips ahead.

When the user volunteers a need that maps to a future node, the engine pushes that node's agent, runs it, and pops back to wherever the conversation was. This is the "sideways bridge / sub-hierarchical node" pattern a navigable design needs, and it ran in production systems in 2003.

RavenClaw also separates "what to talk about" (the domain-authored task tree) from "how to handle the conversation" (domain-independent discourse behaviours: error handling, grounding, topic shifts, reprompting), so dialogue behaviour is not hard-coded into each gate.

Known limitation: RavenClaw is pre-LLM. The task tree is hand-authored and transitions fire on NLU intent labels. For LLM deployment the pattern is adapted (LLM as the discourse engine over an explicit goal-tree) rather than running RavenClaw itself.

Confidence: High (primary sources, peer-reviewed, production-deployed in CMU systems).

1.3 Information State Update (ISU): TrindiKit

Developed through the TRINDI project (Task-Oriented INstructional Dialogue), principally by Staffan Larsson, David Traum, Robin Cooper and colleagues, and formalised in Larsson & Traum (2000), Natural Language Engineering.

Core idea: dialogue is a sequence of updates to a shared information state (IS) recording what has been said and acknowledged, the questions under discussion (the QUD stack), active plans and goals, and each participant's beliefs about the other. A dialogue move engine fires update rules (condition-action pairs) on every dialogue move: "if IS satisfies condition X, update IS component Y in way Z."

Why this matters for decoupled capture: structured data extraction is a first-class part of the information state, separate from the conversational surface. A rule can update a slot value in response to an utterance without the system having asked for it. This is the formal basis for a background extraction layer. The QUD stack, ordered by recency, handles answers to questions that weren't asked: the answer updates the IS and the stack adjusts, which formally grounds "following a volunteered need."

TrindiKit, the reference implementation, predates transformers, but the model transfers directly: an LLM can be the conversation layer while the IS is an explicit data structure updated by extraction rules.

Confidence: High (peer-reviewed, widely cited foundational work).

1.4 Plan-based and BDI dialogue management

BDI (Beliefs-Desires-Intentions) systems model the agent as rational, with beliefs about the conversation, desires (e.g., learn the prospect's budget) and committed intentions. HTN (Hierarchical Task Network) planning decomposes tasks into sub-tasks online, so plans can be revised mid-execution. BDI represents "follow a volunteered need" as adopting a new intention without abandoning existing ones. HTN backtracking revisits alternative decompositions when a sub-task fails, which is stronger than RavenClaw's stack-pop. In sales dialogue, "this topic thread hit a dead end" is HTN-style failure and "the prospect changed their mind about a stated need" is BDI-style revision. CANPLAN combines both and is described as "provably more expressive than either BDI or HTN systems alone." The Glengarry Glen Ross paper (AAAI 2020) uses BDI for sales game dialogues; it is directly relevant but scores low on authority (conference paper).

Confidence: Moderate (well-established theoretically; production sales dialogue applications are sparse in the literature).

1.5 Statistical and POMDP dialogue management

POMDP dialogue systems treat dialogue as sequential decision-making under uncertainty, holding a belief state (a probability distribution over interpretations) instead of committing to one. Dialogue State Tracking (DST), benchmarked by the Dialog State Tracking Challenge series (2012–2019), is the sub-problem of updating that belief turn by turn. POMDP planning scaled poorly and LLMs have largely superseded it, but DST as a background extraction task remains relevant: recent papers use LLMs to produce structured slot-value pairs from free dialogue ("Towards LLM-driven Dialogue State Tracking", 2023), to extract slots from a natural-language state summary (arXiv 2503.08857), and to fill slots zero-shot without domain training (arXiv 2411.18980).

Confidence: High for POMDP theory and for LLM-based DST as background extraction (multiple independent 2023–2025 papers).

2. Hierarchical and tree-structured conversation models

RavenClaw, BDI/HTN and ISU share one insight: a dialogue is a tree, not a sequence. The root is the ultimate goal ("complete the discovery call"), interior nodes are sub-goals ("identify pain points"), and leaves are conversational acts ("follow up on stated frustration"). Navigation has three primitives: descent (follow a volunteered topic into a sub-goal), backtrack (return to the parent when the sub-goal is complete or abandoned), and skip (mark a sub-goal satisfied because the information arrived incidentally).

The stack is the navigation mechanism. When a user volunteers a need (for example, wanting to move beyond their current AI tool), the agent pushes a "develop stated need" sub-dialogue, probes it, pops when it is developed or dead-ends, and resumes the main plan. For an LLM, the stack and task tree are explicit data structures passed in the system prompt or retrieved by tool call, not implicit in context. The LLM is the executor, not the planner. Subgoal Discovery for Hierarchical Dialogue Policy (arXiv 1804.07855) is relevant RL-based, pre-LLM background on learning such hierarchies.

Confidence: High for the tree model as the correct abstraction; Moderate for specific LLM-era implementations.

3. LLM-era orchestration frameworks

3.1 pipecat-flows

A graph of nodes, each with role_messages (system prompt), task_messages (goal for this turn) and functions. Node functions keep the LLM in the same node; edge functions transition to a hard-coded target node and are the only way to advance. The LLM cannot choose to jump to node N on conversational reasoning; the conversation path is the graph structure. Switching prompts per node solves "context rot" (a long system prompt diluting focus), but it means the LLM never holds the full plan. Advancing past a node means completing its data-capture function, so conversation and capture are tightly coupled, and there is no backtrack primitive, sub-dialogue stack or skip mechanism. If the user volunteers "node 5" information while the bot is on "node 2," the bot ignores it unless the developer authored an edge for that exact case.

Confidence: High (primary documentation, direct analysis).

3.2 Rasa CALM

Developers define "flows" of collect/action/logic steps, and an LLM command generator issues commands to the flow executor each turn ("start flow X," "set slot Y to Z"). The generator can interrupt the current flow or start another, and built-in pattern flows (chitchat, out_of_scope, correction) handle off-script turns, which is closer to mixed initiative than pipecat-flows. But a rule-based executor still decides what is legal, and slot collection is embedded in flow steps (collect), so conversation and capture remain coupled.

Confidence: High (primary documentation).

3.3 Google Dialogflow CX

Flows contain Pages; state handlers fire on intent match or event. Transitions can target any page in the active flow or another flow's start page, not arbitrary cross-flow navigation. END_FLOW_WITH_CANCELLATION and END_FLOW_WITH_FAILURE give a controlled exit with a typed signal, the closest thing to a backtrack, but only along paths the developer authors. Max stack depth is 25 flows, and the LLM (via Generative Playbooks) cannot navigate the flow graph freely.

Confidence: High (primary documentation).

3.4 LangGraph

A directed graph of nodes with conditional edges, cycles and checkpointed state. Its conditional edge, where LLM output selects the next node, is the closest current production tool to "LLM navigating a graph with agency." But it is a general workflow graph: there is no built-in agenda, sub-dialogue stack, expectation management, mixed-initiative handling or background extraction. LangChain's pipecat tracing integration confirms pipecat pipelines can use LangGraph agents as the LLM stage.

Confidence: Moderate (architecturally plausible as a dialogue backbone, not established practice).

3.5 LLM as policy over a goal tree: academic work, 2024 to 2025

• Script-Based Dialog Policy Planning (arXiv 2412.15242, December 2024): expert-authored scripts act as a "deterministic constraint"; the LLM moves through script states but generates freely within each. Closest to "agenda as constraint, LLM as surface."
• Planning Like Human: Dual-Process Dialogue Planning (arXiv 2406.05374): a fast RoBERTa-large policy for familiar contexts plus MCTS for novel ones reaches 99.23% task success on emotional support conversations in 2.13 average turns (vs. 4.56 for baseline), analogous to a salesperson mixing instinct and deliberation.
• ProToD (arXiv 2309.08949): "look-forward motivated goals" condition the LLM on anticipated future actions, outperforming fully supervised baselines on MultiWoZ 2.1 with 10% of the training data.
• Proactive Conversational Agents with Inner Thoughts (ACM CHI 2025): an internal monologue running alongside the conversation lets the agent steer toward goals without explicit user triggers.

Key finding: the academic frontier is converging on (a) explicit goal/plan representation external to the LLM, (b) the LLM as surface conversationalist plus background planner, and (c) mixed initiative. This is in papers, not yet in production frameworks.

4. Consultative selling and SPIN as a dialogue model

The search found no peer-reviewed NLP paper that models SPIN (Rackham, 1988) as a navigable dialogue state machine. The closest is the Glengarry Glen Ross AAAI 2020 paper, which models a sales dialogue game with a BDI agent holding beliefs about customer state and a desire to close.

SPIN's structure maps naturally to a goal tree:

Root: Complete Discovery
├── S: Establish Situation (background facts)
│   ├── Current tools / stack
│   ├── Team structure
│   └── Current workflow
├── P: Identify Problems (pain points)
│   ├── Known frustrations
│   └── Probed problems (follow volunteered hints)
├── I: Develop Implications (need amplification)
│   └── [For each identified problem: what's the downstream impact?]
└── N: Need-Payoff (solution linking)
    └── [Bridge identified problems to the solution's capabilities]

The LLM navigates this tree: descending into P when a problem is volunteered, pushing an I sub-dialogue when a problem is confirmed, popping back to P for the next problem. SPIN is a recursive interleaving, not a sequence. A skilled salesperson does S → P → I (problem 1) → P → I (problem 2) → N (linking both). A gate model forces S → P → N and cannot represent this.

Flagged as engineering inference, not sourced: the SPIN-as-recursive-goal-tree mapping is our synthesis from Rackham and the BDI literature, not validated in a published paper. Moderate confidence.

5. The tension between capture and conversation

In a gate-completion design, each gate couples what the LLM says, what is captured (the structured data the gate must collect) and the UI progress indicator (a visual rail advancing for the prospect). Coupled this way, the LLM optimises for finishing the capture checklist rather than conducting a good conversation, because the gate boundary is the only thing that advances.

Prior art on decoupling:

• Zep structured extraction: client.memory.extract(session_id, ModelClass) reads conversation history and populates a Pydantic model after the fact. The LLM converses freely; extraction runs separately per turn or on demand; missing fields can be mentioned in the prompt without gating on them. Zep's guidance is to extract iteratively and tell the LLM what is still needed, but "do not ask for all fields at once." This is the clearest production implementation of background extraction.
• Zero-shot LLM slot filling (arXiv 2411.18980) confirms extraction from free conversation is feasible without domain fine-tuning.
• Multi-agent extraction (arXiv 2505.14299, May 2025): a Conversational Agent handles dialogue while an Information Extractor Agent converts transcripts to structured data.
• Hybrid slot manager (iMagist486/Chatbot-Slot-Filling on GitHub): the LLM handles language; a lightweight deterministic manager tracks completeness, which "avoids excessive LLM calls."

Confidence: High for decoupled extraction as a feasible, established pattern.

Synthesis

What each architecture contributes

Architecture	Key contribution	Directly usable?
RavenClaw (Bohus & Rudnicky)	Task tree + execution stack + expectation agenda	Pattern: yes. Code: no (pre-LLM).
ISU / TrindiKit	Information state as separate layer from conversation	Theoretical basis for decoupled extraction.
BDI/HTN	Dynamic plan revision, HTN backtracking	Pattern for "adopt new intention" on volunteered need.
POMDP/DST	Uncertainty handling, background state tracking	LLM-based DST as the extraction layer.
Zep extract()	Production decoupled extraction	Use directly or replicate pattern.
pipecat-flows	Context management, voice pipeline	Keep the voice pipeline, redesign the navigation layer.
Script-Based Dialog Policy (arXiv 2412.15242)	LLM constrained by explicit script	Direct model for "LLM + agenda as constraint."
Dual-Process Planning (arXiv 2406.05374)	Fast heuristic + deliberative MCTS	Model for "when to follow instinct vs. plan deliberately."

Recommended architecture: agenda, stack and background ISU

The design adapts RavenClaw for LLM execution, with ISU-style background extraction, in three layers.

Layer 1: Goal Tree (static, authored). SPIN stages as a hierarchical goal tree held as JSON or Python data, not a pipecat-flows graph. Each node has a prompt fragment, acceptance criteria and child nodes.

flowchart TD
  R["root: discovery_call"] --> S["situation_node (S)"]
  R --> P["problem_node (P): can be entered multiple times"]
  R --> I["implication_node (I): entered after each confirmed problem"]
  R --> N["need_payoff_node (N)"]
  S --> S1["current_ai_tools"]
  S --> S2["team_context"]
  S --> S3["current_workflow"]
  P --> P1["probe_frustrations"]
  P --> P2["develop_volunteered_problem (sub-dialogue)"]
  I --> I1["amplify_impact"]
  N --> N1["bridge_to_solution"]

Layer 2: Execution Stack (runtime). A list whose top is the active node. When the LLM decides a sub-dialogue should begin, the orchestrator pushes the target node and adds its task to the system prompt; when the node completes (required slots filled, or the LLM signals completion), it pops.

Layer 3: Information State / Extraction Layer (background). After each turn, a lightweight extraction call (Zep-style, or an LLM call with JSON output) updates the IS. The conversation prompt can read the IS ("their current stack is X, don't re-ask") but does NOT gate on IS completion; conversational logic drives advancement.

Design implications for a pipecat-flows voice agent

The pipecat voice pipeline (STT → LLM → TTS) stays; the node graph is replaced:

1. A goal-tree JSON in the LLM's context, navigated through a single navigate(action: "push" | "pop" | "skip", target_node_id: str) tool instead of pre-authored edge functions.
2. A background extraction agent that reads the last N turns (5–10) after each LLM turn and updates the IS asynchronously, in place of gate-completion triggers.
3. An expectation agenda in the system prompt: the nodes currently in scope (stack top plus siblings the user might volunteer information for).
4. A UI progress rail driven by IS completeness, not gate advancement. The LLM never "knows" the rail.

The prototype order is the agenda-plus-stack navigation first (the minimal change that addresses the gate-completion problem), then the background extractor, with a Script-Based Dialog Policy variant (a SPIN script as a formal constraint set, with explicit backtracking arcs) as the third candidate.

Open questions

1. When does the LLM push versus continue? RavenClaw used intent matching; an LLM-native system needs a classifier, a structured navigate call or inline reasoning. Giving the LLM the tree and the tool and observing its use is the first test.
2. How deep can the stack go before coherence drops? Each level adds a node's task description to the prompt.
3. What granularity is right? One node per question means navigating instead of conversing; one per SPIN stage adds nothing. Hypothesis: 10–15 nodes for a discovery call.
4. Can extraction run fully in parallel, with results ready by the next turn?
5. How is incidental satisfaction represented? Navigation should check the IS before descending into a child node.
6. Does the tree need cycles? Implication must be re-enterable per confirmed problem, which needs a cycle or a per-problem clone of the node. This is the primary architectural question before committing to a design.

Evidence gaps

• Full text of arXiv 2412.15242 (script-based dialog policy) was not retrieved, abstract only. Likely highly relevant.
• Springer "Plan-Based Approaches for Dialogue Management" (2022 review) is paywalled; abstract-level coverage only.
• No peer-reviewed treatment of SPIN as a dialogue state machine was found.
• Production evidence for "LLM-as-policy-over-goal-tree" is sparse; the pattern exists in 2024–2025 papers but not in documented production systems.

Primary sources fetched: the RavenClaw framework PDF (Brandeis mirror), pipecat-flows docs, Dialogflow CX state handler docs, Rasa CALM docs, the Zep blog, arXiv abstracts for 4 papers, and the Dual-Process Planning HTML.

Sources

Primary and peer-reviewed

• Bohus & Rudnicky (2003), "RavenClaw: Dialog Management Using Hierarchical Task Decomposition and an Expectation Agenda," Eurospeech: ISCA Archive | Carnegie Mellon KiltHub | PDF via Brandeis | Microsoft Research
• Bohus & Rudnicky (2009), "The RavenClaw dialog management framework: Architecture and systems," Computer Speech & Language 23(3): ScienceDirect
• Larsson & Traum (2000), "Information state and dialogue management in the TRINDI Dialogue Move Engine Toolkit," Natural Language Engineering 6(3-4): ACM DL | Semantic Scholar
• Traum & Larsson (2003), "The Information State Approach to Dialogue Management," Springer: Springer
• A comparison of BDI based real-time reasoning and HTN based planning (CANPLAN): ResearchGate
• Glengarry Glen Ross BDI sales dialogue (AAAI 2020): AAAI PDF
• Hierarchical task structure in dialogue (ICSLP 2000): ISCA Archive PDF
• Towards LLM-driven Dialogue State Tracking (2023): ResearchGate
• arXiv 2503.08857, Interpretable and Robust Dialogue State Tracking via Natural Language Summarization with LLMs: arXiv
• arXiv 2411.18980, Zero-shot Slot Filling in the Age of LLMs: arXiv
• arXiv 1804.07855, Subgoal Discovery for Hierarchical Dialogue Policy: arXiv
• arXiv 2412.15242, Script-Based Dialog Policy Planning: arXiv
• arXiv 2406.05374, Dual-Process Dialogue Planning: arXiv
• arXiv 2309.08949, ProToD look-forward goals: arXiv
• arXiv 2505.14299, Empowering LLMs in Task-Oriented Dialogues: A Domain-Independent Multi-Agent Framework: arXiv
• ACM CHI 2025, Proactive Conversational Agents with Inner Thoughts: ACM DL
• Rackham, N. (1988), SPIN Selling. McGraw-Hill. (foundational, not online)

Framework documentation

• pipecat-flows: Pipecat Docs | Daily.co Blog on context window rationale | PyPI
• Rasa CALM dialogue management: Rasa Docs | LLM Command Generators | Original Rasa paper (Bocklisch et al., 2017)
• Dialogflow CX state handlers: Google Cloud
• LangChain / pipecat tracing integration: LangChain Docs

Production pattern

• Zep structured extraction from chat: Zep Blog
• Zero-shot chatbot slot filling (GitHub): GitHub