> ## Documentation Index
> Fetch the complete documentation index at: https://docs.maadify.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Rules and Routing
> Define conditions and actions that control workflow routing
## How rules work
Rules evaluate workflow context and decide what runs next. Each rule has:
* **Conditions**: what must be true.
* **Actions**: what should happen when conditions match.
* **Order**: the priority for evaluation on a node.
All conditions and actions make up the flow view.
## How the state transition selects the next step
The runtime evaluates rules in order and stops on the first rule that triggers. If no rule triggers, the run fails with a “no rule triggered” error.
The engine builds a context map from tool outputs, runtime inputs, and message history, then exposes that data as rule variables.
Rule conditions are normalized (types are applied, tool scoping is resolved, and sub-agent IDs are mapped to current names).
The first rule that matches runs its actions and determines the next step.
If a rule executes a tool, the engine stores the response in context and re-evaluates rules with the new data.
Always add a fallback rule at the end so the workflow has a deterministic next step.
## Add a rule
Pick the condition that matches the data you want to evaluate.
Use type-specific operators and provide the comparison value.
Route to the next agent, execute a tool, request approval, or set an error.
## Add/edit rule dialog behavior
When you open the rule dialog, it supports both **Add** and **Edit** modes:
* **Add New Rule** when no rule is selected.
* **Edit Rule** when you clicked a rule from the flow or list.
* **View Rule** if you do not have edit permissions.
Use the dialog to build conditions, actions, and nested groups in one place.
## Condition groups and nesting
Rules support **all**/**any** logic with nested groups for complex branching.
Use nested groups to model branching without duplicating rules.
## Condition types
Available condition types include:
* **Last agent name**: route based on the most recent sub-agent.
* **Last message content**: match text returned by the last step.
* **Last tool executed**: route based on which tool ran last.
* **Execute tool content**: evaluate fields inside tool output.
* **Runtime inputs**: evaluate values provided by triggers or prior steps.
## Operators by content type
For **execute tool content**, operators change based on the selected content type:
* **Text**: `equal_to`, `not_equal_to`, `starts_with`, `ends_with`, `contains`, `does_not_contain`, `non_empty`, `matches_regex`
* **Numeric**: `equal_to`, `not_equal_to`, `greater_than`, `less_than`, `greater_than_or_equal_to`, `less_than_or_equal_to`
* **Boolean**: `is_true`, `is_false`
* **Select**: `contains`, `does_not_contain`
* **Select multiple**: `contains_all`, `is_contained_by`, `shares_at_least_one_element_with`, `shares_exactly_one_element_with`, `shares_no_elements_with`
* **Array length**: `equal_to`, `not_equal_to`, `greater_than`, `less_than`, `greater_than_or_equal_to`, `less_than_or_equal_to`
Array operators compare the length of the selected array to the value you provide.
## Actions you can run
Rules can trigger one or more actions:
* **Select next agent**: route to a sub-agent.
* **Execute tool**: call a tool with templated input.
* **Send approval**: pause and request confirmation.
* **Set error**: flag the run and route to error handling.
## Approvals and errors
Approvals pause execution and can send email notifications to selected users. Errors generate notifications and can route to recovery steps.
Approvals appear in **Notifications** and in **Agent activity**.
## Rule ordering
Rules are evaluated in order for each node. Use **Rule order** in flow view to change evaluation priority.
## How rule data is interpreted at runtime
Rules are normalized before evaluation to make them resilient and consistent:
* **Sub-agent ID resolution**: rules that reference a sub-agent ID are resolved to the current agent name so renames do not break routing.
* **Tool-scoped context paths**: conditions referencing tool output are scoped by tool ID or tool instance ID.
* **Typed variables**: condition types (text, numeric, boolean, select, array) control how values are compared.
* **Fallback conditions**: an empty condition set is converted to an always-true condition so the rule can be used as a default.
## Context variables and tool scoping
Rule conditions can reference tool outputs using a dot-path. At runtime, the engine resolves:
**tool\_key** would be `{tool_name}_{tool_id}`
* **Tool ID paths**: `tool_key.field.path` (e.g., `64.items.0.id`)
* **Tool instance paths**: `tool_key__instance_id.field.path` when multiple tool instances exist
When a rule targets **last tool executed** and a tool instance is provided, the engine evaluates against `last_tool_executed_instance` so the condition matches the correct instance.
## Tool execution effects on rule evaluation
Rules that execute tools can change the rule evaluation loop:
* After a tool runs, its response is stored in context and rules are re-evaluated.
* Tools already executed in the current transition are filtered out to prevent loops.
* After a tool executes, only rules that check **last tool executed** are eligible to trigger, which prevents earlier entry rules from firing again on the same message.
## Continue conversation behavior
Two parent-agent settings change how “last agent” and “last message” are interpreted:
* **Default agent on continued conversation**: routes directly to the configured agent when a conversation resumes.
* **Continue with last agent**: ignores a returning user message and keeps the last agent as the routing reference.
Use these settings to control whether a resumed conversation restarts your rule logic or continues from the last agent.
