Authority
Not whoever's online. The person whose role permits this decision, picked by your rules rather than by who saw the message first. Otherwise the record shows an approval from someone who couldn't give one.
People and handoffs
Escalation without authority is a ticket
Nearly every agent design has a human-in-the-loop step in it. Most of them break in the same spot, and it isn't the routing.
What usually gets built
The agent hits something outside policy. The system posts to a channel, or files a ticket, or sends an email. Someone reads it, thinks for a minute, and replies.
Then a person has to take that reply and go do something with it. By hand.
That isn't oversight. It's a handoff to a separate process that happens to have a person in it, and it fails in predictable ways. The reply lands after the workflow gave up. The person who answered was available, not authorized. The answer was "approved" when what they meant was "approved up to thirty thousand," and there was nowhere to put the number.
It looks like oversight on a slide. It doesn't survive being asked about.
Three things the request has to carry
Context, and where it came from
The facts the decision needs, each one traceable to a source. Someone approving a payment should see the amount, the budget left, and the vendor's status, and know which system said what.
A response that fits
Approve and reject is rarely what's being decided. It's a limit, a date, a corrected field, a pick from a few options, or a note that sends the work back for another pass.
Forrester's advice is to treat every agent as a governed identity: unique credentials, least privilege, full logging, and a named owner. The same discipline has to reach the people in the loop, or the identity story has a hole exactly where the consequential decisions happen.
What a working handoff looks like
Here's how it runs in VeriProof, with one vendor payment.
The agent proposes a $45,000 vendor payment. The rule says anything over $25,000 needs someone with payment authority. The application pauses and saves where it was.
The exception goes to the person who holds that authority, as an Inbox item, an email, or a Slack or Teams message. In VeriProof they see the amount, the remaining budget, the vendor's status, and where each fact came from. If they don't answer, reminders go out, and overdue work escalates instead of sitting in a queue. They approve the payment up to $30,000.
That answer comes back signed and structured, attached to the payment that was waiting. The workflow picks up with the reviewer's actual values, not somebody's retyping of them. The record holds the request, the person, their answer, and what the application did next.
Scroll horizontally to see all columns.
| Step | Who holds it |
|---|---|
| The work pauses and saves where it was | Your application |
| The exception reaches the person with authority, with reminders and escalation | VeriProof, using your review settings |
| The decision, with the limit or correction it needs | The reviewer |
| The signed answer returns to the waiting work | VeriProof |
| Whether the work resumes, changes, stops, or stays paused | Your application, under current policy and its own checks |
Then your application decides what follows
This is where many designs overreach, so it's worth being precise.
A reviewer approving a $30,000 limit doesn't mean the payment goes out. It means one condition is now met. Your application still runs its own checks against the revised action, and it might still stop for a reason that has nothing to do with the review.
Keeping that last step with your application is what makes this safe to adopt. The reviewer brings judgment. The system that owns the action still owns the action.
For the business owner, this is what lets an agent take on bigger work. Every exception that reaches the right person and comes back with a usable answer is one less reason to keep the agent's limits small.
See exceptions from the business owner's side
Follow a week of one agent's work: what it finished on its own, which exceptions reached a person, and what they decided.