Decide which actions an agent may take alone and which need a person to approve, and enforce it in the action layer rather than in the instructions. A prompt asking the model to check with a human first is a request. An action that writes an approval record and stops is a control. The distinction matters because instructions are followed most of the time, and “most of the time” is not an oversight model.
Where the line goes
The useful test is reversibility and blast radius, not how clever the action is.
| Agent acts alone | Person approves first |
|---|---|
| Reads and summarises records | Anything sent to a customer |
| Answers from knowledge | Financial commitments — refunds, credits, discounts |
| Drafts content for review | Deleting or merging records |
| Creates an internal task | Changing entitlements or access |
| Updates a low-consequence field | Anything hard to reverse |
| Logs its own activity | Anything with a regulatory dimension |
Two questions settle most cases. If this is wrong, can we undo it in five minutes? And if this is wrong a hundred times before anyone notices, what is the total damage? An action that fails both needs a human.
Why instructions are not a control
“Always confirm with the user before issuing a refund” is a strong instruction and it is still probabilistic. It competes with everything else in the context, it degrades as the conversation gets longer, and it can be argued around by a determined user.
Building the check into the action makes it deterministic. The refund action does not issue a refund — it creates an approval request and returns a message saying so. The agent cannot skip it, because there is no code path that does.
This is the same principle as validation rules versus asking users to enter good data. One is a control and the other is a hope, and the reason to prefer the first is not distrust of the model.
Three patterns, and what each costs
Approve before
The agent proposes. A person approves. The action then executes. Highest safety, highest friction, and the only acceptable pattern for irreversible or regulated actions.
The failure mode is queue latency. If approvals sit for four hours, the agent has not saved anybody time and users route around it. Measure time-to-approval from day one. If it is bad, the answer is usually fewer things needing approval rather than faster approvers.
Act and notify
The agent acts. A person is told immediately and can reverse it. Low friction, and it depends entirely on the action being genuinely reversible and on somebody actually reading the notification.
Be honest about the second condition. A notification channel nobody monitors converts this into “act”, with extra steps and a false sense of oversight.
Sample and review
The agent acts. A percentage is reviewed afterwards. This is quality control, not oversight — it catches systematic problems, not individual bad outcomes. Appropriate for high-volume, low-consequence actions and inappropriate for anything on the right-hand column above.
Designing the approval so it is actually used
Give the approver the reasoning, not just the request. “Refund £400 to Account X” is not reviewable. “Refund £400 because the customer reported a duplicate charge on 14 March, and the two matching payments are linked” is. If the approver has to reconstruct the case, they will rubber-stamp instead.
Make rejection cheap and informative. A reject button that requires a reason gives you the training data for what the agent is getting wrong. Without it you learn only that approval rates are falling.
Put the approval where the approver already works. A separate console nobody has open is how you get four-hour latency.
Set an expiry. An approval request with no timeout sits forever. Decide what happens when nobody responds, usually expire and tell the requester, rather than leaving it undefined.
Logging, which is the part that gets skipped
Every consequential action needs a record of what was done, what the agent was asked, what it decided, and who approved. Not for the model’s benefit — for the incident six months from now when somebody asks why a customer received a credit.
A custom object with the conversation reference, the action, the inputs, the outcome and the approver is enough. Build it with the first action, not after the first incident, because reconstructing history you did not record is not possible.
The oversight that decays
The honest risk with approve-before is automation bias: approvers who see ninety-nine good proposals approve the hundredth without reading it. This is well documented in other domains and there is no reason to think this one is different.
Mitigations are partial. Keep the volume low enough that each approval is a real decision. Vary what the approver must actively confirm rather than presenting an identical dialogue each time. Sample the approvals themselves occasionally. And accept that approval is a control with a known failure mode rather than a guarantee, which is an argument for keeping genuinely dangerous actions out of the agent’s reach entirely, rather than gating them.
Frequently asked
Does this apply to read-only agents?
Less, but not not at all. An agent that reads can still disclose something to the wrong person, so access scoping matters even where approval does not.
Should the agent tell the user it is waiting for approval?
Yes, explicitly, with an expectation of how long. Silence while a request sits in a queue is the worst experience available and generates support contacts of its own.
Can the agent approve its own low-value actions?
That is the “acts alone” column, and it is fine when the threshold is set deliberately and reviewed. Thresholds set once and never revisited tend to drift out of date as usage grows.
Where should the threshold live?
In configuration you can change without a deployment (custom metadata, for instance) because you will change it, probably more than once in the first month.
Is a confirmation prompt to the user enough?
For low-consequence, reversible actions, often yes. For anything financial or regulated, the person confirming should be someone accountable for the outcome, which is usually not the person asking for it.
Reference: Einstein Trust Layer and Agentforce documentation, Salesforce; general practice on human oversight of automated decision-making.
