Prepare → Confirm: Designing Safe Mutation Gates for Autonomous Agents
Why AI agents should never have a single-step "publish now" tool—and how two-phase confirmation gates prevent accidental live mutations.
- LLMs are probabilistic; external API mutations (publishing a post, replying to a customer, activating a strategy) must be deterministic.
- Splitting every mutation into `prepare_*` (dry-run validation + preview token) and `confirm_*` (token execution) eliminates accidental side effects.
- A confirmation token must bind to the exact target channel, payload hash, and scheduled timestamp—expiring if anything changes.
The Danger of Single-Call Mutation Tools
If you give an AI agent a single `publish_post(channel, text, time)` tool, a misunderstood prompt—such as "Show me what it would look like if we scheduled this for tomorrow"—can trigger an actual live API call. In production systems, reading or previewing an action must never share the same step as committing it.
Single-step `publish_post()` or `send_reply()` tools that execute immediately on the first tool call.
Phase 1: `prepare_publication_action` (validates rules & returns preview + token) → Human/Policy Review → Phase 2: `confirm_publication_action`.
1. Mechanics of the Two-Phase Prepare → Confirm Gate
The Prepare → Confirm pattern adapts database two-phase commit principles to human-AI collaboration. When an agent wants to schedule, move, retry, or publish a post (or publish an article or reply to a comment), it must first call `prepare_publication_action`.
During the `prepare` phase, the server validates channel capabilities, checks workspace autonomy rules and quiet hours, computes the exact preview diff (channel, caption, media, target slot), and returns a short-lived `confirmationToken` without touching any external social network.
INVARIANT OF AGENT SAFETYNo external mutation can occur without a fresh confirmation token generated from an explicit `prepare_*` call for that exact payload.
// PHASE 1: Prepare (Dry-run validation + human-readable preview)
{
"tool": "prepare_publication_action",
"arguments": {
"draftId": "draft_drift4l_ig_01",
"action": "schedule",
"channel": "instagram",
"scheduledAt": "2026-10-11T18:00:00Z"
}
}
// Server Response:
{
"status": "prepared_awaiting_confirmation",
"preview": {
"workspace": "fieldwork",
"channel": "Instagram (@fieldwork)",
"scheduledLocal": "Oct 11 · 18:00",
"captionPreview": "Two days. Four litres. Jacket, snacks and a repair kit..."
},
"confirmationToken": "cfm_9f82a1b4c7e0_exp15m"
}
// PHASE 2: Confirm (Executed only after explicit human approval or policy check)
{
"tool": "confirm_publication_action",
"arguments": {
"confirmationToken": "cfm_9f82a1b4c7e0_exp15m"
}
}2. Applying Prepare → Confirm Across Posts, Articles, Comments, and Strategy
A consistent architecture uses the same two-phase pattern across every sensitive boundary in the workspace: `prepare_publication_action` / `confirm_publication_action` for social queues, `prepare_article_action` / `confirm_article_action` for CMS delivery, `reply_to_comment` / `confirm_comment_reply` for public audience replies, and `prepare_content_strategy_approval` / `approve_content_strategy_draft` for activating a new strategy version.
3. Designing Clear Confirmation UX for Humans
A confirmation gate is only effective if the human reviewer can see the exact text, target channel, and timestamp in one glance. After confirmation, provide a direct deep-link from the agent conversation straight to the newly scheduled row in the publishing plan so the operator can verify the result in context.
Direct Execution vs. Two-Phase Prepare → Confirm Architecture
| Property | Direct Tool Execution | Two-Phase Prepare → Confirm (MUMRO Pattern) |
|---|---|---|
| Ambiguous prompt risk | High—agent may publish when asked to "test scheduling" | Zero—`prepare_*` only generates a safe preview and token |
| Payload integrity | Agent might alter text between preview and execution | Token is cryptographically bound to the prepared draft and slot |
| Policy enforcement | Checked too late or bypassed | Evaluated during `prepare` against autonomy mode and quiet hours |
| Audit trail | Single opaque log entry | Explicit record of Prepared Preview + Confirmed Authorization (`AG03`) |
MCP Simulator: Prepare → Confirm Gate & 3 Graduated Autonomy Modes
Agent reads active Strategy v2, Brand Voice boundaries, quiet hours (22:00–07:00), and available schedule slots without mutating any state.
Agent saves a visible draft inside the FIELDWORK workspace. Creating a draft never triggers an external social API call.
MCP server validates autonomy rules and returns an exact human-readable preview (Instagram · Oct 11 · 18:00) plus short-lived token `cfm_9f82a1b4`.
After explicit human sign-off, the confirmation token commits the exact post to the MUMRO publishing plan with a full audit trail.
Inspecting the MCP Preview Before Adding the DRIFT 4L Post to the Plan
In the MUMRO interactive MCP flow, the agent prepares the DRIFT 4L post for Oct 11 · 18:00 and pauses in the `review` state.
- Agent reads context, generates the draft, and invokes the schedule preview.
- The operator inspects the exact caption, target channel (Instagram), and slot (Oct 11 · 18:00).
- Only after clicking the explicit confirmation button does the item enter the FIELDWORK publishing plan, with a direct link to focus that exact row.
Workflow outcome: Fast agentic preparation paired with 100% deterministic human sign-off.
Built-in Prepare → Confirm gates across every external mutation.
MUMRO enforces two-phase confirmation gates for social publishing, CMS articles, comment replies, and strategy approvals—so you stay in command of every live action.
- Two-phase `prepare_publication_action` and `confirm_publication_action` for scheduling, moving, retrying, or publishing (`AG03`).
- Dedicated confirmation gates for CMS articles (`prepare_article_action`), comment replies (`confirm_comment_reply`), and strategy approval.
- Direct handoff link from confirmed MCP actions to the exact scheduled item in your MUMRO plan.