From intents to LLMs

The classic pipeline

Before large language models, most assistants followed the same pipeline. It is still how many contact-center bots work, and its vocabulary is everywhere.

User utteranceIntent classificationSlot fillingDialog managerFulfillmentTemplated reply

The classic intent-based pipeline.

Utterance: what the user said or typed.
Intent: the goal, such as BookFlight or CheckOrderStatus.
Slots (entities): the details the intent needs, such as destination or date.
Dialog manager: decides what to ask next and tracks what is still missing.
Fulfillment: calls your systems to do the work.

Slot filling in an intent-based bot

I want to fly to Lisbon

Which day would you like to leave?

next Friday

Got it, Lisbon on Friday. One passenger or more?

This is predictable and easy to test. Its weakness is coverage: anything outside the trained intents falls into a "didn't understand" fallback, and users must learn the bot's phrasing.

What language models changed

A large language model reads text as tokens (pieces of words) and predicts what comes next. Trained at huge scale, it picks up grammar, facts, and a surprising amount of reasoning. For assistants, three consequences matter.

Instructions replace training data. Instead of collecting hundreds of example utterances per intent, you describe the task in plain language, perhaps with a few examples. That makes the first version fast to build.

Everything is context. The model has no memory between calls. Each request includes whatever you choose to send: your instructions, the conversation so far, retrieved documents and tool results. All of it must fit in the context window, and the model pays more attention to some parts than others. Managing that context is a core design job.

Output is probabilistic. The same input can produce different replies. That helps with natural language and hurts with exact procedures, so you will wrap the model in checks (module 9 and module 14).

Embeddings: meaning as numbers

An embedding converts text into a list of numbers so that texts with similar meaning land close together. "Reset my password" and "I can't log in" end up near each other even though they share no words. Embeddings power semantic search (module 6), routing, deduplication and clustering of conversations.

Use the LLM as a language-understanding component

You don't have to hand the whole conversation to a model. A powerful pattern is to use it only to understand the user, and return structured data your code can trust.

python
import json

SCHEMA = {
    "intent": ["change_booking", "cancel_booking", "policy_question", "other"],
    "slots": {"booking_code": "string or null", "new_date": "ISO date or null"},
}

PROMPT = """Classify the customer's message.
Return only JSON like: {{"intent": "...", "slots": {{"booking_code": null, "new_date": null}}}}
Allowed intents: {intents}
Message: {message}"""

def understand(message: str, call_llm) -> dict:
    raw = call_llm(PROMPT.format(intents=SCHEMA["intent"], message=message))
    try:
        data = json.loads(raw)
        assert data["intent"] in SCHEMA["intent"]          # validate, never trust
        return data
    except (ValueError, KeyError, AssertionError):
        return {"intent": "other", "slots": {}}            # safe fallback: ask a clarifying question

Most model providers now offer structured-output or tool-calling modes that constrain the response to a schema, which is more reliable than asking nicely in the prompt. Even then, keep the validation step.

NLU or LLM? A decision guide

Both approaches are good tools. The mistake is choosing one by fashion. Work through the questions below, then use the helper.

Question	Points toward classic NLU	Points toward an LLM
How wide are the requests?	A handful of known tasks	Open-ended, long-tail requests
Do you need exact wording or an audit trail?	Yes: legal text, payments, confirmations	No: flexible phrasing is fine
How many languages?	One or two, with data in each	Many, with little data per language
Do you have labeled examples?	Hundreds per intent	Few or none
What is the cost and latency pressure?	Extreme: huge volume or voice with tight budgets	Normal
How often do topics change?	Rarely	Often
How bad is a confident mistake?	Very bad: prefer constrained choices	Tolerable with grounding and checks

Try it: a quick helper that weighs those questions. It is a thinking aid, not a verdict, so test your real traffic before deciding.

Range of requests

Exact wording or audit trail needed?

Languages to support

Labeled examples available

Cost and latency pressure

How often topics change

The usual answer is a hybrid

NLU or rules for high-stakes, high-volume, well-defined steps: identity, payments, confirmations and phone menus.
An LLM for understanding messy input, the long tail of questions, summarizing, drafting and handling languages you lack data for.
A router between them, with confidence thresholds and a handoff (module 8).

A small, fast classifier can sit in front of everything: confident, known intents go to the deterministic path, and everything else goes to the model.

What did not change

The user still wants something done. They still get frustrated by being misunderstood, still need to know what the assistant can and cannot do, and still need a human when it fails. Models changed how we understand language, not what makes an experience good.

In short

What you will learn