NLP chatbots in 2026: what changed and what still matters

An NLP chatbot used to mean one specific architecture: classify the user's sentence into an intent, pull out the entities, then walk a dialogue tree. That architecture is still running in thousands of production systems, and it is no longer how new assistants get built.

This is what changed, what survived, and how to tell which of the two you should be building.

What an NLP chatbot was

The classic design has four parts. An intent classifier decides what the user wants. An entity extractor pulls the values out of the sentence, such as a date or an order number. A dialogue manager tracks where the conversation is. A set of rules or a tree decides what happens next.

Rasa, whose framework popularised the pattern, is blunt about its limits in its own documentation. Intent-based assistants classify each message "without the context of the full conversation". Their logic is "predefined in large dialogue trees, breaking if users deviate". Accuracy degrades as you add topics, because the intents start to overlap (Rasa CALM documentation).

Anyone who has maintained one recognises all three. The bot works until a user says two things in one sentence, or changes their mind halfway, or asks something adjacent to an intent that was never written.

What replaced it

The new pattern uses a language model for understanding and keeps deterministic code for the parts that must not improvise.

Rasa's own answer, CALM, describes itself as "an LLM-native approach". The model interprets the message in context and emits internal commands. Business logic stays in structured flows that the model routes between. Google took the same direction in Dialogflow CX with playbooks. Its documentation calls them "the basic building block of generative agents", where "the playbook data is provided to the LLM, so it has the information it needs to answer questions and execute tasks" (Dialogflow CX playbooks).

Both vendors landed on the same shape, which is the useful signal. Neither replaced the deterministic layer. Google's documentation describes playbooks that can "defer conversation handling to a flow", and Rasa keeps business logic in flows the model routes between rather than invents.

The part that still matters

Move the money, personal data, and irreversible actions out of the model's hands. A language model is good at deciding what the user means and bad at guaranteeing what happens next.

In practice that means a refund is a tool call with validation and a limit, not a sentence the model composes. A cancellation writes through the same service the web app uses, with the same authorisation checks. The model chooses which tool, and code decides whether it is allowed.

The second thing that survived is grounding. If the assistant answers from its own weights, it will answer questions about your pricing with text that reads like your pricing. Answers need to come from documents you maintain, with the source attached, or the assistant becomes a liability the moment a policy changes.

What you need before shipping one

1. A corpus you own and update. Help pages, policies, product documentation. If it contradicts itself today, the assistant will contradict itself in front of customers.
2. Tools with real contracts. Typed arguments, validation, and permission checks in code, not in the prompt.
3. An evaluation set. Fifty to two hundred real questions with known correct answers, rerun after every prompt or model change. Without it, every change is a guess.
4. A handover path. What the assistant refuses, and where the conversation goes when it does. Containment is not the goal if the contained conversations end badly.
5. A logging decision. What is stored, for how long, and whether transcripts carry personal data. Decide before launch, because retrofitting redaction is painful.

How to tell which one you need

If the task is narrow, high volume, and never changes, an intent-based bot is still cheap, fast and predictable. Order tracking with three variants does not need a language model.

If users ask in their own words, if the question set keeps growing, or if the answer lives in documents rather than in a tree, the LLM-native design is the one that will not need rebuilding in a year.

Most real deployments end up hybrid, which is what both Rasa and Google now describe: the model for understanding and routing, deterministic flows for the steps that must behave the same way every time.

Where we fit

Cubitrek builds the hybrid version: retrieval over your own content, tools with validation around anything that changes state, an evaluation set you can rerun, and a defined handover to a human. If you have a bot that breaks whenever a customer phrases something new, that is usually an architecture problem rather than a training-data problem. Our AI agents and AI automation work covers it, and a 15-minute call is enough to tell whether it is worth rebuilding or worth leaving alone.