A good hold shows a named person the exact action the agent will take, why it was held and what it relied on, then executes exactly that. Design five things: what triggers a hold, what the approver sees, who may approve, what happens if nobody does, and how the approved action is locked so it cannot change after sign-off.
What is the hold-and-approve step, and who owns it?
A hold is the point where an agent has prepared an action but may not complete it. The action waits, drafted, for a named person to approve, edit or reject it. It is the main way an agent works above its depth safely, and the place most governance either works or quietly fails.
The process owner owns the design, because they decide which actions need a person and who that person is. Operations owns the queue day to day. The engineering team builds it, but the rules come from the business. The place of the hold in the agent's cycle of reading, planning and acting is described in how does an AI agent work, step by step?
What are the steps to design it?
- Person, process owner: defines the triggers. Common ones: the capability is set at depth 2; the value exceeds the customer's limit; a source of external provenance supports the action; the customer is flagged as possibly vulnerable; the agent itself reports uncertainty.
- Person, process owner: specifies the approver's view. The action as it will execute, field by field; the trigger that caused the hold and the bound that decided; the sources used and their provenance; and what changes in which system if it is approved.
- Person, process owner: sets approver rules. A named roster for each type of hold, with authority limits. The person who requested the work cannot approve it, and no agent can.
- Person, process owner: sets the outcomes. Approve, edit then approve, reject with a reason, or return to the agent for more information. Edits are recorded as edits, not as the agent's work.
- Person, process owner: sets time rules. A target time to decide, an escalation when it is missed, and an expiry after which the held action is refused, never approved by default.
- Person, engineering lead: locks the approved action. What runs is what was approved. If the agent regenerates or the data changes before execution, the item returns to the queue.
- Agent, depth 2: runs in test, producing held items across every trigger so approvers can try the view on realistic cases.
- Person, process owner: approves the design as part of the agent's go-live.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Triggers | Nothing | none | Choosing what needs a person |
| Approver's view | Nothing | none | Deciding what approvers must see |
| Approver rules | Nothing | none | Naming the roster and limits |
| Outcomes | Nothing | none | Defining approve, edit, reject, return |
| Time rules | Nothing | none | Setting targets and expiry |
| Lock | Nothing | none | Building execute-as-approved |
| Test | Drafts held items for every trigger | 2 | Trying the view |
| Sign-off | Nothing | none | Approving the design |
Which controls make it safe, and what evidence do they leave?
No silent approval. A held item that times out is refused, not executed. Evidence: expired items with a refused verdict.
Separation. The requester, the agent and the approver are three different parties. An agent checking another agent's work can help the approver, but one agent should not approve another agent's work. Evidence: approver identities on every decision.
Execute as approved. Evidence: a fingerprint of the approved action stored with the decision and compared with what executed.
Reasons on rejection. Evidence: a reason code and free text, which feed back into the agent's brief and testing.
Authority limits. An approver can only approve within their own limit. Evidence: the roster with limits, and refusals when someone tries to exceed theirs.
Which signs show the hold is failing?
- Decisions take seconds. A payment approved in four seconds was not read.
- Almost nothing is rejected. Either the triggers are too cautious or approvers are clicking through.
- Queue age rises. Approvers cannot keep up, and the pressure to approve in bulk grows.
- Edits are frequent. If approvers routinely rewrite the draft, the agent is not ready for that capability, or the trigger is in the wrong place.
- Approvals cluster on one person. The roster exists on paper, but one person does all the work.
What should you measure?
Time to decision by trigger, rejection and edit counts by capability, items expired, queue age at the end of each day, and the spread of decisions across approvers. Sample approved items each week and re-check them; the sample tells you whether approval means anything.
Where does it usually go wrong?
The approver sees a summary, not the action. "Refund approved for customer" hides the amount, the account and the reason. Show the exact action.
Bulk approval for convenience. A select-all button turns fifty decisions into one. Allow batching only for low-value, depth 3 work, never for money movement.
Holds bolted on after design. The hold is added late and lives in email. Put it in your agent integration design template from the start, as part of how you design an AI agent architecture for a regulated business.
Approval detached from production sign-off. The roster and triggers should be reviewed when you approve a new AI agent for production, not afterwards.
Where Pryme fits
In Pryme, held is one of four verdicts. The agent drafts the action, it waits for a named person, and the verdict names the bound that caused the hold. Each decision is filed in an append-only record. How holds sit among the other bounds is in agent governance is a bound, not a model.
Questions people ask
Should approvers see the agent's reasoning?
They should see the sources it relied on and why the action was held. Long reasoning text tends to persuade rather than inform, so lead with facts and provenance and keep reasoning available on request.
Can a held action be approved from a phone?
For low-value items, yes, if the view shows the full action. For money movement and hard-to-undo actions, require a screen where the approver sees everything and authenticates strongly.
What happens to a held item if the agent is suspended?
It stays in the queue. A person can still approve, reject or let it expire, but approved items should not execute through a suspended agent; route them to a person to complete.