Git For AI: Why Every Memory Edit Should Be Attributed

What this article answers (plain language): When AI agents and humans share a memory layer, every mutation needs provenance. The fix is the discipline git brought to source code, applied to AI substrate: content-addressed storage, parent-pointed revisions, and required authorship on every change.

Every AI memory layer I've used eventually has the same conversation: "Wait, who wrote this?" The model wrote it, the user edited it, the model overwrote, and now there's no way to recover the original or tell what changed when. The fix isn't better UX. It's the discipline git brought to source code thirty years ago — content-addressed storage, parent-pointed revisions, required authorship on every mutation. Applied to AI memory, it's the layer that makes shared substrate trustworthy.

I shipped this in my own product six weeks ago and I'd put it in the top three architectural decisions of the year. Every change to every file in every workspace now goes through a single write path that requires an author identity, a parent revision pointer, and a message. The blob is content-addressed and shared across workspaces (identical content reuses one blob). The revision chain is walkable. Nothing is lost. Everything is attributed.

This is what I mean by the Authored Substrate.

The Problem Nobody Talks About

AI products are converging on a memory layer. ChatGPT has memories. Claude has projects with files. Cowork has a workspace folder. Every agent product I've shipped or used has some equivalent — files the model can read, files the model can write, files the user edits.

The moment two writers share a file, you have a coordination problem. In AI, the writers are the model and the user. They overwrite each other. The model writes confidently, the user corrects, the model overwrites the correction in the next run, the user gives up and copies the file out to a Google Doc where the model can't touch it.

This isn't a bug. It's the predictable outcome of shared mutable state without provenance. Every distributed system that ever shared mutable state hit the same wall and solved it the same way: attribute every change, retain every version, make merges explicit. This is what file systems with version history do. It's what databases with audit logs do. It's what git does for source code. It's the discipline AI memory needs and almost nobody has built.

The Three Disciplines Git Brought To Source Code

Before git, source control was a coordination problem. Files got overwritten. Branches diverged silently. Authorship was ambiguous. The fix wasn't better commit UI. It was three architectural choices:

Content-addressed storage. Every blob of content is keyed by its hash. Identical content reuses storage. Different content gets a different identifier. This makes deduplication automatic and equality cheap.

Parent-pointed revisions. Every commit knows its parent. The chain is walkable. You can always reconstruct any prior state from the chain.

Required authorship. Every commit has an author. Anonymous commits don't exist. Provenance is structural, not optional.

These three together gave source code the trust model that allowed every modern collaboration pattern — branches, pull requests, blame, bisect — to exist downstream. They are the load-bearing primitives.

The Authored Substrate applies the same three to AI memory.

What Authored Substrate Looks Like In Practice

In our system, every file in every workspace is backed by:

A blob table. Content-addressed by sha256. A blob is immutable. Identical content (an empty markdown file, a default template) deduplicates to one blob shared across workspaces.

A revision chain. Every mutation produces a new revision row with a parent_version_id pointing to the previous one. Required fields: authored_by (who wrote this), message (why), created_at (when). The current state of any file is the head of the chain.

A required write path. There is one function in the codebase that mutates file content: write_revision(). It takes the path, the new content, the author identity, and the message. It hashes, dedupes, links to parent, writes. Every call site goes through it. There is no "just update the file" path.

The author identity is a typed taxonomy: operator (the human user), yarnnn:<model> (the chat orchestration), agent:<slug> (a specific agent), specialist:<role> (a production role like analyst or writer), reviewer:<identity> (the judgment seat), system:<actor> (kernel-level writes like initialization or cleanup). Every revision belongs to exactly one of these.

Once this exists, downstream patterns become obvious. The cockpit can show "edited 6 hours ago by yarnnn:claude-sonnet-4-5" next to any file. The reviewer can read "this principle was authored by operator on 2026-04-23, last edited by ai:reviewer on 2026-05-01 with the message 'tightened threshold after week of paper losses'" and understand the trajectory. Conflicts surface as actual conflicts, not silent overwrites.

Why This Isn't "Just Add A History Tab"

A lot of products have shipped "version history" as a feature. Google Docs has it. Notion has it. Most AI products will eventually bolt it on. Version history as a feature doesn't solve the problem. Authored Substrate as a primitive does.

The difference: a history feature retroactively reconstructs what changed by diffing snapshots. It works fine when humans are the only writers and changes are infrequent. It breaks when an AI is making dozens of small edits per session, when multiple actors share the same file, when "who wrote this" needs to be a structural property the system reasons against.

Authored Substrate makes provenance structural. Every read of a file knows who wrote each line. The compact prompt context surfaces "files edited by ai:reviewer in the last 24 hours" as a one-liner. The reviewer agent reasons against "this principle was last touched by operator three days ago" and treats it differently than "this principle was last touched by another AI agent this morning." The system uses the provenance, because the provenance is data, not metadata.

What This Unlocks

A few patterns that the Authored Substrate makes possible:

Trustable AI edits. When the model writes to a memory file, the operator can see that the model wrote it, what message the model attached, and what the prior version looked like. The cost of the model writing freely drops because the operator can always undo.

Reviewable AI behavior. Over time, the operator can audit "every edit the AI reviewer has made to my principles file in the last month." Patterns surface. The AI gets better because its edits are inspectable.

Multi-actor coordination. When two AI agents and one human all share a file, the conflict pattern becomes visible. The operator can decide that certain files are operator-only, certain files are agent-write-allowed-with-review, certain files are append-only. The substrate enforces the policy.

Provenance-aware retrieval. When the model reads a memory file to inform a generation, it can know "this was authored by operator three weeks ago" vs "this was synthesized by an AI agent this morning" and weight accordingly.

Survival of mistakes. No mutation is destructive. Every prior state is recoverable. The fear that "the AI overwrote my notes" stops being a fear because the previous revision is still there.

What Most AI Products Do Instead

The current state of the art in AI memory is one of three patterns, none of which is Authored Substrate:

Last-write-wins flat files. The model writes, the file is overwritten, the prior version is gone. Most agent frameworks default to this. It's terrible but cheap to ship.

Append-only logs. Every change becomes a new entry in a log. The current state is "everything ever written." Eventually the log gets too long to reason about and becomes noise.

Snapshot-based history. The system periodically snapshots files. You can roll back to a snapshot. Provenance is missing — you know the state at a point in time but not who changed what between snapshots.

Authored Substrate combines the best of these: every mutation is retained (like the log), the current state is a single coherent file (like last-write-wins), and you can walk back through the history (like snapshots) — and on top of that, every revision is attributed.

Why This Matters For Trust

The trust problem in AI agents isn't really about model capability. It's about what happens when something goes wrong. If the agent makes an unattributed edit and the operator can't figure out what changed when, trust degrades to zero quickly. If every edit is attributed and every prior state is recoverable, trust survives mistakes.

This is the model that worked for human collaboration. Nobody trusts a coworker who edits shared documents anonymously and overwrites silently. Everyone trusts a coworker whose changes show up in the document history with their name and a note about why. The same model is what's required for AI agents to become trustworthy collaborators on shared memory.

The Authored Substrate is what makes that trust structural rather than aspirational.

Key Takeaways

• AI products that share memory between humans and models need git-style discipline, not "version history" as a feature.
• Three primitives: content-addressed storage, parent-pointed revisions, required authorship.
• Author identity is a typed taxonomy: operator, model, agent, specialist, reviewer, system.
• Every write goes through one function that requires the full attribution.
• This makes trustable AI edits, reviewable AI behavior, multi-actor coordination, and survival of mistakes possible.
• For the architecture this sits inside, read The Agent OS Is Real. For why this is the layer that compounds, read The 90-Day Moat.