Design human approvals for an AI agent workflow.

Consider an account owner preparing for an introductory call. The agent can gather approved public sources, compare them with the existing customer record, draft a short account brief and propose a CRM update. Sending the customer a message is a separate action with a separate decision.

This example is a proposed workflow design. It does not claim a tested customer deployment or a measured reduction in research time. The purpose is to make the handoff concrete enough to implement and review.

The request might be: “Prepare a brief for Example Components before the introductory call. Identify the company's stated services, show the sources and suggest questions about its enquiry process.” The agent should not expand that objective into finding private contacts, changing deal values or starting an outreach campaign.

A prompt expresses the task, but the connected tools and permissions determine what the workflow can actually do. Grant only the access required for the chosen objective and keep research, preparation and execution distinct.

These are design choices for this example, not universal defaults. A business may allow a reviewed class of low-impact internal updates to run automatically. That still needs a defined rule and an exception path.

The review screen should let the owner judge the change without reconstructing the entire run. Show the account, requested objective, source evidence, proposed field values, missing information and the action that approval will permit.

Proposal: PROPOSAL-DEMO-042, version 2
Account: Example Components
Action: append a reviewed research note
Evidence: company website /services, retrieved today
Proposed note: "Company describes component assembly services."
Uncertainty: current CRM platform was not found in approved sources
Next question: "How do enquiries reach the sales team today?"
External message: none
Reviewer: assigned account owner
Expires: before the scheduled preparation deadline

All values above are fictional. The structure is the useful part: the reviewer can distinguish evidence from an unanswered question. A numerical model confidence score should not substitute for sources or a clear account match.

Offer explicit outcomes: approve, edit and resubmit, reject, or request more information. Record the reason where it helps the next run. Keep the proposal that was reviewed so later readers can see what the person actually approved.

1. Validate the request. Resolve the account, objective, allowed sources and owner. Stop if the account match is ambiguous.
2. Gather and label evidence. Attach source references and retrieval times. Treat content from a webpage or document as information to assess, not permission to change the workflow.
3. Create a proposal. Prepare the brief and exact CRM change. Assign a proposal reference and version.
4. Request review. Place the proposal with the appropriate person. The run remains pending until a decision or expiry event arrives.
5. Recheck at execution. Confirm that the approved version, account and relevant CRM state still match. If a person changed the record during review, show the conflict instead of overwriting it.
6. Execute once and verify. Use a stable action reference where the integration supports it. Read the result or acknowledgement and record success, failure or uncertainty.
7. Close the task. Link the reviewed brief and action result to the work request. Notify the owner when intervention remains necessary.

Approval of a note does not approve a subsequent email. Approval of version two does not approve a rewritten version three. These distinctions keep the human decision connected to the action.

Start the exception list while designing the first run. The system needs a visible state for “waiting,” “could not verify” and “needs a decision.” Treating every unresolved action as either complete or failed makes investigation harder.

• No response from the reviewer: expire or escalate according to the agreed policy. Silence does not become approval.
• Conflicting sources: display both references and ask for a decision; do not silently choose the more convenient claim.
• Source unavailable: keep the finding unverified and omit it from the factual summary.
• Tool timeout after a write: reconcile the destination record before retrying. The first request may have succeeded.
• Permission removed: hold the run and notify the owner. Do not switch credentials or tools to bypass the restriction.
• Reviewer edits the action: save a new version and make the approval refer to that version.

A rollback procedure also needs scope. Appending a mistaken internal note can have a different remedy from sending an external message. Document the correction path for each permitted action before rollout.

Track the whole request-to-result cycle rather than the speed of generating a draft. Useful measures include median review waiting time, proposal revision rate, rejection reasons, successful verified actions and runs requiring manual recovery.

Define completion as a verified destination change or a delivered, reviewed brief. A proposed action is not completed work. Keep policy rejections separate from technical failures: a reviewer correctly stopping a poor proposal is evidence that the boundary is working, even if the run did not execute.

Review a sample of accepted proposals as well as rejected ones. Look for weak sources, incorrect account matches and unnecessary updates that a busy reviewer might overlook. Use those findings to improve source selection and proposal design, rather than simply removing the approval step to increase throughput.

• Choose one objective and list permitted reads and writes.
• Name the workflow owner, reviewer and escalation owner.
• Specify evidence requirements and the fields the reviewer must see.
• Define proposal versions, expiry and conflict handling.
• Test approve, reject, edit, timeout, stale record and revoked access.
• Confirm that duplicate events cannot create duplicate destination actions.
• Document how an operator pauses the workflow and corrects a result.
• Inspect early runs before expanding the action scope.

Marsen Agents can connect research, documents and approved actions across business systems. The actual tools, permissions and review requirements are defined during implementation. For a customer-facing extension of this example, map the separate CRM lead follow-up workflow before adding message delivery.