Most AI bots lose context after two or three messages. Clients repeat themselves, the bot responds nonsensically, and the dialogue hits a dead end. The root cause is the lack of a dialog management system. As AI/ML engineers, we solve this by designing a component that remembers history, manages state, and selects appropriate actions. End-to-end, with documentation and support. This is not just an abstract module—it's the core that determines user retention and CX effectiveness.
How Does Dialog Management Solve Context Loss?
Dialog management stores the conversation state: current intent, filled slots, message history, and based on that decides which response to give. Without it, a bot cannot carry a coherent conversation longer than a few exchanges. In production systems, dialog management is a critical component that determines user experience quality and support load. For example, if a user writes "I want to order pizza," the manager must remember that the intent is ordering and sequentially collect slots: size, toppings, address. It should not re-ask for already filled data.
How to Choose a Dialog Management Model?
- Finite State Machine (FSM) — explicit states and transitions. Reliable, predictable, but for complex scenarios the number of states grows exponentially.
- Frame-based — sets of forms with slots (booking, ordering).
- LLM-based — the model decides based on history, maximally flexible but less predictable.
- Hybrid (production-best) — FSM for critical paths (payment, authorization), LLM for free-form dialogue.
| Model | Predictability | Flexibility | Scalability | Typical Scenarios |
|---|---|---|---|---|
| FSM | High | Low | Poor | Forms, surveys |
| Frame-based | Medium | Medium | Medium | Orders, booking |
| LLM-based | Low | High | Good | Free-form chat |
| Hybrid | High (critical paths) | High | Excellent | Production |
The key criterion is predictability for critical paths. For financial transactions or medical data, FSM is needed; for general conversation, LLM. We always recommend hybrid.
Why Is Hybrid Architecture the Production Standard?
Hybrid architecture reduces wrong answers by 30–40% compared to a pure LLM solution—that is 1.5 times more effective and 3x more reliable for critical paths. In one fintech project, we implemented such a scheme: FSM handled 80% of traffic (short balance inquiries, transfers), LLM handled 20% (complex questions, complaints). This reduced p99 latency from 1500 ms to 120 ms and cut operator escalations by 35%, resulting in annual savings of $50,000. Contact our engineers to assess your project.
How to Store Dialog State?
Dialog state must be persisted between sessions and after bot restarts. For active sessions we use Redis with TTL (30 minutes). State is serialized to JSON and stored by conversation_id. For long-term history and analytics we use PostgreSQL. This approach ensures dialog recovery after any failure and low latency. A sample state structure is shown below.
@dataclass class DialogState: conversation_id: str user_id: str current_intent: str | None filled_slots: dict dialog_history: list[DialogTurn] context: dict # business context (user profile, session) flow: str # "main_menu" | "booking" | "support" | "handoff" pending_action: str | None # expected confirmation/input What Is Policy and How to Implement It?
Policy is the algorithm that selects the bot's next action. Rule-based: if-else tree—transparent but limited. Learned policy (Rasa Core) uses a neural network on dialogue stories—flexible but requires data. LLM policy: language model chooses an action from a tool set. In production we use a hybrid: rule-based for critical paths, LLM for resolving ambiguities.
class DialogManager: def process_turn(self, state: DialogState, user_input: str) -> BotAction: # Update history state.dialog_history.append(DialogTurn(role="user", text=user_input)) # Detect intent intent = self.intent_detector.detect(user_input) # Decide next action if self.should_escalate(state, intent): return HandoffAction(reason=EscalationReason.USER_REQUEST) if state.flow == "booking" and state.pending_action == "confirm": return self.handle_booking_confirmation(state, user_input) # Update slots state.filled_slots = self.slot_filler.update(user_input, state.filled_slots) # Select next action return self.policy.select_action(state, intent) What Performance Metrics Will You Achieve?
| Metric | Target | Typical Improvement |
|---|---|---|
| p99 Latency | < 200 ms | Reduction from 1500 to 120 ms |
| Intent Accuracy | > 95% | +20% after refinement |
| Escalation Rate | < 10% | Reduction of 35% |
| Average Steps to Goal | < 5 | Reduction of 40% |
Development Process and Timeline
- Analysis: collect dialogues, identify scenarios.
- Design: draw FSM diagram, define slots, escalation rules.
- Implementation: write DialogManager, integrate with NLP pipeline (Rasa, LLM API).
- Testing: dialogue simulation, A/B tests.
- Deployment: containerization, monitoring (latency, accuracy).
Timeline: 3 to 6 weeks depending on scenario complexity.
What's Included in the Deliverable
- documentation of states and transitions,
- DialogManager module code with tests,
- integration with Redis/PostgreSQL,
- training for the client's team,
- 3-month warranty support.
Our team's experience—50+ AI bots in production, 10+ years in NLP and MLOps. Contact us for a project assessment. We guarantee that the dialog management will be robust to edge cases and handle loads up to 10,000 requests per minute.
Finite-state machine (FSM) — a mathematical model for describing system behavior through a finite number of states.