What a Node-Based Automation Builder Buys You Over a Chain of If-This-Then-That Steps
Editor ships a real node-based flow editor with branching, loops, and AI-agent steps — a look at the node vocabulary itself, without claiming it's the same engine that runs production automations.
Classic automation tools — the Zapier-style "when this happens, do that" chain — work well right up until your logic needs to branch. The moment you need "do this, unless that condition is true, in which case do these two things instead, then wait for a response before continuing," a linear chain starts requiring workarounds: duplicate zaps, filter steps standing in for real conditionals, manual reassembly of what should be one coherent flow. A node-based builder — branching, looping, merging, and waiting represented as distinct, connectable pieces — is built to represent that logic directly instead of working around a linear format's limits.
What Editor's flow builder actually has
The builder lives in frontend/apps/editor/src/components/flow/, built on @xyflow/react, and it ships a real node vocabulary — twelve distinct node-type configuration dialogs: action, AI-agent, decision, error-handler, loop, merge, split, switch, transform, wait, and webhook-response, plus a general custom-nodes surface. That's a meaningfully richer vocabulary than "trigger, then action" — decision and switch nodes let logic actually branch; loop and merge nodes let a flow repeat over a set and recombine; an AI-agent node lets a step in the flow be handled by an agent rather than a fixed rule; an error-handler node gives a flow a defined response to something going wrong instead of just stopping.
What this piece is deliberately not claiming
It's worth being precise about scope here rather than overselling what was verified. This is Editor's node-editing surface — the vocabulary and the interface for building a flow out of these node types. Piskes separately has a DAG-based execution engine living in apps/workflows, built for actually running production automations. Whether Editor's flow builder and that execution engine are the same system, or how they relate to each other, wasn't directly confirmed in the research behind this piece, so this isn't a claim that building a flow here executes it against real, production-connected automations. Describing the node vocabulary and the editing experience is the honest scope of what's being covered.
Why the vocabulary itself is still worth talking about
Even scoped narrowly to the editing surface, a twelve-node vocabulary with real branching and looping primitives is a genuinely more expressive way to represent complex logic than a linear if-this-then-that chain, regardless of exactly how execution is wired underneath. The comparison content around visual workflow builders (n8n, Zapier, Make) consistently treats branching and looping as the dividing line between a toy automation surface and a serious one — and on the strength of the node types alone, Editor's flow builder sits on the serious side of that line. What this piece won't do is claim more than that about how a flow built here actually runs, because that's a separate question this research didn't settle.