For AI service providers · Research
AI agent approval patterns for managed client services
Use approval patterns that match the consequence of an action and the controls the tool actually exposes. This research describes one-time review, bounded persistent trust and manual handoff. It is a design and verification guide, not proof that every Agentic Workers action is intercepted or that a workflow meets a compliance standard.
By Agentic Workers Team · Published · Updated
Decision criteria
Apply these checks before choosing a product. Record unknowns rather than inferring a capability.
- Read-only lookup
- Confirm the intended account and source; review access even when no write occurs.
- External message
- Review recipient and content before a supported send.
- Record update
- Check record identity and proposed fields before the write.
- Paid action
- Require a clear scope and budget through a verified approval path.
- Persistent trust
- Record owner, scope and review date; verify future behavior.
- Unsupported action
- Keep a manual handoff until an enforced control is verified.
One-time action review
Require a person to inspect the proposed account, recipient and change before a supported action executes. Test both approval and rejection using a harmless destination. Confirm that the rejected action leaves the destination unchanged.
Bounded persistent trust
Only use persistent trust when the action class and account scope are understood. Record who enabled it and when it should be reviewed. A previously safe action can become unsafe if recipients, inputs or permissions change.
Manual handoff
When a runtime or action has no verified approval barrier, stop automated execution at a draft or instruction. Have a person perform the final step through the source application. Prompt wording alone is not a substitute for an enforced control.
Example provider workflow. Adapt it to the client’s agreed scope.
- 01
Request
Record the action, account and proposed inputs.
- 02
Review
Apply one-time review, bounded trust or manual handoff.
- 03
Verify
Inspect the external result and retain the decision evidence.
Fit and limitations
- Good fit
- Providers defining a review process for specific client tools.
- Poor fit
- Using an approval badge as proof of universal safety or regulatory compliance.
- Known limits
- This is an authored operating model. Only supported and tested actions can be described as enforced. Earlier writes are not undone when a later action is rejected.
Sources and evidence
Documentation establishes the scope of a claim. It does not replace an acceptance test in your client’s environment.
| Source | What it supports | Checked |
|---|---|---|
| Agent tools and review guidanceProduct documentation | Supported tool actions can require approval. Test the exact tool and runtime; coverage is not universal. | |
| Read an agent run recordProduct documentation | Inspect available tool calls and execution details within the relevant workspace. A completed run is not proof of an accepted result. |
Questions providers ask
Does every action pause?
No universal coverage is claimed. Test the exact action, tool and runtime.
Can a rejected action still have earlier effects?
Yes. Rejection of one proposed action does not roll back prior completed actions.
What is the evidence standard?
Retain the proposed action, decision, run reference and observed external result with safe test data.
Set up one client service
Set up the client workspace, connect its tools and review the first deliverable. Use a tested delivery path, such as Telegram, so the client can receive work in chat. Track operating costs and review effort before pricing a recurring service.
Sign up now