Conditions blocks

A Conditions block compares request fields with values you choose. A match applies the block's outcome; a non-match passes the request to the next block.

To add one, open an approval pipeline, select Edit pipeline, then Add block and Conditions.

Conditions

Give the block a Name and use When to define its conditions. Each condition identifies a field, an operator and, where needed, a value to compare it with.

The field picker includes Tool name, MCP server, Agent slug, Agent name and fields from the tool's arguments. Tool names are the names servers define, so the same tool matches whichever runtime called it; use MCP server to tell apart tools that share a name across servers. Suggestions come from requests and your test sample. Nested argument fields use dotted names, such as customer.email.

Choose an operator that fits the field's type. A numeric comparison needs a number; a text comparison needs text. Text comparisons are case-sensitive. The operator list shows the available choices.

Match outcomes

On match can Approve, Deny or Ask a human. For human review, select an Escalation path or keep Pipeline default. The Reason explains why the rule produced that outcome.

These outcomes stop the pipeline. A request that doesn't match continues automatically.

flowchart TD
    request["Request reaches this block"] --> match{"Do the conditions match?"}
    match -->|"No"| next["Continue to the next block"]
    match -->|"Yes"| outcome["Apply On match"]
    outcome --> approve["Approve"]
    outcome --> deny["Deny"]
    outcome --> human["Ask a human"]

Example: A $500 refund limit

Our organization should deny USD refunds over $500, regardless of which agent sends them. We'll add Deny refunds over $500 to the organization pipeline with these conditions.

We'll use All so every condition must match, and set On match to Deny. A $600 USD refund is denied; a $75 refund continues. Other tools and currencies also continue because they don't match this rule.

Our tool sends amounts in dollars. A tool that sends cents would need a different comparison value.

Condition groups

All requires every condition in a group to match. Any requires at least one. Groups can contain other groups, so one part of a rule can offer alternatives while the rest remains required.

Example: Alternative refund reasons

Suppose we only want Support assistant to approve small refunds for duplicate charges or missing items. We'll extend its small-refund rule with this grouping.

• All: the tool is issue_refund, the currency is USD and the amount is at most 20.
• Within that group, Any: the reason is duplicate_charge or item_not_received.

We'll set On match to Approve. Either reason is enough, but the tool, currency and amount checks still apply. This is an extra restriction on the basic amount rule in the main page.

Block testing

Test request, in the pipeline's action menu, shows whether a sample matches each block. Check the block's result as well as the final outcome: a later block can still decide a request that this one passes on.

Changing one field at a time helps show which condition affects the result. If a block reports an error, check the field's type and the operator it uses.

Example: A nested refund rule

Our $10 USD refund with reason duplicate_charge should be approved. We'll then change the reason to changed_mind, the amount to $75 or the currency to EUR, one change at a time. Each variant should continue past this block instead.

Once the rule behaves as intended, it can be saved and activated.

Operator list

These are the operators available in the visual editor. Check the field's actual type and value when choosing a comparison.

For a missing field, only does not exist matches. Missing isn't the same as null or an empty list. If a field has the wrong type for an operator, such as text in a numeric comparison, evaluation can fail and send the request to human review.