Skip to main content
Beta Workflows are a visual orchestration layer for your AI agents. You arrange agents, tools, and logic on a horizontal canvas to build deterministic, multi-step pipelines — with full control over execution order, branching, and data flow. If you have three specialized agents (one that triages, one that researches, one that drafts a response), Workflows let you wire them into a single pipeline that runs reliably on every trigger. But this isn’t a traditional workflow builder where you map fields between steps. Under the hood, every node is powered by an AI agent. When you drop an Email node onto the canvas, you’re not wiring up an SMTP call. You’re deploying an agent that reads the previous step’s output, understands what needs to be communicated, composes a properly formatted email, and sends it. The same is true for OCR, Guardrails, Summarizers, and Action nodes — they all use LLMs to reason about the data flowing through them. The result: a deterministic runtime that orchestrates your custom AI agents, where the execution path is predictable and repeatable, but the intelligence at each step is adaptive. You write instructions — natural language descriptions of what each step should do — and the agents figure out the rest.

​
Why Agentic?

Traditional workflow builders force you to map every field manually: take response.data.items[0].email from Step 1 and pipe it into recipient on Step 2. If the API changes shape, your workflow breaks. xpander workflows are different. Each node receives the full output of the previous node as context. An AI agent inside the node reads that context, understands what’s needed, and takes the right action. There’s no brittle field mapping — just intelligent data flow. This design has three consequences:
  • Zero-config nodes — Most nodes work the moment you add them. An OCR node doesn’t need you to tell it which field contains the image URL. It reads the previous step’s output and finds it.
  • Natural language control — Instead of JSON schemas and field mappings, you write instructions like “Extract only the billing address from this document” or “Only continue if the sentiment is negative.”
  • Graceful adaptation — When upstream data changes shape, the agent adapts. A renamed field or a restructured payload doesn’t break the pipeline.
Example of a workflow where every node is powered by an AI agent — no field mapping required:

​
The Canvas

The workflow canvas uses a horizontal left-to-right layout. Data flows from the START block on the left, through your processing nodes, to the END block on the right. Every workflow has two fixed blocks:
  • START — Your triggers. Every workflow comes with four trigger types pre-configured: Webhook (HTTP POST), API (REST), Chat (conversational interface), and Schedule (cron). Each trigger shows an Enabled badge when active and provides its own URL, test buttons, and API docs.
  • END — Your output configuration. The END block determines how results are returned: as an AI-generated summary (Summarizer), structured JSON (JSON Object), or notifications (Alert settings).
Between START and END, you build your logic by clicking + buttons on the canvas. Nodes auto-connect to adjacent steps — there are no dangling or disconnected nodes. The canvas enforces a clean, valid pipeline at all times.

​
Preventing Duplicate Events

Webhook-triggered workflows often receive the same event more than once — retries, redundant notifications, or upstream systems that fire multiple times. Enable Prevent Duplicate Events in the Webhook trigger settings to handle this automatically. When enabled, the workflow uses Event Identifier Fields (JSON paths like messageId, customer.email, or payload.iCalUID) to build a composite key for each incoming event. If the same key arrives within the configured time window (in minutes), the workflow skips execution and returns "Event skipped: duplicate event within configured time window". This means you can point a webhook at a chatty upstream system and trust that the workflow only processes each unique event once.

​
Node Types

Nodes are organized into three categories.

​
Agents

These nodes explicitly invoke AI models to process data.

Agent

Invokes one of your xpander AI agents. Select an existing agent or create a new one inline. The agent receives the previous node’s output as its input and runs with its full tool set, memory, and system prompt.

Classifier

An LLM that classifies, labels, or transforms inputs based on natural language instructions. Use it to route data to different branches — e.g., “Is this a billing question or a technical support request?”

Summarizer

An agent that takes large payloads and answers specific questions. Give it instructions like “What is the total revenue?” or “List the action items” and it returns a focused answer from the data.

​
Actions

Action nodes execute tools, code, and integrations. Most of them are secretly agents — they use an LLM behind the scenes to intelligently map data and invoke tools, so you never touch a schema.

Action

Pick any tool from the xpander library. An AI agent reads the previous step’s output and calls the tool with the right parameters — no schema configuration needed.

Email

Sends emails via xpander’s email service. Specify a recipient and describe what you want to say. The agent composes a properly formatted email and sends it.

OCR

Extracts text from images and documents. Processes files from the previous node automatically — no configuration needed.

Code

Execute custom code for data transformation, API calls, or any deterministic logic. The one node that doesn’t use an LLM — it runs exactly what you write.

Custom Function

Run a pre-defined function. Useful for reusable logic shared across workflows.

Workflow

Nest another workflow inside this one. Build composable automations by referencing existing workflows as sub-steps.

​
How the Action Node Works

When you add an Action node and select a tool from the xpander library, you won’t see any schema to fill in. No input fields, no output mapping, no parameter configuration. Behind the scenes, xpander creates an AI agent with that tool marked as required. At runtime:
  1. The agent receives the full output of the previous node
  2. It reads the tool’s function signature to understand what parameters are needed
  3. It extracts the right values from the previous node’s output
  4. It invokes the tool and returns the result
This is why you can drop a “Send Slack Message” action after any node and it just works — the agent figures out what to send, to which channel, based on the context flowing through the workflow.
You can customize what the Action node returns by configuring its output schema in Advanced settings. By default, it returns the raw agent response, but you can define structured output fields so downstream nodes get clean, predictable data.

​
Flow

Flow nodes control the execution path.

Condition

Branch your workflow into different paths based on conditions. Route data depending on the input.

Guardrail

An AI judge. Write a natural language condition like “Only continue if this is a pull request to the main branch” and the node evaluates incoming data against your rule, returning Pass or Fail.

Wait

Pause execution until a condition is met. Supports webhook callbacks and human-in-the-loop approval.

Send to End

Skip remaining nodes and route data directly to the END block. Useful for early exits or conditional completions.
Guardrails are agents too. When you write “Only continue if this is a pull request to the main branch,” you’re configuring a Classifier agent with structured output set to Pass/Fail. The LLM reads the incoming data, evaluates your condition, and makes a judgment call — this isn’t pattern matching, it’s reasoning. You can add more output options beyond Pass/Fail in the Advanced settings.

​
Instructions and Data Flow

This is the core concept that makes workflows powerful. Every agent-powered node has an Instructions field — and what you write there controls what the node does at runtime.

​
How Instructions Work

When you click a node on the canvas, its settings panel opens. The Instructions field (also called “Agent Instructions” on Agent nodes) accepts natural language text that gets injected into the agent’s system prompt at runtime, alongside the data from the previous node. For an Agent node, these instructions are added alongside the agent’s existing system prompt — they extend the agent’s behavior for this specific step. For Action, Email, OCR, Summarizer, and Guardrail nodes, the instructions guide the hidden agent that powers the node. Example — Summarizer node instructions: 
Extract the following from the incoming data:
1. Customer name
2. Total amount billed
3. Whether any line items are flagged as overdue
Return the result as a JSON object.
Example — Guardrail node instructions: 
Only pass if the document contains a valid signature
and the total amount is under $10,000.
Example — Agent node instructions: 
You are analyzing a sales call transcript.
Focus on identifying customer objections and
the rep's responses. Ignore small talk.

​
What Happens at Runtime

When a workflow executes, data flows left to right through each node:
  1. START block receives the trigger payload (webhook body, API request, chat message, or schedule event)
  2. Each node receives the full output of the previous node as context
  3. The agent inside the node reads its instructions + the incoming data, then acts
  4. The node’s output becomes the input for the next node
  5. The END block formats the final result as a summary, JSON, or notification
The data format between nodes defaults to a string. If you need structured data between nodes, you can configure the output schema in a node’s Advanced settings to define exactly what fields the node produces.

​
Configuring Output Schema

In a node’s Advanced settings, you can define structured output using schema fields. This is useful when:
  • A downstream node needs specific fields in a predictable format
  • You want to filter out noise and pass only the relevant data forward
  • You’re building a pipeline where multiple branches converge
When you configure an output schema, the agent uses structured output to return exactly the fields you defined — making the data contract between nodes explicit and reliable.

​
Agentic Context

Agentic Context is what makes workflows stateful across runs. When enabled in Workflow Settings, the workflow remembers data from previous executions and makes it available to nodes in subsequent runs.

​
How It Works

Toggle Agentic Context on in Workflow Settings. Once enabled:
  • The last run datetime and last run result are automatically stored after each execution
  • Every node that has input instructions can access this stored context
  • You control what flows in and out of the agentic context through per-node input/output instructions

​
Input and Output Instructions

Each node can have two types of instructions that interact with the agentic context:
  • Input instructions — Tell the node what to pull from the agentic context. For example: “Check the previous run’s result. If the customer list has changed since last time, only process the new entries.”
  • Output instructions — Tell the agentic context what to remember from this node’s execution. For example: “Store the list of processed customer IDs so we can diff against them next run.”
This turns a stateless pipeline into an intelligent process that evolves over time. A workflow that monitors a GitHub repo can remember which PRs it already reviewed. A daily report workflow can compare today’s numbers against yesterday’s. An alert workflow can avoid sending duplicate notifications.
Agentic Context is different from agent-level memory. Agent memory persists across conversations within a single agent. Agentic Context persists across workflow runs, making the entire pipeline aware of its own history.

​
Example: Call Analyzer Workflow

Here’s a real workflow that processes sales calls from a CRM: 
START → Code (Prompt Builder) → Agent (Call Analyzer) → END
How it works:
  1. START — A webhook receives a Salesforce notification when a new call recording is available. The payload includes the recording URL and account metadata.
  2. Code: Prompt Builder — A Code node transforms the raw Salesforce payload into a structured prompt. It extracts the recording URL, account name, deal stage, and recent activity, then formats them into a context block for the agent.
  3. Agent: Call Analyzer — An AI agent receives the formatted prompt. Its instructions tell it to transcribe the call, identify customer objections, assess rep performance, and score the call on a 1-10 scale. The agent has tools for audio transcription, CRM lookup, and sentiment analysis.
  4. END — The Summarizer output extracts the call score, key objections, and recommended next steps into a clean summary. A Notification sends an alert to the sales manager if the score is below 5.
The Agentic Context is enabled, so the agent can reference previous calls with the same customer. Its input instructions say: “Check if this customer has been analyzed before. If so, note any changes in sentiment compared to the last interaction.” The workflow runs via a saved preset labeled “Salesforce request” — one click in the Builder to test with real CRM data.

​
Version Management

Workflows use immutable versioning.
  • Auto-save — Changes save automatically as you work in the Builder
  • Deploy — Click Deploy to publish a new version (v1, v2, v3…). Each deployment is an immutable snapshot.
  • Version History — Click the clock icon in the top bar to see all published versions with timestamps
  • Rollback — Select any previous version to restore it

​
Monitoring

Switch to the Monitor tab to observe your workflow in production.

​
Threads

Every workflow execution appears as a thread showing the last interaction time, action count, token usage (input and output), and task ID. Click a thread to see its execution timeline:
  • Step-by-step logs — Each node execution with timestamps, request payloads, and responses
  • Execution duration — Total time broken down by step (e.g., “2 seconds and 530 milliseconds”)
  • Download Log — Export the full log for debugging

​
AI Insights

Click Evaluate on any thread to get an AI-powered analysis of the execution — bottleneck identification, prompt improvement suggestions, and behavior analysis.

​
Metrics & Tasks

The Metrics tab shows aggregate analytics across all executions — performance trends, success rates, and resource consumption. The Tasks tab provides task-level tracking for individual executions.

​
Workflow Settings

Click the gear icon in the top bar to access:
  • General Details — Name and description (shown in the workflow list)
  • Agentic Context — Enable cross-run memory (see Agentic Context above)
  • LLM Settings — Default AI model for the workflow. Select a provider (OpenAI, Anthropic, Google, etc.), choose a model, and set reasoning effort. Individual nodes can override these defaults.
  • Access — Control who can view and edit the workflow
  • Notifications — Alert rules for failures, completions, or threshold breaches

​
Running and Testing

The green Run button in the top bar executes the workflow. Click the gear icon next to it to open the test input panel:
  • Test Input — Enter a text or JSON payload. Toggle between Text and JSON modes.
  • Presets — Save test inputs with names for quick reuse. The Run button label updates to show the active preset (e.g., “Salesforce request” instead of the default “Hello World”).
The Output Console opens at the bottom of the canvas during execution. Each event shows the Input and Output side by side — you can see exactly what data entered a node and what came out. Events stream in real time (Task Created → Tool Request → Result → Workflow Finished) with timestamps and duration for each step. After completion, you get a Run Again button, a search bar to filter events, and copy buttons on every payload.

​
Next Steps

AI Agent

Build and configure the AI agents that power your workflow nodes

Tools & Connectors

Browse the tool library for Action nodes

Webhooks

Set up webhook triggers for event-driven workflows

Scheduled Tasks

Configure cron schedules for recurring executions