Intents don't exist

Executive summary. Most chatbots are designed around the idea that the user has one clear intent, which the system guesses and processes step by step. In a demo it looks flawless; in production it breaks on the very first live message. People rarely arrive with a single intention — they hold several at once and shift them as the conversation goes. A bot built on a rigid intent scheme loses those people, and revenue with them. This isn’t an under-tuned prompt — it’s a flaw in the foundation.

Open any dialog-bot slide deck and you’ll see the same scheme: the user says a phrase, a classifier determines the “intent”, the system collects the missing “slots” and produces a result. It’s a clean engineering picture, and it has almost nothing to do with how people actually talk.

Hypothesis: a live user has no single intention

The classic NLU model (Natural Language Understanding) assumes that at every moment of the dialog the user has exactly one intention, and the system’s job is to recognize it. The entire industry of scripted bots rests on this: a tree of intents, slot forms, transitions between states.

Our hypothesis is simpler and less pleasant: there is no single intention. A person writing to support or to a sales chat usually holds several things in mind at once. “I want to know if there are spots in July, and also whether I can bring a dog, and honestly whether I’ll regret the money at all” — that’s not one intent to classify. It’s three intentions tangled into one message, none of them fully formed yet. And two messages later a fourth appears that wasn’t there at the start.

An intention isn’t recognized — it forms and mutates right inside the dialog. A system that tries to collapse this into a single label loses most of the meaning at the input.

Problem: the scheme breaks on the very first live message

A rigid intention → slots → result scheme demands of the user what they don’t do: speak one intention at a time, in the right order, without deviating. Reality looks different, and every deviation is a point of failure.

Several intentions in one message. The classifier must pick one. Any choice is a loss: either the system ignores part of the request, or it drags the person down a branch that closes only a third of their question.

The intention changes mid-stream. The user started with “book it”, realized halfway that they hadn’t settled on dates, and effectively moved to “help me choose”. The scripted bot doesn’t notice — it’s still collecting slots for the booking and asking for a card number from someone who hasn’t even decided whether they’ll go.

The wording doesn’t fit a label. Live speech rarely matches what the developer named the intent. “I’m not sure it’s worth it” is neither intent: complaint nor intent: booking. It’s a doubt to work with, not to classify.

In a scripted architecture, every such case turns into “didn’t understand, please rephrase” or, worse, into a confident answer to the wrong question. It’s the same disease we covered in the note on hidden scripted hardcode: rigid logic wired for the ideal path falls apart on live input.

The chart is about something else — data exchange between machines — but it shows exactly the pattern that kills the intent scheme. The more strictly the exchange is formalized and the closer the input is to the expected format, the more reliable the result. A rigid intent scheme holds only when the input is tidy and predictable. A live person feeds in free text in the least convenient form — and recognition reliability drops precisely where the cost of error is highest: on the hesitant customer you could still have kept.

Why the usual approaches don’t work

When a scripted bot starts losing people, the team usually treats the symptom, not the cause. And none of the familiar moves fixes the foundation.

Add more intents. It seems logical: not enough branches — add more. But the problem isn’t the number of labels, it’s the very idea of a label. No matter how finely you split, the person still arrives with a combination that isn’t on the list, or with an intention that only forms by the third message. More intents means more points where the classifier errs and a more brittle transition tree.

Improve the classifier. You can raise single-intent recognition accuracy from 85% to 95%. But that solves the wrong problem: we’re picking one label ever more precisely where intentions are multiple and moving. A precise answer to a wrongly posed question stays wrong.

Make the user speak “correctly”. Menus, buttons, “pick one of the options”, “describe your question in one sentence”. This tries to push the architecture’s flaw onto the user — to train the human into a scheme convenient for the bot. It sometimes works for simple lookups, but the moment the task is a bit harder than picking from a list, the person falls back into live speech and the bot fails again. We explore why “training the user” is a dead end in the note on chaos as the norm of dialog.

The root is one: an intent is an abstraction convenient for the developer, not a description of what’s happening in a person’s head. As long as the architecture rests on it, any improvement remains polish on the wrong foundation.

Engineering model: intention as state, not as a label

If intentions are mobile and there are several of them, the dialog must be modeled not as classification but as work with changing state. This is the shift from a scripted bot to a real agentic architecture.

Several intentions live at once. The system doesn’t pick a “main intent” — it holds a set of the user’s active goals and tracks which have advanced, which appeared, which dropped off. The message “can I bring a dog?” in the middle of a booking doesn’t reset the booking context — it adds another goal to hold and close.

An intention is a state that evolves. Instead of a tree of transitions between fixed intents, the system maintains a picture of current goals and updates it on every message. The shift “I want to book” → “help me decide” isn’t a failure or an off-script event but a normal change of state, to which the agent responds by changing behavior: it stops collecting booking data and starts helping with the choice.

Reacting to events, not following a plan. The same logic applies here as in event-driven AI systems: a dialog is a stream of events (a new goal, a changed goal, a contradiction, a return to an old question), and the agent is what responds to them. Linear slot filling assumes the plan is known in advance; the event-driven model makes no such assumption and therefore survives what the script breaks on.

Technically this costs more than a scripted tree: you need a model able to hold several goals and their history, and a loop that doesn’t fall apart when the intention changes. But it’s the only architecture that works on live people, not on those who play along with the bot.

Practical takeaway for the business

How to test your bot. Take ten real dialogs from your support or sales — not scripted ones, live ones. See in how many of them the customer had exactly one intention, stated up front and unchanged to the end. Usually they’re a minority. That minority is the share of dialogs the intent architecture is built for; everything else it handles poorly.

What to commission. If your dialog product has to sell, retain, or guide a customer toward a decision — not just hand out lookups by button — design an architecture that works with a mobile state of intentions, not a tree of intents. There’s a difference in development cost, but it’s incomparable to the cost of customers a scripted bot silently loses every day.

What not to do. Don’t judge a bot by intent-classification accuracy — that’s the metric of a correctly solved wrong problem. Don’t try to “retrain the user” to speak in bot-friendly phrases: people don’t do that, and every “didn’t understand, please rephrase” is a lost customer. And don’t trust a demo where an operator carefully steers the dialog down one branch: that’s not how it goes with live people.

To understand where your bot loses people — talk to an engineer → .

Open questions

Where is the line beyond which an intent scheme is justified after all. For truly simple tasks — checking a balance, an order status, opening hours — a tree of a few intents may be cheaper and more reliable than an agent. The question is how to honestly tell “a script is enough here” from “a script silently loses money here”, and not to pass off the second as the first.

How to measure system quality without the notion of “intent”. If intentions are multiple and changing, the familiar “percent of intents correctly recognized” loses meaning. What metric replaces it is a separate engineering question; the short answer is that you must measure the outcome for a live person, not label accuracy along the way.

And how much intention mobility the current model can even hold before it itself starts losing the goal in a long, chaotic dialog — that runs into the problems of multi-agent systems and context entropy, and no one has named an honest limit here yet.

If your bot answers simple questions well but loses customers the moment the conversation turns live, the cause is almost certainly the intent architecture under the hood. Discuss your case → — we’ll figure out which dialogs your system breaks on and what to do about it.