Keep a human in the loop by placing review at the decision that authorises a consequential change, while letting the agent gather permitted evidence and prepare the proposal. Give the reviewer a clear change, supporting sources, uncertainty, and ownership. Bind approval to that version, and let a separate executor carry out only the approved work.
Give the agent useful preparation work
Human review becomes frustrating when the person must reconstruct the task from a conversation. The agent can do useful work before a decision: locate permitted records, compare their current state, identify missing information, and draft a specific change with evidence attached.
For a hypothetical internal service-request workflow, the proposal might recommend changing the assigned support team. It should identify the request, explain which documented ownership rule applies, and show what would change. The reviewer should not need to ask the agent to repeat its search merely to understand the recommendation.
This preparation remains bounded. The agent must not send the notification, update the ticket, or create an external record as part of “getting ready.” Under CodeDTX's Propose–Decide–Execute pattern, outward writes belong to the separate executor after a named human has recorded a decision.
Ask for a decision people can actually make
A button labelled “approve agent” is too vague. The interface should show the exact proposed effect: the target, the current value, the proposed value, and the relevant consequence. If the action produces a message, show the recipient and the message that would be sent.
Present source evidence next to the claim it supports. A list of document links without context moves the reasoning burden back to the reviewer. Identify the relevant passage or record field, its freshness, and any conflicting evidence that remains unresolved.
Keep uncertainty visible. If the agent inferred a team from an ambiguous description, the reviewer should see that limitation before deciding. Do not turn an unresolved assumption into a definitive statement merely to make the approval screen look complete. A request for clarification can be a valid outcome.
Route proposals to the right decision owner
Review should follow decision authority, not whoever happens to be online. Define who may approve each action type and how ownership is resolved when a request crosses teams. The interface should explain why a proposal is in that person's queue and what they are being asked to authorise.
Use risk and responsibility to route review. A person authorised to correct a descriptive label may not be authorised to change an operational entitlement. That distinction belongs in policy and application code, with the relevant role checked when the decision is recorded.
Define an escalation path for absent owners and disputed responsibility. Escalation should find another authorised decision maker or pause the proposal. It should not quietly remove the approval requirement because a queue is inconvenient. The operating arrangement is part of the product, not an exception handled outside it.
Reduce interruption without weakening the boundary
A useful approval queue lets people review related proposals in context, inspect evidence without losing their place, and separate items ready for decision from those waiting for clarification. Notifications should direct attention to work the recipient can act on, rather than announce every internal agent step.
A grouped review can be appropriate when the reviewer can inspect the scope and understand each included change. Record what the group contains and bind the decision to that membership. Adding another item later must not make it inherit a decision intended for different work.
Let routine preparation continue while a proposal waits, where that preparation remains within the permitted read scope. The agent may gather newly available evidence and create a revised draft, but material changes should make the earlier review state visibly outdated. Preparation and authorization are different workflow states.
Make edits and rejection productive
Reviewers need more than an accept button. They should be able to reject a proposal with a reason, request missing evidence, or correct the proposed content within their authority. Preserve the distinction between an edited proposal and the original recommendation so the record remains understandable.
An edit that changes the target, recipient, or substantive content creates a different action to approve. The executor should receive the approved version, not a mutable draft fetched later. This prevents a well-intentioned background revision from changing what the person agreed to execute.
Use reviewed rejection reasons to improve prompts, retrieval, and evaluations. Do not automatically convert every reviewer preference into a universal rule. A rejection may reflect a local exception or evidence the agent could not access. An accountable owner should determine what the feedback means before changing workflow behaviour.
Show what happened after approval
Approval is an authorization event, not evidence that execution succeeded. After the person decides, the product should show whether the executor is waiting, running, completed, blocked, or uncertain. Link the completed action to the resulting artifact or destination record where the user has access.
If execution discovers that the target changed while review was pending, preserve that conflict. Show which assumption is no longer valid and whether a revised proposal is needed. Automatically forcing the earlier change through can undermine both the reviewer's intent and the destination's own business rules.
For an interrupted write, operators need a reconciliation path. The reviewer should not be asked to approve an identical retry without knowing whether the original action already happened. Preventing wrong actions requires this execution discipline as well as a thoughtful review interface.
Evaluate the review experience as part of the system
Test whether a reviewer can identify the target, understand the proposed change, locate supporting evidence, and see unresolved uncertainty. Include a proposal with plausible wording but an incorrect record, a stale source, and a hidden change to the intended recipient.
Inspect what the person approved in the stored decision record. A usable screen is insufficient if the backend accepts a different payload or permits a reviewer outside the required role. Product tests and authorization tests should support the same intended workflow.
CodeDTX's reference architecture treats approval queues and operating runbooks as product-layer work, alongside safety-layer human review gates and audit trails. The human contribution becomes useful when the surrounding application delivers a decision worth making and faithfully carries that decision into controlled execution.
Frequently asked questions
Does human review mean approving every tool call?
No. Permitted evidence gathering and proposal preparation can proceed within defined access boundaries without asking a person about each internal step. In CodeDTX's pattern, a named human decides on the proposed outward change. Review the meaningful action with its evidence, while enforcing read permissions and tool contracts throughout the preparation process.
Can several proposals be reviewed together?
Yes, when the reviewer can understand the included actions and has authority over them. Make group membership explicit, preserve the approved content of each proposal, and record the decision against that fixed scope. New or changed proposals need appropriate review instead of inheriting approval simply because they appear in the same queue.
What if nobody approves a proposal?
The action should remain unexecuted. Define visible waiting states, ownership, reminders, and escalation to another authorised reviewer where policy permits. A stalled queue is an operational problem to address, not permission for the agent to proceed. The product should also let owners withdraw or expire work that is no longer relevant.
How should reviewer feedback improve the agent?
Capture the reason for edits or rejection and have an accountable owner determine whether it indicates a general defect, missing evidence, or a local exception. Add representative failures to evaluations and adjust the appropriate component. Avoid silently training workflow policy from individual clicks whose context or authority has not been reviewed.
