Node Reference

Nodes are the building blocks of workflows. Each node type performs a specific function, from triggering workflows to processing data to taking actions in external systems.

Node Categories

Agents provides 25+ nodes organized into five categories:

Triggers

Nodes that start workflow execution.

Loaders

Nodes that fetch data from external sources.

AI

Nodes that process data with artificial intelligence.

Actions

Nodes that take actions in external systems.

Control Flow

Nodes that control execution flow and data routing.

Node Anatomy

Every node follows a consistent structure:

┌─────────────────────────────────────┐
│         Node Type Icon              │
│           Node Name                 │
├─────────────────────────────────────┤
│  ○ Input Port(s)                    │  ← Receive data from upstream
├─────────────────────────────────────┤
│         Configuration               │  ← Parameters you configure
│         • param1                    │
│         • param2                    │
├─────────────────────────────────────┤
│  ● Success Output                   │  ← Send data downstream
│  ● Error Output (optional)          │  ← Route errors separately
└─────────────────────────────────────┘

Ports

Input Ports:

• Receive data from connected upstream nodes
• Most nodes have 1 input port
• Merge nodes (Zip, Broadcast) have 2-4 input ports
• Trigger nodes have 0 input ports (they start the flow)

Output Ports:

• Send data to connected downstream nodes
• Success channel: Normal output when node completes successfully
• Error channel: Output when node encounters recoverable errors

Node ID Format

Nodes have internal IDs following this pattern:

<family>.<mode>.in<N>.success<K>.error<M>

Example: ds.slackPost.perItem.in1.success1.error1

• ds.slackPost: Slack Post node family
• perItem: Processes items individually
• in1: 1 input port
• success1: 1 success output
• error1: 1 error output

Execution Modes

Nodes operate in one of two execution modes:

Per-Item Mode

Processes each input item individually. If 5 items arrive, the node runs 5 times.

Use case: Sending individual messages, processing records one at a time

Example: Slack Post sends one message per input item

Batch Mode

Processes all input items together as a collection.

Use case: Aggregating data, merging streams, operations that need all items at once

Example: Zip combines multiple streams into a single output

Configuration Parameters

Node parameters can be configured in two ways:

CEL Expressions

Dynamic values computed at runtime using Common Expression Language:

trigger.meetingPlanId
json.score > 0.8
json.attendees[0].email

For static literal values, use CEL string/number literals:

"#sales-updates"
42
true

Liquid Templates

Text with variable substitution for message content:

Hello {{ json.name }},

Your meeting "{{ json.meeting.title }}" has ended.

Timeouts and Retries

Default Timeouts

Retry Behavior

Most nodes retry on failure:

• Max attempts: 3 (default)
• Strategy: Exponential backoff with jitter
• Initial backoff: 1 second
• Max backoff: 30 seconds

Nodes marked as side-effecting (Slack, Email, CRM) use idempotency keys to prevent duplicate actions on retry.

Finding the Right Node

"I want to start a workflow when..."

→ Use a Trigger node

"I want to fetch data from..."

→ Use a Loader node

"I want to use AI to..."

→ Use an AI node

"I want to send a message via..."

→ Use an Action node

"I want to update my CRM..."

→ Use a CRM Action node

"I want to control the flow..."

→ Use a Control node

Best Practices

1. Handle Errors

Connect error outputs to appropriate handling:

• Log errors for debugging
• Send alerts for critical failures
• Use Sink to gracefully terminate error paths

2. Use Appropriate Execution Modes

• Per-item when each item needs individual processing
• Batch when you need to aggregate or compare items

3. Configure Meaningful Names

Rename nodes to describe their purpose:

• ❌ "AI Prompt"
• ✅ "Summarize Meeting Transcript"

4. Keep Workflows Focused

• One workflow per logical automation
• Break complex processes into multiple workflows if needed

5. Test Before Releasing

• Use MANUAL trigger to test with real data
• Verify outputs at each step
• Check error handling paths