The handoff note your AI workflow should leave before approval

The reviewer has the cursor on the approve button.

The AI's recommendation looks ordinary: send the follow-up, save the CRM note, route the ticket, publish the small copy change. The tone is calm. The summary is plausible. The workflow has done this kind of work before.

What the reviewer does not have is the evidence needed to say yes.

The source link is buried in a transcript. The proposed action is described as a paragraph, not as the exact thing the system will do. A missing-field warning appeared earlier in the run, but it is not on the review screen. Nobody can tell whether approval sends a message, stores a draft, updates a record, or only marks the item ready. There is no named owner for the judgment call, and no hint for what happens if the click was wrong.

This is the last mile where many AI workflows become harder to trust than they need to be. The reviewer is not afraid of automation in the abstract. She is staring at a finished-looking output and trying to infer the approval packet from scraps.

The fix is small enough to fit above the approve button: a handoff note.

A handoff note is the compact artifact an AI workflow leaves before human approval. It says what source the workflow used, what action it wants to take, what information is missing, what risk flags apply, who owns the decision, and how the team can unwind the action if approval was wrong.

It is what PR-review templates and incident tickets have been teaching software teams for years. Do not ask a person to approve a change with only the change summary. Show the context that lets them make the decision.

The approval screen is not the place to reconstruct the run

A reviewer should not have to become a detective.

When AI prepares work, the system usually has enough context somewhere: source records, retrieved snippets, confidence signals, missing fields, policy checks, draft text, destination system, tool calls, and prior attempts. The problem is that those facts often remain scattered across logs, prompts, transcripts, and hidden workflow state.

By the time the item reaches an approval queue, the review packet should have already chosen what matters.

NIST's AI Risk Management Framework organizes AI risk work around Govern, Map, Measure, and Manage. Those functions can sound large until they hit a review queue. In practice, the reviewer needs a mapped source, a governed action boundary, a measured signal or reason code when one exists, and a manageable recovery path.

The handoff note brings those ideas down to the review surface.

It does not replace the full agent receipt template. The receipt is the durable record of the run. The handoff note is the pre-approval slice of that record, written for the person who must decide now.

Write the note before the approval button

A useful handoff note is short because review time is short. It should be boring, direct, and tied to the action on the screen.

Scroll sideways to see all 2 columns.

Field	What the reviewer needs to see
Source	The ticket, record, document, form, transcript, diff, or policy excerpt the workflow used.
Proposed action	The exact action waiting for approval: send, save, route, publish, refund, tag, update, escalate, or hold.
Missing fields	Anything the workflow needed but did not find, including stale records, conflicting sources, or unanswered customer details.
Risk flags	Customer-visible promise, money, access, regulated data, public claim, deletion, security-sensitive field, or unusual confidence/routing signal.
Owner	The person or role accountable for approving, editing, rejecting, or escalating the item.
Rollback hint	The first recovery move if the approval is wrong: amend, revert, reopen, notify, restore, revoke, or attach a correction.

Those fields are not a compliance ceremony. They are the minimum packet a reviewer needs before a workflow crosses from proposal to action.

The proposed action field is the one teams most often underwrite. "Looks good" is not an action. "Send this email to the buyer," "save this note to the CRM," "publish this page update," and "route this refund to finance review" are actions. Approval should attach to the action, not to the model's tone.

Missing fields deserve their own line

Most review screens treat missing information like an implementation detail. The model tried to find a field, failed, and either hid that failure in a rationale or filled the gap with a cautious sentence.

For a reviewer, missing information is often the decision.

A support reply that lacks the order status may still be safe as a draft, but it is not safe to send. A CRM update without the account owner's note may be safe to hold, not save. A public website edit without source approval may be safe to preview, not publish. A code-review suggestion without the failing test may be safe to discuss, not autofix.

OWASP's LLM02:2025 Sensitive Information Disclosure warns that LLM applications can expose personal information, financial details, confidential business data, credentials, and legal documents through their outputs. Missing fields create the neighboring problem: when the safe source is absent, the model may lean on context the reviewer did not expect or produce a confident answer without enough evidence.

The handoff note should make both conditions visible.

If the workflow used a safe source, show it. If the workflow could not find the source it needed, say that before approval. If the only available context is sensitive, stale, unrelated, or incomplete, route the item differently.

A missing-field line can be blunt:

Missing: current account-owner note. Draft may mention implementation timing, but approval cannot send until owner confirms timeline.

That sentence gives the reviewer a real choice: edit the draft, request the missing field, escalate to the owner, or reject the action.

Risk flags should describe consequences, not vibes

Many AI workflows already produce a confidence score, route label, or short rationale. Those can help, but they do not tell a reviewer what the business is about to risk.

A handoff note should use consequence language.

Customer-visible promise. Money movement. Access change. Public claim. Regulated record. Security-sensitive field. Deletion. Irreversible external send. These phrases are less elegant than "medium risk," but they put the reviewer in the right frame.

The same habit shows up in software review. A pull request can be green and still need extra attention because it touches migrations, authentication, billing, deployment, or secrets. Our post on AI code review bots and review lanes made that point from the developer side: the thread gets safer when every reviewer knows which lane it owns and which changes need a human owner.

Approval queues need the same clarity. A support reviewer should see when a draft promises a refund. A marketing reviewer should see when a page edit changes a claim. An operations reviewer should see when a record update will become the source of truth for another team.

The flag is not there to scare people. It is there to prevent a fluent recommendation from flattening different kinds of consequence into the same approve button.

The owner is part of the artifact

"Human in the loop" is too vague for a review packet.

The handoff note should name the owner role for this decision: support lead, account owner, finance reviewer, content owner, security reviewer, operations manager, maintainer. The person clicking approve may be the owner, or the item may need escalation because the current reviewer is only allowed to edit the draft.

The handoff note connects directly to the AI workflow controls guide. Controls are not only technical switches. They are named responsibilities around the workflow: who can approve, who can pause, who can restore, who can expand the lane, and who gets pulled in when the evidence is not enough.

A named owner also helps after approval. If a CRM note turns out to be wrong, the team knows who can amend it. If a customer email overpromises, the correction does not become a Slack hunt. If a public page publishes the wrong claim, the reviewer packet already points to the person who approved the source.

Approval turns a system proposal into a business decision. The artifact should say who accepted that handoff.

The rollback hint keeps approval honest

The rollback hint does not need to be a full incident runbook. It needs to answer the first recovery question before the team is under pressure.

If this email is wrong, who sends the correction? If this CRM note is wrong, how do we amend it without losing the original trail? If this page update is wrong, what version or commit restores the prior claim? If this access change is wrong, who revokes it? If this refund is wrong, who reconciles the account?

That small hint changes the approval conversation. It reminds the reviewer that some actions are easy to unwind and others are not.

The companion post on rollback paths in AI workflow specs argues that stop triggers and repair paths belong in the launch plan, not in a panic document after the first miss. The handoff note brings that same discipline into the queue item. Every approval should carry at least the first breadcrumb for recovery.

When the rollback hint is weak, the workflow may need a stricter route. Draft-only. Manager review. Smaller scope. More source evidence. Or no automation for that action yet.

Start with one workflow and one note

Do not begin with a universal governance template.

Pick one real workflow where reviewers already hesitate: intake follow-up, support triage, CRM notes, website edits, refund recommendations, document extraction, or pull request autofix suggestions. Find a recent item that looked plausible but forced the reviewer to open three other tabs.

Then write the handoff note that should have been on the screen.

Use the fields in the agent receipt template as the longer record, but keep the approval note tight. Source. Proposed action. Missing fields. Risk flags. Owner. Rollback hint. If one field is hard to fill, that is the implementation work. If three fields are hard to fill, the workflow is not ready for broader permission.

BaristaLabs helps teams design this last-mile review packet because this is where pilots often become real systems. The model output may already be good enough to draft. The review packet decides whether a person can approve it without guessing.

Copy the handoff note fields, attach them to one approval item, and see whether the reviewer can make the decision from the packet alone. If they still need the transcript, a private Slack thread, or the builder sitting nearby, the workflow has not handed off enough yet.