Curator Can Stop the Edit Before It Breaks Your Code

There is a failure mode every team with a coding agent has lived through. The agent decides to “fix” a file that is load-bearing, edits it the same wrong way it did last week, and the only thing that catches it is a human who happened to be watching. You told the agent, twice, that this file does not get touched that way. It remembered nothing, because remembering was never the hard part.

Advisory memory is the norm: it stores a past decision, then hopes the agent reads it back at the right moment. Hope is not a control. Curator now closes that gap by stepping in at the moment of the edit instead of narrating after the fact.

From remembers to prevents

A memory that only recalls is a memory that arrives too late. By the time your agent asks “what did we decide here,” it has often already decided something else. The interesting question is not “can the layer recall the decision” but “can it stand between the agent and the mistake.”

Curator runs a pre-edit guard as an editor hook. Before a change is written, the guard checks whether a recorded decision or a recorded rejection binds the file about to be touched. If one does, it puts that decision in front of the agent right at the moment of the edit, before the change lands, not after it ships. Turn on enforce mode and it goes further: the edit is refused outright until the decision is acknowledged or deliberately superseded, the mode you want for an autonomous run where nobody is watching to honor a surfaced warning. Either way the shift is the same: memory stops being a thing the agent might consult later and becomes a thing the edit runs into first.

Sub-second, or it is worthless

An enforcement step that adds a visible pause to every edit is an enforcement step people rip out by Friday. The guard is built to run in the flow of editing without becoming the thing you notice. It resolves in a fraction of a second, either surfacing a binding decision or waving the edit through, and gets out of the way.

You can inspect the surface directly. memctl decision-guard is how the guard is wired and exercised, so the same rule that protects a live session is one you can reason about and test on your own terms. Enforcement you cannot see into is just a different kind of hope.

Corrections that used to vanish now stick

The most valuable signal a coding session produces is the moment you interrupt. You stop the agent mid-edit, say “no, not like that,” and steer it back. That correction is worth more than a page of narration, and in most setups it is the first thing thrown away. The transcript keeps the agent’s confident wrong plan and loses your override.

Curator captures the interruption instead of losing it. When you cut in and correct course, that becomes a recorded signal the guard can enforce against later. So the agent that tried to re-break a load-bearing file does not just get caught once by a human. The correction outlives the session, and the next attempt to make the same edit runs straight into that recorded decision, surfaced right where the edit happens and refused outright under enforce mode, instead of depending on a person who has to be paying attention.

Why enforcement is the point

Curator ranks what it keeps by how well-established it is, not by how recent it is. That ranking decides what surfaces on recall. Enforcement is what makes the ranking bite. A decision you keep reaffirming does not merely rank first anymore, it can refuse the edit that would violate it. The layer moves from describing your standards to holding the line on them.

Where it stands

Curator is a working pre-release product and runs on your own machine, close to where the edits happen. It remembers for Warden and TheAuditor, shares a brain with Arbiter, and answers to the same proof discipline as BenchProctor. Read good memory knows when to refuse for the other half of the story, or follow release preparation.