8 Agent Intent Recognition Methods: From Keyword Matching to Hybrid LLM Routing

1. Keyword and Rule Matching

The simplest approach uses keywords, regular expressions, and if‑else logic to classify intent. For example, phrases like “refund”, “money back”, “don’t want it” map to a refund request; “human agent”, “talk to a person” trigger handoff.

Pros: fast to develop, low cost, results are explainable. Ideal when intent count is small and business rules are clear. High‑risk operations (account deletion, bulk export, limit changes) should always be guarded by rules first.

Cons: misses paraphrases (“I don’t want this anymore” lacks “refund”). Rules grow into a “tropical rainforest” of code as more keywords are added.

2. Traditional Classification Model

Prepare a labeled dataset and train a dedicated text‑classification model. Input user query → output fixed labels (refund, complaint, order query).

Pros: low latency, low per‑call cost, stable performance with sufficient quality training data. Suits high‑volume, stable‑intent customer‑service systems.

Cons: depends on annotated data; adding a new intent requires new samples and retraining. Unseen expressions often cause confident misclassification.

3. LLM Prompt Classification

Place the intent list, business definitions, and few‑shot examples in the prompt; let the LLM classify directly.

Pros: rapid cold start — no need for thousands of labeled samples. Adding “change shipping address” only requires updating the prompt with description and examples.

Cons: prompt must define boundaries, confusing cases, and fallback behavior. Without that, “refund inquiry” and “refund execution” collapse into one label, causing the agent to call the refund tool prematurely.

4. Embedding Semantic Routing

Convert user query and each intent description to vectors, compute semantic similarity , pick the closest intent.

Example: “when will money return via original route” contains no “refund progress” but is semantically close, so it recalls the correct intent.

Pros: fast, relatively low cost, scales to many intents.

Cons: good at “what it looks like”, not “what it actually is”. Typical pattern: embedding recalls top‑k candidates, then LLM makes final decision.

5. Tool‑Description‑Driven Selection

In tool‑calling agents, give each tool a clear name, description, and parameters; the LLM selects the tool based on user goal.

Example: “where is my order” → query_logistics; “cancel order” → cancel_order.

Pros: short chain — intent recognition and tool call in one step.

Cons: heavily dependent on tool descriptions. Similar descriptions (query refund policy vs. execute refund) cause wrong selection. For money, deletion, or state changes, add permission, parameter, and business‑rule checks beyond model choice.

6. Hierarchical Intent Routing

When dozens or hundreds of intents exist, stuffing all labels into one prompt hurts accuracy. Use two‑level routing:

Level 1: coarse domain — order, after‑sales, finance, complaint, general.

Level 2: fine‑grained within domain — e.g., after‑sales splits into refund apply, refund status, exchange, repair.

Analogy: find the floor first, then the room. Each step chooses from a small set, improving accuracy and allowing separate teams to maintain their own intent sets.

7. Context‑ and State‑Aware Recognition

Many queries are unintelligible without history. Example:

User: “Can order 10001 be refunded?” → System: yes.

User: “Then refund it.”

Classifying only “Then refund it” misses order ID and product; must combine historical messages to infer refund for order 10001.

Also incorporate workflow state . If user is at the refund‑confirmation node and says “confirm”, it means confirm refund, not casual chat. Process‑oriented agents must track the current step.

8. Combined Rule, Vector, and LLM Pipeline

Real‑world enterprise systems often combine all three:

Rules catch high‑risk intents (handoff, data deletion, refund execution).

Embedding recalls a few candidate intents.

LLM uses context to make the final precise classification.

If confidence is low, do not force a choice — ask for clarification or escalate to human.

Full pipeline design:

Final output should be structured data, not a raw string:

{
  "intent": "REFUND_APPLY",
  "subIntent": "ORIGINAL_PAYMENT_REFUND",
  "confidence": 0.91,
  "entities": {
    "orderId": "10001"
  },
  "needClarification": false,
  "route": "refundWorkflow"
}

Important: the model’s self‑reported confidence ≠ true accuracy. A claimed 98% confidence does not guarantee 98% correctness. Production systems must evaluate with test sets using Accuracy, F1, confusion matrix, and unknown‑intent rejection rate.

Selection Guidelines

Only 5‑6 fixed intents → rules + prompt is enough.

Many intents → embedding recall + LLM fine classification .

Complex business hierarchy → hierarchical routing (default choice).

High‑risk operations (money, permissions, state changes) → rules + human review as safety net .