Build a flow, then test it without spending
A flow is a graph you can read: nodes do the work, edges carry data between them, and a run executes the graph in dependency order. This page covers the work you do on the canvas: placing nodes, wiring them, and testing the result.
- What you'll do
- Place nodes from the palette, wire them into a flow, and run dry runs that exercise every step without spending anything.
- What you'll have
- A flow whose wiring, branches, and output shape are proven, ready for a handful of live runs and then launch.
Quick definitions: node and dry run
- Node
- One step on the canvas: a trigger, a model call, a tool, a branch, or an output. Edges between nodes carry data and set the order they run in.
- Dry run
- A test run that executes your flow's logic for real but stubs every step that would cost money or reach an outside system, so nothing is spent.
Every step is a node with typed params
Drag a node from the palette and its config panel shows typed fields: strings, numbers, selects, JSON. A node declares input and output ports; what arrives on the inputs plus the node's own params determines what it emits on the outputs. Nodes that cost money show their per-call price directly on the card, so a flow's worst-case cost is visible while you build it.
The palette groups nodes by what they do:
A minimal working flow is three nodes: Input → LLM → Output. Input defines what a caller (or the schedule, or a webhook) provides; LLM does the judgment step; Output names what the run returns. Everything else (HTTP fetches, branches, transforms, loops) earns its place by making that spine more capable. Field-level reference for HTTP, Webhook, Transform, and Loop (caps, SSRF guard, expression grammar, failure policy) is on the developer quick reference; the complete catalog, every node type with its dry-run behavior, effects, and cost, is the node reference.
Edges are the data flow and the execution order
An edge connects one node's output port to another node's input port. That single connection means two things at once: the downstream node receives the upstream node's output as input, and the engine will not run the downstream node until the upstream one has finished. There is no hidden shared state: if a node needs a value, a path of edges must carry it there.
Routing is explicit. A Branch node evaluates its condition and activates exactly one of its outgoing paths; nodes on the inactive path are skipped, not failed. Reshaping is explicit too: when the JSON coming out of one node does not match what the next node expects, put a Transform between them rather than asking an LLM to reformat data. String params in several nodes also support {{path}} interpolation from upstream values: the HTTP node's URL, headers, and body all take it.
Two structural rules the studio enforces rather than trusts you to remember: the graph must actually be wired together before it can launch (a disconnected island of nodes is a validation error, not a warning), and subflow nesting is bounded by the engine's depth guard: subflows and loops can nest inside each other up to 16 levels deep, all sharing one in-run cost ceiling, and a run that would go deeper fails at that boundary. Fan-out over a list is the Loop node's job, with concurrency capped at 4 and iterations at 200.
Run it, watch every node, spend nothing
The run dock executes the flow and streams progress node by node: status, output, and cost per node, plus a running cost total for the whole run. When something fails, the dock shows which node failed and with what error; downstream nodes on that path never run against bad data.
Runs in the studio are dry runs. The rule: every node that costs money or reaches an outside system is stubbed (model calls, HTTP and URL fetches, Slack, GitHub, CRM webhooks, transcription and speech, and paid Suede nodes), and every node that only computes locally runs for real (Input, Output, Branch, Switch, Transform, Aggregate, Loop, Subflow, and the document and data nodes). The node reference shows each node's dry-run behavior. A dry-run loop genuinely iterates; it passes dry-run mode through to every inner run so nothing inside can spend.
That split tells you what each kind of test proves. A dry run is a complete test of your graph's structure: wiring, branch logic, transform expressions, loop behavior, output shape. To prove prompt quality and the real behavior of an external API, launch a version and run it from its Live controls for a handful of runs at the actual node costs. With both passing, the launch step takes a minute.
In live runs, every run shares one cost ceiling ($5 per run unless configured otherwise), checked before each cost-bearing node, so a runaway loop aborts at the ceiling instead of draining your credit. Dry runs cannot spend, so the ceiling does not apply to them.
From working flow to published agent
When the flow does what you want against ugly inputs as well as clean ones, continue to Launching. For design judgment rather than mechanics (how narrow to make LLM steps, where to put branches, what to do with loop errors), read Designing a good agent flow. Want the whole path in one sitting? Build your first agent takes you from a blank canvas to a published agent.
Last updated .