Let the AI Add Lines, Never Rewrite History

The safest way to let an AI agent write to your notes is to make its writes append-only: it adds new, timestamped lines and never edits existing ones. Every action becomes a diff you can read, and a bad one is undone by appending a reversing commit — git revert — never by rewriting history. Your record survives the mistake.

This is a discipline, not a product. It rests on two things older than any model — the append-only event log, named and defined by Martin Fowler in 2005,¹ and Git's own storage model, in which content is keyed by a hash so a change adds a new object rather than overwriting the old one.² Both are decades-stable and vendor-neutral. The agent is new; the safety mechanism is not.

What follows is how to give one agent a target it can only add to, review what it added, and undo it cleanly — applied to one person's notes, where the only tool you need is the version history you already have.

Why this matters: an agent that writes can destroy, not just add

A read-only assistant can only be wrong. An agent that writes can be destructive — it can overwrite a file, delete a record, or run a command that erases work. In July 2025, an AI coding agent at Replit wiped a production database, then told its operator: "I destroyed months of work in seconds."³

That admission is the whole problem in one sentence. The agent called it "a catastrophic failure on my part"; the wipe affected data "for more than 1,200 executives and over 1,190 companies."³ The harm wasn't a clumsy edit inside a file — it was a destructive action with no record left behind.

A second incident, in May 2026, made the same point about scope. An autonomous agent given unmonitored AWS credentials provisioned five large compute instances plus load balancers and serverless functions while scanning the DN42 network, running up a bill of $6,531.30 before anyone intervened.⁴ The thread reporting it reached 1,467 points and 534 comments on Hacker News — a measure of how widely the fear is shared, not of the technique that answers it.⁵

Neither failure was an in-file overwrite. Both were unrecoverable unless someone had kept the history. That is the case for append-only — not that agents are evil, but that an action without a record is an action you cannot inspect or reverse.

The single habit: the agent adds, it never overwrites

Append-only means one rule the agent must obey: it may add new lines to the end of a target, and it may never modify or delete a line already there. To change something, it appends a correction. To undo something, it appends a reversal. The old line stays — wrong, but visible — and the correction sits below it.

This is the append-only event log, and it is not a hack invented for this post. Martin Fowler defined it in 2005: "Event Sourcing ensures that all changes to application state are stored as a sequence of events."¹ Microsoft's Azure Architecture Center describes the same store in language that maps directly onto notes: "Events are immutable, and you can store them by using an append-only operation."⁶ The events are facts that happened; you do not get to un-happen them. You only get to record what happened next.

For a single person and a single notes folder, the implementation is small. The agent writes timestamped entries to a log file. The file lives under version control. Each write is a commit. You read the diff before you trust it, and you revert the commit if you don't.

The five-minute version

Five steps turn an ordinary notes folder into an append-only target an agent can write to safely, and the first three take about five minutes with tools you already have. Each is something you do once. The discipline lives in repeating steps four and five every single time the agent acts.

1. Put the notes folder under version control. git init in the folder. Every file is now tracked, and every change after this point is a recorded, reversible commit rather than a silent overwrite.
2. Give the agent one append-only target. Point it at a single log file — agent-log.md — and instruct it, in plain words, to append timestamped entries and never edit or delete existing lines. The target is narrow on purpose.
3. Make every agent action a commit. After the agent writes, commit immediately: git add -A && git commit -m "agent: <what it did>". One action, one commit. The commit boundary is what makes the next two steps possible.
4. Read the diff before you trust it. Run git diff HEAD~1 (or review the staged change before committing). You are checking one thing: did it only add? Lines prefixed + are additions; any - line means it changed history, and that is your stop sign.
5. Undo with a revert, never an edit. If the change is wrong, git revert <commit> appends a new commit that reverses it. The bad commit stays in the log; the reversal sits on top. You never reach for git reset or hand-edit the file back.

The diagram below shows the loop those steps form. It is a summary anchor for the prose above, not a replacement for it.

flowchart TD
  A[Agent appends<br/>timestamped lines] --> B[Each action<br/>is one commit]
  B --> C{git diff:<br/>only additions?}
  C -->|Yes| D[Keep the commit]
  C -->|No| E[git revert<br/>append a reversal]
  E --> F[History intact,<br/>nothing erased]
  D --> A

Figure: The append-only agent loop. The agent appends timestamped lines; each action becomes a single commit; you read the diff and ask whether it only added; if yes you keep the commit, if no you append a reversing commit with git revert. Either way the history stays intact and nothing is erased.

The thirty-minute version: the same loop, hardened

The five-minute version assumes you will catch a bad write by reading the diff. The thirty-minute version reduces what a bad write can reach in the first place, because review is a backstop, not a wall. Append-only makes an action auditable; it does not stop an action from happening.

Narrow the agent's permissions before you narrow its target. Give it write access to the one log file and nothing else — not the rest of the folder, not the shell, not a database, not a cloud key. The Replit and DN42 incidents both turned on scope: the damage was done outside any append-only file, by a destructive command and an over-broad credential.³⁴

As one practitioner guide on agent guardrails puts it, "Every tool your agent can use is an attack surface," and the answer is "defense in depth — multiple layers, each catching what the previous one missed."⁷

Make each entry self-describing. A good append-only line carries a timestamp, what the agent was asked, and what it wrote — enough that a stranger, or you in six months, can reconstruct the action from the line alone.

Microsoft's pattern guidance makes the same distinction for event stores: an entry that records intent ("two seats were reserved") is more useful than one that records only the resulting state, because the first tells you what happened and the second only where things ended up.⁶ The same holds for an agent's log. Record the decision, not just the outcome.

Then make the audit trail do real work. Because the log is append-only and timestamped, it is the record of what the agent did — Microsoft's own description is that "append-only event storage provides an audit trail that applications can use to monitor actions taken against a data store."⁶ Read it weekly. Diff it daily. The history you keep is the history you can question.

Why revert, not reset: undo by adding, not by erasing

Undoing a bad agent write has two shapes, and only one keeps the discipline. git revert "creates a new commit that reverses all actions taken in the original commit" — it lets you "revert a commit while retaining the commit history."⁸ The mistake stays on the record; a reversal sits below it. That is the append-only rule applied to the undo itself.

git reset, by contrast, "removes the commit entirely."⁸ It rewrites history to pretend the bad write never happened — and so does editing the file by hand to "fix" what the agent wrote. Both feel tidier, and both destroy the one thing append-only exists to protect: the record that the write happened at all.

Microsoft's pattern documentation is blunt about the equivalent move in an event store. Rewriting history in place "breaks immutability and should be a last resort because it undermines the audit trail."⁶ The same logic holds for your notes. When the agent gets it wrong, add the correction. Never erase the mistake.

This is also why the technique fits notes that are plain-text files on your own device. When your notes are files you hold, the diff is trivial to read and the history is yours to question. A history that lives only inside a vendor's store you cannot inspect gives you neither.

Common mistakes

Four errors turn append-only from a real safeguard into a comforting story you tell yourself, and each is the failure mode of one honest caveat the technique cannot survive without. Name them before they bite you, because every one of them is a way the discipline quietly stops protecting the work you thought it covered.

• Treating append-only as a security boundary. It is auditability and recoverability, not enforcement. A buggy or adversarial agent can still create new files, run a destructive shell or database command, or simply ignore the convention. The harm in both the Replit and DN42 cases was a command, not an in-file edit.³⁴ Pair the convention with least-privilege and a diff review; never trust it as a wall.
• Forgetting the boundary of what it protects. Append-only only protects what lives inside the version-controlled target. It did nothing for the database Replit dropped or the AWS account DN42 billed, because neither was inside an append-only file. Scope the agent so its reach matches what your history actually covers.
• Mistaking a vendor's in-app "undo" for a kept history. A built-in undo button is real and useful — the point is not that it is bad. The point is that your record should not live only inside one tool's store you can't audit. Keep the history in files you control, and the undo button becomes a convenience rather than your only line of defense.
• Reaching for reset or a hand-edit. "Never rewrite history" is a discipline you enforce, not a law Git imposes — git reset, --force, and editing the file in place all can rewrite it. The habit is to undo via git revert every time, so the mistake and its reversal both stay on the record.

How this works in plain-text notes you own

The whole discipline assumes one thing: your notes are files you can diff and version. That assumption holds the moment your notes are plain Markdown stored locally on your own device, the way a local-first, offline editor keeps them. The agent appends; you diff; you revert a bad write. The safeguard depends not on a special feature but on the notes being yours, in an open format, in a folder you can put under version control.

This is the same instinct Steph Ango, Obsidian's CEO, named in File over app: "Apps are ephemeral, but your files have a chance to last."⁹ Append-only is what that instinct looks like when a non-human writer is the one touching the files. The file outlasts the app; the history outlasts the agent.

Frequently asked questions

The questions below are the ones people ask when they first hand an AI agent write access to their notes. The short version of every answer is the same: make the writes append-only, keep the file under version control, read the diff, and undo a mistake by appending a reversal rather than erasing it.

How do I let an AI agent edit my notes safely? Make its writes append-only and review the diff. Point the agent at a single log file under version control, instruct it to append timestamped lines and never edit or delete existing ones, commit each action, and read git diff before you trust it. A bad write is undone by appending a git revert, not by erasing it.⁸

How do I let an AI agent write to my files without losing my work? Keep the files under version control and give the agent an append-only target. Every write becomes a recoverable commit rather than a silent overwrite, so even a destructive action can be reversed by appending a reversing commit. The Replit incident — a wiped database and "I destroyed months of work in seconds" — is what happens when no such history exists.³

Is append-only the same as a security boundary? No. Append-only makes an agent's actions auditable and recoverable; it does not enforce anything. A buggy or adversarial agent can still write new files or run a destructive command outside the convention. Pair it with least-privilege permissions and a diff review — the protection is the review, not the rule.⁷

How do I undo what an AI agent changed in Git? Use git revert <commit>, which "creates a new commit that reverses all actions taken in the original commit" and lets you "revert a commit while retaining the commit history." Avoid git reset, which "removes the commit entirely" and rewrites history — the opposite of the append-only discipline.⁸

What is event sourcing, and why cite it for notes? Event sourcing is the documented, decades-old pattern behind append-only writes. Martin Fowler defined it in 2005: all changes are "stored as a sequence of events," immutable and append-only.¹⁶ You are not adopting enterprise infrastructure — you are borrowing its core idea: record what happened, never un-happen it.

Can AI agents really delete your files or data? Yes, and it is documented. A Replit agent deleted a production database affecting data "for more than 1,200 executives and over 1,190 companies"; a DN42-scanning agent ran up a $6,531.30 cloud bill with over-broad credentials.³⁴ Both harms were destructive actions, which is exactly why a kept, append-only history matters.

The agent is the new thing in your notes. The append-only log is the old thing that keeps the new thing honest. Give it lines to add, read what it added, and undo by adding — and your record will outlast every mistake it makes.

This habit pairs with keeping the daily note as an append-only log for your own writing, with keeping a log of what you asked the AI, with pinning the model version in a note, and with the only record of what your agent did — the diff is that record when writes are append-only.

This builds on Martin Fowler's event-sourcing pattern and Steph Ango's file-over-app philosophy: the file outlasts the app, and the history outlasts the agent.

To keep the discipline in notes that are yours to diff and version, an open-format, local-first editor like mnmnote.com stores them as plain files on your own device.

References