Approvals
The queue where a person decides what an AI agent may do: where requests come from, who can decide, what approving actually does, and expiry.
When an AI agent wants to do something consequential — spend money, act on a customer's account, take a step somebody would want to be asked about — it does not simply do it. It files an approval request, and a person decides.
Approvals, on the product rail, is where those decisions are made.
The queue
Five tabs, each with a live count: Pending, Approved, Denied, Expired and All. The queue can be searched, and sorted by Most urgent, Pending first, Newest first, Oldest first, Recently decided or Highest value. Each tab starts on the sort that suits it — Pending is a queue, the decided tabs are a log.
Each row is one request: the tool the agent wants to run, the money involved if any, the reason it gave, and links back to the ticket or the conversation it came out of.
Rows close to running out of time are highlighted as at risk, with a count above the queue, so a quiet week does not silently turn into a pile of expired requests. A request counts as at risk within 24 hours of expiry, or within the last quarter of the window when the window is shorter than four days.
Where requests come from
Each agent has a risk policy, expressed in money. Three outcomes follow from it:
- Below the automatic threshold, the agent just acts. No request is ever filed, and nothing appears here.
- In the middle band, it asks: a pending request lands in this queue and the agent's action waits.
- Above the ceiling, it is blocked outright. A row appears already denied, marked as auto-blocked by the risk tier, so you can see what was attempted.
If no policy is configured at all, the fallback is to ask. An agent with no risk settings does not get free rein; it gets a queue you have to work.
Who can decide
The queue is open to editors and up, but the authority to decide is resolved per request rather than by one blanket rule.
Two things set the bar for a given request. Each tool has its own minimum role, and each has a money ceiling above which the decision escalates to an admin, whatever the tool's normal floor. An unclassified tool — one nobody has written a rule for — requires an admin. Owner is not a separate approval tier; owners decide as admins do.
The practical consequence is that the same tool can be yours to approve at one amount and an admin's at another. The queue works this out for each row and shows you the right thing, and if you cannot decide something it tells you why rather than offering a button that would be refused.
There is no delegation and no reassignment. A request is not assigned to anybody; it sits until somebody with the authority decides it.
Approving, denying, and what actually happens
Approving runs the tool
A decision is not a note recorded for the agent to act on later. Pressing approve is what causes the action to happen.
It happens exactly once. Two people pressing approve at the same moment produce one execution, and the second person is told, plainly, what the first one decided rather than getting an error.
Denying records the decision and dispatches nothing. You are asked for a reason, which stays on the record.
The decision and the execution are kept as two separate facts: the request says a human decided, and the execution record says what then happened. Both come back together, so an approval that was granted but whose action then failed is visible as exactly that, rather than reading as a success.
Requests that need something before they can be decided
Some tools need details the agent did not have. When that is the case, the row shows the reason instead of an Approve button, naming what is missing, and offers a form for exactly those fields — no more.
Supplying a missing fact is not the same as deciding, so it sits at a lower bar: you can fill in what you know without holding the authority to approve. Only pending requests accept details, and where the value came from is recorded alongside it.
Expiry
A pending request expires when its approval window closes. The window defaults to 24 hours and is set per workspace under Settings, AI agents, Autonomy — see Autonomy.
Expiry is not a decision. Nothing runs, nothing is denied on your behalf, no note is written to the ticket. The request simply stops being actionable and moves to the Expired tab. A decision arriving after the window has closed is refused rather than applied late.
This is why the at-risk highlighting matters. An expired request means the agent's action never happened and nobody said so; if it still needs doing, it needs doing by hand.
Notifications
When a request is filed, everyone who could decide it is notified — it goes to the workspace rather than to one person, because any authorised member can act on it. The notification carries the tool's name.
After a decision, a second notification reports whether the action succeeded or failed. That second one is the one to watch: it is how an approval whose execution went wrong reaches somebody instead of sitting quietly in a log.