Rule matching
Discovering and applying rules
Rule matching is how Parlant decides which of your rules the agent should follow on each turn. It finds the rules the conversation has made relevant, checks the important ones more carefully, and applies the relationships you declared between them. This lets you write hundreds of rules without putting all of them in front of the model at once.
- How discovery finds the rules a conversation has made relevant
- Which rules get a model verdict, and how effort changes that
- When a decision model judges a whole batch in one request
- How dependency and priority relationships shape the final set
Now that you know how rules work in Parlant, let's look at how they are discovered and applied during a conversation.
There are two main stages: discovery and evaluation. A third step, resolution, applies the relationships between rules.
Discovery
The purpose of discovery is to make sure your agent knows about every rule that might be relevant to its current context.
Discovery asks one question: has the conversation made this rule relevant to the session at all? Parlant answers it with a cheap, similarity-based check of each message against your rules. No language model is involved. It uses a logistic regression algorithm based on the Signals and Queries research paper.
Once a rule is discovered, it joins the session's working set and stays there as the conversation moves around. The working set is what makes discovery sticky: Parlant records the rule there and stops checking it again, so your agent stays grounded in your rules even while the customer talks around a topic.
Discovery is optimized for recall, not precision. The algorithm assumes that overlooking a rule that is relevant is worse than including one that is not especially relevant right now.
Evaluation
The purpose of evaluation is to decide, with greater confidence, whether a rule truly applies right now, at each point of the conversation.
Not every rule is evaluated. Evaluation asks a model for a verdict, which costs more than an embedding-based check, so only rules whose match has consequences get one.
Some conditions that automatically promote a rule to evaluation are: high weight, dependencies, changing the agent's effort level, bringing tools into context, triggering a review, and applying labels. Parlant chooses for you whether a rule needs evaluation or only discovery.
Which rules are evaluated also depends on the turn's effort level. At HIGH and MAX effort, medium- and high-weight rules are all evaluated. At MEDIUM effort, only high-weight rules are. At MIN and LOW effort, rules are left to discovery unless something else promotes them.
How the verdict is produced
By default, Parlant asks a model about each candidate rule in its own request. The requests share a long common prefix, which the provider's prompt cache serves cheaply. Parlant warms that cache with one extra request when a session is created, and again after each reply, so that the per-rule requests on the next turn read from it.
At MIN, LOW, and MEDIUM effort, Parlant can use a decision model instead, when one is configured for the matching.rank route. A decision model answers a batch of yes-or-no questions with probabilities rather than prose. Parlant then sends the whole batch of candidate rules in a single request.
At these three effort levels, no per-rule explanation is written in either case. And because a batched turn makes one request instead of many, the cache warm-up is skipped on such turns.
A batched verdict is cheap enough that Parlant evaluates more rules with it. With a decision model in place, medium-weight rules at MEDIUM effort and high-weight rules at LOW effort are evaluated as well, instead of being left to discovery alone.
A decision model is routed like any other model, with the [capability=decision] qualifier on the route (for example, matching.rank[capability=decision]). The default OpenRouter setup already registers one. Model routing covers how routes are configured.
Resolution
Parlant lets you declare relationships between rules.
There are a few types, but the common ones in practice are dependency and priority.
A dependency relationship keeps a rule out until its prerequisites have properly matched (that is, been evaluated and confirmed) at some point in the session. For example, if rule A depends on rule B, rule A is not considered for the assembled context until rule B has been matched and confirmed, either in this turn or earlier.
Once that has happened, rule A stays available for the rest of the session.
A priority relationship sets aside a matched rule when another rule declared to outrank it also matches. The outranked rule stays in the instructions, but Parlant tells the model explicitly not to act on it this turn.
Rule relationships covers each supported relationship in more detail, and how they combine.
The rule matching sequence
To bring it all together, the following diagram shows the sequence that happens on every turn: