Propose-then-approve: trust patterns for agent writes

The first time an agent breaks something it shouldn’t, the postmortem tends to find the same thing: there was a human “in the loop,” but the human was approving a sentence, not a change. Approval theater is easy to build. The real pattern — the one that lets agents write to production data without anyone losing sleep — has a specific shape, and every part of it earns its place.

The shape is propose-then-approve: the agent drafts a change, a human approves it, and the system applies it. Three roles, deliberately separated. The agent can propose anything but publish nothing. The human judges but doesn’t type. The system enforces the rules and performs the write. Most of what goes wrong in agent systems comes from collapsing two of these into one.

Approve the diff, not the description

An agent reporting “I updated the FAQ to reflect the new 3-month term” is grading its own homework. The description is what the agent believes it did; the diff is what will actually happen. A reviewer has to see the old value and the new value, side by side, for every field the draft touches. If your approval screen shows a prose summary next to an Approve button, you’ve built a politeness gate — the human is confirming the agent’s confidence, not its work.

This has an upstream consequence people miss: the data has to be structured enough to diff. If a page is one blob of HTML, the diff is a wall of markup noise nobody reads. If it’s typed fields — headline, price, a list of FAQ items — the diff reads like a change log: this field, was this, becomes that. Diffability is a data-model decision, made long before any agent shows up.

The server decides what a draft may touch

Human review catches bad judgment; it shouldn’t be the only thing standing between a confused agent and a deleted pricing section. Server-side, every draft passes an allowlist keyed to the kind of request: a copy edit may change text fields and nothing else. Crucially, the classification comes from the actual base-versus-proposed diff, not from what the request claimed to be — a draft labeled “copy edit” that adds, removes, or reorders sections is rejected before a human ever sees it.

This is also your prompt-injection defense. Agents read untrusted text — customer emails, web pages, ticket threads — and untrusted text sometimes contains instructions. An allowlist enforced in the server means a hostile sentence in a support email can, at absolute worst, produce a strange text edit for a human to reject. It cannot make a copy edit delete a section, because no copy edit can.

Two more properties are non-negotiable. Apply must be idempotent: approvals get double-clicked and requests get retried, and applying the same approved draft twice must produce exactly one change. And everything goes in an audit trail — who requested, what the agent drafted, who approved, when it published — because when an agent does forty things a week, “what happened here” has to be a query, not a reconstruction.

A worked example: the managed-site edit queue

The platform our managed client sites run on is built around this pattern; here is the concrete flow. An edit request arrives — by email or the site’s request box — and lands in a queue. An agent claims it and drafts a revision through the same structured content API a human editor uses; it never hand-edits markup. The server runs a structural diff gate and rejects any draft that exceeds what the request’s category allows. A human opens the review queue, reads a field-by-field diff — old text, new text — and approves or rejects. Approval writes an immutable, versioned revision and publishes it; the change is live minutes later and revertible forever. The agent holds no publish permission anywhere in the system. Approval is the only path to production, and rollback means an agent mistake costs minutes, not a rebuild.

Approval fatigue, and the graduation path

Now the uncomfortable part: if a human rubber-stamps 100 diffs a day, the gate is theater. Review quality collapses with volume — by the fortieth diff, approval time is trending toward two seconds, and the process delivers the feeling of control without the substance. Pretending otherwise is how “human in the loop” ends up as a phrase in an incident report.

The fixes are structural, not motivational:

• Batch. Twelve related copy tweaks across one page should be one review, not twelve.
• Sample. For a trusted action type, review one draft in ten and audit the rest after the fact; keep 100% review for anything touching money or deleting data.
• Graduate. Grant autonomy per action type, with budgets. After, say, 300 approved copy edits with under a 2% rejection rate, let copy edits under 50 changed words auto-apply — capped at 20 a day, every one still versioned, revertible, and reviewed weekly in a batch. A cap turns “what if it goes wrong” into “it can go wrong at most 20 small, reversible times.”

Graduation is per action type, never global. Copy edits can earn autonomy; “delete a section” never graduates, because its blast radius doesn’t shrink with a track record. Reversibility changes the math too: a versioned content write can graduate far sooner than an outbound email, which has no undo.

The honest boundary: if your agent only reads, or writes to a scratch environment someone reviews wholesale, skip the ceremony — approval gates are for writes that are customer-visible or hard to reverse. A read-only research agent behind this much process is just slow.

This pattern is built into the platform our managed websites run on, and it’s the spine of every agent system we build for clients: the safety lives in the system — diffs, allowlists, caps, audit — not in the prompt.