Nodes, edges, and testing
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 walks the three things you actually do on the canvas: place nodes, wire them, and test the result.
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 USDC 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 main reference page.
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: a flow may call a subflow or loop, but that inner flow cannot contain another one. 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 USDC 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 are dry-run by default, and the semantics are precise rather than approximate. The engine stubs exactly the nodes that are cost-bearing or side-effecting: LLM returns without calling the model, HTTP returns a fixed placeholder envelope without touching the network, and paid Suede endpoint nodes never settle. Everything else (Input, Output, Branch, Transform, Schedule, Webhook, Subflow, Loop) executes for real. A dry-run loop genuinely iterates; it just 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. It proves nothing about prompt quality or the real behavior of an external API; for that, flip the run to live in the studio and pay the actual node costs for a handful of runs. Test with both before launching; the launch step is deliberately boring if the flow already behaves.
Budget guards apply even while testing: every run shares one in-run cost ceiling (the minimum of the per-run cap, $5 unless configured otherwise, and the agent's remaining daily budget), checked before each cost-bearing node. A runaway loop aborts at the ceiling instead of draining anything.
From working flow to paid endpoint
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.