How Do AI Agents Classify Search Intent Across Multi-Step Tasks?

Search intent classification used to be a one-shot decision. A query arrives, a model assigns a label, the pipeline fires. That architecture worked when search was a vending machine: insert query, receive document list. AI agents broke the assumption the moment they started chaining tool calls across multiple steps, because the user's intent at step one is often not the same intent that needs satisfying at step five.

We've read through the 2026 agentic search trajectory research and the production engineering literature on this, and the gap between how classification is theorized and how it actually behaves in deployed systems is wider than most vendor documentation admits. The article below traces the full problem: what classification means when an agent is mid-task, how LLMs changed the underlying method, where multi-step trajectories break single-query assumptions, what a richer taxonomy looks like, how the pipeline steps execute, how routing turns classification into action, and where the whole system falls apart in production.

What Is Search Intent Classification in an AI Agent System?

Search intent classification is the process by which an AI agent analyzes a user's query, infers the underlying goal, and assigns it to an intent category so the agent can route the request to the right tool, workflow, or response type. It is not keyword matching. A keyword is the literal string typed; intent is what the user is trying to accomplish, and two queries can share every word while meaning entirely different things depending on context.

The four canonical categories most practitioners know, informational, navigational, transactional, and commercial investigation, still form the taxonomic foundation. But in agentic systems, those four categories function as a starting point, not a complete solution. Modern agents extend the taxonomy with sub-intents that map more precisely to task execution: declarative goals (retrieve a fact), procedural goals (execute a method), and reasoning goals (synthesize across sources and make a judgment). The classification step determines which of these the user needs before the agent spends a single token on retrieval or generation.

In practice, classification is a routing layer. The agent reads the query, scores it against intent categories, and dispatches: send this to the search tool, send that to the booking handler, escalate this ambiguous one for clarification. Larger production systems often use a dedicated router rather than relying on a general-purpose LLM to handle routing inline, because dedicated routing is more reliable and cheaper at scale. Confidence scoring is standard: a well-designed classifier returns a primary intent label, secondary intent candidates, a confidence score, and a reasoning trace before any action fires. Conversation history feeds into that scoring, because prior turns help the model infer current goals that the surface query alone wouldn't reveal.

How Do AI Agents Classify Intent Differently Than Traditional Keyword-Based Search Engines?

AI agents classify intent by modeling meaning from context and conversation history, while keyword-based systems match tokens against rule-based buckets. Before BERT, a traditional keyword-based system asked "does this query contain the words my system recognizes?" An AI agent asks what the user is trying to accomplish, given the wording, context, and conversation history. Google's BERT deployment made this shift visible to the industry.

The architectural difference is significant. Keyword-based systems rely on surface-level token lookup and rule-based intent buckets. A query containing "buy" routes to transactional; a query containing "what is" routes to informational. Those heuristics work until they don't, and they fail on any query where the same words carry different intent depending on context, or where different words carry identical intent.

Google's MUM extended this further, handling complex multi-step intents across modalities, the kind of query that isn't a single information need but a composite task requiring synthesis across sources. Bing's integration of GPT-class models into Microsoft Copilot follows the same architectural logic: the model reads intent from meaning, not from token presence.

This matters for SEO because a page optimized around exact-match keywords for a transactional query can lose retrieval to a page that better matches the entity-attribute-value structure the agent expects for that intent category, even if the keyword-optimized page has more backlink s.

How Does Agentic Intent Classification Handle Multi-Step Task Trajectories Instead of Single Queries?

Intent in agentic systems is a dynamic property that shifts across agent actions, tool calls, and intermediate results, not a static label attached to the initial query. A user who starts with what looks like an informational request ("what are the best project management tools for remote teams?") pivots to commercial investigation once the agent surfaces a comparison, then to transactional once a pricing page loads. Any classification system that fires once at query ingestion and then hands off is architecturally mismatched to this.

The default agent loop is plan, act, check, adapt. Intent classification should operate at every checkpoint in that loop, not just at the front door. Decomposing a complex goal into ordered sub-steps helps here: when the agent tracks what's done, what's in progress, and what's failed, it has evidence about whether the current trajectory still aligns with the original intent or has drifted into something else.

Intermediate artifacts matter as a classification signal. Scratchpads, partial summaries, structured files, and tool outputs all carry information about what the agent is actually trying to accomplish. A reflection step, essentially asking "are we still solving the right problem?", reduces the rate of silent misrouting on long-horizon tasks. Some architectures add reviewer gates that verify claims against the stated goal and escalate when the trajectory has diverged past a confidence threshold.

The trajectory optimization work in SE-Agent describes revisiting and recombining previously generated trajectories to improve decision-making. Intent understanding strengthens when the system compares multiple candidate action paths rather than committing to a single classification at query time. That is a materially different design philosophy from single-event classification, and it's the one worth building into any production system handling tasks longer than two or three steps.

Single-event classification isn't just imprecise on long tasks. It fails silently. There is no error signal when a user's intent evolves and the pipeline doesn't notice, so the agent keeps executing toward the wrong goal.

What Are the Intent Categories AI Agents Use Beyond Informational, Navigational, and Transactional?

The four-category model was built for web search, not task execution. Modern AI agents use a substantially richer taxonomy, and the extensions aren't academic , they map to real routing decisions that the classic four buckets can't handle.

Commercial investigation is the one most SEO practitioners already know: the user is comparing options before a decision, bridging informational and transactional. But agentic systems need several more categories to function correctly.

Exploratory intent covers open-ended discovery where the user doesn't have a precise target yet. Routing an exploratory query to a transactional handler is a common failure mode, pushing a purchase flow at a user who is still in early research mode.

Procedural and instructional intents are distinct from informational. A user who wants to know what something is has informational intent. A user who wants step-by-step guidance on how to do something has procedural intent. The content format those two intents require is different, the retrieval strategy is different, and the success metric is different.

Clarifying intent is the category most systems handle worst. The query is ambiguous enough that the right action is a follow-up question, not a retrieval attempt. Forcing a label onto an ambiguous query and routing it anyway produces confident wrong answers, which is the failure mode that erodes trust fastest.

Orchestrated intent marks the start of a chain of related actions rather than a single isolated task. Ambient intent flips the model entirely: the system delivers context-triggered updates without waiting for a direct query. Analytical intent wants reasoning and evaluation, not retrieval. Creative intent wants original output.

If your pages are optimized for informational, navigational, or transactional signals but an AI agent is routing queries through procedural, exploratory, or analytical categories, the mismatch in entity-attribute-value structure reduces retrieval probability regardless of traditional ranking signals.

What Are the Pipeline Steps AI Agents Follow to Classify Search Intent?

The classification pipeline has four core stages, and understanding where each one fails is more useful than knowing the stages in the abstract.

1. Ingest and normalize the query. Attach a trace ID, redact PII, and strip noise. This step is boring but its absence causes hard-to-debug downstream failures.
2. Retrieve exemplars. Embed the query and pull back three to five similar labeled examples from a vector database. These ground the classification by giving the model concrete anchors rather than asking it to classify from first principles on every request.
3. Classify with a compact model call. A small LLM call returns a structured label, not free-form text. Schema-constrained output matters here; free-form classification responses are harder to validate and route programmatically.
4. Validate, score, and route. Schema checks, a deterministic fallback for out-of-distribution queries, and an optional judge model attached to the trace. The output of this stage is the intent label plus a confidence score that the routing layer reads.

Semantic embeddings are what make step two possible at scale. Transformer architecture, the attention mechanism that BERT pioneered, allows the model to represent query meaning as a position in embedding space rather than as a bag of tokens. Queries with similar meaning cluster together regardless of surface phrasing, which is why "cheapest project management software" and "low-cost PM tools for startups" retrieve the same exemplars and receive the same intent label.

For search-focused agentic systems, the pipeline extends beyond these four stages. After classification, the agent selects a retrieval strategy matched to the predicted intent, searches across relevant collections, refines candidates with a small model, validates query constraints, and only then sends evidence to a larger model for final synthesis. Intent classification is not the endpoint; it is the decision layer that determines how search proceeds.

A classification that returns with 0.51 confidence and no fallback logic is worse than a classification that abstains and asks a clarifying question.

How Does Intent Classification Drive Routing Decisions in a Production AI Agent Pipeline?

Routing is where classification errors become user-facing failures, and it is the most underappreciated bottleneck in production agentic pipelines. A classifier that correctly identifies intent but dispatches to the wrong downstream agent still produces a bad outcome. Classification accuracy and routing accuracy are distinct engineering problems with different failure modes and different remediation strategies.

The sequencing is: classify first, route second, execute third. That order reduces latency, limits unnecessary tool calls, and makes scaling tractable because each handler only receives the requests it was built to solve.

Production routing is often hierarchical. Classify the broad domain or topic first, then classify the specific action or sub-intent. That two-stage approach reduces confusion between similar intents that would be hard to distinguish in a single flat layer. "Find me a hotel in Paris" and "compare hotel prices in Paris" share domain but differ in action, and a flat classifier that conflates them routes to the wrong handler.

Confidence gates change the route. If the model scores below a defined threshold, the message goes to a clarification step rather than the wrong branch. One production pattern uses 60 on a 0-to-100 scale as the cut-off, with anything below triggering a default reply or escalation rather than a confident-but-wrong execution.

Mixed-intent queries require special handling. A query like "pick between X and Y and then help me buy the winner" blends commercial investigation and transactional intent in a single message. Forcing a single label onto that query and routing it to one handler loses half the user's request. The right architecture either splits the query into sub-tasks before routing or uses a layered routing pattern that handles each intent component in sequence.

Conversation context improves routing accuracy in ways that pure query-level classification cannot. A phrase like "just optimize it" means nothing without the prior turns that established what "it" refers to. Routing pipelines that ignore conversation history fail on exactly this class of query, because the classifier reads the message in isolation, assigns a generic label, and routes to the wrong tool.

Where Does the Standard Agentic Classification Model Break Down in Real Deployments?

The standard model breaks down when the input is messy, exceptions dominate, and the workflow depends on long chains of steps rather than clean single-label decisions. Agents struggle with out-of-order information, overlapping events, hidden edge cases, tool brittleness, and weak recovery from transient failures.

Three pressure points define where production systems diverge from the clean pipeline description above: conversational context resolution, domain-specific performance gaps, and cold-start data costs.

One number worth holding onto: research on agentic AI project costs found that roughly 80% of the work went to data engineering, stakeholder alignment, governance, and workflow integration, not to prompt engineering or model fine-tuning. The classification pipeline is a small fraction of the total engineering surface. The surrounding infrastructure is where most deployments actually fail.

How Does Intent Classification in Conversational AI Differ From Search Intent Classification?

Conversational AI intent classification infers a user's goal from multi-turn dialogue that includes follow-up questions, pronoun references, topic shifts, and corrections, while search intent classification takes a single input and predicts the dominant intent against a fixed taxonomy. The difference matters because many agentic systems blend search and dialogue. Deploying a search-intent classifier in a conversational context produces systematic errors on anaphoric references and context-dependent queries. A search-intent model trained on isolated queries has no mechanism for resolving "can you do that for the Paris one instead?", reading "Paris one" as a search term rather than a reference to a prior turn's entity.

BrightEdge's analysis of AI engine behavior found that informational intent still dominates across AI search platforms, but navigational behavior in ChatGPT often surfaces as branded questions that the parser classifies as informational rather than as a distinct navigational category. That reclassification reflects how conversational engines process brand queries differently than link-list search engines do, but it means the classic four-category taxonomy behaves differently in conversational contexts than in traditional search.

Conversational AI classification needs dialogue history, clarification signals, and user feedback to refine intent over time. Search intent classification relies primarily on query text and SERP-pattern signals. Running a search classifier in a conversational pipeline without injecting dialogue context is the architectural equivalent of asking someone to answer a question when they only heard the last sentence.

Does Resolving Pronoun References Across Turns Require a Separate NLP Model?

Resolving pronoun references across turns does not require a separate NLP model, but it does require architectural attention that standard search-intent classifiers don't provide. Modern systems handle coreference resolution through conversation history injection, concatenating recent turns and feeding them to the classifier so "it" and "that one" have an antecedent the model can resolve. One documented approach uses the previous two turns fed to a neural coreference model to replace pronouns with their referents before classification fires.

The more practical production pattern is a sliding window of the last five to ten turns with persistent entity pinning for the most salient references. State-of-the-art neural coreference models on standard benchmarks reach 80-85% F1, and GPT-4-class models handle common conversational pronouns at above 90% accuracy. Those numbers are good enough for most production use cases, but not for high-stakes domains where a misresolved pronoun changes which patient record or financial account the agent acts on.

Can a Single-Turn Intent Classifier Handle Multi-Turn Dialogue State Without Retraining?

A single-turn classifier cannot handle multi-turn dialogue state reliably without architectural support, but retraining is not always necessary to make it useful in multi-turn contexts. The LARA framework demonstrated this directly: combining a conventional model trained on single-turn data with in-context retrieval augmentation achieved state-of-the-art performance on multi-turn intent classification and improved average accuracy by 3.67% over single-turn baselines without requiring multi-turn training datasets.

The caveat is that wrapping matters. A plain single-turn classifier applied to a multi-turn message without history injection will fail on context-dependent queries. One OpenReview study reported an average 39% performance drop across generation tasks when models moved from single-turn to multi-turn settings. The classifier doesn't degrade gracefully; it degrades silently, returning confident labels for queries it is fundamentally misreading.

Which Business Domains Show the Biggest Performance Gap Between Generic and Domain-Specific Intent Models?

Healthcare and finance show the largest documented gaps, followed by legal, insurance, and enterprise customer service workflows. In a 12-industry evaluation, generic NLU models reached 63.4% intent recognition accuracy while domain-adapted models reached 92.7%, a 29-point gap that compounds in longer conversations. After three or more turns, generic models fell to 41.8% while domain-specific systems held at 88.3%. That gap is large enough to make generic models a false economy in any high-stakes vertical.

The healthcare number is the starkest: domain-adapted systems correctly processed 91.3% of complex medical terminology versus 38.7% for general-purpose chatbots. Medical language is dense with terms that look like ordinary words but carry precise clinical meaning. "Discharge" means something different in a hospital context than in a product return context, and a generic classifier trained on general web text doesn't have the domain grounding to disambiguate.

Legal retrieval shows a similar pattern. Domain-specific embeddings outperform general-purpose models by over 15 percentage points in NDCG@10 on legal benchmarks, driven by the need to capture jurisdiction, recency, and case-type signals that general embeddings don't represent.

For customer service and enterprise workflows, the gap is partly about proprietary vocabulary. When the intent taxonomy includes product-specific categories, internal process names, and workflow-specific actions, a generic classifier trained on public data simply hasn't seen the label space it's being asked to classify into.

We evaluate domain fit before recommending a classification approach to any client with specialized vocabulary. Generic models are cheaper to deploy and maintain, but the accuracy penalty in niche domains makes them a poor choice when the downstream action is high-stakes.

Does Training on Domain-Specific Query Logs Always Outperform Fine-Tuning a General LLM?

Domain-specific query log training does not always outperform fine-tuning a general LLM. The answer depends on label stability, data volume, and how quickly the domain's intent taxonomy changes. Domain-specific logs help most when the target domain is stable, the intent taxonomy is fixed, and enough labeled examples exist to train robust decision boundaries. General LLMs with zero-shot or few-shot prompting are competitive or better when the task requires flexibility, zero-shot adaptation to novel intents, or handling of query types that never appeared in the historical logs.

IntentGPT outperformed prior methods that required extensive domain-specific data and fine-tuning on standard benchmarks including CLINC, a direct counterexample to the assumption that domain-specific training always wins. The hybrid pattern worth using in production: a fast fine-tuned classifier for the high-volume, stable-intent cases, with an LLM fallback for ambiguous, novel, or multi-intent queries. That design captures most of the accuracy benefit of domain-specific training while preserving the flexibility of LLM-based classification for the long tail.

How Does a Hierarchical Intent Classification Scheme Outperform a Flat Taxonomy for Complex Queries?

Hierarchical classification outperforms flat taxonomies for complex queries because it reduces decision complexity by staging classification into coarse-to-fine levels, which aligns with how intent naturally decomposes. A flat classifier trying to distinguish between 50 intent labels in a single step faces a harder problem than a hierarchical classifier that first asks "is this a product query or a support query?" and then applies a narrower label set to each branch.

The precision gain is real. Hierarchical routing separates broad categories first, which reduces confusion among similar intents that would be hard to distinguish in a single flat layer. HumanFirst documents an additional benefit: broad top-level intents can surface utterances that match the parent category but not any child intent, helping teams discover missing sub-intents or underrepresented training data. Flat classifiers don't provide that feedback loop.

For unbalanced taxonomies, where some intents are common and others are rare, hierarchical methods show better training efficiency and accuracy than flat methods. The rare intents don't get drowned out by the high-volume categories because the hierarchy creates a branch structure that gives each sub-intent its own classification context.

The maintainability argument is also practical: as an agent's capability set grows, adding new intents to a hierarchical taxonomy is cleaner than expanding a flat label set. Each new intent has a natural home in the existing branch structure rather than competing with every other label simultaneously.

Does Adding Sub-Intent Tiers Always Improve Classification Latency as Well as Precision?

Adding sub-intent tiers does not improve latency; it increases it. Each classification tier adds an inference step before the routing decision is made, and those steps compound. A cascade architecture keeps costs manageable when earlier tiers are cheap: keyword filtering runs at sub-millisecond speeds, embedding-based routing runs at 16-100ms, and fine-tuned classification runs at 50-200ms. Adding an LLM-based classification step at any tier roughly doubles latency and cost compared to embedding-based routing alone.

Use hierarchy for precision, and cascade architecture for latency management. A well-designed cascade exits early for high-confidence cases: simple queries pay only the cost of the first tier, and only genuinely ambiguous queries pay the cost of deeper classification. That structure preserves the precision benefit of hierarchy while limiting the latency penalty to the cases that actually need it.

What Does an Open-Source Intent Agent Implementation Reveal About Production Trade-Offs?

The real production trade-offs are cost versus setup time, flexibility versus reliability, and speed versus accuracy, and the routing layer is where all three tensions converge simultaneously. Code-level implementations expose what theoretical frameworks don't.

The token cost arithmetic is concrete. With 10 tools at 500 tokens each, a router adds 5,000 tokens per request before the user's message is included. Scale that to 741 tools and the overhead rises to 127,315 tokens per request. A classification layer reduces that to roughly 1,084 tokens, a 117x reduction. At one million requests per month, that difference translates to approximately $3.79 million per year in API costs at frontier-model pricing. This is not a theoretical concern.

Open-source frameworks cut per-agent costs by roughly 55% compared to managed alternatives but require about 2.3 times more setup time. That trade-off is worth making for custom, high-value workflows and not worth making for rapid deployment on standard use cases.

The most consistent lesson from production agent research: most agents fail because tools fail, not because classification fails. Execution reliability is often more important than raw classification accuracy once a system moves from prototype to production. A classifier that routes correctly 95% of the time but dispatches to a tool that fails 20% of the time produces a 76% end-to-end success rate, and the failure signal looks like a tool problem, not a classification problem.

Should a Low-Confidence Classification Trigger a Clarification Prompt or Silent Default Routing?

A low-confidence classification should trigger a clarification prompt or explicit fallback routing, not silent default routing. Silent default routing on a low-confidence classification is the failure mode that erodes user trust fastest, because the system proceeds confidently toward the wrong goal with no signal that anything went wrong.

The production pattern: above the confidence threshold, execute the matched intent. Below it, route to a safe default reply, a clarification prompt, or human escalation. One documented threshold is 60 on a 0-to-100 scale; below that, the system sends a default reply rather than guessing. For higher-stakes domains, the threshold should be higher.

An agent that says "I'm not sure what you're asking, can you clarify?" is more trustworthy than an agent that confidently executes the wrong action. We wouldn't deploy a classification pipeline without explicit confidence thresholds and documented fallback behavior. The cost of a clarification prompt is one extra turn. The cost of silent misrouting is a user who stops trusting the system.

Does Token Cost Make LLM-Based Intent Classification Impractical at High Query Volume?

At high query volume, pure LLM-based intent classification is impractical on frontier models. The cost and latency compound quickly, and the accuracy gain over cheaper alternatives rarely justifies the spend for high-volume, stable-intent queries. A practical rule of thumb from agent routing research: fewer than 15 tools, LLM function calling is fine; 15 to 50 tools, add an embedding router; more than 50 tools, use a fine-tuned classifier; more than 100 tools, the classification layer is non-negotiable.

Routing simple queries to cheaper models reduces average cost per query by 60-70%. Adding semantic caching eliminates another 20-30% of calls in workloads with repeated query patterns. The cascade pattern, keyword filter first, then embedding router, then fine-tuned classifier, then LLM catch-all for novel cases, is the architecture that balances accuracy, latency, and cost most effectively at scale. LLM-based classification earns its cost for the ambiguous, multi-intent, and out-of-distribution cases that cheaper tiers can't handle. It does not earn its cost for the 80% of queries that a fine-tuned classifier can label correctly at a fraction of the inference cost.

How Does the Cold-Start Problem Limit ML-Based Intent Classification for Niche Query Types?

ML-based intent classifiers require labeled training data that is domain-specific, expensive to produce, and unavailable for niche or emerging query types. Without it, the classifier overfits common intents, misses rare ones, and fails on ambiguous queries in exactly the domains where precise classification matters most. This is the failure mode that doesn't show up in vendor benchmarks.

The feedback loop is the structural problem. Rare query types get fewer correct predictions, which means fewer good training examples are collected from real usage. That keeps the niche intent underrepresented, which keeps prediction quality low, which keeps the intent underrepresented. The cold-start condition is self-reinforcing.

Organizations with specialized vocabularies, healthcare providers, legal firms, niche e-commerce categories, face this barrier disproportionately. Their query vocabulary diverges from general-purpose training data enough that a generic classifier produces unreliable labels, but their query volume is too low to generate the labeled examples needed to train a domain-specific model quickly.

The practical mitigation sequence: start with zero-shot classification to get a working system, collect interaction data from real usage, identify the intent categories where zero-shot is failing, and fine-tune a supervised model once enough examples exist. Don't wait for a complete labeled dataset before deploying anything. The interaction data from a zero-shot system is itself a source of training examples.

Can Synthetic Training Data Substitute for Human-Labeled Query Logs in Low-Volume Domains?

Synthetic training data partially substitutes for human-labeled query logs, but not as a universal replacement. A 2024 review of synthetic data generation reported empirical gains of roughly 3-26% from synthetic augmentation in low-data regimes, while also documenting a persistent quality gap between purely synthetic and large real datasets.

The most defensible strategy: synthetic data plus a small human validation set, with iterative prompt refinement and error analysis. Synthetic data is most reliable for bootstrapping coverage of intent classes that are underrepresented or absent in human logs, the rare intents where the cold-start problem is sharpest. It is least reliable as a full replacement when you need precise calibration to real user behavior, because multiple studies find a gap between synthetic-only and human-labeled training that grows as the task requires nuanced disambiguation.

Amazon's approach to cold-start in new product categories with low search volume is instructive: use synthetic queries to augment observed query-product interactions in logs, not to replace them. The synthetic data fills gaps; the human data provides ground truth. Apply the same principle to intent classifier bootstrapping, generate synthetic examples for the underrepresented categories, validate against a small human-labeled set, and treat the synthetic data as scaffolding rather than foundation.

How Should You Design an AI Agent Intent Classification System That Holds Up in Production?

Classification accuracy alone is not enough. A system that correctly labels intent 90% of the time but routes to the wrong handler, fails silently on low-confidence outputs, or treats intent as a one-shot decision at query ingestion will still fail users at scale. Trajectory-aware re-classification, confidence-gated routing, and domain-specific tuning are not separate features to add incrementally; they are architectural commitments that need to be made together.

The single most important instrumentation step is logging confidence scores at the routing layer, not just at the classification layer. A classification that returns 0.87 confidence but routes to a handler that fails 30% of the time looks like a routing problem in the logs. A classification that returns 0.53 confidence and routes correctly by luck looks like a success. Without confidence scores attached to routing decisions, you cannot distinguish between a classifier that is performing well and a router that is compensating for a classifier that isn't.

Build re-classification into the agent loop explicitly at trajectory checkpoints. After each major tool call or intermediate result, score whether the current trajectory still aligns with the original intent. This is a structured prompt with a confidence threshold and a branch condition, not an expensive architectural addition. What it prevents is the silent misrouting failure mode where a user's intent evolves mid-task and the agent keeps executing toward the wrong goal without any signal that something has gone wrong.

Domain specificity is not optional for production systems in specialized verticals. The 29-point accuracy gap between generic and domain-adapted models in healthcare and finance shows up in real query logs as misrouted support tickets, wrong product recommendations, and failed task completions. If your agent operates in a domain with specialized vocabulary, budget for domain-specific tuning before launch, not as a post-launch remediation.

Start with a cascade architecture. Keyword filters handle the obvious cases at sub-millisecond cost. Embedding-based routing handles the majority of standard queries at 16-100ms. A fine-tuned classifier handles the domain-specific cases. An LLM fallback handles the genuinely ambiguous, multi-intent, and out-of-distribution queries. Instrument your routing layer before you optimize your classifier. The confidence score at the routing decision point is the single metric that tells you whether your classification system is actually working, not the accuracy score on your evaluation set.

Sources

1. A Taxonomy of Task-Based Information Request Intents , 2026, arXiv.
2. Agentic Search in the Wild: Intents and Trajectory Dynamics from ... , 2026, arXiv.
3. How to Build an Intent Classification Hierarchy , Vonage Developer Blog.
4. Intent classification techniques , OpenAI Developer Community.
5. Identify user search intent with machine learning , Algolia.
6. What is intent detection? , Decagon.
7. Issue #109 - Intent Classification for AI Agents , ML Pills (Substack).
8. Agent Series (5): Intent Recognition and Routing - DEV Community , DEV Community.
9. AI Intent Recognition: Key Benefits and Real-World Use Cases , Nurix AI.
10. AI Intent Recognition for Chatbots: How It Works in 2026 , IrisAgent.
11. Enhancing Intent Classification and Error Handling in Agentic LLM Applications , Medium.
12. intent_agent.py , Hugging Face Spaces.