Building Blocks
Every block type on the agent canvas, what it does, when to reach for it, and how the pieces snap together.
An agent is a graph of blocks. Each block does one job, receives what came before it, and hands its result to whatever comes next. You never place blocks by hand; the builder chooses them from your description. But knowing what each one does makes it easy to ask for exactly the automation you want, and to read any canvas at a glance.
Every block on the canvas is inspectable. Click a node and a details panel opens showing exactly what it's configured to do: the code it runs, the request it sends, the fields it expects. You can test a single node from here without running the whole automation.
How a run starts
Trigger
Every automation begins with a trigger, which is simply how a run gets started:
- Manual: the Run button in the builder.
- API: a POST from your own systems; see the API reference.
- Schedule: a recurring interval.
- Email: a matching message to your team inbox starts a run, with the email's body and attachments handed in as inputs.
Email and schedule triggers go live when you publish, and are managed on the Triggers page under the Agents tab.
When to use it: always; every automation has one. Example: "run this every morning at 9" becomes a schedule trigger, no code required.
Input
The typed fields a run asks for (a count, a date range, an ID) plus any files
attached at launch. Attached files are available throughout the run as
inputs.files, so a spreadsheet you attach can be read by a code step or an
agent step downstream.
When to use it: whenever a value changes from run to run.
Example: an order_limit field with a default of 10, so one automation
serves both the daily batch and the occasional big backfill.
Deterministic steps
These blocks do exactly the same thing every time. No model is involved, so they're fast, cheap, and perfectly repeatable.
API Call
One HTTP request to a fixed endpoint: fetch records, post an update, hit a
webhook. When the endpoint needs credentials, the block authenticates with
Password references (#key): the graph stores only
the reference, and the secret value is resolved server-side at run time. API
keys and tokens never appear in the graph, the chat, or the run history.
When to use it: the data you need is one known request away. Example: GET the ten newest orders from your commerce API before fanning out over them.
Transform
Mechanical reshaping of data: pick fields, map values, filter a list, flatten nested structures. Fully deterministic and instant.
When to use it: the reshaping rule is simple enough to state in one
sentence. Example: "keep only rows where status is open and drop every
column except id and amount."
Code
A Python or TypeScript snippet running in an isolated sandbox. It receives the step's input, does its work, and returns a result. This is the workhorse for parsing, math, deduplication, and building files like CSVs.
When to use it: the logic is precise but too involved for a Transform. Example: take the loop's collected results and write them into a CSV with a header row, like the "Build CSV" step in the pipeline on the overview page.
Code is always sandboxed
Code steps run in an isolated sandbox on every run, sandbox and live alike. The isolation is a safety property, not a simulation: your code executes for real, it just can't touch anything it shouldn't.
Model-powered steps
These blocks bring judgment into the graph, each with a clearly defined job and output shape.
LLM
A single structured model call: classify, extract, or summarize, with an output shape you define so downstream blocks always receive predictable data.
When to use it: one judgment, one answer, no tools needed.
Example: read a support ticket and return {urgency: "high" | "normal", category: string}.
Agent
A tool-using agent for the parts that need multi-step reasoning. Instead of a fixed sequence, you give it instructions and grant it capability bundles; the agent decides how to use them to finish the job:
Capabilities you don't grant simply don't exist for that agent, which keeps each node's reach as narrow as its job.
Credentials follow the same rule as everywhere else on the platform: an API-calling agent authenticates through Password references, so it can call authenticated endpoints without the secret ever entering the model's context, the graph, or the chat. The agent sees that a request is authenticated; it never sees the key.
When to use it: the task needs judgment across several steps. Example: "reconcile these two exported spreadsheets and explain every mismatch" needs file reading, some ad-hoc code, and reasoning about what counts as a mismatch.
Keep deterministic work in API Call, Transform, and Code blocks; reach for an Agent when a fixed recipe genuinely can't express the task.
Browser Agent
A one-off, prompt-driven browser task inside the automation, without building a full workflow first.
When to use it: a small or occasional browser step that doesn't deserve its own workflow. Example: "open this product page and grab the current price" as one step of a bigger pipeline. For anything you'll run repeatedly, publish it as a proper browser workflow and use the next block instead.
Reusing what you've built
Browser Workflow
The flagship integration: runs one of your published browser workflows as a step. The automation passes it inputs, the workflow runs exactly as it would on its own, and its outputs flow back into the graph. The builder inspects the workflow's real contract (its exact input fields and outputs) when wiring it in, so the mapping matches reality.
When to use it: the browser task already exists as a workflow. Example: put "Create JODL DS Order in Zoho" inside a loop and you get "create an order in Zoho once per fetched record", which is the whole heart of the pipeline on the overview page.
Sub-automation
Calls another published automation as a step, so automations compose the same way workflows do.
When to use it: you've built and tested a pipeline you want to reuse. Example: a "validate and enrich a customer record" automation called as one step inside three different intake pipelines, maintained in one place.
Flow control
Condition
Multi-way branching. Routes can be decided by plain rules or by model judgment, and each branch is labeled on the canvas so the logic stays readable.
When to use it: different situations deserve different paths. Example: rule-based, "if the total is over 1,000, route to the approval branch"; judgment-based, "route by how urgent this ticket sounds."
Loop / Map
For-each over a list: the loop's body runs once per item, and results are collected at the end. Loops can run items in parallel, say three at a time, and each parallel worker shows up separately in the run view so you can watch every item progress.
When to use it: the same work applies to every item in a list. Example: "run the Zoho workflow for each of the ten fetched orders, three in parallel" is one loop block with the browser workflow as its body.
Wait
Two flavors of pause:
- Delay: wait a fixed amount of time before continuing.
- Approval: a human checkpoint. The run pauses and shows waiting approval; an approver reviews and either resumes or rejects it.
When to use it: a delay for pacing; an approval before anything irreversible. Example: pause for sign-off after the CSV is built but before the email goes out.
Finishing up
Output
The final result of the run: the value your API callers receive and the run history displays. An output can also deliver by email, with files produced during the run attached automatically.
When to use it: every automation that produces something ends here. Example: "Email CSV Report" delivers the built CSV as an attachment to the address you named in the brief.
Test drafts safely, watch runs, approve checkpoints, and review self-healed fixes.
How #key references keep credentials out of graphs and chats.
Was this page helpful?