How to Build an AI Workflow with Human Review

Separate drafting from acting

An AI workflow with human review should show the reviewer what will happen before the system changes anything important. Producing a summary, recommending a label, sending an email, and publishing a page are different capabilities. Give each its own rules instead of treating a single model response as permission to perform every step.

Start with an internal draft. Define the intended reader, source material, required fields, and conditions that make the draft unacceptable. For example, a support summary might need the customer request, relevant dates, unresolved questions, and links to the original messages. It should distinguish an observed fact from an inference.

Match the review gate to the consequence

List the possible actions and their consequences. An internal draft can be edited. An external message can expose information or create expectations. A deletion or access change may be harder to reverse. OWASP guidance on excessive agency recommends limiting available functions and permissions, with human approval for high-impact actions.

Apply that principle through the component that performs the action. A prompt saying “wait for approval” is not sufficient when the agent still has an unrestricted publishing tool. The publishing endpoint should verify a valid approval for the exact content and target. If either changes, the previous approval should no longer authorize the action.

An approval screen should display the recipient or destination, complete proposed content, important source links, and any expected cost or side effect. A reviewer who sees only a green status indicator cannot make a meaningful decision. Make rejection, revision, and escalation as clear as approval.

A hypothetical lead-response workflow

Consider a hypothetical studio receiving a project inquiry. The AI extracts the requested outcome and drafts a response. A validation step checks that required contact details exist and that the response does not promise a price, deadline, or capability that has not been approved. A staff member then compares the draft with the inquiry.

The reviewer notices that the customer asked about an integration the studio has not assessed. They replace a confident promise with a discovery question. The revised text receives a new draft version. Only the approved version may be passed to the sending component, which records the message identifier and final delivery status.

This example illustrates a design pattern, not a claim that Medivh Code currently runs an automated email service. The important property is traceability: staff can tell which source was used, who approved which version, and whether the authorized action completed.

Give reviewers a specific checklist

Review quality depends on the questions asked. A vague request to “check the AI” encourages people to skim the prose. Make the check short enough to use repeatedly and specific enough to catch the failures that matter.

• Facts: Can each material claim be traced to an approved source?
• Scope: Does the draft answer the request without creating new commitments?
• Privacy: Is every included detail appropriate for the destination?
• Action: Are the target, parameters, and content visible and correct?
• Uncertainty: Are missing facts identified instead of guessed?
• Authority: Is the reviewer permitted to authorize this action?

Test rejection, interruption, and changed drafts

Create a small evaluation set with ordinary requests and deliberately difficult ones. Include missing information, conflicting instructions, an irrelevant document, and text that asks the system to bypass its controls. Score the results against the checklist. Smooth prose should not earn a pass when the content is wrong.

Test what happens when the reviewer rejects a draft, edits it after approval, or closes the browser halfway through. Also test repeated execution of an approved action. The system needs a durable status record so an interrupted run does not silently become an unreviewed retry.

OWASP’s AI agent guidance also calls for authorization outside the agent context and monitoring appropriate to the risk. Use that as a starting point for engineering review, then document the actual controls you implemented. Record enough operational metadata to investigate failures while keeping credentials and unnecessary private content out of logs.

A practical first release can keep all outputs as drafts and let people perform external actions themselves. Add controlled execution only when the review gate, permissions, and recovery path have been tested. The objective is a useful process whose decisions a responsible person can inspect.