NLU: block configures how the agent classifies user intent, extracts entities, resolves synonyms, and matches utterances. NLU definitions are used by the runtime for intent routing, digression matching, and entity extraction during conversation.
Overview
ABL’s NLU configuration supports:- Intent classification with keyword patterns and example utterances.
- Entity extraction with typed extractors (enum, pattern, location, date, number, free text).
- Synonyms for normalizing variant expressions to canonical values.
- Embeddings-based matching for semantic similarity when keyword patterns are insufficient.
- Multi-language support with per-language model configuration.
- A glossary for domain-specific terminology.
Intent classification
Intents represent categories of user messages. Each intent has a name, keyword patterns for quick matching, and optional example utterances for model-based classification.Syntax
Intent properties
| Property | Type | Required | Default | Description |
|---|---|---|---|---|
NAME | string | Yes | — | Unique intent identifier. |
PATTERNS | string[] | Yes | — | Keyword patterns for quick substring matching. |
EXAMPLES | string[] | No | — | Full example utterances for model-based classification. Improves accuracy. |
EXAMPLES_FILE | string | No | — | Path to an external file containing example utterances (one per line). |
ENTITIES | string[] | No | — | Entity types expected to co-occur with this intent. |
Pattern matching
Patterns are matched as case-insensitive substrings against the user’s message. If any pattern appears in the message, the intent is a candidate match. Pattern matching is the first tier of classification; it is fast but imprecise.Example-based classification
WhenEXAMPLES are provided, the runtime uses an LLM or embedding model to classify messages based on semantic similarity to the examples. This is more accurate than pattern matching but requires more compute.
Intent with external examples file
For intents with many examples, reference an external file:Entity extraction
Entities are structured values extracted from user messages. ABL supports six entity types.Syntax
Entity types
| Type | Description | Additional properties |
|---|---|---|
enum | Matches against a fixed set of values with optional synonyms. | VALUES, SYNONYMS |
pattern | Matches against a regular expression. | PATTERN, VALIDATION |
location | Extracts geographic locations (cities, countries, addresses). | — |
date | Extracts date and time references, including relative expressions (“next Tuesday”). | — |
number | Extracts numeric values. | — |
free_text | Captures arbitrary text spans. Useful for notes, descriptions, or comments. | — |
Entity properties
| Property | Type | Required | Default | Description |
|---|---|---|---|---|
NAME | string | Yes | — | Unique entity identifier. |
TYPE | string | Yes | — | Entity type. See Entity types. |
VALUES | string[] | No | — | Valid values (for enum type). |
SYNONYMS | Record<string, string[]> | No | — | Synonym mappings. Keys are canonical values. |
PATTERN | string | No | — | Regular expression (for pattern type). |
VALIDATION | string | No | — | Validation description or expression. |
Synonyms
Synonyms map variant expressions to canonical values. When a synonym is detected, the runtime normalizes it to the canonical form before storing:currency_code: "USD".
Embeddings-based matching
For more accurate semantic matching, enable embeddings-based NLU. This uses vector similarity to match user messages against intent examples.Embeddings properties
| Property | Type | Required | Default | Description |
|---|---|---|---|---|
enabled | boolean | Yes | — | Whether embeddings-based matching is active. |
provider | string | No | — | Embedding model provider name. |
model | string | No | — | Specific model identifier. |
baseUrl | string | No | — | Custom endpoint URL for the embedding service. |
threshold | number | No | — | Similarity threshold (0.0—1.0). Below this, the match is rejected. |
cache_ttl | number | No | — | Cache duration in seconds for computed embeddings. |
Multi-language support
ABL NLU supports multiple languages with per-language model configuration and optional code-switching detection.Multi-language properties
| Property | Type | Required | Default | Description |
|---|---|---|---|---|
languages | string[] | No | — | Supported language codes. |
default_language | string | No | — | Default language when detection is ambiguous. |
allow_code_switching | boolean | No | false | Allow users to switch languages mid-conversation. |
language_models | Record<string,string> | No | — | Per-language model assignments for classification. |
Model configuration
Specify which models to use for NLU classification tasks:| Property | Type | Required | Default | Description |
|---|---|---|---|---|
fast | string | No | — | Model for fast, low-latency classification. |
balanced | string | No | — | Model for higher-accuracy classification. |
Evaluation configuration
Control NLU evaluation behavior for monitoring and testing:| Property | Type | Required | Default | Description |
|---|---|---|---|---|
log_predictions | boolean | No | — | Log all NLU predictions for analysis. |
ab_test | boolean | No | — | Enable A/B testing between NLU models. |
confidence_threshold | number | No | — | Minimum confidence score for accepting a prediction. |
Glossary
The glossary defines domain-specific terms and abbreviations. These definitions are injected into the LLM context to improve understanding of specialized vocabulary."term -- definition" format.
External NLU configuration
For complex NLU setups, reference an external configuration file:Complete example
Related pages
- Multi-Agent & Supervisor — intent-based routing in Supervisors
- Expressions & functions — expression syntax used in intent conditions
- Memory & Constraints — NLU results stored in session variables