Intent Classification Explained: How Natural Language Becomes Structured Authority

The Problem: Natural Language Is Ambiguous

An AI agent connected to your production infrastructure says: "I need to update the firewall rules to allow traffic from the new partner's IP range on port 443."

That sentence contains an action (update firewall rules), a resource (firewall rules), a modification (allow traffic), a source (partner IP range), a protocol detail (port 443), and an implied environment (production, because firewalls are production infrastructure). A human security engineer parses all of this instantly. A governance system needs to parse it just as accurately, every time, at machine speed.

This is the intent classification problem. It is the first step in the Intended governance pipeline, and arguably the most important. If you misclassify the intent, every subsequent step -- policy evaluation, risk scoring, authority token issuance -- operates on wrong data. Garbage in, garbage out.

The Intended Intent Reference Taxonomy

Before we can classify intents, we need a taxonomy to classify them into. Intended uses the Intended Intent Reference (MIR) taxonomy, which organizes all possible AI agent actions into a hierarchical structure.

The top level contains 14 domains: Infrastructure, SecOps, SDLC, SaaS Operations, Data Management, Compliance, Financial Operations, Customer Operations, HR Operations, Legal Operations, Content Operations, Communication Operations, Supply Chain, and AI/ML Operations.

Each domain contains categories. Infrastructure, for example, includes categories like Compute Management, Network Configuration, Storage Operations, DNS Management, Certificate Management, and Load Balancer Configuration. Each category contains specific action types: create, read, update, delete, execute, configure, deploy, rollback, and so on.

The full taxonomy contains over 300 specific intent types across the 14 domains. Every AI agent action, no matter how it is expressed in natural language, maps to one of these intent types.

The Compiler Architecture

Intended's intent compiler follows a three-stage architecture that transforms raw natural language into a fully classified, structured intent object. The stages are extraction, classification, and enrichment.

Stage 1: Extraction

The extraction stage identifies the key components of the agent's request. This is not full natural language understanding. It is targeted extraction of governance-relevant fields.

The extractor identifies the primary verb (the action the agent wants to take), the target resource (what the action operates on), qualifiers (conditions, constraints, or parameters), and context signals (environment references, urgency indicators, scope markers).

For the firewall example: the primary verb is "update," the target resource is "firewall rules," qualifiers include "allow traffic," "partner IP range," and "port 443," and context signals include the implied production environment.

Extraction uses a combination of pattern matching for common request formats and a lightweight language model for ambiguous or novel expressions. The pattern matcher handles roughly 70 percent of requests with zero model inference cost. The language model handles the remaining 30 percent.

Stage 2: Classification

The classification stage maps extracted components to the MIR taxonomy. This is a multi-label classification problem: given the extracted verb, resource, and qualifiers, determine the domain, category, and action type.

The classifier operates hierarchically. First, it determines the domain. "Firewall rules" maps to Infrastructure. Then it determines the category within that domain. "Firewall rules" plus "update" maps to Network Configuration. Finally, it determines the specific action type. "Update" plus "firewall rules" plus "allow traffic" maps to network.firewall.rule.update.

This hierarchical approach has two advantages. First, it is more accurate than flat classification because the domain determination narrows the search space for category and action type. Second, it allows domain-specific classification models to specialize. The Infrastructure classifier does not need to understand HR vocabulary, and vice versa.

The classifier also assigns a confidence score to each classification. If the confidence falls below a configurable threshold, the intent is flagged for human review rather than being classified automatically. This prevents misclassification from propagating through the governance pipeline.

Stage 3: Enrichment

The enrichment stage adds contextual data to the classified intent. This data comes from the connector that submitted the intent, the agent's historical behavior, and the organization's configuration.

Enrichment adds the agent identity (which agent submitted this intent, what are its trust levels, what is its historical behavior pattern), the environment context (production, staging, development -- determined from the connector configuration and resource identifiers), resource metadata (what do we know about the target resource from the organization's asset inventory), and temporal context (when was this intent submitted, is it during a change window, is it during an incident).

The enriched intent object is the input to the policy evaluation stage. It contains everything the Authority Engine needs to make a governance decision: the classified action, the agent identity, the environmental context, and the risk-relevant metadata.

The Intent Object

The output of the compiler is a structured intent object. Here is what it looks like for our firewall example:

{
  "intentId": "int_7f3a9b2c",
  "domain": "infrastructure",
  "category": "network_configuration",
  "action": "network.firewall.rule.update",
  "confidence": 0.94,
  "resource": {
    "type": "firewall_rule_set",
    "identifier": "fw-prod-east-01",
    "environment": "production"
  },
  "parameters": {
    "direction": "inbound",
    "protocol": "tcp",
    "port": 443,
    "source": "partner_ip_range"
  },
  "agent": {
    "id": "agent_network_ops",
    "trustLevel": "standard",
    "recentActions": 47,
    "escalationRate": 0.02
  },
  "timestamp": "2026-02-16T14:32:00Z"
}

This object is fully structured, unambiguous, and contains all the context needed for policy evaluation. The natural language ambiguity is gone. The Authority Engine can evaluate this against policies with deterministic precision.

Handling Ambiguity

Not every agent request maps cleanly to a single intent. Consider: "Set up the new microservice with a database, load balancer, and monitoring." This is actually multiple intents: create a compute resource (the microservice), create a database, configure a load balancer, and set up monitoring. Each one may have different risk profiles and different policy requirements.

The intent compiler handles multi-intent requests by decomposing them into individual intents. Each intent is classified and enriched independently, and each goes through the Authority Engine separately. The original request maintains a correlation ID so that all component intents can be traced back to the original agent request.

Ambiguity in action type is handled differently. If the agent says "handle the database," the verb "handle" is ambiguous. It could mean read, update, delete, or something else entirely. In these cases, the classifier assigns low confidence and the intent is routed to clarification. The system asks the agent (or the agent's human operator) to specify the intended action.

Performance Characteristics

The intent compiler is designed for latency-sensitive workloads. Every millisecond of classification latency adds to the total governance overhead.

Stage 1 extraction: median latency 2 milliseconds for pattern-matched requests, 15 milliseconds for model-inferred requests. Stage 2 classification: median latency 3 milliseconds using the hierarchical classifier. Stage 3 enrichment: median latency 5 milliseconds, dominated by the agent history lookup.

Total compiler latency: median 10 milliseconds, p99 25 milliseconds. This is fast enough that the classification step does not meaningfully impact agent operation latency.

The compiler processes intents statelessly, which means it scales horizontally. Each compiler instance can handle approximately 2,000 intents per second. For organizations processing millions of agent decisions per month, multiple compiler instances run behind a load balancer.

Why This Matters

Intent classification is the foundation of AI governance. Without accurate classification, policies cannot be evaluated correctly. Without structured intents, risk scoring is impossible. Without confidence scores, you cannot know when to escalate to humans.

Every governance decision Intended makes starts with the intent compiler. It is the translation layer between the messy, ambiguous world of AI agent behavior and the precise, structured world of policy evaluation. Getting this translation right is what makes everything else possible.