Approval Inbox
One tidy inbox where every action the AI wants to take — but is not allowed to take alone — waits for a human yes or no, with all the context attached.
Picture the tray on a manager's desk where papers wait for a signature. Each page arrives with the full story stapled to it, and nothing moves until someone signs. The approval inbox is that tray for AI actions — instead of approval requests scattered across chat (Slack) and email threads, where they get lost.
The problem, in plain words
The agent has prepared a refund and needs a human to say yes. Where does that request go? Today it's a ping in a chat channel, aimed at whoever happens to be online. The message scrolls away under lunch plans. Three days later the customer writes back, annoyed, and you're scrolling through history trying to figure out whether anyone ever approved it — or whether the agent is still waiting. Multiply that by every refund, account change, and outbound message across every workflow, and 'human in the loop' becomes 'human somewhere in the building, hopefully'.
What we set up
We give pending actions a home of their own. Every action that needs signoff lands in a dedicated inbox, and each item carries everything a reviewer needs to decide without digging: what triggered it, exactly what the agent wants to do, the agent's reasoning, a link to the trace (the recorded play-by-play of every step the agent took), and an SLA (a promised response time — a deadline on the request itself). The reviewer can approve, reject with a reason, or modify the action before approving. If nobody answers in time, the request expires into a documented default — nothing just falls on the floor. And every rejection or edit is saved as a test case, so the system learns what people push back on.
How it works, step by step
- The agent hits a checkpoint
A workflow reaches an action it isn't allowed to take alone — a refund, an account change, a message leaving the company.
- The request lands in the inbox
With the trigger, the proposed action, the agent's reasoning, the trace link, and its deadline. Not a ping in a channel — an item in a queue.
- It's routed to the right person
Requests go to the reviewer who owns that kind of decision, not to whoever is online.
- The reviewer decides
Approve, reject with a reason, or edit the action and then approve. One click, full context already on screen.
- No answer in time? The default applies
Every request has an expiry and a documented fallback, so nothing waits forever in silence.
- Decisions feed the tests
Rejections and edits become eval cases (saved test examples), so the next version of the workflow proposes better actions.
What changes for you
Before, approvals lived wherever they happened to be asked, and finding out what was decided meant archaeology. After, there is one place, with response times tracked and a full history behind every decision. You also get a signal you never had: which workflows almost never get rejected — evidence they've earned looser gates — and which get corrected constantly and need tighter ones. What it won't do: it won't make the decisions for you. If nobody staffs the inbox, requests will expire into their defaults — the inbox organizes the waiting line, it doesn't replace the signer.