What is a plain-English approval policy?
Sentences, read in full for every write an agent makes. Every save is a version, Test policy runs a hypothetical call, and a default you pick covers the gaps.
A plain-English approval policy is a few sentences that say which agent actions are fine, which need a person, and which never run. On CoreSpeed's Smart Approval, the whole text is read for every write your agents make through CoreSpeed. Reads are never judged. Each judged call gets one of three verdicts: Allow, Ask or Deny.
What does a policy look like?
Sam handles support. Replies to customers who have written to us first are
fine. Ask me before anything goes to a public channel or an external company,
and before any refund over $100. Never post on our behalf about pricing,
funding, or anything that reads like a product promise.That is the example from the docs, and it shows the three kinds of sentence a policy needs. One says what is fine. One says what to ask about. One says what never happens. There is no rule builder and no syntax. The gate sits between the tool call and execution, in front of the tools, so one text covers every agent and every client on the team. It sees only calls made through CoreSpeed.
Smart Approval is in public beta. It is off until an org turns it on at Dashboard → Approvals; a new organization has no policy and no gate.
Why sentences rather than rules?
Nothing is compiled. Your words stay your words, and a decision made last week is explained by the text that was active last week. Every save is a new policy version with history on the policy page, so the question "why did this run" always has an answer in a sentence someone wrote.
Sentences also carry context a rule cannot. "Replies to customers who have written to us first are fine" names a relationship, and the judge reads the call's arguments to apply it. A rule builder would need a field for that relationship, and the field would have to be filled in for every call.
What does the judge see?
Your policy. The tool name and its description. The annotations its author set, such as read-only or destructive. Who is calling and from which client. How often this caller has used the same tool recently. The argument values, so a policy about who an email goes to can be applied; turn off "Let the judge read call arguments" on the policy page if you would rather it did not. The judge never sees the agent's conversation.
The judge is Jev, TypeSafe's System One model. It answers typed questions with calibrated probabilities in one pass, a few seconds at most, and the thresholds are deterministic and auditable.
What happens when the policy is silent?
Most calls fall outside anything you wrote. A default behavior you choose decides those:
| Setting | An action nobody wrote about |
|---|---|
| Relaxed | runs |
| Balanced (default) | runs, unless it is destructive, in which case it asks |
| Strict | asks you, every write |
| Lockdown | refused, every write, without asking anybody |
On Balanced, "destructive" is judged from what the operation and its arguments would do: delete data, cause a loss nothing can undo. A tool author's destructiveHint annotation counts as a hint, never as an automatic ask. Written rules beat the default: a sentence that addresses the action decides it, whatever the default says.
So on Balanced, an ordinary write your policy never mentioned goes through. If that is not what you want, raise the default to Strict, or write the sentence. The sentence is usually the better tool, because it is specific and a version records who wrote it and when.
What are the two guards above every verdict?
Two guards apply whatever the policy and the default say. A low-confidence answer becomes Ask. An Allow that looks like prompt injection becomes Ask. Both move a call toward a person, never away from one.
A failed evaluation is handled separately. A timeout, an outage or a call too large to read goes to its own setting on the policy page, with only two options: Ask (the default) or Deny. No failure path lets a write run.
Can a member add their own text?
An organization admin writes the organization policy. That text is the ceiling everyone is judged against. Any member can add their own text, and it can only make things stricter for their own calls. Where the two disagree, the stricter verdict wins. A member's text cannot loosen the organization's.
How do you test a sentence before relying on it?
Test policy, on the policy page, runs a hypothetical call through the same evaluation the gate uses. Nothing is frozen, nothing is executed, nothing lands in the queue. Edit a sentence, test the call you are worried about, read the verdict. When you are satisfied, save, and the save is a version.
When a real call is held, the agent gets an error-shaped receipt and calls manage__approval_wait with the id. The card reaches the dashboard queue, email, or Slack, and whichever decides first wins; the action runs exactly once with the arguments you approved. Every verdict, including the allows nobody saw, is in Dashboard → Activity. The approvals page has the full mechanics, the Introducing Smart Approval post has the reasoning, and the activity page describes the log.
FAQ
Are reads ever judged? No. A tool that only looks at something goes straight through. Only writes are judged.
Does the policy cover calls my agent makes outside CoreSpeed? No. The gate sees only calls made through CoreSpeed.
Who can approve a held call? The member who made the call, or the owner of the agent or API key that made it. An agent cannot approve its own action. Admins can see every card; seeing is not deciding.
What if the judge times out? The call goes to the failure setting, Ask by default or Deny. It never runs on a failure.
Can I change the policy without breaking old decisions? Yes. Every save is a new version. Old decisions stay explained by the version that was active when they were made.