Human-in-the-loop approvals

Approval is a property of the agent's tools, and the controls are the same wherever you configure them — the agent builder, the workflow canvas, and Compass Chat. Gate as much or as little as you want:

• A single action — on an integration tool, click 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 — for an integration, Require approval for every action gates everything it can do. For a workflow or another agent used as a tool, the shield on its row gates invoking it at all.

On the canvas, an integration's or dataset's controls live in its Tool Capabilities window, and a workflow or agent attached as a tool carries the shield in its card's header.

Everything you configure defaults to off — an agent asks for nothing unless you tell it to. The one exception is built in: on the Compass harness, the tools that create or change a workflow or agent always ask first, and that can't be switched off.

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 several places:

• The notification bell — top-right, from anywhere in Compass, with a badge counting what's waiting on you in your current project. 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 and the Test panel — 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. Once the decision lands, the card folds into a receipt on the tool call — Approved by you · 10:49 AM, or Rejected by you with the reason — however it was decided, so a request approved from the bell clears in the conversation too.
• In observability — a paused execution shows as Needs approval in the executions list, and Console Home has a Waiting for approval tab.
• From the CLI and API — compass approvals list, approve, and reject, or the /v1/approvals routes. See API, CLI & SDK.

Anyone in the project can see what's waiting. Deciding takes an Admin or Developer role — Reviewers 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 (the default), it expires — and expiry is treated as a rejection: the agent is told no decision was made in time, and the run continues without the tool.

Each request becomes part of the execution's permanent record. Its trace carries an approvals strip showing the tool, who approved or rejected it, when, and how long the run waited, and each gated tool call keeps its own decision: select the call in the trace, or look under it in the conversation, to see who let it run. 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.