Conditions

Conditions allow a BindAI workflow to make decisions during execution. A condition evaluates information available in workflow state and selects the next execution path. Conceptually:

Workflow State
      |
      v
  Condition
    /    \
 true    false
  |        |
  v        v
Path A   Path B

Conditions are part of BindAI V1’s workflow control-flow capabilities.

What Is a Condition?

A Condition node represents a decision point in a workflow. For example:

Agent
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Tool      End

The condition determines which connected path continues execution. The operations on each branch remain responsible for performing the actual work.

Why Use Conditions?

Conditions allow workflows to:

Select different execution paths
Validate workflow results
Route requests
Handle different outcomes
Control loops
Implement approval flows
Respond to runtime values
Avoid unnecessary downstream operations

Without conditions, a workflow would generally follow the same execution path regardless of runtime results.

Condition Execution

A condition follows this general execution model:

Workflow State
      |
      v
Evaluate Expression
      |
      v
Boolean Result
   /        \
 true       false
   |          |
   v          v
Path A      Path B

The condition does not perform the business operation itself. It produces a decision that the workflow graph uses to determine what executes next.

Condition Expressions

BindAI V1 conditions are configured with an expression. The expression is evaluated against information available during workflow execution. Conceptually:

Workflow Variables
       |
       v
   Expression
       |
       v
  True / False

For example, a workflow may evaluate whether a previous result indicates approval:

approval_result
       |
       v
Condition
       |
   +---+---+
   |       |
 true    false
   |       |
   v       v
Continue  Stop

The exact expression syntax should follow the expression support implemented by the current BindAI workflow runtime.

True and False Paths

A condition in BindAI V1 uses a boolean decision to control execution. Conceptually:

              +--> True Path
              |
Previous --> Condition
              |
              +--> False Path

This allows a workflow graph to represent explicit branching. For example:

Agent
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Tool      Human Task

Condition Configuration

A Condition node can be configured with an expression in the Studio workflow editor. The Studio configuration represents the decision expression as workflow configuration rather than requiring application code for every decision. Conceptually:

Condition
├── expression
└── connection mode

The V1 Studio condition configuration uses a true_false connection mode for the two decision paths. This means the visual workflow can connect the two outcomes explicitly:

Condition
   |
   +---- true ----> Node A
   |
   +---- false ---> Node B

Example: Approval Decision

A simple approval workflow can be represented as:

Start
  |
  v
Agent
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Human     End
Task

The expression determines whether the workflow follows the true or false branch. The condition itself does not approve or reject the request. It only evaluates the configured decision.

Example: Agent Result Routing

An agent can produce a result that is then evaluated by a Condition node.

Start
  |
  v
Agent
  |
  v
agent_output
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Tool A   Tool B

This separates:

Agent reasoning
Workflow routing
Tool execution

The agent produces information, while the workflow determines what happens next.

Example: Tool Result Routing

A Tool node can also provide information used by a later condition.

Tool
  |
  v
tool_output
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Continue  Alternative

This allows deterministic tool operations to participate in explicit workflow branching.

Conditions and Workflow Variables

Conditions operate as part of the workflow’s state and data flow. For example:

input
  |
  v
Agent
  |
  v
agent_output
  |
  v
Condition

The expression can use information produced earlier in the workflow. This makes workflow variables an important part of conditional execution.

Conditions and Loops

Conditions are also used as part of repeated workflow execution. Conceptually:

Process
   |
   v
Condition
 /       \
true     false
 |         |
 v         v
Repeat    Continue
 |
 +----> Process

The condition determines whether the loop continues or exits. A loop should always have a clear termination condition.

Conditions and Human Tasks

Conditions can be used after a Human Task to route the workflow according to the human decision. For example:

Human Task
     |
     v
Condition
   /     \
true     false
 |         |
 v         v
Execute   Stop

This provides an explicit separation between:

Waiting for human input.
Evaluating the resulting workflow state.
Continuing along the appropriate branch.

Conditions and Connections

A connection-backed Tool can produce information that is subsequently evaluated by a Condition node. For example:

Agent
  |
  v
Webhook Tool
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Continue  Alternative

The connection performs the external operation through the tool layer. The condition controls what happens after that operation.

Conditions and Knowledge

An Agent node can use configured Knowledge and then produce a result that is evaluated by a condition. For example:

Question
   |
   v
Agent
   |
   +--> Knowledge
   |
   v
Condition
 /       \
true     false

Knowledge remains responsible for providing information to the agent. The workflow condition remains responsible for routing execution.

Conditions and Memory

Similarly, an Agent node can use configured Memory while participating in a conditional workflow.

Workflow
   |
   v
Agent
   |
   +--> Memory
   |
   v
Condition
 /       \
true     false

Memory and workflow state have different responsibilities:

Memory provides retained information to the agent.
Workflow state carries information needed by the workflow execution.

Multiple Conditions

A workflow can contain multiple decision points.

Start
  |
  v
Condition A
  |
  v
Agent
  |
  v
Condition B
  |
  v
Tool
  |
  v
End

Each condition can make a decision using information available at that point in execution. This allows decisions to be made progressively as the workflow produces new results.

Chained Conditions

Conditions can also form decision trees.

Condition A
   /    \
 true   false
  |       |
  v       v
Condition B
  |
  +--> true  --> Path A
  |
  +--> false --> Path B

For example:

Check Customer
   |
   v
Condition
 /       \
active   inactive
  |         |
  v         v
Check      End
Payment
  |
  v
Condition
 /       \
valid    invalid
 |          |
 v          v
Process   Request Payment

Separate conditions can make complex routing easier to inspect.

Combining Decisions

A decision may depend on multiple pieces of workflow information. For example:

Customer Valid
      AND
Payment Valid
      |
      v
   Continue

The implementation should keep complex decision logic understandable. When a single expression becomes difficult to read, consider separating the decision into multiple workflow conditions. For example:

Validate Customer
       |
       v
Condition
       |
       v
Validate Payment
       |
       v
Condition
       |
       v
Continue

Missing Values

A condition may depend on a value that has not been produced. For example:

Agent
  |
  v
Condition
  |
  +--> expects agent_output

If the required workflow information is missing or invalid, the workflow may fail rather than producing the intended decision. For this reason, workflows should make required data dependencies explicit. A useful pattern is:

Input
  |
  v
Validation / Preparation
  |
  v
Condition

Condition Errors

Condition evaluation can fail because of problems such as:

Missing required data
Invalid expression configuration
Unexpected value types
Invalid workflow state
An exception during expression evaluation

The workflow runtime determines how such execution failures are surfaced. Applications should not assume advanced retry or timeout behavior for conditions in V1.

Conditions Are Control Flow

A Condition node should primarily control workflow execution. For example:

Agent
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Tool A   Tool B

The Condition node decides where execution goes. The Tool nodes decide what work is performed. This separation makes the workflow easier to understand.

Condition vs Agent Reasoning

Agents and Conditions have different responsibilities.

Agent	Condition
Performs model-based reasoning	Controls workflow routing
Produces information	Evaluates a configured expression
Can use Knowledge	Uses workflow execution information
Can use Memory	Produces a branch decision
Can use Tools	Does not replace application operations

A common pattern is:

Agent
  |
  v
Result
  |
  v
Condition
 /       \
true     false

The agent can perform reasoning, while the condition provides explicit workflow control.

Condition vs Tool

Tools and conditions also serve different purposes.

Tool
  |
  v
Result

versus:

Condition
 /       \
true     false

A Tool performs an operation. A Condition determines which workflow path should execute. They can therefore be combined:

Tool
  |
  v
Condition
 /       \
true     false

Conditions in Visual Studio

BindAI Studio provides a visual way to configure Condition nodes. A typical graph is:

Start
  |
  v
Agent
  |
  v
Condition
 /       \
true     false
 |         |
 v         v
Tool     Human Task

The node configuration contains the condition expression. The graph connections represent the resulting execution paths. This makes the condition part of the executable workflow definition rather than merely a diagram.

Testing Conditions

Both branches should be tested. For example:

Condition = true

Expected:
    True branch executes
    False branch does not execute

And:

Condition = false

Expected:
    False branch executes
    True branch does not execute

Important additional cases include:

Missing input values
Unexpected values
Boundary values
Invalid expressions
Downstream branch execution
Conditions inside loops
Conditions after tools
Conditions after agents
Conditions combined with human tasks

Testing both outcomes is particularly important because a workflow can appear correct while only one branch has actually been exercised.

Condition Design

Good condition expressions should be:

Small
Readable
Explicit
Based on available workflow information
Easy to test
Focused on one decision

Avoid hiding large amounts of business logic inside a single condition. Prefer:

Prepare Data
    |
    v
Validate
    |
    v
Condition
    |
    v
Execute Branch

over an opaque decision that combines preparation, validation, and execution logic.

Best Practices

When using conditions:

Keep expressions small and readable.
Base decisions on explicit workflow information.
Keep reasoning separate from workflow routing.
Use descriptive workflow variables.
Make both branches explicit.
Validate required data before making important decisions.
Give loops clear termination conditions.
Test both true and false paths.
Test missing and unexpected values.
Avoid unnecessarily complex decision trees.
Keep external operations inside tools or connection-backed tools.
Document only the expression behavior supported by the installed runtime.

Current BindAI V1 Scope

BindAI V1 supports conditional workflow execution. Conditions can currently be used to:

Select execution paths
Route agent results
Route tool results
Control loops
Coordinate human-task outcomes
Build branching workflow graphs
Combine multiple decision points
Participate in workflows using Memory and Knowledge
Route results from connection-backed tools

In BindAI Studio, Condition nodes are configured with an expression and use the true_false connection mode for their two decision paths.

Deferred Features

The following are not part of the verified V1 Condition feature set:

Advanced retry policies
Advanced timeout policies
Scheduling
Automation triggers
Distributed decision execution
Advanced workflow monitoring

These should not be presented as Condition capabilities until they are implemented and verified.

API Accuracy

This documentation intentionally avoids assuming a particular public Python API such as:

ConditionNode(...)

or:

workflow.condition(...)

unless that API is verified in the current BindAI release. The verified V1 concept is the Condition workflow node, configured with an expression and connected to its true/false paths. When a public programmatic Condition API is formally exposed, its documentation should include:

The actual import path.
The actual constructor or factory.
The actual parameters.
The expression behavior.
The connection behavior.
Runtime examples.
Tests demonstrating the behavior.

Summary

Conditions provide the branching mechanism of BindAI workflows. A typical workflow looks like:

Operation
    |
    v
Condition
   /     \
true     false
 |         |
 v         v
Path A   Path B

Conditions work alongside:

Agents
Tools
Loops
Parallel / Join
Human Tasks
Memory
Knowledge
Connections

The key principle is:

Agents and tools perform work; conditions control which workflow path executes next.

BindAI V1 provides executable conditional branching through Condition nodes configured with expressions and explicit true/false workflow paths.

​Conditions

​What Is a Condition?

​Why Use Conditions?

​Condition Execution

​Condition Expressions

​True and False Paths

​Condition Configuration

​Example: Approval Decision

​Example: Agent Result Routing

​Example: Tool Result Routing

​Conditions and Workflow Variables

​Conditions and Loops

​Conditions and Human Tasks

​Conditions and Connections

​Conditions and Knowledge

​Conditions and Memory

​Multiple Conditions

​Chained Conditions

​Combining Decisions

​Missing Values

​Condition Errors

​Conditions Are Control Flow

​Condition vs Agent Reasoning

​Condition vs Tool

​Conditions in Visual Studio

​Testing Conditions

​Condition Design

​Best Practices

​Current BindAI V1 Scope

​Deferred Features

​API Accuracy

​Summary