Most AI integrations are stateless: send a prompt, get a response, done. A multi-round dialogue system is a fundamentally different problem. Each exchange has to know what came before — the AI needs context, and that context grows with every turn. Managing that state without a custom server is the architectural challenge this project solves.
Demo Judge is an internal tool that runs a simulated multi-round conversation between a presenter and a fake AI audience, then scores the session against a Momen knowledge base. The business scenario is internal. The architecture is the point.
This showcase explains how a stateful conversational AI system with nine agents and seven Actionflows is built entirely inside Momen — no custom server, no session middleware, no external orchestration layer.
What the System Does
A session moves through three phases: setup, conversation loop, and evaluation.
The core of every round is the DB query in the loop: before each AI call, continue_session fetches the full session_details history for this session — that query is what makes the conversation stateful across turns.
The Core Design Problem: Where Does Conversation State Live?
An AI agent has no memory between calls. Send it a question without context and it answers in a vacuum. To make a multi-round conversation work, every call needs the full history of what came before.
The design decision in Demo Judge is to use the Momen database as conversation memory. Each round is a session_details record. Before every AI call, the continue_session Actionflow queries all session_details records for the current session, formats them into a conversation thread, and passes them to the agent as context. The database is the state machine.
This means:
- No in-memory session state that disappears on refresh
- No custom session management layer
- The conversation is persistent, queryable, and inspectable by default
- The system can resume a session after a browser close or network drop
How the Data Is Structured
The data model is built around the conversation at its center and supporting context around it.
session — One complete evaluation run. Stores completion status, final score, score reason, session summary, full transcript, and whether it ended by timeout.
session_details — Every single round of the conversation. Stores the presenter's input (initiator_text), the audience response (response_text), an audio version of the response (response_audio), and a timestamped version. This is the table the continue_session agent reads from on every round.
audience — The fake audience member. Stores name, profile, additional info, and a user_simulator field that configures how this persona behaves in the dialogue.
demo_project — The Momen project being demonstrated. Stores name, description, editor URL, publish URL, and crucially: project_schema and project_schema_analysis — a machine-readable snapshot and a human-readable interpretation of the project's architecture, used to give agents accurate context about what's being demoed.
tool and tool_used — A catalog of Momen features (with complexity and intro fields) and a record of which ones were actually demonstrated in a session.
session_mode — Whether the session runs in conversation mode (back-and-forth Q&A) or presentation mode (more monologue-like delivery).
Knowledge base tables — momen_docs, blog_rss, product_philosophy, talks_material, demo_example — Momen product documentation and content used to ground agent responses and scoring in accurate product knowledge.
This structure is configured visually in Momen with relational links between tables. See How to Create Data Models for Your App in Momen.
Nine Agents, Each with One Job
Demo Judge uses nine AI Agents configured separately in Momen. Separating them means each can be prompted and tuned independently.
audience_profile_gen — Generates the fake audience persona from a role and additional context. Called during setup, not during the live session.
question_planner — Pre-plans the questions and challenges the audience member is likely to raise during the session, based on the audience profile and the project being demoed. This runs at setup time so the audience has a coherent strategy going into the conversation.
start_session — Generates the opening context when a session begins. Receives the audience profile and project details, and produces the initial framing for the conversation.
audio_to_transcript — Converts voice input from the presenter into text. Called only when the session receives audio, before the transcript is passed into the conversation flow.
continue_session — The central agent of the multi-round loop. On every round, it receives the full session_details history for the current session plus the presenter's latest input, and returns the audience's next response. This is what makes the conversation feel stateful and contextual rather than isolated.
summarize_session — Called at end of session. Reads the complete conversation history and generates a human-readable summary of what was covered and how the session went.
score_session — Evaluates the full session against the knowledge base and scoring criteria. Returns a numeric score and a written reason, which are saved back to the session record.
tool_classifier — After the session ends, identifies which Momen product features were mentioned or demonstrated during the conversation, and writes those to the tool_used table.
project_schema_analysis — Analyzes the project_schema of a demo_project record and generates a natural-language interpretation of its architecture. This analysis is stored in the project record and used as context for the session agents.
The Actionflows That Wire It Together
Seven Actionflows handle all orchestration. Each one chains database queries, branching logic, and AI agent calls into a single server-side operation.
audience_profile_gen (async) — Setup flow. Generates a unique ID for the audience record, inserts it, then runs five sub-flows to classify which tools this audience persona is familiar with. Calls audience_profile_gen and question_planner agents in sequence. Updates the audience record with the generated profile.
start_session (async) — Called when a presenter begins. Queries the audience record and the demo_project record to build full context. Calls the start_session agent. Inserts the session record and the first session_details record. Updates the audience's current session reference.
continue_session (async) — The multi-round loop engine. Called on every presenter input. Queries the audience profile and the full session_details history for this session. Branches first on input type: if audio, calls audio_to_transcript before proceeding. Then branches on session mode (conversation vs presentation) and calls continue_session agent with the full history as context. Inserts the new session_details record for this round.
end_session (async) — Called when the session closes. Handles the timeout edge case by querying and deleting the last incomplete session_details record if the session timed out mid-round. Calls summarize_session and updates the session record with the summary. Then calls score_session and updates the session with the final score and reason.
tool_classifier (async) — Runs after session end. Calls the tool_classifier agent to identify which Momen tools appeared in the session transcript, and writes the results to tool_used.
project_schema_analysis (async) — Utility flow for setup. Queries a demo_project record, runs a custom code node to pre-process the schema, calls the project_schema_analysis agent, and writes the human-readable analysis back to the project record.
insert_tool_use_if_good — A helper sub-flow called inside audience_profile_gen. Conditionally inserts a tool_used record based on branching conditions.
Why the Database Makes This Work
The continue_session Actionflow is the architectural core. Before every AI call, it runs a database query that fetches every session_details record for the current session, ordered by creation time. That complete history is what the continue_session agent receives as context.
Without this query, each round would be a disconnected single-turn exchange. With it, the agent knows everything the presenter has said and everything the audience has responded with. The conversation is coherent across any number of rounds.
This pattern — database as memory, Actionflow as orchestrator, agent as stateless processor — applies to any conversational AI system: customer support that remembers previous exchanges in a session, an AI interviewer that adapts based on earlier answers, a tutoring system that tracks what a student has already covered. In each case the pattern is the same: every turn is a record, every AI call includes the full history, and the database is the source of truth.
The Frontend
The frontend was built with Claude Code using the Momen no-code plugin. The plugin passed the project context — data model, Actionflow IDs, GraphQL API schema — to Claude Code, and the UI was described in natural language. The frontend connects to Momen's GraphQL API and subscribes to async Actionflow results over WebSocket to show generation progress in real time.
Conclusion
A stateful multi-round dialogue with scoring — the kind of system that usually needs custom session infrastructure — built entirely inside Momen. Nine agents, seven Actionflows, the database as memory.
Top comments (0)