How approvals work in Piolet
Every agent output that could reach a customer stops in an inbox first. Here is what that looks like, what it covers and why it cannot be switched off.
The approvals inbox is the centre of Piolet. Agents do the work; the inbox is where your team keeps the final word. This post explains how it behaves, because the detail is where trust is won or lost.
What needs approval
Each agent declares an approval policy in its manifest. Most launch agents are required: every deliverable they produce waits for a person. A deliverable is anything that could leave the workspace or change something a customer sees. Drafts, posts, newsletters, budget recommendations, CRM updates.
Read-only agents, such as a monthly scan that only reports, record their output in the run history and can optionally route a summary to the inbox. They never act on a connected tool.
The policy is part of the agent, not the workspace settings. You cannot loosen it from the UI, and nothing an agent reads at run time can change it. If we ever ship an agent with a looser policy, the agent page says so before you enable it.
What you see in the inbox
Each item shows the agent that produced it, the output itself, and whatever the agent attached to help you decide. For Content Engine that is the critique: claims to verify, places where the voice slipped, structural notes. For the paid-media audit it is the reasoning behind each recommendation and the numbers it read.
Items are grouped by workspace. An agency sees one inbox per client from HQ, and each client can have their own approvers.
The three actions
- Approve. The deliverable is released to whatever the agent does next: schedule the post, send the draft to your CMS as a draft, mark the plan as accepted. Approval is logged with who and when.
- Request changes. You write a note. The agent runs again with your note as input and the item comes back to the inbox. The original is kept.
- Reject. The item is closed and the agent learns nothing from it unless you say why. Rejections are logged too.
There is no fourth option that skips the queue.
What approval does not mean
Approving a draft does not publish it to the public web on its own. Agents in the launch catalogue hand approved content to your tools as drafts or scheduled items. Publishing is still a step in your tool, under your account. We may add publish-on-approve for specific tools later; if we do, it will be a per-agent setting that is off by default and shown clearly on the agent page.
Systems and approvals
When agents run together as a system, each one keeps its own policy. Radar can emit an event to Content Engine without approval because the event is internal and reads nothing new. The draft Content Engine produces still stops at the inbox. A system never grants an agent more autonomy than it has alone.
Audit trail
Every run records what the agent read, what it produced, what it cost in credits, and the approval decision. The history is kept for the life of the workspace, so a question months later ("who approved this and what did the agent see?") has an answer.
Why we built it this way
Agents are good at the weekly grind. They are not accountable, and the people who sign your invoices know that. Keeping a person at the approval step is what makes it reasonable to let agents do the rest. We would rather have an inbox with ten items waiting than a feed with one mistake already live.
If you want to see the inbox fill with your own tools, every plan starts with a seven-day trial.