An approval without a diff is a ceremony.

Human approval is useful when it transfers a bounded decision to a person who can understand and own it. The person needs to see what the agent wants, why it wants it, what will change, who will be affected, what evidence supports the proposal, and which uncertainty remains.

Do not ask a person to approve the agent. Ask them to approve one exact change.

This is the same lesson software teams learned from code review. A pull request is not merely a merge button. It gathers the intent, exact changes, discussion, automated checks, and decision history around one proposed update. An agentic approval needs the domain equivalent.

For email, the unit of review is not the prose alone. It is a campaign plan: goal, audience, exclusions, content, claims, sender, schedule, budget, tools, connected automations, and expected measurement. If any of those can move, the reviewer needs the movement, not a reassuring summary.

The cheapest human-in-the-loop interface puts a modal before a tool call. It says the agent wants to send a campaign and offers two choices: Approve or Reject. This may satisfy a technical requirement that execution paused. It does not necessarily create meaningful oversight.

Reviewers compensate for missing context in predictable ways. They trust the agent because it sounded confident. They reopen five tabs and reconstruct the plan by hand. They approve because the deadline is close. Or they reject safe work because the interface makes every proposal look equally dangerous.

NIST's AI Risk Management Framework treats human oversight as an organizational process, not a decorative last step. It calls for clear roles, documented context and limitations, impact assessment, and oversight designed around policy and risk tolerance. A popup is only one surface inside that system.

A useful pause therefore answers a harder question: has the system assembled enough evidence for this particular person to make this particular decision without becoming the agent's forensic investigator?

The approval packet should be short enough to scan and complete enough to challenge. Put the consequence first, details second, and raw evidence one layer deeper. For an email campaign, eight fields usually deserve the front page.

The packet should link to evidence, not drown the decision in it. A recipient count can open the audience definition. A deliverability result can open the test. A proposed message can open its template and variants. Progressive disclosure preserves both speed and scrutiny.

Review is an attention-allocation problem. A full campaign plan may be correct in ninety-nine places and dangerous in one. Showing the whole plan with equal visual weight makes the dangerous change harder to find.

Start with a trusted baseline: the last approved version, the governing template, or the plan the person just reviewed. Compare it with the proposed version at the semantic level. Highlight that the audience grew from active customers to all contacts, a discount changed, the destination URL moved, a suppressed group reappeared, or a follow-up automation was added. Do not make reviewers infer those changes from two walls of prose.

A diff must include removals and invariants too. Show that the suppression policy remains active, the sender is unchanged, and no new data source is introduced. Confidence comes partly from knowing what did not move.

An approval is stale the moment a material input changes. If an agent can replace the audience query, destination page, discount, sender, or schedule after approval, the review was attached to a story rather than an action.

Freeze the plan and calculate a stable digest over the fields that matter. Store the audience snapshot or reproducible query, suppression version, rendered content, links, sender, schedule, budgets, tool arguments, and connected effects. The execution path should accept only that approved identity.

Not every typo requires a board meeting. Define which edits are cosmetic, which trigger focused re-review, and which invalidate the whole approval. The essential rule is that the policy is explicit and the interface says when approval has been dismissed.

Human in the loop does not mean any available human in the loop. A copy editor can judge tone. A lifecycle owner can judge frequency. A privacy or security owner may need to review a new data source. Finance may own a promotion budget. The sender-domain owner may control a risky volume jump.

Split review by responsibility when the proposal crosses boundaries. Ask each person a question they are equipped to answer, then assemble the decisions. Avoid presenting one giant approval that makes every reviewer implicitly endorse every domain.

This is where scoped permissions and autonomy budgets meet interface design. The agent should know who can approve which boundary, how long that decision lasts, and when a higher-impact proposal needs escalation.

Approve and Reject are often the least informative choices. A reviewer may agree with the goal but not the scope, agree with the copy but not the timing, or need one unresolved fact before deciding.

1. 01

   Approve this exact version

   Authorize the bound plan once, inside the displayed limits.

2. 02

   Narrow the scope

   Remove a segment, lower the volume, reduce the budget, or disable a follow-up before reconsidering.

3. 03

   Request a change

   Return a precise instruction tied to the field that needs work; the new version receives a new diff.

4. 04

   Ask for evidence

   Pause on a missing test, stale count, ambiguous claim, or unresolved data source without rejecting the goal.

5. 05

   Decline

   Close this proposal with a reason the agent may use as policy feedback, not as an invitation to route around the reviewer.

The agent should preserve the reviewer's edit as structured intent. “Exclude dormant customers” belongs in the next plan, its diff, and eventually the receipt, not only in a chat transcript the execution layer never sees.

Too little approval creates unowned risk. Too much approval creates fatigue. People learn to click through harmless reads and carry that habit into consequential sends. Match the review to impact, novelty, uncertainty, sensitivity, and reversibility.

Model confidence may help decide when to ask for more evidence. It must not decide authority. A highly confident agent can still be outside its recipient, spend, data, or tool boundary.

Imagine an agent is asked to prepare a win-back campaign for customers who have not purchased recently. It starts from an approved template and a previously approved audience rule. During planning, it finds a larger dormant group and proposes a stronger incentive.

A weak approval says: “Win-back campaign ready. 48,210 recipients. Approve?” A useful approval begins with the change: 12,840 additional people have no purchase in the last 180 days; the offer moved from free shipping to 15%; the send moved from local morning delivery to immediate global delivery; and a reminder branch was added.

If the reviewer narrows the audience and removes the reminder, the agent creates v13. The new review highlights those two removals and preserves the unresolved offer and schedule changes. Nothing is sent merely because the conversation sounded complete.

In an MCP-connected workflow, a server may need more information or a human decision while a client is handling a request. The current draft elicitation specification defines structured form and URL modes, requires clear identity and decline paths, and separates sensitive interactions from ordinary in-client data collection.

That protocol boundary is valuable, but it does not decide what a marketer needs to see. A raw function name and JSON arguments may be technically accurate and practically unreadable. Moosewave should translate the tool call into the campaign's audience, message, timing, budget, safeguards, uncertainty, and diff, while retaining the raw call for inspection.

Decline and cancel are normal outcomes. The agent must handle them without retrying through a different tool, shrinking the description until the same action looks harmless, or treating silence as consent. A request for approval is a question, not an error state to route around.

After approval, preserve what the person actually saw: the plan identity, semantic diff, policy checks, linked evidence, remaining uncertainty, available choices, decision, approver, and time. Then connect that record to the execution identity and provider receipts.

This makes later questions answerable. Did the campaign that ran match the campaign that was approved? Was a material edit made after review? Did a requested exclusion reach the final audience? Did the action remain inside its autonomy budget? If something went wrong, the receipt becomes the starting point for containment and recovery.

Do not call a hidden model explanation the audit trail. Store the external facts, policy results, versions, decisions, tool arguments, and observed outcomes. Those are the parts an operator can inspect, reproduce, and dispute.

A person gives Moosewave a goal. The agent prepares a private plan using scoped connected data, runs audience, policy, link, rendering, and deliverability checks, then opens a review surface focused on material change.

Desktop can hold the complete comparison. Mobile can lead with consequence and changed fields, then let the reviewer inspect evidence or narrow the plan. Both surfaces refer to the same immutable plan version. Approving on a phone must not mean approving a different summary than the one prepared on desktop.

After the decision, Moosewave either closes the proposal, prepares the requested revision, or executes the exact bound plan. The evidence layer then joins approval, send receipts, placement, engagement, and customer outcomes into one history.

The product should make careful work feel faster because the right difference is already on the table, not slower because a human has been inserted as a ceremonial obstacle. Explore the full connected ecosystem or follow one goal end to end in the product walkthrough.

• NIST AI Risk Management Framework Core , governance, documented context, human-AI roles, impact, and oversight across the system lifecycle.
• GitHub Docs: About pull requests , an established review pattern combining intent, diffs, discussion, checks, and a merge decision.
• Model Context Protocol: Elicitation , the current draft interaction model for requesting structured human input with review, decline, and privacy boundaries.
• Microsoft Agent Framework: function tools with approvals , a concrete human-in-the-loop tool-call approval flow.