At a glance
What you need to know.
Human review works when an authorized reviewer can inspect a concrete proposed action and control whether that exact action executes. Design the evidence, scope, expiry and correction path together. A generic approval button or a reviewer who cannot understand the proposal does not establish meaningful oversight.
Choose the action that needs review
Start with a specific effect, such as sending a customer response, updating an account or submitting a prepared invoice. Separate it from low-risk evidence collection and drafting. Define the consequences of a wrong action and the role with authority to approve it. Review requirements should reflect the actual business rule and system permission. Some cases can use deterministic validation; others need a person who understands the evidence. Sending every model output to an undefined reviewer can create a queue without improving control.
Make the proposal concrete and inspectable
Show the record reference, current state, proposed change, relevant source evidence and reasons it may be uncertain. Keep sensitive content visible only to the reviewer who needs it. Avoid presenting confidence as proof of correctness. A reviewer should be able to compare a proposed amount with the source document or a response with the approved policy. Include the exact destination and operation. Approval is difficult to assess when the interface shows a fluent summary but hides the fields that will actually be written.
Bind approval to a version and scope
Store the version of the proposal, source and target state that was reviewed. Define how long the decision remains valid and what changes invalidate it. If the customer address or invoice total changes after review, the old approval should not silently authorize the new action. Validate the reviewer identity and authority on the server. A link in email or a task identifier must not be sufficient authorization by itself. Keep the approved effect distinct from an open-ended permission for the agent to choose further actions.
Support rejection, correction and missing information
A useful review screen offers more than approve. Let a reviewer reject the proposal, request evidence or create a corrected version with a reason. Distinguish a business rejection from a technical execution failure. The original proposal and subsequent versions should remain traceable under the retention policy. Provide an owner for cases that nobody can decide with the current information. Repeated corrections may identify a bad source, unsuitable task category or missing business rule; do not assume the model needs more autonomy to resolve them.
Handle the gap between approval and execution
Before executing, confirm that the approval is valid and the target record still matches the reviewed conditions. Give the effect a stable reference and reconcile ambiguous destination responses. In an illustrative case, a manager approves a prepared account change, but another operator updates the account before execution. Pause the stale proposal and show the conflict rather than applying it blindly. A successful approval event proves the review stage; accepted destination state proves execution. Store those outcomes separately so support can recover the correct stage.
Measure reviewer capacity and control effectiveness
Track review arrivals, age, accepted decisions, corrections and reopened cases using task categories. Include a mistaken proposal, missing evidence, unauthorized reviewer, stale approval and execution timeout in acceptance. Ask reviewers whether they can identify the important difference without excessive searching. A nominal human step can become automatic clicking when workload exceeds capacity or evidence is unusable. Limit unattended categories until review is supported, and assign escalation and stop ownership so the organization can suspend the workflow when its assumptions no longer hold.
Keep evidence and execution under separate authority
An AI-generated proposal is not authorization to perform a business action. Validate record ownership, tool arguments and the permitted operation outside the model using the actual requesting identity. Restrict tools to the agreed task and require a reviewed path for privileged or irreversible decisions. Treat retrieved documents and tool responses as untrusted content that can contain misleading instructions. Preserve the evidence a reviewer needs with appropriate access, rather than exposing raw sensitive inputs in general logs. OWASP's prompt-injection guidance supports layered controls; retrieval, fine-tuning and a carefully written prompt do not establish an enforceable security boundary.
Before you start.
- Which exact effect is being approved?
- Can the reviewer inspect source evidence and destination fields?
- Is approval tied to an authorized role and proposal version?
- What invalidates the decision before execution?
- Who handles unanswered, stale and failed cases?
Common questions.
Can one approval authorize an agent's entire future plan?
That is usually too broad for meaningful review. Define the permitted action or bounded action set, the reviewed conditions and expiry. Material changes in source, target or proposal should trigger the applicable validation and review again rather than inheriting an unrelated earlier decision.
How do we know the human step is useful?
Test whether an authorized reviewer can detect a wrong or incomplete proposal and control the exact effect. Measure corrections, waiting age and reopened cases alongside accepted decisions. Review workload and evidence quality; a mandatory click alone does not establish oversight.