Approvals — human-in-the-loop

Some steps should not be automatic: shipping an order over a threshold, sending the customer email, deleting production data. The Approval node parks the run until a person decides — and every pending gate across your whole fleet lands in one inbox in the Nucleus header.

The gate

Drop Approval (Logic group) where the decision belongs. Its config:

The node has two outputs — approved and rejected — so both outcomes are wires, not status codes.

A real example

The shipped Approval Gate demo gates an HTTP-triggered order flow with four nodes:

1. an HTTP Trigger listening for POST /orders,
2. an Approval gate titled “Approve order?”, its description written for the human (“A new order needs a human decision before it ships”), no timeout,
3. an HTTP Response with status 202 wired to the gate’s approved port, and
4. an HTTP Response with status 403 wired to rejected.

The two outcomes are two visibly different wires on the canvas — the Approval node reference shows the wired capture and a real approved run’s data.

POST an order to /orders and the caller waits while the run parks at the gate. Approve → the caller gets 202; reject → 403. (To answer the caller before the gate instead, put an HTTP Response node in front of it — early response.)

Here is the live loop, recorded end to end — an order arrives, the inbox bell lights up, Approve, and the parked run resumes:

The host’s own dashboard shows the same gate in its Pending approvals panel — see the capture in the Hosts guide.

The fleet-wide inbox

The bell in the Nucleus header polls every pending gate across every authorized host. Each card shows the gate’s title and description, the workflow and app, the host, how long it has waited, and a live countdown when a timeout is set. Approve / Reject (with an optional note) resumes the parked run immediately — the deciding user’s name is recorded with the decision.

Deciding requires the executor role; viewers see the inbox read-only. Hosts also show their own apps’ pending gates in a panel on the host dashboard.

Where the run actually waits

On a deployed host the parked run lives in the host’s embedded engine; the host serves its pending-gate listing and decisions. Pending gates don’t survive a host restart — by design in the current model: a restarted host starts clean, and an undecided gate’s caller sees the connection close rather than a silently dropped decision.

In the editor

Approval gates work in test runs too — the run pauses, Studio surfaces the gate, and you decide it inline. Same node, same semantics, before anything is deployed.

Agent tool calls can wait for you too

The gate pattern extends to AI: the AI Agent node’s approval property (off / write / all) parks the agent’s tool calls for a human decision through the same machinery — an agent can research freely but needs a sign-off before it writes. The pending call surfaces like any other gate, with its own timeout policy.