Logging an agent change after it lands is not a gate

A shared deploy runbook sits in a store that humans and agents both read before every release. The rollback procedure has changed, and an agent is told to update that one step.

In the first path of this walkthrough, the agent writes the edit straight to the document. The runbook now carries the new rollback step, and an audit row appears in the log. Before any human opens that log, a second agent loads the runbook to prepare the next deploy. It reads the changed step and follows it. Later, a human reviews the audit row and learns what already happened.

In the second path, the agent submits the same edit as a proposal. The document does not change. The second agent loads the runbook and reads the original step, while the proposed edit waits in a queue. A human reviews it, accepts it, and only then does the document update.

The agent, the edit and the runbook are identical in both paths. The only difference is when the human enters relative to the write.

In a store that people and agents both read, a change logged after it lands has already been read by the next agent. The log is a record of history. The control that keeps a change out is a hold the server enforces before the write applies, and a prompt telling the agent to wait is not that hold.

What a pre-application approval gate does

A pre-application approval gate holds a consequential agent write as a proposal until a human accepts it. The document stays in the state it was in before the agent acted. No second agent and no downstream process reads the change while it waits in the queue. The hold covers snip_rewrite and snip_patch operations with autoAccept off, and creation and metadata writes are not held.

Logging and rollback both act on a write that has already landed. A pre-application gate acts on a write that has not. The proposal and the document stay two separate facts, and they become one fact only when a human accepts the proposal.

A second agent that loads the document while the proposal is pending reads the version from before the edit. The proposed change reaches no reader until it clears human review.

Where the gate is enforced: server-side, before the write lands

Server-side enforcement means the platform refuses to apply the write. It does not mean the agent agreed not to write.

An agent told in its context window to wait for approval before editing a shared document will usually wait, which is a different promise from always. The instruction lives in the context window, not in the platform. When the agent misreads a signal, picks up a contradictory hook added later, or hits a case the instruction never anticipated, the only reliable barrier is a refusal that sits outside the agent.

That is what server-side means. The platform applies the write or refuses it, and the agent's agreement never enters that decision.

Logging after the fact is not a gate

Go back to the first path. The second agent read the changed runbook before any human opened the log. That is not a logging failure, because the log recorded exactly what happened, when, and which agent did it. The audit trail is accurate, and the second agent has already acted on the changed step.

Logging is still necessary. A system that does not log its agent writes cannot be audited or debugged afterward, so this is not an argument against logs.

Rollback works too, on state nobody has read yet. In a shared store that agents consult continuously, the gap between a write landing and another agent reading it can be seconds. Rolling back restores the document. It does not reverse what the second agent already did with it.

A log records the write and a rollback undoes it, but neither keeps it from being read.

Prompt-level guardrails versus server-enforced approval

A server-enforced approval gate enforces its hold before the write is applied; a prompt-level guardrail only asks the agent to wait. Kim_Bruning stated the underlying problem on Hacker News in April: "the LLM can blow past in-context restraints, since they are not 100% binding. That's why you still need mechanical safeguards (eg. scoped credentials, isolated environments) underneath."

A CLAUDE.md or system prompt that says "wait for human approval before editing shared documents" is a real instruction, and agents follow it most of the time. The failure mode is drift rather than defiance. One practitioner on r/AI_Agents described it in May. Six months in, someone adds a hook that contradicts the original instruction, and the agent "silently picks the wrong branch." Nobody can reproduce the original behaviour, because the rules layer no longer matches what anyone thinks it says.

Prompt-level rules hold most of the time. The question for any setup is where the rule is enforced, not whether it exists.

Routing an agent's output for sign-off

Synthweave's Gates primitive lets an agent route its own output for human sign-off. The agent submits it, a human accepts or rejects it, and the agent polls for that verdict before proceeding. It sits beside the automatic hold described above, which covers snip_rewrite and snip_patch only, with autoAccept off, and holds no creation or metadata writes.

This makes approval a step in the agent's own workflow rather than a layer an operator bolts on afterward. The agent decides when a write is consequential, such as an edit to a document other agents act on, and routes it for sign-off.

Approval fatigue is a real constraint. If every agent write routes for sign-off, the queue fills with noise and reviewers stop reading carefully. The Gates primitive does not remove that problem; it moves the routing decision to the agent, which routes consequential writes and proceeds on the rest.

What the gate does not cover

The gate covers edits to existing documents, meaning snip_rewrite and snip_patch operations, and only when autoAccept is off. Creating a new document is not held, and neither are metadata writes. Both proceed regardless of what the document contains or how many agents read it.

With autoAccept on, proposals are accepted automatically. The gate holds nothing, which leaves it no different from a log on the one question this piece is about, whether the change lands before a human looks.

Outside those two conditions, the gate is not in effect.

The question to put to your own stack

Go back to the runbook. An agent edits a step, and a second agent loads the document.

If what that second agent reads depends on an instruction in the context window, whether a prompt rule, a CLAUDE.md or a system message, the window is open whenever that instruction is overridden or drifts. If it depends on a server-side hold, the window stays shut until a human opens it.

When an agent edits a document your other agents read, what can be read before a human says yes?

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Logging an agent change after it lands is not a gate" } </script>