Foundations · Explore this field ↗ · Start here · 2 min read
What a chatbot actually is
A practical system definition—from the message box to the policies, tools, people, and failure paths behind it.
The whole system, not the bubble
A chatbot is a user interface wrapped around a decision system. The visible conversation may be text, speech, or an embodied character, but the useful unit is larger: channel, identity, dialogue state, knowledge, tools, policy, logging, and human operations. A model can generate language while another component decides whether a refund is allowed. A retrieval layer may supply the policy; an authenticated service may perform the action. Treating all of that as ‘the bot’ makes responsibility blurry. A better architecture names every boundary and records which component can read, decide, and change data.
Four operating modes
Most systems combine four modes. A scripted flow handles high-stakes or tightly structured work. Retrieval answers questions from approved material. A generative layer interprets messy language and writes responses. An action layer calls services. The proportions should follow risk. Password resets and payments need more deterministic control than a question about store hours. Google’s Dialogflow documentation explicitly distinguishes deterministic flows from generative features, a useful reminder that ‘uses an LLM’ is not an architecture.
A conversation is a sequence of commitments
Each turn should make a limited commitment: what the system understood, what it needs next, what it changed, and what the user can do if the interpretation is wrong. Good conversational products therefore resemble well-designed forms more than improvisational theater. They collect only necessary information, show progress, confirm consequential actions, preserve recoverable state, and make correction cheap.
Operator note
Write a one-page system card before implementation. List users, channels, jobs, data sources, tools, irreversible actions, handoff destinations, retention rules, and owners. Then draw the turn path for one successful task and three failures. If the diagram cannot show where a human takes over, the service is not ready to be called autonomous.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.