A confession: I have never once enjoyed reading an agent transcript. You know the genre — "Here's a fascinating multi-agent conversation between Researcher and Critic!" — followed by forty lines of dialogue that were interesting to the person who built the agents and to no one else. And by the time you read it, it's over. It's a recording of an event nobody attended.
So when I sat down to build a multi-agent demo, I gave myself one constraint: it has to feel live. Not a pipeline that produces a text file. An event. Something a room of people can watch and, fittingly, argue about in real time.
What I ended up with is now a public code sample: two AI agents with opposing stances debate a topic, arguments and vote tallies stream live over WebSocket, and the audience votes — with every ballot persisted to a SQL ledger that lives inside the debate room itself.
The problem with multi-agent demos
Here's what "make it live" actually demands, and why most demos skip it:
- Durable shared state. The debate has a phase, a current turn, a growing list of arguments. That state has to survive restarts and be consistent.
- A broadcast layer. Every state change needs to reach every connected viewer, immediately, as a diff — not a full re-fetch.
- A database. Audience votes need to be persisted, deduplicated, and tallied. One vote per person, re-votes overwrite.
- Secret management. The agents call a model, which means credentials — somewhere.
Each of those is an afternoon of plumbing on its own. None of them is the demo. Most multi-agent samples quietly drop the "live" part and hand you a transcript instead, because the plumbing eats the fun.
What I built
The flow is simple to describe. You POST /debate with a topic. Two DebateAgent actors — one pro, one con — take turns composing arguments through model inference. A DebateRoom actor orchestrates the turns and holds the canonical state. Every state change streams automatically to anyone connected to the room's WebSocket. The audience votes with a call frame over that same socket (or plain HTTP, if they prefer). Votes land in an embedded SQL ledger — one row per voter. When someone hits the end endpoint, the winner is declared straight from the SQL tally and broadcast in state.
The whole thing runs locally on one port. Demo mode ships with canned arguments, so streaming, voting, and tallying all work before you wire up live inference.
Three things made it click
1. Zero-credential inference. The agents call the model through Telnyx's [telnyx] binding. There is no API key in the agent code — the platform injects authentication at runtime. My agents hold no secrets, which means I can share the code, and the inference path can't leak a credential it doesn't have.
2. State that streams itself. This is the one I keep thinking about. The room updates its state with setState(), which applies a JSON merge-patch, persists it durably, and fans it out to every connected WebSocket client. I did not write a broadcast layer. I did not write a diffing protocol. The room's connection surface is the broadcast layer. The live part of the demo — the part that makes it an event instead of a transcript — fell out of the state model for free.
3. A database per actor, no database server. Each room actor carries its own embedded SQL store. The vote ledger is a handful of lines: create the table, upsert the vote with ON CONFLICT, SELECT the tally. No provisioning, no connection strings. And because the tally gets written back into agent state, the moment someone votes, every watcher's UI updates.
Why this is the interesting part
Telnyx frames its platform as AI Communications Infrastructure — a unified stack for building agents that communicate over voice, SMS, and real-time WebSockets. When I first heard that phrase, I filed it under "marketing." Building this sample changed my mind.
A live debate is a communications event. The audience is connected in real time. The state is the broadcast. And the same Agent runtime that streams my debate state can carry a phone call — which means the obvious next version of this demo is a debate you can call into and hear, with the same state streaming to a live audience on the web. That's not two products stitched together; it's one runtime whose primitives (durable agents, streaming state, embedded storage, zero-credential inference) happen to be the primitives a live event needs.
Try it
The repo is team-telnyx/telnyx-code-examples → multi-agent-debate. npm install, npm run build, npm start (the local actor stack needs Docker and the Edge Compute CLI), and you're at http://localhost:8787. If you want to kick the tires with nothing but Node, npm run smoke runs a self-contained test with an in-process actor host.
Start in demo mode. Watch the arguments stream. Vote. Change your vote. End the debate and watch the winner come out of the SQL ledger.
The audience is the missing ingredient in most agent demos. Give them a way to vote, and suddenly the transcript becomes a show.
Top comments (0)