Which agent actions need a person? A threshold table
An agent that drafts a refund is easy to trust. Before an agent issues one, someone has to decide which of its actions wait for a person and which run alone.
The table below is where we would draw that line for the actions teams most often hand to an agent. It is our recommendation, not a standard, so set the amounts and counts to fit your own business.
| Action | Our default | Where to draw the line | Why |
|---|---|---|---|
| Refund | A person approves above a set amount | The most a new support hire may refund without asking | A small wrong refund costs little and shows up in the books |
| Payment or transfer out | A person always approves, and two people for large ones | No amount runs alone | Money sent to the wrong account is hard to get back |
| Reply to a customer who wrote in | Runs alone once the agent has a clean record | A person approves while the agent is new, and whenever the reply promises money or a date | One reader, who asked for an answer |
| Outbound message to people who did not write in | A person approves | Any send to a list or to a new contact | It cannot be unsent, and it speaks for the company |
| Record edit | Runs alone on routine fields | A person approves changes to amounts, owners and permissions | Most edits can be rolled back from history, but those three move money or access |
| Delete | A person approves | Every hard delete, while a soft delete with a restore can run alone | A hard delete has no undo |
| Bulk change | A person approves | More records than one person would check by hand | One wrong filter repeats the mistake on every record it matches |
| Irreversible action | A person always approves | Every time, and it never becomes automatic | A long clean record does not make the next one reversible |
Why the line sits where it does
The line follows the cost of a mistake rather than the kind of action. A refund and a wire both move money. A small refund paid in error is a nuisance, while a wire sent to the wrong account may be gone for good. For each action, ask what it costs if the agent is wrong and how soon you would find out.
Reversibility settles the hard cases. Darwin AI’s governance framework for 2026 asks for a person on “any irreversible action, regardless of scale,” and says those thresholds “should never disappear entirely for irreversible actions” (Darwin AI). We agree, which is why the last row never graduates.
Bulk changes get their own row because the count matters as much as the kind of action. One bad record edit takes a minute to fix. Pushed to thousands of records by a loose filter, the same edit becomes an incident.
Every row should start supervised, including the ones marked “runs alone”. A few weeks of a person deciding shows you what the agent gets wrong before anyone stops watching.
How PromptCompute handles it
PromptCompute is our approvals service for AI agents. Your agent adds one tool call before a risky action: request_approval over MCP, withApproval in the TypeScript SDK, or a decorator in Python. A policy then decides whether the action runs now, waits for a person or is refused.
The policy is a YAML file in your repo. Rules run in order, the first match wins, and a default rule is required. PromptCompute’s example policy lets refunds up to $50 run alone, sends refunds from $50 to $200 to the support group and anything larger to support leads, and needs two people with the owner role for every bank transfer. Before you publish a change, you can replay it against the last 30 days of requests to see which past decisions it would have changed.
When a rule needs a person, the agent pauses and the right group gets a card in Slack, email or the web. The approver can approve, change the amount, reject with a note or ask the agent a question. The agent then resumes with the final approved arguments, edits included, and never with the ones it first sent. The wait survives restarts and deploys, even when it lasts days. A request nobody answers expires as rejected or denied, never approved. Neither the person the agent acts for nor the person who created its API key can approve the request.
PromptCompute does not run the action itself. Your agent does. Every request and decision goes into a signed, hash-chained ledger, and an approved request carries a signed grant, so the service that does the work can check the arguments match what a person approved.
Earning autonomy one action at a time
PromptCompute tracks how people decide each kind of action, split along the amounts your policy already uses. It suggests letting a bucket run alone only after three things hold: at least 200 human decisions in 30 days, a 95% lower bound of 97% on approvals given without edits, and no rejections among the latest 50. A bucket where any request reached critical risk never qualifies, and neither does an action you mark never automatic.
A suggestion you accept starts a shadow test. People keep deciding for 14 days while PromptCompute checks whether auto-approval would have agreed, and the rule changes only after at least 100 requests with 99% agreement.
After that, 5% of the auto-approved requests still go to a person. The rule rolls back if more than 2% of the last 50 of those reviews are rejections, or at once if an action it approved causes an incident. Your team can raise these bars but cannot lower them.
What is live
The site, docs and pricing are up at promptcompute.ai. The free plan covers 500 requests a month with no card. Team is $99 a month for 5,000 requests, and Business is $499 a month for 25,000. When we checked on October 24, the hosted API and MCP server were not answering yet, so teams cannot connect an agent today. If you want early access, send us a message.