New274+ blocks and 249+ tools are now fully documented

Core Concepts

The five ideas that make every Zelaxy workflow work — blocks, connections, variables, triggers, and outputs.

Master these five ideas and every workflow in Zelaxy — from a one-block toy to a multi-agent pipeline — makes sense.

Blocks

A block is a self-contained unit of work you drag onto the canvas. Each has inputs (configuration + data from upstream), does one job, and produces outputs. Blocks fall into a few families:

FamilyExamplesPurpose
AI & ReasoningAgent, Evaluator, VisionLanguage, reasoning, and multimodal work.
Flow ControlCondition, Router, Loop, ParallelDecide the path and shape execution.
Data & I/OFunction, API, ResponseTransform data and talk to the outside world.
Knowledge & MemoryKnowledge, MemoryRetrieve documents and persist state.
IntegrationsSlack, Gmail, 240+ moreCall external services via tools.

Connections

A connection is a line you draw from one block's output to another block's input. It defines data flow and order: the target block runs after the source, and can read the source's outputs. Zelaxy runs the graph as a DAG — blocks run as soon as their inputs are ready, and independent branches can run in parallel.

Variables & references

This is the heart of Zelaxy. Every block's output is addressable with double-brace references:

{{blockName.fieldName}}
  • {{starter.input}} — the trigger payload.
  • {{agent.content}} — an agent's text answer.
  • {{agent.output}} — an agent's structured (JSON) answer when Response Format is on.
  • {{knowledge.results}} — retrieved document chunks.
  • {{ENV_VAR}} — a secret/env value, injected at run time and never saved into the graph.

References use double braces: {{block.field}}. Angle brackets like <block.field> do not resolve. And when an Agent has structured output enabled, read {{agent.output}} — not {{agent.content}}.

You can rename blocks on the canvas to make references self-documenting — {{researcher.output.facts}} reads better than {{agent1.output.facts}}.

Triggers

A trigger decides how a workflow starts. Configured on the Starter block:

  • Chat / Manual — you run it yourself or via a chat panel.
  • Webhook — an external service (Gmail, Slack, GitHub, Stripe…) starts it on an event.
  • Schedule — a cron expression runs it on a recurring timer.
  • API — a programmatic HTTP call starts it.

Whatever the trigger, its payload arrives as {{starter.input}}. See Triggers.

Outputs

Each block documents the fields it emits. Downstream blocks reference those fields. A Response block (optional) marks the final result returned to the caller or shown in chat.

Putting it together

Starter
webhook · {{starter.input}}
Agent
classify · {{agent.output}}
Router
branch on the result
urgent → Slacknormal → Gmail

The trigger fills {{starter.input}}; the agent classifies it into {{agent.output}}; the router branches on that; each branch calls a tool. Every guide in the Guides section is just this pattern, scaled up.

Next