--- title: "Where human approval belongs in an AI assistant workflow | R&D COPILOT" lang: en canonical: https://rdcopilot.com/insights/ai-approved-workflow-actions/ content_version: 896917b52dc31d9ddf0b7b197e34a35372fdce02b78e156ca07c2f4a71be8445 contact: https://rdcopilot.com/contact/ --- [RDC](https://rdcopilot.com/) [Insights](https://rdcopilot.com/insights/)AI Copilot AI CopilotHow-to guide # Where human approval belongs in an AI assistant workflow An assistant can prepare a useful supplier update without receiving permission to send it or change an order. We design approval around the exact action: the recipient, the fields being changed and the business record affected. This gives the reviewer a concrete decision and gives the system a reliable way to tell the difference between a draft, an approved request and a completed operation. By R&D COPILOT6 October 20265 min read In this guide 1. [Separate preparation from execution](https://rdcopilot.com/insights/ai-approved-workflow-actions/#guide-section-1) 2. [Approve an exact version of the action](https://rdcopilot.com/insights/ai-approved-workflow-actions/#guide-section-2) 3. [Handle an uncertain delivery outcome](https://rdcopilot.com/insights/ai-approved-workflow-actions/#guide-section-3) 4. [Give approvers the right reach](https://rdcopilot.com/insights/ai-approved-workflow-actions/#guide-section-4) 5. [Test changed approvals and retries](https://rdcopilot.com/insights/ai-approved-workflow-actions/#guide-section-5) 6. [Build one approval path end to end](https://rdcopilot.com/insights/ai-approved-workflow-actions/#guide-section-6) [Sources & inspiration](https://rdcopilot.com/insights/ai-approved-workflow-actions/#guide-sources) ## Separate preparation from execution Consider a purchasing assistant drafting a follow-up about a delayed delivery. Reading the order and proposing wording are different permissions from contacting the supplier or changing the expected date. We list those capabilities separately. The interface should show the proposed message and intended recipient alongside the order context, so approval covers more than a plausible paragraph. Create a capability list for the supplier workflow: read an order, inspect its attachments, draft a message, request approval and submit the approved message. Assign each capability to a role or service identity. Keeping them separate makes it possible to introduce assistance gradually. It also lets the business disable outbound communication while preserving useful drafting if an operational issue occurs, without removing the whole assistant from the team's work. ## Approve an exact version of the action Attach approval to the proposed content, target record and allowed operation. If someone edits a quantity or changes the recipient afterwards, the existing approval should no longer authorize execution. Show what changed and request a new decision where required. This avoids a review that was correct at the time becoming permission for a materially different action. The approval view should show a difference when the proposed action changes an existing record. For a delivery-date update, display the current value, proposed value and reason. For a message, show attachments as well as the text and recipient. A reviewer can only approve what the interface makes visible. Store the decision with the exact version reviewed so later investigation can distinguish a changed request from an incorrect execution of an unchanged one. ## Handle an uncertain delivery outcome A timeout after submission does not establish whether a message was sent or an order changed. The workflow needs an operation identifier and a way to inspect the destination outcome. Where an API supports idempotent requests, use its documented contract; otherwise design reconciliation before replay. Repeated clicks should not silently produce repeated supplier communications. Use separate states for rejected, expired, cancelled, executing and awaiting outcome where the workflow requires them. An approved request may become stale because the order changed before execution. Recheck the relevant business conditions and authorization immediately before the action. If execution has started, cancellation must explain whether it can stop the request or only prevent a future retry. That distinction matters more than the presence of a generic cancel button. ## Give approvers the right reach The person reviewing a draft may have authority for one supplier or purchasing team but not another. We check authorization when the action executes as well as when it is prepared. Keep personal contact details, commercial terms and message history within the agreed audience. Operational logs should record decisions without collecting every document or message body by default. Messages can contain supplier contacts, delivery details and negotiated terms. Decide which of these the model receives and whether attachments are required for drafting. Use limited service credentials for the action endpoint and keep them outside the model's text context. Audit information should identify the decision and operation without recording secrets. Where a support engineer needs message content, make that a controlled investigation path with appropriate retention rather than routine unrestricted logging. ## Test changed approvals and retries Acceptance testing includes rejected drafts, changed recipients, revoked roles and a network failure after the destination accepted the request. Review both unauthorized executions and legitimate actions left stuck in a queue. Measure review effort alongside completion reliability. A workflow that requires supervisors to inspect technical logs for every failure still needs product work. Test a reviewer approving one version while another person edits the order, an approver losing a role and a provider returning an uncertain result. Ask operations staff to recover those cases through the interface. Record accidental sends, duplicate actions, abandoned approvals and the time needed to resolve an exception. The test evidence should show both that blocked actions remain blocked and that authorized work can be completed without administrative workarounds. - List read, draft, approve and execute permissions separately for the supplier communication you intend to automate. - Invalidate approval when the recipient, attachment or consequential field changes after the reviewer has checked it. - Recheck authorization and business conditions immediately before execution, including an order that changed while awaiting approval. - Investigate uncertain destination results before retrying any action that might send another message or create another record. ## Build one approval path end to end We can scope a supplier follow-up from order lookup through review to recorded delivery. The quote should name the communication channel, business system, permitted actions and escalation owner. Agree which failures remain with the purchasing team and which require technical support. Expansion to autonomous actions should depend on evidence from the bounded workflow. An implementation proposal can name one supplier communication channel and one order system, then list the permitted actions and required approvals. We can build the review screen, execution boundary and result tracking as separate inspectable deliverables. Agree an operating procedure for failed or disputed actions and identify the owner of each. Later autonomy can be considered action by action, using observed performance and business authority rather than an all-or-nothing agent setting. Inside the product ## AI Copilot [![Research notebook with pilot questions, a brief and source evidence.](https://ai.rdcopilot.com/product-demos/ai/gallery-overview-en.png)View full size](https://ai.rdcopilot.com/product-demos/ai/gallery-overview-en.png) Research notebook with pilot questions, a brief and source evidence. [![Supplier follow-up brief marked as reviewed, with supporting source evidence.](https://ai.rdcopilot.com/product-demos/ai/gallery-detail-en.png)View full size](https://ai.rdcopilot.com/product-demos/ai/gallery-detail-en.png) Supplier follow-up brief marked as reviewed, with supporting source evidence. Swipe or use the arrows to explore. Image 1 of 2 Follow the references ## Sources & inspiration ### [ShipSense AI: Invoice Processing Agent for Enterprise](https://devpost.com/software/invoice-processing-agent-for-enterprise) Devpost project by KP Kshitij Parashar Invoice intake and field checks. This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis. - [Stripe: idempotent requests](https://docs.stripe.com/api/idempotent_requests) - [EDPB data protection guide for small business](https://www.edpb.europa.eu/sme_en) Put the guide to work ## Start with your workflow. Tell us what your team needs to do, which systems are involved and where the current process slows down. [Discuss your project](https://rdcopilot.com/contact/?service=company-ai-agents) [Explore AI Copilot](https://ai.rdcopilot.com/en/products/ai/) AI Copilot ## Keep exploring. [All guides](https://rdcopilot.com/insights/) Decision guide ### [AI copilot for R&D: scope an implementation pilot for your team](https://rdcopilot.com/insights/ai-copilot-first-team-pilot/) Scope an AI copilot for R&D around one research task, approved sources, reviewer checks and measurable pilot outcomes for a small technical team. [Read guide](https://rdcopilot.com/insights/ai-copilot-first-team-pilot/) Workflow ### [From scattered technical files to a research brief with sources](https://rdcopilot.com/insights/ai-research-brief-source-review/) Build research briefs that connect technical claims to pages, tables and document revisions, with explicit handling of conflicts and reviewer decisions. [Read guide](https://rdcopilot.com/insights/ai-research-brief-source-review/)