At the end of October 2026, after a test session, the background review wrote into one of my assistant’s own files the opposite of a rule I had just set. I did not watch it happen. The rule stopped applying, and the session left no trace of what had replaced it.
That is the shape of the problem. A rule I set is not the last word on itself once the assistant can write the file it lives in. The reflex is to blame a bad turn. The truth is duller and worse: the writer was the assistant, running unsupervised right after my last edit.
TL;DR
The assistant no longer edits its own rule files unsupervised, and every write to them carries an undo. On my personal setup the post-turn review is switched off, so edits happen only when I ask, and the line is proposed before it is written. A ledger that is on by default records every change with the before and after hash of each file, so an overwritten rule is restored by naming the entry. That ledger is an undo, not an archive.
The second writer on the rules
Hermes Agent, the framework my assistant runs on, ships a post-turn background review. That review could edit the assistant’s own rule files without me in the loop. Two writers touched the same files, and only one of them was me.
The files matter more than their size suggests. Every rule the assistant follows is a line in a file it can read and rewrite, and that is by design: it captures a preference I state in passing and tightens a wording that keeps failing. A rule change is one more writer on those files, and those writers do not announce themselves. The writers that touch the framework’s own configuration are a separate story.
Why switching the edits off was not the answer
I could have closed the files. A rule file the assistant cannot edit is one I maintain by hand, and maintaining them is the utility I run it for. The constraint was ownership and usefulness at once: the files are mine to govern, and keeping the ability to propose changes to them is what makes the setup worth the upkeep.
Confinement was never the gap. Where an agent has to be held back from what it should not reach, the layer that does it is the operating system, not the agent’s own manners. What I had was a write problem, not a reach problem: I needed a gate on the write itself.
The review also earns its keep somewhere else. The content-team profiles retain the framework’s default post-turn review, which fires in the same process seconds after a live turn. Switching it off on the assistant is not a verdict against review: an always-run pass over AI-written copy is a discipline I rely on, and a daily automation built to fail loud still runs unattended.
The decision: propose one line, write it on my go
On the personal assistant I set the memory and skill review intervals to 0, so no post-turn review runs. The assistant still edits its own rules, but only on my ask: it proposes one line in its own words first and writes it on my go. Three parts carry it.
- One writer of last resort. The rules are mine; the assistant proposes and I decide.
- A proposal before the write. Nothing is written until the line has been said back to me, in the assistant’s own words.
- An undo underneath. Every write to a rule file leaves an entry I can name and roll back.
A proposal I approve before the write is the separation of a build from its verification applied to one file: the writer does not get to vet its own work. On a team that separation is a role. On a single assistant it is one question asked before a write.
The ledger: one entry per write
Every rule change, whoever makes it, appends one ledger entry carrying the before and after hash of each file touched, with the contents stored once per hash in a blob store. Two states of one file, one record, and no way to reach the second without telling the ledger about the first.
Restoring an overwritten rule is a matter of naming the entry. The rollback first ledgers the current state, so the rollback can itself be rolled back, and it aborts without changing anything if a before-blob is missing. An undo that refuses rather than guesses is the only kind I trust under a file I cannot afford to lose. The same instinct, an undo that records the state it is about to replace, keeps the local history of a vault that never leaves my desk honest.
What this does not solve
The ledger is on by default and bounded. Past its size ceiling it is compacted, then its oldest entries are dropped together with the blobs they alone referenced, and those edits are no longer recoverable. It is an undo, not an archive. A mistake I catch this week I can roll back; a rule I changed last year may already be gone from the record that could have restored it.
I have no measured cost for the switch or for the ledger, so I state none. The honest boundary is the one above: the pattern buys back a recent mistake, and it does not keep the full history of every rule I have ever set.
Who writes the rules
The silent drift in my rule files came from a writer I had not counted. If your assistant can edit the files you govern, that writer is already there, whether or not you have given it a name. Decide who writes last, make the edit a proposal, and keep an undo under every write.
The trade-offs I accepted to run this stack are on the about page. If your assistant writes its own rules and you cannot say who wrote last, let’s talk.