Skip to main content

​
Overview

SuperDialog is the brain layer for conversational systems - it works anywhere, and shines on Unpod. It takes a prompt or an authored artifact and turns it into a running conversation runtime - managing turn-by-turn logic, tool calls, outcome tracking, and conversation memory.
Animated SuperDialog text loop diagram showing user text entering the Agent protocol, agent.turn using tools and state, and reply text coming back.
It ships two engines behind one Agent protocol, and the Playbook engine is the default everywhere:
  • Playbook engine (default) - checkpoints gate outcomes, not utterances. A fast Talker streams every spoken turn while an async Director extracts data, judges progress, and runs tools over an event-sourced log. This is where new investment goes.
  • DialogMachine (supported legacy) - the graph-railed state machine: nodes, edges, and criteria, where every transition is authored. Still fully supported, opt-in via engine="flow". Existing flow graphs run compiled on the Playbook engine by default, so nothing breaks.
It is intentionally narrow in scope. Audio, STT, TTS, telephony, and media servers are all out of scope - those belong to voice infrastructure like LiveKit, PipeCat, or the Unpod Voice Platform. SuperDialog ends at text in, text out - on both engines.

New to the checkpoint model?

Read the mental-model guide before diving into the quickstart.

SuperDialog on GitHub

Browse the source, issues, and releases at unpod-ai/superdialog.
Coming from the Speech Stack? Assign your SuperDialog agent to ctx.session.dialog_machine and the SDK wraps it for you - see Level Up to SuperDialog.

​
Why SuperDialog exists

​
The brain has natural reuse beyond voice

A conversation brain that runs a customer-onboarding journey works the same whether the user is on a phone, a WhatsApp thread, an Intercom widget, or a CLI test harness. Coupling it to telephony forecloses every non-voice use case.

​
The dependency direction matters

Voice infrastructure should depend on SuperDialog (as one brain option), not the other way around. A modular architecture keeps the framework portable and the platform composable.

​
Who it’s for

​
How it compares

SuperDialog is to conversation flow what n8n is to integration workflow - a simple, composable, eval-able runtime for orchestrating turn-by-turn logic. Where LangChain and LangGraph expose general agent primitives, SuperDialog focuses narrowly on the conversational core: who speaks next, what to say while tools run, which checkpoint or flow the conversation is in, when to call a tool, when to escalate, and which outcome the session ended with. The pitch: “if your problem is conversation state, this is the right size.”

​
Two engines, one entry point

DialogMachine is the recommended way in. It runs the Playbook engine by default; pass engine="flow" for the legacy graph runtime. Both engines sit behind the same Agent protocol, so sessions and host adapters run either one unchanged.
Why the engines swapped places, honestly: users don’t follow graphs. The graph-railed model accumulated stacked escape hatches and still cost two serial LLM calls per turn with only cosmetic streaming. The Playbook engine moves fluidity to the model and keeps the framework’s authority where it belongs: on outcomes. Existing flows are migrated, not replaced - Playbook.load detects flow JSON and compiles it (compile_flow), with coverage_report proving every node, edge, and action mapped.

​
What ships today (v0.2)

​
What it explicitly is not

  • Not a UI flow designer - that belongs to a downstream tool
  • Not a voice framework - audio, STT, TTS are out of scope (the Talker streams text tokens; the host turns them into speech)
  • Not multi-modal - text only at the interface (vision/audio via tools if needed)
  • Not a hosted service - SuperDialog is a library; the Unpod Voice Platform provides hosting for those who want it