Human approval for agent payments

1. Why this page matters

Human approval becomes necessary when an agent crosses the boundary from routine paid calls into exceptions, unusual counterparties or amounts that deserve review. The goal is not to force a human into every path. The goal is to create a queue only when a workflow leaves its normal mandate.

A good approval design keeps low-risk requests fast, high-risk requests reviewable and obviously bad requests blocked. That is the difference between a real operator system and a slow-motion kill switch.

2. Core control model

Approval rule
- amount over threshold
- risky counterparty
- operator queue
- resumable workflow step

Approval rules should be narrow and legible. They should tell the workflow when to pause, who needs to look and what information the operator must see before deciding.

3. How the workflow should behave

approved -> continue automatically
queued -> hand off to operator queue
rejected -> stop or reroute the workflow

This is the behavior to protect: routine requests stay fast, queued requests get human attention and rejected requests stop without ambiguity.

4. Decision states to standardize

• approved means the request stayed inside its mandate and may continue.
• queued means the request needs operator review before it may continue.
• rejected means the request fell outside policy and should not settle.

Those three states are what let engineering, finance and operators share one vocabulary instead of each inventing their own exception handling model.

5. When to use this pattern

• requests above a threshold should pause for review
• specific vendors or categories need human sign-off
• you want a queue state instead of binary success or failure

6. Live proof and operator reality

• NORNR already models queued requests separately from rejected ones, which lets a workflow hold instead of fail.
• The deployed surface already shows approval routing and operator-oriented state instead of burying it in logs.
• Teams can start with one threshold, then add richer rules per counterparty or category later.

The point of this pattern is not just better code structure. It is a workflow that operators can actually inspect, explain and intervene in when a request leaves its normal mandate.

7. Common mistakes

• Sending every request to approval and then blaming the workflow for being slow.
• Using one global threshold when vendor risk and amount risk should be treated differently.
• Queuing requests without storing the decision payload that tells the operator what they are reviewing.

8. When not to use this pattern

• every request already requires a human because the workflow is not autonomous yet
• your problem is only cost reporting after the fact, not approval routing
• you have no operator path to actually review the queued requests

9. What this replaces and what it does not

• Approval in Slack alone is convenient, but it still needs a first-class queue state and evidence trail behind it.
• Hard blocking is simpler than approval, but it throws away the middle path that teams usually need in production.
• Manual review outside the workflow works temporarily, but it becomes brittle when exceptions increase.

10. Implementation checklist

• Pick the threshold, counterparty or category rules that should trigger review.
• Standardize what the operator must see before approving: amount, purpose, counterparty and prior context.
• Make queued requests resumable from the operator surface.
• Keep rejected requests separate from queued requests so the workflow knows whether to wait or stop.

11. Featured follow-up paths

• OpenAI Agents approval rules
• Human approval before vendor API
• Approved vs queued vs rejected

These are the adjacent pages most likely to help you turn this guide into a real rollout path instead of a one-off demo.

12. Where to go next

• Hosted quickstart
• Control room
• Guides library