Most citizen-facing government chatbots are not powered by a single black-box model guessing at the next reply — underneath the friendly chat window sits a dialogue state machine: a graph of named states ("awaiting property ID", "confirming permit type", "handed off to human") connected by transitions that only fire when the system's understanding of the current message matches what that state expects. This keeps the conversation predictable and auditable, which matters when a bot is quoting a fee, confirming a filing deadline, or logging a report that a council must action.
This simulation renders that graph directly: a start state fans out into three service intents — Property Tax, Permit Application and Report an Issue — plus a direct "Talk to a Human" exit, and each branch walks through its own slot-filling states before merging back at "Anything else?". Click through the built-in example messages (or type your own) and a small rule-based NLU layer decides, from the current state and the text you sent, which state to move to next — including looping back on itself if a required slot wasn't found, exactly like a production dialogue manager would.
What is a dialogue state machine and how does it differ from a single intent classifier?
A single intent classifier looks at one message in isolation and outputs a label — "property tax", "permit", "complaint" — with no memory of what came before. A dialogue state machine instead tracks a current state (e.g. "awaiting property ID") and only accepts transitions that make sense from that state, using the incoming message to decide which edge to follow. This lets the same word mean different things in different states — "123 Oak Street" is an address when the bot is asking for one, and meaningless noise otherwise — and lets the system remember what has already been asked and answered across many turns, not just the last message.
What does "slot filling" mean in a conversational AI system?
Once an intent is known (say, "Permit Application"), the system usually still needs several pieces of structured information — called slots — before it can act: an address, a permit type, maybe a date. Slot filling is the process of extracting each of these values from the user's free-text replies and writing them into a small structured record. A permit request is not actionable until every required slot (address, permit_type) has a value; the dialogue manager's job is to keep asking for whatever is still empty.
Why does the bot loop back when a slot is missing instead of just asking once?
Real users often answer a different question than the one asked, go off topic, or give an answer the extractor cannot parse ("the big one near the school" is not a parseable address). If the state machine simply moved on regardless, it would try to look up a permit with a missing address and fail silently or crash downstream. Instead, the "ask" state has a self-loop: if the expected slot pattern is not detected in the reply, the machine stays in the same state and re-prompts. This loop is exactly what this simulation counts as a "slot-fill loop" — a real, measurable signal of how much friction a turn caused.
Hand-off is triggered either explicitly — the citizen says "talk to a person" — or implicitly, when the same slot-fill loop fires more than a couple of times, when the intent classifier's confidence stays low across several turns, or when the request touches something the bot is not authorised to resolve. Routing to a human early, before the citizen gets frustrated, is treated as a success metric in well-designed systems, not a failure — an efficient hand-off is far better than a long dead-end loop.
A large language model can handle open-ended phrasing, mixed intents in one sentence and follow-up questions without a hand-authored graph, because it generates the next response from a learned distribution over language rather than by matching keywords. That flexibility comes at the cost of predictability: an LLM can wander off-script, hallucinate a policy, or accept an address it never actually validated. A rule-based state machine like this one is far less flexible about phrasing, but every path through it is enumerable, testable and auditable — which is why many government and regulated systems still pair an LLM front-end with a deterministic state machine or slot-validation layer underneath for anything that has legal or financial consequences.
Intent detection answers "what does the user want to do" — pay a bill, apply for a permit, report a pothole — and is usually decided once near the start of a conversation. Entity or slot extraction answers "what specific values did they give me" — an address, a permit type, a date — and can happen on almost every turn as the conversation fills in the details needed to act on the intent. A message can carry both at once: "there's a pothole on Main Street" sets the intent (report_issue) and can fill a slot (location) in a single utterance, which this simulation's NLU handles by checking both patterns against every incoming message.
Government services are bound by rules that must be applied consistently and defensibly — the wrong permit fee quoted, or a tax deadline miscommunicated, has real consequences and can be subject to freedom-of-information or audit requests. A finite state machine guarantees that certain steps always happen in the same order and can never be skipped, and every possible path through the conversation can be listed and tested in advance. That auditability and predictability is usually worth more to a public body than the more natural conversation a pure LLM could offer.