Skip to main content

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.

​
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.
Flow view showing conditions and actions

​
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.
1

Prepare context and variables

The engine builds a context map from tool outputs, runtime inputs, and message history, then exposes that data as rule variables.
2

Normalize rules

Rule conditions are normalized (types are applied, tool scoping is resolved, and sub-agent IDs are mapped to current names).
3

Evaluate rules in order

The first rule that matches runs its actions and determines the next step.
4

Re-evaluate after tool execution

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

1

Choose a condition type

Pick the condition that matches the data you want to evaluate.
2

Set operators and values

Use type-specific operators and provide the comparison value.
3

Select actions

Route to the next agent, execute a tool, request approval, or set an error.
Rule builder with conditions and actions

​
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.
Rule builder with conditions and actions

​
Condition groups and nesting

Rules support all/any logic with nested groups for complex branching.
Use nested groups to model branching without duplicating rules.
Rule conditions showing nested all and any groups

​
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.
Condition type dropdown listing the available condition types

​
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.
Operator dropdown showing operators that change with the selected content type

​
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.
Rule action picker listing select next agent, execute tool, send approval, and set error

​
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.
View of email

​
Rule ordering

Rules are evaluated in order for each node. Use Rule order in flow view to change evaluation priority.
Rule order dialog showing 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.
Pick your tool

​
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.
Parent agent settings showing default agent on continued conversation and continue with last agent toggles