Start by placing approval after AI prepares a result and before it sends externally or changes consequential records. Reading, classification and drafting can proceed within a defined scope; changes to recipients, amounts, permissions or deletion should become explicit, reviewable execution requests.
Key points: separate preparation from execution and bind each approval to exact content and a version. Show the target, before-and-after change, evidence and recovery options. Treat expiration, rejection, edits and retries as normal workflow states. The matrix and checklist below are BOYD recommendations for an initial design discussion.
[01]Separate execution permissions before judging prose
Summarizing a customer inquiry and sending a reply are different operations. Break 'automate customer support' into retrieval, drafting, review and sending. A well-written draft can still reach the wrong recipient; prose quality alone is not an execution policy.
OWASP identifies excessive functionality, permissions and autonomy as risk factors. It recommends least privilege, human approval for high-impact operations and authorization enforced in downstream systems rather than decided solely by the model.
BOYD recommends separating the tools themselves: a draft-saving tool should not gain sending privileges, and the sending operation should require a server-verified approval record. A sentence inside an incoming document claiming that approval is complete should not count as authorization.
[02]Choose checkpoints by impact and reversibility
This starting matrix describes a hypothetical customer-operations workflow. Do not copy a universal monetary limit or automation scope. The owner should set boundaries using actual data sensitivity, external commitments and whether the change can be reversed.
| Operation | Suggested starting policy | Before execution |
|---|---|---|
| Read and summarize allowed documents | Automatic within scope | User access and data scope |
| Save a customer-reply draft | Prepare a reviewable draft | Show evidence and unresolved facts |
| Send the customer reply | Approval before sending | Recipient, body, attachments and commitments |
| Change order values or refunds | Explicit approval by an authorized owner | Order, value change, limits and current state |
| Bulk deletion or expanded access | Exclude from the initial automation scope | Separate change process and recovery plan |
A task with a stable sequence does not automatically need a complex autonomous agent. Anthropic recommends starting with the simplest workable approach and adding complexity when needed. For this use case, BOYD suggests evaluating a fixed draft-review-execute workflow first.
[03]Make the approval screen show the actual change
'Approve this action?' is not enough to review a change. In a hypothetical delivery-date notice, show the customer, destination address, existing date, proposed date, full message and attachments together. This is an illustrative scenario, not a client case study.
- Target: show customer, order or document IDs and the actual recipient.
- Change: show current and proposed values, the full outbound content and attachments.
- Evidence: distinguish source documents, retrieval time and unresolved details.
- Decision: offer approval, rejection and revision; show owner and expiration.
BOYD recommends invalidating approval when the content changes. Record an execution-request ID and content version, then recheck permissions and current state at execution time. A model-generated 'approved' flag should not replace that check.
[04]Design rejection, expiration and retries explicitly
The reviewer may be unavailable or an order may be cancelled while approval is pending. BOYD recommends holding expired requests rather than executing them, and requesting a new review when the target changes. Avoid keeping long-lived locks on external systems while waiting for a person.
As one implementation example, LangGraph interrupts persist state and pause for external input. Resuming restarts the interrupted node, so side effects before the interruption can run again; its documentation recommends making them idempotent. A framework pause does not itself verify the reviewer's business authority.
Use an execution idempotency key and distinguish pending, approved, running, succeeded and failed states. If a send API times out, provide a way to inspect the external result before retrying. An already delivered email may not be retractable; recovery can include an owner sending a correction.
[05]An acceptance checklist for the pilot
Test one workflow with scoped accounts first. Observe what reviewers change while the system only prepares drafts, then connect execution. This reveals gaps in both automation scope and review information. Record observable events instead of assuming a success rate or time saving in advance.
- Are unapproved execution, unauthorized reviewers and approval reuse across requests blocked?
- Do edits, target-state changes and expiration trigger a new review?
- Do rejection and revision requests stop sending and remain visible to the owner?
- Do duplicate clicks, restarts and API timeouts avoid duplicate execution?
- Can the team trace executor, reviewer, version and result without unnecessary personal data in logs?
Track review waiting time, rejection and revision reasons, duplicate execution and manual recovery separately. Long queues may point to missing context or unclear ownership; removing approval is not the only response. To discuss scope with BOYD, bring one de-identified workflow example and the current approval rules.
- AI automation
- Human approval
- Execution permissions
- Workflows
