Chaos as the primary form of human dialog

Executive summary. When a dialog bot can’t handle a live conversation, the team almost always blames the user: “they ask out of order”, “they jump around”, “they don’t know what they want”. It’s a convenient explanation and an expensive mistake. Chaos isn’t a user failure — it’s the normal form of human dialog: people remember, associate, worry, change their minds, get distracted. A system that expects a linear conversation loses on most real customers. You must design for chaos, not try to retrain the person — retraining won’t happen.

Watch how people talk to a live manager. They start with one thing, remember a second, return to the first, drop in an anxious off-topic question, then change their mind. The manager copes and doesn’t consider the conversation “wrong”. A dialog bot, on the same input, breaks — and the team concludes that the user broke.

Hypothesis: non-linearity of dialog is the norm, not a deviation

Most dialog systems are designed on an implicit assumption: a proper conversation is linear. The user states a request, answers clarifications one at a time, moves from start to finish without loops. Anything that doesn’t fit, the system treats as noise or an input error.

Our hypothesis is the opposite: a linear dialog is a rare exception, and the norm is chaos. And chaos here isn’t an insult but a precise description of how human speech works. A person remembers mid-sentence. Associates one thing with another and wanders off. Gets anxious and asks an off-topic question, because the anxiety matters more than the topic. Changes their mind on hearing an answer. Gets distracted and returns five messages later to what seemed closed.

These aren’t user bugs — they’re properties of live dialog. The linear scheme doesn’t describe reality; it describes an ideal convenient for the developer, an ideal that almost never exists.

Problem: teams treat chaos as a user defect

When a bot stumbles on a non-linear dialog, the typical reaction is to shift the blame to the person and try to force them into a linear form. Every such move looks reasonable and every one hurts the business.

“Describe your question in one sentence.” A request a live person can’t fulfill, because their question doesn’t exist as a single ready-made sentence — it takes shape as the conversation goes. In response the person either writes incompletely and gets an answer to the wrong thing, or leaves.

Rigid menus and buttons. An attempt to replace chaotic speech with a choice from a list. It works for the simplest tasks and falls apart the moment the person’s question fits none of the items. Then they tap “other” and fall back into live speech the bot isn’t ready for.

“Let’s go in order.” The bot tries to put the user back on a linear rail: answer this first, then that. A person whose head holds anxiety or a new thought ignores that order — and the conversation diverges for good.

The shared root of all three moves is the same: the team treats chaos as an error to be fixed in the user. But the user can’t be “updated”. Chaos will remain, because chaos is what human dialog is — and every “you asked it wrong” is a lost customer. It’s the same substitution as in trying to keep a bot on a rigid script, which we covered in the note on hidden hardcode: an architecture defect is passed off as an input-data defect.

Why the usual approaches don’t work

Suppose the team accepts that chaos is inevitable but tries to handle it cosmetically, without touching the foundation. These attempts don’t hold either.

More recognizable phrasings. Expand the list of phrases the bot understands. But the problem isn’t the set of phrases, it’s the structure of the dialog: even a perfectly recognized message is useless if the bot can’t hold several pending topics and return to them. Understanding a phrase isn’t the same as not losing the thread.

Long memory without management. Just feed the model the entire dialog history and hope it sorts it out. On a long chaotic conversation this backfires: the context bloats, the important drowns in noise, and the model starts losing the goal — what we cover in the note on context entropy. Memory without structure isn’t help, it’s one more source of chaos.

A script with exception handling. Lay down the main linear path and a dozen branches for “non-standard” cases. But in live dialog the non-standard is the norm, and there turn out to be more exceptions than the main path. A tree of exceptions becomes unmanageable and still doesn’t cover reality.

The root in every case is the same: all these approaches remain attempts to reduce chaos to linearity — somewhere at the input, somewhere in memory, somewhere in the script tree. Chaos doesn’t reduce. It has to be made the primary model, not the exception.

Engineering model: design for chaos, not against it

If chaos is the norm, the architecture must accept a non-linear dialog as a regular mode, not a failure. This means several concrete design decisions.

Several open topics at once. The system doesn’t require closing one question before the next. It holds a set of active topics, remembers which are pending, and calmly returns to them when the person does. Jumping from topic to topic is a normal event, not an off-script one. This directly continues the thought from the note that intents don’t exist: a person has several mobile intentions, and all of them must be held.

Reacting to events instead of following a plan. The event-driven model applies here: a topic change, a return to an old one, a new anxiety, a reconsidered decision — these are events the agent responds to, not deviations from a known plan. A linear script assumes the path is known; an event-driven architecture doesn’t, and therefore doesn’t break on loops and jumps.

Managed memory, not a dump. To hold a long chaotic dialog, storing the whole history isn’t enough — you need to separate the active from the finished, keep current goals in focus, and not let the context bloat into noise. This is engineering work with the dialog’s state, not “pass everything to the model and hope”.

Resilience to noise as the metric. The quality of such a system is measured not by how it answers a clean linear request but by whether it loses the goal after twenty minutes of chaos: topic changes, contradictions, distractions, returns. A good agent is one that guides the person to a result through the chaos, not one that demands there be no chaos.

This architecture costs more than a scripted tree and requires a different team. But it’s the only one that works on real people — the very ones a linear bot considers “wrong”.

Practical takeaway for the business

How to hear the problem. If your team describes users with phrases like “they ask out of order”, “they jump around”, “they don’t know what they want” — that’s not a diagnosis of the user, it’s a diagnosis of your architecture. Chaos was and will be there; the question is whether the system is designed for it.

What to commission. For any dialog product that must guide a live customer to a decision — sales, selection, complex support — design an architecture that accepts a non-linear dialog as the norm: several open topics, event-driven reaction, managed memory. It costs more than a scripted bot up front and less in total, because it doesn’t lose customers on every non-standard conversation.

What not to do. Don’t build a product around the idea “we’ll teach the user to ask questions properly” — you won’t. Don’t judge a bot by a smooth demo on a linear script: that’s not how it goes with live people. And don’t treat “unclear” requests as garbage — those are your real customers, and the system must work precisely on them. How to honestly measure readiness for this is in the note on testing AI agents and in RED-driven development.

To understand whether your system is ready for live dialog — talk to an engineer → .

Open questions

How much chaos the current architecture can even hold before it loses the thread itself. Every system has a limit: past some number of open topics and turns, even a well-designed agent starts getting confused. Where that limit is and how to measure it honestly is an open question that runs into the problems of multi-agent systems.

How to tell “productive chaos” from a genuine dead end. Sometimes non-linearity leads to a solution (a person thinking aloud); sometimes it’s a signal that a live operator’s intervention is needed. Where the line is and how to recognize it in the moment is non-trivial engineering, currently handled more by heuristics than by a strict model.

And where the limit of the approach itself lies: there are tasks where chaos is better not “accepted” but gently structured, without turning it into “speak correctly”. The balance between “accept the chaos” and “help the person form the thought” is a fine design fork, and there’s no universal answer to it yet.

If your team explains the bot’s failures by “users asking wrong”, it’s worth looking at the architecture, not the users. Discuss your case → — we’ll figure out whether your system can withstand a live, non-linear conversation.