Curator Can Stop the Edit Before It Breaks Your Code
Most memory only remembers a decision and hopes the agent reads it. Curator now enforces at the moment of the edit, so a change that violates a recorded decision gets blocked before it lands.
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 enforcing 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, the edit is blocked before it lands, not flagged after it ships. The shift is small to describe and large in practice: memory stops being a thing the agent might consult and becomes a thing the edit has to pass through.
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, returns a clear block or a clear pass, 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 meets a block instead of 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.
Was this useful?