This page walks through actually building a flow, the two ways Heliox supports it, and the day-to-day actions you’ll use once it exists. For the underlying concepts (steps, loops, checkpoints, contracts) see Core Concepts first if you haven’t yet.
The canvas
The canvas is a mental graph you compose by hand: drop a step node, give it a prompt, wire it to the steps it depends on, and repeat. A group of connected steps lives inside a Frame — the canvas representation of a flow — which also carries the flow’s title, description, tags, author, and version in its inspector.
A left-hand NodeTree mirrors the canvas as a collapsible outline: Frames (flows) at the top level, their steps nested underneath, so you can navigate a large graph without hunting across the canvas viewport.
Selecting a step opens its inspector, where you configure:
- the prompt template,
- dependencies (which upstream steps feed it),
- tools available to it (for
tool_call/ router steps), - exactly one role, plus any number of mods, dragged in as attachable cards from the marketplace,
- an optional contract and per-step model override.
Selecting a Frame opens the flow-level inspector instead, with the flow’s metadata fields and the Run action that compiles and executes the whole graph.
Text-to-Flow
Instead of wiring a DAG by hand, describe the outcome in a sentence. Text-to-Flow — a meta-agent compiler — reads your intent against the discovered role and mod catalog and assembles a complete step DAG: step prompts, role and mod selection per step, dependency wiring, and (when the intent calls for iterative refinement) a bounded loop-back edge. The result lands on the canvas as a regular Frame — there’s no separate “generated flow” mode — so you can immediately open any step and adjust it by hand, same as if you’d drawn it yourself.
If your request needs a capability the current catalog doesn’t have (an integration, a tool, a role that doesn’t exist yet), Text-to-Flow surfaces that gap explicitly rather than silently approximating it.
Attaching roles and mods
Drag a role card onto a step to set its persona — this replaces whatever role was there before, since a step carries exactly one. Drag one or more mod cards onto the same step to layer constraints on top; mods stack, and the UI flags (non-blocking) when a mod’s declared domain doesn’t match the step’s role, in case that’s not what you meant. See Roles & Mods for the full catalog and how conflicts between stacked mods resolve.
Running
Three granularities, all available from the canvas without leaving it:
| Action | What it does |
|---|---|
| Run (on the Frame) | Compiles the flow and executes the whole DAG start to finish. |
| Run step (on a step) | Executes just that one step in isolation. |
| Run from here (on a step, via its context menu) | Re-executes from that step through the rest of the DAG, reusing already-completed upstream context. |
Every step completion — at any granularity — is recorded as an immutable checkpoint.
Time-travel, edit, and fork
Open the time-travel panel to step through a run’s checkpoints in order. Each checkpoint shows exactly what the step received and what it produced. From any checkpoint you can:
- Edit output — hand-adjust what a step produced, in place, to test how downstream steps react.
- Fork from here — branch a brand-new execution from that checkpoint forward, leaving the original run untouched.
This is the debugging loop Heliox is built around: instead of re-running an entire flow and hoping the flaky part behaves differently, jump straight to the step that misbehaved, correct it or its inputs, and re-run only what comes after.
Exporting
When a flow is ready to leave the IDE, export it to a portable HelioxFlowExport (.flow.json).
That file is a complete, vendor-neutral description of the DAG — prompts, tool names, dependency
graph, contracts, model overrides, and loops — decoupled from any Heliox-internal representation.
From there:
- Run it unmodified on the TypeScript, Java, or Python SDK runtime — Cross-Runtime SDKs.
- Serve it over HTTP or MCP — Serve & Deploy.