Agentic and autonomous runs

The agentic node is a design-time flow generator that also takes on a post-apply monitor role. Together with the autonomous run mode, it forms a complete generate → review → run → observe → fix lifecycle. Every stage is bounded, audited, and reviewable.

Generator: from request to reviewable flow

When you press Run, a flow that contains an agentic node short-circuits to the agentic path. The node turns its natural-language workflow request into a proposed flow. A review modal renders the proposed DSL and plan, and you pick Accept or Reject. Nothing merges onto the canvas without acceptance.

Only one agentic node is allowed in the main flow. Sub-flows may host their own.
Generation is workspace-grounded. The agent inspects the chosen workspace folder so that generated nodes carry real paths and commands.
Pre-apply verification statically scans every proposed flow for destructive operations and sandbox-escape paths. It renders per-node warnings in a Checks section of the review modal before anything runs.
An ai node can also run in agentic mode with a cloud provider. Generation uses the node’s provider and model, while the rest of the lifecycle is shared.

Monitor: the post-apply watcher

When you accept and apply, the agentic node flips into monitor mode. It shows a monitoring tag and is excluded from the executed graph. The monitor watches the run, scoped to its sub-flow when applicable.

On an unhandled failure, meaning there is no explicit .fail edge leaving the failed node, the run pauses and an interception modal opens. always and pass edges do not count as handling a failure. Only an explicit .fail branch does.
The modal auto-plans a fix when it opens. It shows the detected issue and the proposed correction, and it offers Accept fix & apply, Resume without fix, or Reject (stop).
Fixes are context-aware. Re-planning sends the serialized current flow along with the failure observations. It is not a regeneration from the original request.
Fixes are surgical where possible. A single-node proposal patches the failed step in place and keeps its id and edges. Multi-node proposals land as a grouped, retryable sub-flow.
An ai node can carry an expect assertion. After generating, the node self-evaluates its output against the expectation and fails when the expectation is unmet. The monitor path then engages on output that is semantically wrong but did not error.

Autonomous mode: bounded convergence

Run autonomously hands the loop to the engine. The monitor auto-plans and auto-accepts each fix in the background, applies it, and re-runs until the flow passes or a budget is exhausted. The interception modal is suppressed, but progress stays visible in three places. On the canvas, executed nodes pulse per step and the monitor shows an auto-fixing state. The status bar shows a live fix counter, and the flow tab shows a badge with the same count.

A separate converge autonomously action hands the whole generate → run → observe → re-plan loop to the backend in one bounded call. It streams each iteration’s execution events live, then loads the converged flow onto the canvas with the agentic node left monitoring.

Autonomous run is an opt-in capability that is controlled by governance. The org setting allow_autonomous_run must be on, or the entry is refused. When it is refused, the CLI errors, the desktop disables the menu item, and a cross-host workflow downgrades to manual review. The in-node tool loop is gated the same way, through allow_agent_tool_loop plus a per-node allowToolLoop.

The three budgets

Budget	Setting	Behavior when exhausted
Iteration cap	max agentic iterations	The loop stops proposing fixes
Wall-clock ceiling	max agentic seconds (0 = unlimited)	No new iterations start once elapsed
Token ceiling	max agentic tokens (0 = unlimited)	Stops once the executed flows’ AI nodes exceed it

All three are editable in Settings → Execution safety. The iteration cap is captured at session start so that the loop, status bar, and tab badge share one value.

Safety gates around every run

Destructive-action confirmation. A run pauses before any node that performs a destructive operation, such as a file delete, rm, git push, git reset --hard, or kubectl delete, and waits for per-step confirmation. This is on by default. Unattended scheduled runs override it, and headless runners bypass it.
Pre-run validation. Required adapter fields are checked before execution, and missing fields block the run.
Sandboxed adapters. Every tool call an AI node makes in its tool loop runs through the real, workspace-confined adapters.

Everything is recorded

Every interception is logged and recorded against the run, whether it was manual or autonomous and whether it was fixed or un-fixable. The record includes a DSL before/after snapshot. The History view’s Interceptions section shows each one with Revert (load before) and Load fixed flow actions. These open the snapshot on a fresh tab without changing the original.

Session memory

Flows can persist working values through the set-variable utility ({{memory.<key>}}). These values are durable across sessions and restarts, and you can clear them on demand. The orchestrator owns all retry and session state, not the model. Models stay stateless by design.

AI overview - the unified AI node.
Agentic and monitor - the AI-side mechanics.
Sandboxing - the gates in detail.