A named approver is a specific, identified person recorded as authorised to approve a particular type of held action from an AI agent, usually up to a stated value. Each held action goes to one, and the approver's identity is filed with the verdict. A team inbox or a job title is not a named approver.
Why does a named approver matter?
Accountability needs a name. If a payment drafted by an agent is approved from a shared queue, and later turns out to be fraudulent, "the finance team approved it" tells an investigator nothing. A named approver makes it possible to ask the right person what they checked and why they agreed, and to test whether they had the authority to agree.
Naming also changes behaviour. People review more carefully when the record shows their name next to the decision. That matters because the main failure in held items is approval that has become a reflex. The role of named approvers in the wider design is set out in agent governance is a bound, not a model.
How does it work in practice?
The business keeps a roster that answers three questions for each type of held action: who may approve, up to what value or scope, and who covers when they are away. A layout is in the named approver roster template.
| Held action | Named approver | Limit | Cover |
|---|---|---|---|
| Customer refund | Customer service team leader | Up to 500 | Duty manager |
| Supplier payment | Accounts payable manager | Up to 10,000 | Financial controller |
| Account closure | Operations lead | Any | Deputy operations lead |
| Credit limit increase | Credit manager | Up to 25,000 | Head of credit |
When a held item arrives, the system routes it to a person on the roster who holds enough authority. If no one does, it escalates. The approver's identity, the time and the decision are filed against the agent's draft.
Two rules sit alongside the roster. The approver must not be the person who prepared the item or set the agent's bounds for that capability. And the approver must never be an agent, a point argued in the payment approver must never be the agent.
What does that look like in an example?
A property management company's agent drafts a deposit return of 1,800 to a departing tenant, after deducting 200 for cleaning. The deduction is a dispute risk, so the action is held. The roster names the lettings manager for deposits up to 2,500. She opens the item, sees the check-out report and photos, and approves. The record shows her name, the time, and that she reviewed the deduction. If the tenant later challenges it, the company knows who decided and on what evidence.
How is a named approver different from an approval role?
An approval role says "team leaders may approve refunds". A named approver says "this team leader approved this refund". Roles are useful for building the roster, but the verdict needs the person. The difference matters most when something goes wrong: you can retrain or remove authority from a person, but not from a job title. It also matters for limits, because two people in the same role may hold different delegated authority.
A named approver is also distinct from a customer ceiling. The ceiling decides that a person must approve; the roster decides which person. Refusals, by contrast, involve no approver at all, because a refused action does not proceed. Each verdict names the bound that decided it, as argued in why every agent decision needs a named bound.
Questions people ask
Can a named approver delegate to someone else?
Only to someone on the roster with enough authority for that action, such as a named deputy. Ad hoc delegation, such as forwarding the item to a colleague, should not be possible inside the workflow, because it breaks the link between authority and decision.
What if the named approver is unavailable?
The roster should name cover for every approver, and held items should escalate after a set time. Items should not approve themselves when the deadline passes. If the cover is also unavailable, the item waits and the customer is told.