Running a flow · Semantix

Press Run in the strip above the canvas. It becomes a red Stop until the run ends.

Before anything starts#

Two checks happen before a single model is called, and both report into the strip:

"Add a Message Trigger to start the flow."
"Message Trigger has no message — type one in the Inspector." — the trigger node also turns red.

After that, the flow is checked for problems that can be caught early: an agent with no model, a model you've since deleted, a tool badge nothing can satisfy, or tools with no project open. Any of those refuses the run rather than starting one that must fail.

What decides the order#

Your wires. A plain arrow from A to B means A runs, then B.

Where no wire decides, order falls back to the sequence the nodes were created in. Don't lean on that: the run is worked out from the arrows first and creation order only breaks the remaining ties, so adding a wire anywhere can move an unwired node relative to the rest. If two things must happen in a particular order, wire them.

Note

A parallel branch slot is not a statement about order — it assigns a branch, and branches run together. Wires into output boxes do count toward the ordering, but it never matters, because output boxes don't execute.

Important

A loop in your wiring quietly switches the arrows off. If the wires form a cycle — A to B and B back to A — the order can't be worked out, and every node caught in the loop falls back to creation order. Nothing is dropped and no error appears; the sequence simply stops following your arrows.

Triggers, output boxes and containers never execute. A trigger does still take part in the ordering, because its wire into the first agent is an ordinary arrow — one more reason to wire it rather than leave it floating.

Reading a running node#

Each node that does work shows a coloured border and a small pill at its top-right.

Pill	Meaning
`leg 1`	Calling the model for the first time
`1234 chars`	Text is streaming in
`step 2 · Critic`	Which step of a pipeline is starting — shown briefly on the agent itself, then replaced by that agent's own progress
`loop 0/4`	Which feedback-loop iteration this is
`✓ 1.4s`	Finished, and how long it took
`error`	Failed — hover the pill for the message
`stopped`	Was still going when the run ended

Borders follow: accent while working, green when done, red on error.

Note

Pills stay after a run ends. They're cleared when you start the next run, not when the last one finishes — so what you're looking at is the most recent result, not necessarily a live one.

The three output boxes#

Output boxes never execute. They're windows: wire one to a node and it shows you that node's run. Wire several to the same node if you want more than one view.

Text Output shows the answer, streaming as it arrives. Resizable, selectable, with a copy button. A Text Output wired to nothing is a special case — it shows the flow's final result at the end.

Events is the log — newest at the bottom, most rows expandable for detail: leg 1 → calling model…, tool calls and their timings, completed · final_answer · 4200ms, token counts. Streaming text collapses into a single growing row rather than one row per chunk, and the log keeps the last 150 rows, dropping the oldest.

Six toggles in the Inspector filter it: Stream Deltas, LLM Legs, Tool Calls, Agent Lifecycle, Pipeline Steps, Memory Updates, all on by default. This is the box to reach for when something behaves oddly. (Memory Updates has nothing to show today — agents in a flow keep no history, so no memory rows are produced.)

Chat renders the run as a conversation — prompt, reply, tool cards, markdown — built from the same turn and tool-card components as the main chat panel, scaled down to canvas density. Read-only, and not saved with the flow.

Stopping#

Stop ends the run, and every node still in flight settles to a grey stopped.

Important

Stop does not interrupt a model call in progress. It takes effect at boundaries between pieces of work, so an agent halfway through generating an answer finishes that answer first. On a one-agent flow the button can appear to do nothing for a while — it has registered, and it's waiting for a safe place to stop.

How long that wait is depends on where you are: a feedback loop checks between iterations, not between the agents inside one pass, so the pass you're in always completes. On the relay lane it behaves differently — there the answer is cut off mid-generation.

Pressing Stop in the very first instants of a run — before it has an id to cancel — does nothing at all. Press it again a moment later.

Where a run happens#

Runs execute in the desktop app itself, in the same process as the IDE. Your model provider is called from your machine; tools act on your open project.

There is also a relay lane behind a developer toggle in the header — labelled lane: in-process or lane: relay — which sends the model half of each turn through the Semantix server instead. It's off by default and needs you to be signed in. If you turn it on without a signed-in account, the run quietly uses the normal in-process lane instead.

Note

The header button states an intention, not an outcome. The only place that reports which lane actually ran is an Events box: each agent's opening row carries in-process · … or relay · … in the grey text on its right. That row belongs to the Agent Lifecycle family, so turning that toggle off hides it too. Without an Events box wired to an agent, nothing on screen tells you.

When something fails#

Failures appear as red text in the strip above the canvas, truncated — hover for the full message, click to send it to the console. The node that failed turns red with an error pill, and hovering that pill shows the same message.

Common ones, and what they mean:

Message	What to do
"this flow's agents declare tools but no project is open…"	Open the project the tools should work in
"an agent node has no model selected"	Some agent's Model field is empty
"model … is not in custom-models.json"	The flow names a model you've removed
"Agent node … declares tool(s) this run cannot provide"	A tool badge from an older flow no longer exists
"Flow run failed"	A step failed without a message of its own — check an Events box