Rule Based Tool
A Rule Based Tool evaluates a set of conditions against conversation context and returns a structured decision. Unlike API or database tools that fetch external data, a rule-based tool encodes logic that runs locally — no external calls needed.
Use it to express business rules that the agent should apply consistently, such as routing decisions, eligibility checks, or response policy enforcement.
When to use Rule Based
Use a Rule Based Tool when:
- You need deterministic logic the agent must always follow precisely
- You want to separate policy from the agent's system prompt (keeping prompts shorter and cleaner)
- You need to evaluate conditions against structured inputs and return a discrete outcome
Examples:
- Escalation routing — if sentiment is negative and issue type is billing, escalate to senior support
- Eligibility check — if account age > 30 days and subscription = Pro, grant the discount
- SLA classification — classify ticket priority based on issue type and customer tier
Creating a Rule Based Tool
- Go to your project → Integrations
- Click Add Integration → Browse → Rule Based
- Name the tool with a clear action verb (e.g. "Classify Ticket Priority", "Check Upgrade Eligibility")
- Define the rules and conditions in the configuration form
Defining rules
Each rule is a condition + outcome pair:
IF <condition> THEN <action/output>
Rules are evaluated in order — the first matching rule wins.
Condition operators
| Operator | Example |
|---|---|
equals | issue_type equals "billing" |
not_equals | status not_equals "resolved" |
contains | message contains "refund" |
greater_than | account_age_days greater_than 30 |
less_than | sentiment_score less_than -0.5 |
in | tier in ["Pro", "Enterprise"] |
Combining conditions
Use AND / OR to combine multiple conditions within a rule.
Outputs
Each rule returns a structured object the agent can use:
{
"action": "escalate",
"priority": "high",
"route_to": "billing_team",
"message": "This looks like a billing dispute. Escalating to the billing team."
}
Defining parameters
Parameters are the inputs the rule engine evaluates. Define each one:
| Field | Description |
|---|---|
| Name | Input name (e.g. issue_type, sentiment_score) |
| Type | string, number, boolean |
| Required | Whether it must be provided to evaluate rules |
| Description | What this value represents |
Example: ticket routing
Rules:
| Priority | Condition | Output |
|---|---|---|
| 1 | issue_type equals "outage" AND tier in ["Enterprise"] | {action: "escalate", route_to: "enterprise_oncall", priority: "critical"} |
| 2 | issue_type equals "billing" AND sentiment_score less_than -0.5 | {action: "escalate", route_to: "billing_team", priority: "high"} |
| 3 | issue_type equals "feature_request" | {action: "log", route_to: "product_queue", priority: "low"} |
| Default | (no conditions match) | {action: "self_serve", priority: "normal"} |
Parameters:
| Name | Type | Required | Description |
|---|---|---|---|
issue_type | string | Yes | Type of issue the user is reporting: billing, outage, feature_request, general |
tier | string | Yes | Customer subscription tier: Free, Pro, Enterprise |
sentiment_score | number | No | Sentiment score from -1 (very negative) to 1 (very positive) |
System prompt fragment:
After understanding the user's issue, use the Ticket Router tool to classify it.
Provide:
- issue_type: one of billing, outage, feature_request, general
- tier: the customer's subscription tier
- sentiment_score: estimate from -1 to 1 based on how frustrated the customer seems
Then act on the result:
- If action is "escalate": tell the user you're connecting them with the right team and
use {{tool:slack_post_message}} to notify that team
- If action is "self_serve": try to resolve the issue yourself using other available tools
- If action is "log": confirm their feedback has been recorded
Troubleshooting
Rules not matching as expected
Check condition precedence — rules are evaluated top-to-bottom, first match wins. Reorder more specific rules above more general ones.
Agent not calling the tool
Make sure the parameter descriptions are specific. The agent needs to know what values are valid for each input — list the accepted values in the description (e.g. "one of: billing, outage, feature_request, general").
Output not being used
The agent must be instructed to act on the tool output. Add explicit instructions in the system prompt describing what to do for each possible action value.