Conditions

A condition picks out the requests a rule applies to. You write conditions in three places:

• A Branch block's When, to choose the requests that run the branch's blocks.
• A Delegate block's When, to choose the requests it hands to another pipeline.
• An escalation path's If / else step, to choose reviewers.

Each condition has a field, an operator and, where needed, a value to compare it with.

Fields

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, the tool catalogue and your test sample. On the hosted edition, the MCP server field also lists every server registered on the Gateway page by its slug, with the server's name beside it, so you can gate a server before any agent has called it. 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.

Example: A $500 refund limit

Our organization should deny USD refunds over $500, regardless of which agent sends them. In the entry pipeline, we'll add a branch named Deny refunds over $500 with these conditions in its When.

We'll use All so every condition must match, and put an Outcome block that denies the refund inside the branch. A $600 USD refund enters the branch and is denied; a $75 refund skips it. Other tools and currencies also skip it because they don't match.

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 to approve small refunds for duplicate charges or missing items. We'll give a branch named Approve small refunds this grouping in its When.

• 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.

Inside the branch, an Outcome block approves the refund. Either reason is enough, but the tool, currency and amount checks still apply.

Testing conditions

Test request, in the pipeline's action menu, shows whether a sample matched each branch and Delegate block. A branch the sample matches lights the line into its blocks; one it skips is dimmed.

Changing one field at a time helps show which condition affects the result. If a condition 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 enter Approve small refunds and 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 skip the branch 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. In a branch or Delegate block, that sends the request to human review instead of skipping it.