Rules-based chatbots are not obsolete. They are the right tool for a narrow set of support jobs, and a large language model is the wrong tool for some of those same jobs. The useful question is not "chatbot or agent" but which decisions in a conversation you want made by code you wrote, and which by a model reading your documentation.
"Agentic" now gets applied to everything from a help-center search box with a model on top to a system that plans, calls your internal APIs and retries on failure. Those are very different products with very different failure modes. This post separates them, says where each one fits, and describes where LayBuild sits: a retrieval-grounded LLM with fixed tool calls, not a free-roaming autonomous agent.
Three designs that all get called chatbots
Most support automation falls into one of three shapes. The table compares them on the attributes that matter when something goes wrong.
| Attribute | Scripted bot | Retrieval-grounded LLM | Autonomous tool-using agent |
|---|---|---|---|
| Who decides the reply | A decision tree or intent map you wrote | A model, constrained to retrieved content | A model, which also decides what to do next |
| What it can do | Show fixed text, collect fields, follow branches | Answer questions from your docs | Answer, call APIs, chain several steps |
| Typical failure | Customer's phrasing matches no branch | Plausible answer that is wrong or unsupported | Wrong action, wrong arguments, or a loop |
| How you test it | Walk every branch | Sample conversations, check against sources | Sample conversations and every tool path the model might take |
| Who can change it | Whoever owns the tree | Whoever owns the docs | Engineers, usually |
The columns are not a maturity ladder. Each one moves more decisions from you to the model. That buys coverage of phrasing you never anticipated, and costs you predictability.
Where a scripted bot is still the better choice
A decision tree is deterministic. Given the same input, it does the same thing every time, and you can prove what it will say before a customer sees it. That property matters more than fluency in a few situations.
- Wording that is regulated or contractual, such as a cancellation notice or a disclosure that legal has approved. You want those words exactly, not a paraphrase.
- Structured intake, like collecting an order number in a known format before routing. A form or a two-step script does this with no ambiguity.
- Anything with side effects: refunds, plan changes, account deletion. A scripted flow with explicit confirmation is easier to audit than a model deciding when to act.
- A small, stable set of questions. If your customers ask the same eight things, a tree with eight branches is cheaper to run and easier to trust than a model.
The weakness is well known. A tree only handles the phrasings someone predicted, and compound questions ("my invoice is wrong and I also can't log in") tend to fall through to a generic fallback or a menu loop.
Where a retrieval-grounded LLM wins
Retrieval-augmented generation (RAG) changes what you maintain. Instead of editing branches, you edit documents. The model reads the passages retrieval found for this question and writes an answer from them. That handles the long tail of phrasing, follow-up questions that refer back to earlier turns, and questions that span two articles.
The failure mode also changes. A scripted bot fails loudly: it says it doesn't understand. A retrieval-grounded model can fail quietly: it writes a fluent answer that the sources do not support, or it answers from the wrong passage because retrieval ranked it first. Most of the engineering in a RAG support system goes into narrowing that gap: better retrieval, refusing when nothing relevant was found, and checking the answer against the sources afterwards. None of those checks makes wrong answers impossible, which is why you still need a way to reach a human.
What a fully autonomous agent adds, and what it costs
An autonomous agent runs a loop: the model reads the conversation, picks a tool, fills in its arguments, reads the result, and decides whether to call another tool or answer. This is the pattern usually called ReAct (reason and act). It is what you need if the bot is supposed to look up this customer's order, notice the payment failed, and retry the charge.
The cost is that every step the model chooses is a step you have to defend. The model can pick the wrong tool, invent an argument, or be talked into an action by text in the conversation (prompt injection now reaches your APIs, not just your answer text). Testing gets harder because the path through the tools varies from run to run. Doing this safely takes argument validation against a schema, identity bound from the session instead of taken from the model, explicit confirmation before writes, idempotency keys and a hard cap on loop length. Teams that need two or three actions often find a scripted flow for those actions plus a RAG model for questions is simpler to run.
Where LayBuild sits
LayBuild is a retrieval-grounded LLM with a fixed pipeline around it. The model writes the answer. Code decides whether the model is allowed to answer at all, which tools run, and when a human takes over. The pipeline is a LangGraph state machine:
customer message
|
v
preflight guardrails ---- blocked ----> fixed refusal
(blocked terms, injection patterns,
off-topic patterns)
|
v
Q&A pair match? ---- yes ----> stored answer, no model call
|
v
hybrid retrieval (Qdrant vectors, Postgres full-text,
Q&A pairs, knowledge graph)
|
+---- nothing relevant ----> fixed "I do not have specific information" reply
|
v
LLM generates answer from retrieved passages
|
v
grounding check ---- too little overlap ----> fixed reply
|
v
API tools (configured defaults, first success attached)
|
v
output guardrail (PII redaction, length cap)
|
v
handoff checkA few details matter for the comparison above.
LayBuild already has a scripted path. If an incoming question matches a stored Q&A pair (case-insensitive exact match, or a near-duplicate of one of the 100 most recently updated pairs), the stored answer is returned as written and no model is called. If you have wording that must not change, put it in a Q&A pair.
Strict knowledge-base mode is always on. When retrieval returns nothing, the model is skipped and the customer gets a fixed reply. After generation, if fewer than 25% of the answer's stemmed words appear in the retrieved sources, the answer is replaced with the same fixed reply. That check is lexical overlap, not citation verification. It can let a wrong answer through if it reuses the source vocabulary, and it can block a correct answer that paraphrases heavily. We chose a cheap, predictable check over a second model call on every reply; an optional model-based reflection check exists but is off by default.
API tools are not function calling. The model never picks a tool or fills in arguments. After the answer is generated, every tool attached to the agent is called with its configured default parameters, and the first successful result is attached to the reply. That removes a class of failures (hallucinated arguments, injected tool calls) and also removes a class of capabilities: LayBuild cannot look up one customer's order by itself. We cover this in detail in the API tools post.
Handoff is rule-based. A human takes over when the customer asks for one (matched by patterns like "talk to a human" or "escalate") and the organization has enabled handoff, which is off by default, or when a conversation passes 25 AI replies. There is no sentiment detection and no model deciding it is out of its depth.
The trade-off we made, stated plainly
A fully autonomous agent would finish some conversations that LayBuild hands to a person or answers with "I do not have specific information about that." We accepted that. In exchange, the set of things LayBuild can do in a conversation is fixed and inspectable: it can answer from your content, refuse, attach the result of a tool you configured, or hand off.
There are other limits worth knowing before you choose. The default embedding model and the full-text search are English, so retrieval for non-English questions against English documents is weaker, even though the model is told to reply in the customer's language. And LayBuild's learning loop publishes some answered exchanges back into the knowledge base without human approval (retracted if the customer rates the conversation 2 stars or lower), which saves curation time but means an unreviewed answer can become a future source.
Choosing for your team
- If your support volume is a small, stable set of questions and most of them lead to an action, start with scripted flows and a clear path to a human.
- If most tickets are "how do I" and "why does" questions answered somewhere in your docs, a retrieval-grounded model covers far more phrasing than a tree, as long as it refuses when retrieval comes up empty.
- If the bot must act on individual accounts, you need function calling with validation, confirmation and audit, or a scripted flow for those actions. Do not bolt actions onto a model that was designed only to answer.
- Whatever you pick, measure it on transcripts, not on how often the bot replied.
Related reading
- What counts as resolved when an AI agent answers: how to measure outcomes without inflating them.
- API tools without function calling: how LayBuild's tools work and what full function calling would need.
- Preventing hallucinations in customer support: more on the grounding checks.
- Hybrid search with Qdrant: how the retrieval legs are combined.