The short answer
Human approval must be connected to the action it controls. In AgentPlat, approving an artifact records a review decision; a protected action also needs task approval and a checkpoint in the provider execution path.
What does human approval actually approve?
“Approved” is ambiguous unless the application identifies its object. A reviewer may accept the wording of a proposal without authorizing its delivery to a customer. A task may be allowed to proceed while one of its requested external effects remains disallowed.
The AgentPlat human approval guide distinguishes artifact review from protected execution. Keeping these controls separate makes the user's decision more precise and the execution boundary easier to test.
| Control | Question it answers |
|---|---|
| Artifact approval | Has this version of the work been accepted? |
| Task approval | May the protected task proceed? |
| Execution checkpoint | May this provider perform the protected effect now? |
Where should an approval check run?
Enforce the check in the path that performs the effect. A review badge in the interface or an instruction in the agent prompt is insufficient if the provider can still execute without consulting the control.
In the documented AgentPlat integration, the host constructs RoomService with requireProtectedActionCheckpoints: true. A compatible provider declares pre_action support and awaits the checkpoint before each protected effect. The integration controls guide explains the configuration and verified-identity integration points.
Your application must connect the decision to the correct tenant, participant and requested operation. Treat a changed target or payload as a reason to re-evaluate the action, rather than assuming a previous review covers it.
Example: approving a proposal before delivery
Suppose an agent drafts a customer proposal. A reviewer accepts version two. That artifact decision records which text was accepted. Sending the proposal is a separate action with its own recipient, attachment and effect.
- Retain the accepted artifact version and review record.
- Identify the exact delivery operation and its required task approval.
- Require the delivery provider to await the execution checkpoint.
- Stop delivery if the checkpoint denies the effect.
- Record the outcome so a retry can distinguish a completed operation from an unresolved one.
This is an illustrative application design, not a claim that AgentPlat supplies a hosted email service. You implement and operate the provider and its effect-specific controls.
What should you verify before relying on the gate?
The documented protected-action example checks that execution requires approval, incompatible providers are rejected and checkpoint denial prevents a local effect. It also retries after a local receipt commits and checks that only one receipt exists for the fixed payload.
Use those scenarios as a starting point. In your own integration, test denial, changed inputs, provider errors and retries after uncertain outcomes. Confirm that every route to the protected system goes through the checkpoint, including background workers and recovery paths.
What does the example not establish?
A local receipt demonstration does not establish exactly-once delivery to arbitrary external systems. An API timeout may leave the application uncertain whether a remote operation succeeded. Resolving that uncertainty may require an external idempotency key, a status lookup or human reconciliation.
Human governance is useful when the decision, enforcement point and retained evidence agree. Keep approval language specific, expose the actual operation to the reviewer, and test the boundary where it can change external state.
Sources and further reading
Documentation reviewed . Consult the linked documentation for current implementation details.