Tie Human Approval to the Exact Version an AI Agent Delivered

A reviewer approves a change. An agent then makes another edit. The task still shows “approved.”
That is an easy workflow mistake to make when approval belongs to a task rather than a particular delivery.
A practical review process should answer three questions: what was reviewed, who reviewed it, and what changed afterward? You can model those questions without building a large approval system.
Keep the delivery and review separate
Consider a hypothetical task to improve a form’s validation message. The agent prepares the change. A teammate checks the interaction and error wording. An engineering reviewer checks the implementation.
The delivery record should identify the submitted version and its evidence. The review should identify the same version and record the acceptance decision.
Here is a small JavaScript example:
`

javascript
function canAccept(task, delivery, review, actorId) {
return task.status === 'awaiting_review' &&
Boolean(delivery.revision) &&
delivery.revision === task.currentRevision &&
Boolean(delivery.evidenceUrl) &&
actorId === task.reviewerId &&
actorId !== delivery.runnerId &&
review.revision === delivery.revision &&
review.decision === 'accept' &&
Boolean(review.note?.trim()) &&
task.criteria.length > 0 &&
task.criteria.every(id => review.checks[id] === true);
}

`
This function assumes the records have already been validated for their expected shape. It illustrates a workflow rule; it is not a complete authorization system.
Try it with these sample records:

const task = {
  status: 'awaiting_review',
  currentRevision: 'rev-2',
  reviewerId: 'reviewer',
  criteria: ['behavior', 'scope']
};

const delivery = {
  revision: 'rev-2',
  runnerId: 'runner',
  evidenceUrl: '/evidence/rev-2'
};

const review = {
  revision: 'rev-2',
  decision: 'accept',
  note: 'Checked the error message and confirmed the change stayed in scope.',
  checks: {
    behavior: true,
    scope: true
  }
};

console.log(canAccept(task, delivery, review, 'reviewer'));
// true

console.log(
  canAccept(
    { ...task, currentRevision: 'rev-3' },
    delivery,
    review,
    'reviewer'
  )
);
// false: the approval does not cover the current version.

The revision labels and evidence path are illustrative. In an implementation, use an immutable revision identifier and evidence tied to that revision.
Make each criterion inspectable
A checkbox called “looks good” leaves too much interpretation to the reviewer.
For the validation-message example, define observable checks:

• Submitting an empty required field displays the agreed message.
• Correcting that field clears its error.
• The change leaves unrelated validation behavior unchanged. A review note should explain what was inspected and any remaining limits. Checking a field in a record does not prove the underlying behavior works. During preparation, the function was checked against six illustrative cases: a valid acceptance, the wrong actor, an outdated review, missing evidence, an unchecked criterion, and a newer task revision. Those cases passed their expected assertions. They do not establish production security or integration correctness. Enforce the rule where acceptance happens In a real application, derive the reviewer’s identity from the authenticated session. Do not trust an identity supplied in a request body. Load the current task and delivery from trusted storage. Check their revisions and apply the acceptance update atomically, so a new delivery cannot arrive between the check and the update. Keep an audit record of the decision. An AI team management platform can store those records, but the team still has to decide which judgments belong to qualified reviewers. Wagglet’s discussion of meaningful work with human–AI pairs provides the broader context for making that human contribution explicit. Preserve the work behind the approval The person who reproduces an issue, identifies an ambiguous requirement, or rejects an incorrect fix has contributed to the outcome. Keep that work visible. Record why a delivery was returned, what evidence was missing, and which specialist was needed. Include that review time when evaluating the process. A new version should create a new review obligation. Otherwise, the approval stops describing what a person actually checked.