Approvals

The approval gate will turn plain-English intent into enforceable policy at the same server seam every outbound tool action already crosses.

01

Intent becomes policyINPUT

A user describes what the agent may do, what must be reviewed, and what must never run.

compile a reviewable policy

02

Every action is evaluatedGATE

The server-side sandbox combines deterministic rules, organization memory, and an isolated judge before the tool can run.

persist the decision first

03

Approve, review, or blockRESOLVE

The decision resolves exactly once. Timeout and expiry fail closed, so no outbound side effect can bypass the gate.

The invariant

Tool names remain clean—there will be no _with_approval variants and no second execution path around the gate. An action cannot run before approval is persisted, each approval resolves exactly once, and timeout or expiry fails closed.

Policy inputs

Policy code can combine:

• deterministic conditions such as recipients, regexes, and budget windows;
• durable memory inside the caller's organization boundary;
• an isolated LLM-as-judge for contextual decisions.

Dashboard → Approvals demonstrates the state machine with example policies today; nothing is enforced yet, and there is no live queue or decision history. Do not build an integration that depends on an approval response until this page says otherwise.