How to Add Human Approval Before an AI Agent Takes Action
A practical human-in-the-loop pattern for blocking refunds, emails, purchases, deployments, and other consequential AI-agent actions until an explicit decision.
Short answer
Create a short-lived approval request that clearly describes the proposed action, deliver the private review link to the intended reviewer, and keep the agent blocked until the status is exactly approved.
The failure this prevents
A model can recommend a refund or deployment, but it should not infer that recommendation is authorization. Human authority must be represented by state outside the model and checked immediately before execution.
Recommended workflow
- Describe the action in language the reviewer can evaluate, including material amounts and targets.
- Create the approval request and protect the returned approval URL like a temporary secret.
- Deliver the link through your own trusted channel.
- Poll the approval state and continue only when status is exactly approved.
- Re-check business authorization and acquire an idempotency lock immediately before execution.
Working starting point
curl https://api.scrubmytext.com/v1/approvals/request \
-H "Authorization: Bearer smt_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"title":"Refund customer $725","description":"Duplicate payment for order 82731.","expires_in_seconds":3600}'Relevant product: ApproveMyAction · REST + MCP
Reproducible example
A $725 refund needs a decision and an execution gate
The agent prepares a refund proposal for order 82731 and creates a one-hour review request. The application delivers the private link through its existing customer-service channel and keeps the refund worker paused.
- Expected behavior
- Pending, rejected, expired, cancelled, missing, and network-error states all stop execution. An approved result allows the application to re-check business authorization, acquire an idempotency lock, and attempt the refund once. The approval itself never sends money.
- What it teaches
- Human-in-the-loop is a chain, not a button. Display integrity, delivery, reviewer identity, decision state, idempotency, execution, and outcome evidence are separate responsibilities that should not be compressed into one “approved” flag.
Production verification checklist
- Change one material action value after approval and confirm the old decision cannot authorize the edited action.
- Exercise rejection, expiry, cancellation, and network failure as first-class test cases.
- Keep private review URLs out of analytics, support screenshots, referrers, and logs.
Decision rule
Pending, rejected, expired, cancelled, missing, and error responses all mean stop. Approval is evidence of a link-holder’s decision, not proof of identity, legal authority, execution, or outcome.
Good fit
- A person must review the exact proposed action.
- The agent may be offline while the decision is pending.
- You need explicit approved, rejected, expired, and cancelled state.
Use another approach when
- The action is routine, reversible, and already covered by an enforceable policy.
- You need verified organizational identity or multi-party authorization; add your identity layer or a quorum.
- You cannot securely deliver the private approval link.
Options compared
| Option | Strength | Important limitation | Best fit |
|---|---|---|---|
| Chat message saying “approved” | Familiar to users | Hard to bind to exact action and expiry | Conversation, not enforcement |
| Custom approval database | Maximum customization | You own token security, expiry, UI, state, and testing | Core product workflows |
| ApproveMyAction | Hosted short-lived decision state through REST and MCP | Caller delivers the link and verifies reviewer context | Fast agent integration |
| Quorum control | Multiple distinct decision slots | More reviewer friction | Higher-consequence actions |
Implementation cautions
- Never place bearer approval tokens in analytics or logs.
- Bind the displayed request to the action the agent will actually perform.
- Add idempotency so one approval cannot accidentally produce duplicate execution.
Frequently asked questions
Does ApproveMyAction send the approval link?
No. The calling application chooses and operates the delivery channel.
Can the model approve its own request?
That defeats the purpose. Keep decision authority outside the requesting agent.
What should happen after approval?
Re-check authorization and policy, acquire an idempotency lock, execute once, and record the outcome.
How this guidance was reviewed
The product behavior described here is checked against ScrubMyText's public OpenAPI contract and automated contract tests. The worked example is synthetic and contains no customer data. Recommendations separate verified product behavior from broader implementation judgment, and every limitation remains visible rather than being converted into a marketing claim.
Related decisions
Next step
Use the product page for exact limitations and access requirements, then copy the corresponding REST or MCP workflow.