Most teams decide what their AI agent may do by listing features and arguing about each one. That produces inconsistent answers, because the argument is really about trust in the model, and trust in the model is not the variable that matters.
The variable that matters is what a mistake costs and who can undo it. Classify on that basis and the arguments stop, because the rubric answers before anyone has an opinion.
The three axes
Score every action an agent could take on three questions. None of them mentions AI.
Reversibility. If this action is wrong, what does it take to get back to the prior state? One click by the same person? A support ticket? A phone call to a bank? Score reversibility by the worst realistic path, not the best.
Blast radius. How many records, customers or downstream systems does one instance of this action touch? A field update on one contact has a radius of one. A price change on a product category has a radius of every order placed until someone notices.
External visibility. Does the outcome leave your organisation? An internal field edit can be fixed before anyone sees it. An email in a customer’s inbox cannot be recalled, and neither can an invoice in their accounts payable system.
The rule that follows is simple. An action needs a human decision if it scores badly on any one axis. Not two, not a weighted average. One is enough, because the axes describe different kinds of harm and they do not compensate for each other.
Scoring the common actions
| Action | Reversibility | Blast radius | External visibility | Verdict |
|---|---|---|---|---|
| Update a CRM field | High | One record | None | Unchecked, with a rate limit |
| Add a note or tag | High | One record | None | Unchecked |
| Assign or close a ticket | High | One record | Low | Unchecked, if reopening is easy |
| Draft an email or quote | Total; a draft does nothing | One record | None | Unchecked |
| Send an email to a customer | None | One to many | Full | Human decision |
| Post a journal entry or bill | Low: needs a correcting entry | The ledger | Downstream to reporting and tax | Human decision |
| Issue a purchase order | None once transmitted | A supplier relationship | Full | Human decision |
| Delete a record | Low in practice | One to many | Varies | Human decision |
| Change a price | Medium | Every subsequent order | Full | Human decision |
| Change a credential, role or permission | Medium | Everything that credential reaches | Low but severe | Human decision |
The five rows in bold on the right are the list. They are stable across industries because the axes are properties of business operations, not of any particular company.
The list, and why each one is on it
Financial postings. A ledger entry is not reversible; it is correctable, which is a different thing. The original entry stays and a second entry offsets it, so a wrong posting permanently enlarges the audit surface even after it is fixed. Worse, postings feed period closes, tax filings and reporting, so the blast radius extends into documents that leave the company. This is the category that should be locked at the mechanism level rather than the policy level. See the finance module for why double-entry makes the correction visible but never makes the original disappear.
Outbound sends. Email, SMS, anything that reaches a person outside the company. Irreversible and externally visible simultaneously, which is the worst pair on the rubric. The specific danger with agents is not a rude message; it is a correct-sounding message containing a wrong commitment: a delivery date, a refund amount, a discount. That is something you then have to honour or retract.
Deletions. Deletion looks reversible when you have soft deletes and looks catastrophic when you do not, and most systems are somewhere in between. Treat the axis honestly: if any integration, export, cache or downstream report has already observed the absence, the delete is not reversible in any sense your customers experience.
Price changes. The interesting one, because a single price change is trivially reversible — set it back. The blast radius is what condemns it. Every order placed at the wrong price between the change and the discovery is a commitment you either honour or dishonour, and both options cost money.
Credential and permission changes. An agent that can grant access can grant access to itself, or to anything that has manipulated it. This category is on the list even though a permission change is technically reversible with one click, because the window during which it was wrong is the entire harm.
The failure case: the agent that was right about the wrong invoice
A collections agent is given read access to invoices and permission to send payment reminders. Reasonable scope, reversible-looking work; a reminder email is only an email.
It reads an overdue invoice, reads the contact, and sends a firm reminder. The invoice is genuinely overdue in the system. What the system does not know is that the customer paid by bank transfer four days earlier and the payment has not been reconciled yet. There is no bug. Every record the agent read was accurate. The reasoning was sound.
The customer receives a chase for money they have already paid. That email cannot be recalled, the relationship damage is real, and the account manager finds out when the customer forwards it back with a screenshot of the transfer.
The lesson is not “the agent was wrong”. The agent was right about everything it could see. The lesson is that outbound sends fail on information the agent does not have, which is why the axis that condemned this action was external visibility rather than reversibility of the underlying record. The same run, ending at an approval queue, gets caught in four seconds by an account manager who remembers the transfer.
Locks have to sit below approval, not beside it
A rubric only helps if the enforcement matches it. The common implementation mistake is to put the high-stakes categories behind an approval step and stop there, which leaves the category one approval away from happening, and approvals are granted by tired people at the end of a queue.
The stronger pattern is a category lock that the approval cannot satisfy. In Oneop, money and stock actions are refused at the single point where every agent action is dispatched, unless that entire class has been deliberately switched on for the workspace. It ships off. While it is off, an agent that decides to post a bill or issue a purchase order gets an acknowledgement and nothing happens — in the most permissive autonomy mode, and even after a human has approved it, because the check sits underneath the approval rather than beside it. Switched on, those actions create draft records through the same service functions staff use, and posting a bill to the ledger still requires a separate deliberate human approval. The AI governance page sets out where each control is absolute and where it is configurable.
Stock is on the same lock for the same reason: a reservation the agent creates has a blast radius across every other order competing for the same units, which is the inventory version of the price-change problem.
What to do with the rest
Everything not on the list should be unchecked and bounded, not unchecked and unlimited. Two bounds do most of the work.
A per-run action ceiling converts a looping agent from an incident into a stopped run. Oneop’s AI agents allow three write actions counted across a whole run, alongside six reasoning steps, 6,000 tokens and forty-five seconds, and hitting any of them ends the run as escalated with the trace kept.
A granted tool set decides what is even reachable. Eleven of Oneop’s twenty agent tools only read, analyse or draft; nine can write, and every one of those nine goes through the same governed dispatch. Giving an agent invoice reads and no invoice writes is a real boundary rather than an instruction the model is asked to respect.
The mechanism for moving something off the human-decision list, when evidence justifies it, is the autonomy dial and the measurement period around it — set out in autonomy levels and, for the rollout method itself, in moving an AI agent to autonomous safely. The five categories above are the ones that stay regardless of how good the agreement numbers look, because the rubric that put them there does not change when the model improves. A better model makes a wrong ledger posting less frequent. It does not make it reversible.
Worth reading alongside this: when not to automate, which handles the prior question of whether the work should be an agent’s at all.