The Test tab
The Test tab is your workflow actually running, next to the diagram that shows what is
happening. The execution canvas is on the left, the Chat panel on the right; once a run
starts, the Debug and Execution Log panels appear under the canvas.
Starting a run
There is no separate Run button here: a chat message starts the workflow. Your text arrives at the entry node, the answer is taken from exit.
Customer support · Test
Chat
You can attach files with the paperclip to the left of the input. While a turn is running, the send button is replaced by Stop current response. Messages of one session run in order: send several in a row and a queue counter appears at the bottom. If the connection drops, the panel says “Reconnecting…” and picks the stream back up on its own.
Hovering your own message reveals Rerun from this message: the history is truncated from that point and the text returns to the input box. The bin icon in the chat header clears this session’s history entirely.
The Test tab’s chat lives in its own session — its history does not mix with the public chat or with the channels.
Node statuses on the canvas
The canvas here is read-only: nodes cannot be moved or connected, but panning, zoom, the minimap and the zoom controls all work. As the run proceeds a status dot appears in the card header: running (pulsing), completed, failed, cancelled or skipped.
Double-clicking a composite node drills into its subgraph —
the breadcrumbs in the top-left corner bring you back.
The node inspector
Clicking a node opens the inspector. The header carries the node id, its type and a status badge; for a skipped node the reason is spelled out right there, not just the word “skipped”.
ai_agent_1
Node inspector
ai_agent · completed
| Field | Value |
|---|---|
| Node type | ai_agent |
| Status | completed |
| Duration | 4.2 s |
| Tokens | 1840 (↑1520 / ↓320) |
| Credits | 2.84 |
- State — the tab exists only for nodes that really keep state. For memory it is the messages by role plus the summary, for agent_plan the todo list, for agent_skills the skills list, otherwise a key-value store. The storage scope is shown next to it.
- Inputs — what the node received, verbatim.
- Outputs — the error if there was one, the tool calls with their arguments and results, then the node’s own output.
- Info — type, status, start and finish time, duration, plus, where they exist: tokens, credits, retry count, skip reason, the calling node and the exec handle that fired.
Why a node was skipped
A skip is not always a defect. The inspector shows the classification:
| Reason | What happened |
|---|---|
| branch_not_taken | An upstream branch went the other way |
| upstream_failed | Every path here died on an upstream failure |
| upstream_not_run | No predecessor of this node ever ran |
| unmet_in_degree | The node never received some of its inputs |
| loop_body_not_entered | Inside a loop body that never iterated |
| no_exec_trigger | Nothing could trigger it: no incoming link |
Clearing state
The State tab has a Clear state button that deletes the stored state of that one node (conversation memory, plan, skills). It is disabled when the state is already empty. This is a different action from clearing the chat history: the history is what you see in the transcript, the state is what the node remembers between runs.
The Debug panel
One row per node of the run: id, type, status. An expanded row shows the error, the token stream (for streaming nodes), the rendered config templates, the input and the output. Images, audio and video in the output are previewed, and tabular data is drawn as a table rather than raw JSON.
The rendered templates answer the most common debugging question: what a template in the node’s configuration actually became on this particular run.
The Execution Log panel
The header carries the run status and the total token count; clicking it collapses the
panel. Inside is the log with filters: level chips (debug, info, warning, error),
a single-node selector, a search over the message text, and two sliders that bound the
time window relative to the start of the run. The log follows new lines on its own.