Human-in-the-loop approvals

Approval is a property of the agent's tools, set wherever you configure them — in the agent builder's Tools panel and in an agent node's Human in the loop settings on the canvas. Gate as much or as little as you want:

• A single action — on an integration tool, toggle the shield next to an individual action. The agent uses the rest of the integration freely; only the actions you've marked pause for sign-off.
• A whole tool — Require approval for every action gates everything the tool can do. For a workflow or another agent used as a tool, this gates invoking it at all.
• The whole agent — Require approval for all tools pauses on every tool call the agent makes, regardless of the per-tool settings.

Everything defaults to off — an agent asks for nothing unless you tell it to.

When the agent reaches a gated call, the execution's status flips to Needs approval and it waits. The pause is durable — backed by the execution engine, it survives restarts and holds for hours if that's how long the decision takes. Nothing already computed is lost, and nothing reruns: the moment someone decides, the execution picks up exactly where it stopped.

A pending approval reaches you in three places:

• The notification bell — top-right, from anywhere in Compass, with a badge counting what's waiting on you. Each notification names the execution and the tool it wants to run, offers Approve and Reject inline, and links through to the execution itself.
• In chat — when an agent you're talking to needs sign-off, the request appears as a card in the conversation: the tool, the exact inputs it will be called with, and the choice — Yes, run it, or No, reject and tell the agent why, with an optional reason that's sent back to the agent. Requests from agents nested deeper in the work surface in the same conversation.
• In observability — a paused execution shows as Needs approval in the executions list, and its trace shows the request while it waits.

Anyone in the project can see what's waiting; deciding takes a writer role — read-only viewers can watch, but not approve.

A rejection doesn't kill the execution. The agent receives the refusal — along with the reviewer's reason, if one was given — as the outcome of that tool call, and continues: it can adapt its approach, try something else, or explain what it couldn't do. Gating a tool never turns a "no" into a crash.

A pending approval doesn't wait forever. If no one decides within 24 hours, it expires — and expiry is treated as a rejection: the tool is refused and the run continues without it.

Each request becomes part of the execution's permanent record. Its trace carries a human-in-the-loop strip showing the tool, who approved or rejected it, when, and how long the run waited. When someone asks what the AI did — and who let it — the answer is in the trace.

The approval toggles live in the agent's definition, so they follow the same versioning as everything else: set policy on the draft, and deploying freezes it into the version your team runs. The approval rules of deployed work can't drift out from under it.