A File System Your AI Writes Into, Under Its Own Name

Persistent storage for AI work is table stakes now. Several tools keep your files between sessions, organise them into folders, and search them by meaning. They do it well. The distinguishing word is not persistent. It is signed.

This post is about the difference, because from a feature list the two look identical and they are not the same object.

What does a persistence layer give you?

A real answer to a real complaint. Chat interfaces forget; a persistence layer does not. Your uploads, the AI's outputs, the artifacts of a workflow — all of it survives the conversation that produced it, in a structure you can browse.

That is genuinely valuable, and it is the direction the whole category is moving. If a tool cannot do this in 2026 it is behind.

It answers one question well: where did my work go?

What does it still not answer?

Three others, and they are the ones that bite on anything more than one person touches:

• Who made this?
• What was it made from?
• What did the other AI change?

A single-vendor persistence layer is structurally unable to answer these, for the reason covered in part one: it sees one principal and one vendor. It knows what it did. It has no view of your co-founder's edit, or of what a different assistant changed on the same file.

A folder tells you where the work is. It does not tell you whether to trust it. And on a document that more than one person and more than one model has touched, trust is the only question that matters.

It is worth being precise about the second question too. Most storage layers keep files. Very few keep the edge — the fact that this brief was made from that transcript and those three sources. Without that edge, every derived document arrives as an orphan, and deleting a source silently guts the things built on it.

What a signed write adds

Same folders. Same search. One addition: every write carries a name, and every version is kept.

That single addition changes what the file system is. It stops being storage and becomes a record:

	Persistence layer	Signed record
Survives the session	yes	yes
Searchable by meaning	yes	yes
Who wrote each version	the vendor's own AI, implicitly	every principal, explicitly — you, a teammate, ChatGPT, an agent
Full revision chain	usually latest-state	every version kept and walkable
What a file was made from	not modelled	recorded as a derivation edge
Foreign AI writes	out of scope	first-class, and labelled

The rightmost column is not a longer feature list. It is the difference between a place your work sits and an account of how your work got that way.

Why versioning without attribution isn't enough

This is the subtle one, and it is where most "we have version history" claims quietly fail.

Version history was invented for code, and for code it works because the build is the oracle. Two developers can diverge wildly; the compiler and the test suite reconverge them, and anything that does not reconverge fails loudly. Attribution in Git is a convenience — useful for blame, not load-bearing for correctness.

Knowledge work has no compiler. Nothing mechanically verifies that a brief still says what was decided. A fork of a document does not fail to build; it just becomes a second plausible version, and both survive. So the thing that has to carry the trust is not a build result. It is the record of who changed what, and why.

That inverts the priority. In code, attribution is metadata attached to a history. In knowledge work, attribution is the history — strip it out and what remains is a stack of undated plausible drafts.

Which is why "we keep versions" is not the same claim as "every version has an author", and why a tool can honestly say the first while being unable, structurally, to offer the second.

The test to run

Open the file you would least like to be wrong about. Ask your tool: who last changed this, and what did they change?

If the answer requires you to remember, the file system is storage. If the answer is on the screen, with a name on it, it is a record.

---

Part three of Inside the workspace. Next: why the record outlasts the model.