Deciding which AI agent tasks need human sign-off

Deciding which AI agent tasks need human sign-off works best as a short written policy based on risk, not a case-by-case feeling. Routine tasks whose criteria are fully expressed as checks can complete when those checks pass, run independently of the agent. Tasks whose criteria live in someone's judgment (wording, design, security, money, irreversible data changes) need that person to sign off, whatever the tests say. And completing a task is a different decision from releasing it. Without a policy, teams drift into one of two failures: reviewing everything, which becomes rubber-stamping once the queue grows, or reviewing nothing, which works until it does not. This page gives a way to classify tasks, a rule for who signs off, and the separation between done and released. The mechanics of gating are in evidence gates for AI work; the review itself is in reviewing agent output.

Four questions that set the risk level

Classify each task when you write it, not after the agent finishes. Four questions are enough.

Can the criterion be checked mechanically? "The parser accepts ISO week dates" can. "The error message is clear to a non-technical user" cannot. If a check fully expresses the criterion, a passing independent check carries most of the weight.

How far does the change reach? A change local to one module is different from a change to a shared library, a schema or a public API. See why narrow tests miss regressions for what goes wrong at the edges.

How reversible is it? A UI tweak behind a feature flag can be rolled back in minutes. A data migration, a deleted storage bucket, an email to customers or a published package version cannot.

Who outside the team is affected? Anything that touches money, credentials, permissions, personal data, legal text or external users raises the stakes regardless of size.

A task that is mechanically checkable, local, reversible and internal is routine. A no on the first question, or a yes on any of the risk questions, moves it up a tier.

Three tiers and who signs off

Routine. Completion requires the task's checks to pass, run by something other than the agent (CI or a verification step you control). No individual sign-off per task. A person samples completed routine tasks each week, which keeps the classification honest. Examples: dependency updates with green CI, added tests, small refactors inside one module.

Reviewed. The checks must pass and a developer reviews the diff before merge. The reviewer is anyone qualified in that area. Examples: changes to shared code, new endpoints, anything an agent did outside its declared scope.

Owner-only. Checks are necessary but not sufficient. The person who owns the criterion signs off: the product owner for user-facing wording and flows, the security lead for authentication and permissions, whoever is accountable for billing for money paths, the data owner for migrations and deletions. Examples: a change to how invoices are calculated, a new consent screen, a migration on live data.

Write the tier into the task as a field, not a judgment made at merge time. Let anyone raise a tier but only the owner lower it. When an agent's work moves a task up a tier (it touched authentication while fixing a typo), the higher tier applies.

DONE is not released

Teams often let "the task is done" stand in for "the work is ready to ship". They are separate decisions with separate owners.

DONE closes a unit of implementation. Release accepts a set of DONE items, together, into the hands of users. Between the two sit things no single task owns: integration across tasks, manual acceptance, documentation, release notes and a final full test run.

BRAIN FLUID's own development workspace shows the gap. On October 30, 2026 it held 123 cards: 50 DONE, 39 VERIFY, 20 TODO, and the rest spread across in-progress, decision, backlog, declined and on-hold states. A separate acceptance checklist had 139 items, of which 70 had passed and 69 were pending. Those are different populations and do not combine into one number. Some DONE cards were closed at the owner's direction before manual acceptance, so DONE there marks implementation closure, not release readiness.

The board vocabulary supports that separation: review and completed work are distinct states, alongside separate decision and hold states [C2], and the Build workspace tracks implementation and acceptance separately [N02]. Whatever tool you use, keep a release checklist that is not derived from task status.

Making sign-off cheap enough to happen

A policy that demands more review than people have time for will be bypassed. Three habits keep it real.

Batch owner-only reviews. A fixed slot twice a week, with tasks waiting in a decision state, beats interrupting the owner every time an agent finishes. Agents can move on to routine work in the meantime.

Give the reviewer a short packet: the criterion, the checks that ran and their results on which revision, the diff limited to the relevant files, and any deviation from scope. An owner signing off on wording should not have to read a build log.

Record the sign-off with the task: who, when, on which revision. If the code changes after sign-off, the sign-off is stale, exactly like a stale test result.

Also watch for the opposite failure, sign-off fatigue. If a reviewer approves forty agent tasks a day without a comment, either the tier is wrong (those tasks are routine and should rest on mechanical checks) or the review is not really happening. Move them down a tier with stronger checks rather than pretending the review is there.

QUESTIONS

Should every AI-generated pull request be reviewed by a human?

Not with the same depth. Routine changes that are local, reversible and fully covered by independently run checks can rely on those checks plus periodic sampling. Changes to shared code need a developer review. Changes to money, security, data or user-facing wording need sign-off from the person who owns that criterion.

Who should approve AI agent work that changes user-facing text?

The person accountable for that text, usually the product owner, not the developer who ran the agent. Tests can confirm the text appears where expected, but only the owner can judge whether it says the right thing. Record the sign-off together with the revision it applies to, so a later edit makes it visibly stale.

What is the difference between done and released?

Done closes one task's implementation. Released means a set of done tasks has been integrated, accepted and delivered to users together. Release needs checks no single task owns: a full test run, manual acceptance and release notes. Tracking them separately stops a board full of done cards from being read as ready to ship.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build
• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• evidence gates for AI work Evidence gates for AI work: separate proposed from approved execution, run checks, and record outcomes so acceptance rests on evidence.
• human review of agent output Human review of agent output: what to inspect before accepting AI changes, and how recorded outcomes make the review honest.
• kanban for AI agents Kanban for AI agents: the board states that matter when software does the work, including review, blocked and decision owed.
• Self-reported vs independently run checks for AI agent work Self-reported vs independently run checks for AI agent work: why an agent's own "tests pass" is weaker than a check the system runs itself.
• When an autonomous agent run should stop and ask When an autonomous agent run should stop and ask: failed checks, missing approval, open blockers, impact obligations, out-of-scope writes or uncertain state.