Define the smallest reviewable action
Take an agent that proposes changing the priority of support ticket T-17. Before approval, its review record should name the workspace, ticket ID, current priority and requested priority. The approver should see the business reason and the source record used to justify the change.
If the target or proposed value changes, treat the reviewed proposal as changed. Decide explicitly which changes require another review rather than letting an old approval drift to a new action.
- Target
- Workspace A / ticket T-17
- Intended effect
- Change priority from normal to high
- Precondition
- Ticket still has the reviewed state
- Approval scope
- This change, within a defined validity window
Review evidence at the boundary
- Resolve the identity. Confirm the agent's execution identity and the reviewer's authority for this workspace. A name in the prompt is not an access control.
- Inspect the proposed effect. Show the old and new values together. Keep unrelated writes outside this proposal.
- Attach the basis. Retain the source reference and its relevant version or observation time so the decision can be reconstructed.
- Define expiration. Explain when the approval becomes stale, including a changed target record or a changed request.
- Preserve the decision. Record approve, reject or request changes, with a reference linking it to the exact proposal.
For this ticket example, a version check at execution can reject a stale proposal if another operator has already edited the record. The downstream system must enforce the check. Describing it in the agent prompt is insufficient.
Prove the result separately
Approval proves that someone permitted the action. It does not prove that the tool executed it. After the call, read the authoritative ticket record or an appropriate operation receipt and compare it with the requested change.
If the response is missing, retain the original operation identity and route the case through the retry evidence procedure. Do not silently replace an unknown result with success. Keep the approval reference, tool request reference and final state reference together so a later reviewer can follow the chain.
Set limits before expanding the workflow
This example covers a bounded record update. Bulk changes, permission changes and actions with legal or financial consequences need their own review design and recovery semantics. An approval mechanism is one control. It does not replace downstream authorization or application validation.
When a team needs to implement these boundaries, Pharos Production's AI agent development services include the relevant integration and evaluation scope. The T-17 record here is an original illustrative example, not evidence from a delivered client system.
Sources and method
The workflow/agent distinction and the use of environmental feedback are discussed in Anthropic's Building effective agents. The review record above is this publication's proposed template. Source checked on . No vendor benchmark is used.