Skip to main content

The same pattern everywhere

In every host, three things stay the same:
  1. Construct an entry point - DialogMachine(source, llm=...). It runs the Playbook engine by default; source accepts full playbooks, simple-format playbooks, and legacy flow JSON (auto-compiled), so you don’t pick a format, you just point it at your artifact.
  2. Route inbound text to agent.turn(text).
  3. Send the reply text back to the host’s output channel.
Both engines implement the same superdialog.agent.Agent protocol (turn / assist / chat_ctx / load_chat_ctx), so every adapter accepts either one. The host varies; the SuperDialog code is identical.
Advanced: drop to PlaybookAgent when you need to supply the two LLM seams directly - a StreamsLLM Talker and a CompletesLLM Director - or a custom HTTP executor. Any superdialog.llm.LLMProvider (the litellm-backed one behind model URIs) adapts in a few lines:
Why two models, and how the Director steers the Talker without stalling it: Architecture.

Choose your host

CLI chatbot

Zero infrastructure. Best for testing and prompt tuning.

LiveKit

Voice agent via Agent(llm=DialogMachineLLM(...)) plugin.

PipeCat

Drop-in FrameProcessor for PipeCat pipelines.

FastAPI

REST endpoint for text chatbots and web widgets.

Unpod Voice

Plug your DialogMachine into an Unpod AgentRunner session - no extra server needed.

Unit testing

Because SuperDialog is text-only, every dialog is unit-testable.

Lines of code comparison