The same pattern everywhere
In every host, three things stay the same:- Construct an entry point -
DialogMachine(source, llm=...). It runs the Playbook engine by default;sourceaccepts 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. - Route inbound text to
agent.turn(text). - Send the reply text back to the host’s output channel.
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: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
| Host | Adapter | Extra LoC |
|---|---|---|
| CLI | None - direct input()/print() or superdialog chat | ~5 |
| LiveKit | DialogMachineLLM | ~8 |
| PipeCat | make_processor | ~12 |
| FastAPI | FastAPIRouter or direct route | ~6 |
| Unpod Voice (SDK) | unpod.AgentRunner + session.dialog_machine | ~6 |
| Unit test | None - direct calls | ~3 |
| Custom (Slack, Discord, etc.) | None - direct callback | ~3 |