Node Types

Every workflow is built from nine node types. Each serves a specific role in the execution graph — from starting the workflow to branching logic to delivering results.

Trigger

The trigger node is the entry point for every workflow. Exactly one trigger node is required per workflow. It defines how and when the workflow starts, and its output (the trigger payload) is available to all downstream nodes via {{ trigger.payload }}.

Trigger modes:

Each mode has different configuration requirements. See Configuring Triggers for setup details, and Scheduling for cron syntax and the schedule builder.

Action

Action nodes are the workhorses of a workflow. Each action contains a natural language instruction that Thallus executes through the orchestration pipeline. The instruction can reference other nodes' output using Jinja2 templates.

Key settings:

• Instruction — what the node should do, written in natural language. Supports {{ nodes.X.response }} templates
• Execution mode — direct routes through the standard orchestrator; investigate uses the multi-agent investigation pipeline for complex tasks
• Agent selection — the system auto-suggests agents based on the instruction, or you can explicitly select or exclude specific agents
• Success criteria — optional natural language description of what a successful result looks like. When set, the system uses a fast LLM call to evaluate the result against the criteria after each attempt
• Retry config — enable retries with configurable max attempts (1–10), delay (minimum 10s), and exponential backoff multiplier (1.0–5.0)
• Timeout — per-node timeout overrides the workflow branch timeout (default 300s)
• Document scoping — restrict which document collections or specific documents the action can access

Tool confirmations:

If an agent inside an action node calls a tool that requires confirmation, the workflow pauses until you approve or deny — just like an Approval node. To run the node fully automatically, enable Skip tool confirmations in the node's Advanced Settings panel. This bypasses all confirmation checks for that node.

Action nodes produce a result object containing response (the text output), success (boolean), and agents_used (list of agent names).

Condition

Condition nodes create binary branches in the workflow. They evaluate a Jinja2 boolean expression against the current execution context and route to either the true or false branch.

Configuration:

• Expression — a Jinja2 expression that evaluates to true or false (e.g., trigger.payload.amount > 1000)
• True label — display label for the true branch (default "Yes")
• False label — display label for the false branch (default "No")

Condition nodes support A2A learning — they can start with a natural language intent and progressively learn the correct expression from execution data.

Router

Router nodes provide N-way categorical routing. Where a condition node offers a binary true/false split, a router can direct execution down any number of named routes.

Configuration:

• Available routes — named routes, each with an optional description
• Default route — the fallback route if no other route matches
• Route descriptions — help the AI understand what each route is for during learning

Like condition nodes, routers support A2A learning with per-route consistency tracking.

Merge

Merge nodes collect results from parallel branches back into a single path. A merge only waits for branches that actually executed — if a condition sent execution down one path, the merge does not block waiting for the other.

Results are collected into a keyed object where each key is the source node's title (lowercased, spaces replaced with underscores). This makes merged results accessible to downstream nodes via templates:

{{ nodes.collect_results.results.research_task }}
{{ nodes.collect_results.results.data_query }}

Loop

Loop nodes repeat execution with safety guards to prevent runaway iteration.

Configuration:

A loop terminates when any of these conditions is met (whichever comes first): the until expression evaluates to true, the iteration count reaches the maximum, or the timeout expires. The result includes which termination condition was triggered.

Subworkflow

Subworkflow nodes execute another workflow as a nested step. This enables composition — complex processes can be built from reusable workflow components.

Configuration:

• Workflow — select an existing workflow to run as a subworkflow
• Input mapping — map parent context values to subworkflow trigger payload fields (e.g., customer_id → trigger.payload.customer_id)
• Output mapping — map subworkflow results back to parent context
• Wait for completion — when enabled (default), the parent workflow pauses until the subworkflow finishes. When disabled, the subworkflow runs asynchronously
• Timeout — maximum wait time in minutes (default 60)
• Inherit sources — whether the subworkflow inherits the parent's data source restrictions

Circular reference detection prevents a workflow from directly or indirectly calling itself.

Approval

Approval nodes pause workflow execution until a human approves or rejects. The workflow state is persisted, allowing it to resume even after extended delays.

Configuration:

• Approver mode — any (any listed user can approve) or specific user/role requirements
• Approver users/roles — who can approve the request
• Required approvals — how many approvals are needed (default 1, enables multi-approval flows)
• Title and description — displayed to approvers. Description supports Jinja2 templates for dynamic context
• Context fields — which execution context fields to show approvers for informed decision-making
• Timeout — hours before the approval times out (default 24). Timeouts are checked every 5 minutes
• On timeout — what happens when the approval expires (fail by default)
• Notify via — how approvers are notified (email by default)

For full details on the approval lifecycle, see Approval Nodes.

Delivery

Delivery nodes send workflow results to external destinations. A workflow can have multiple delivery nodes, and each supports one of four methods:

The delivery node automatically picks up the most recent action node's response as the content to deliver. For full configuration details, see Delivery Methods.

Related pages

• Workflow Concepts — high-level overview of how workflows work
• Creating Workflows — build workflows with natural language or the visual editor
• Configuring Triggers — set up manual, schedule, webhook, and poll triggers
• Workflow Learning — how condition and router nodes learn from execution data