From the team behind aidrop.it — one workspace to build, host, and keep changing your code.
Your AI's memory should work like git, not like a notepad. Facts change — a rate goes up, a client leaves, a decision gets reversed — and a memory that only stores the latest value can't tell you what changed, when, or why. Versioned memory keeps the history: every fact is a tracked edit you can diff, attribute, and roll back. That's what turns a pile of notes into a memory you can trust over years.
Without versioning, two failure modes appear: stale facts overwrite true ones with no trace, and a bad write (or a poisoned one) is invisible because there's nothing to compare against.
Why static memory breaks over time
A static store holds one value per fact and overwrites on update. That's fine until a fact changes — then you lose the prior state, and you can't see whether the change was right. "We deploy on Fridays" becomes "we deploy daily" with no record that the policy shifted in March, or who decided it. Memory that can't track change slowly drifts out of sync with reality.
Facts have history, not just values
Most knowledge worth storing is temporal: it was true, then it wasn't, and when it changed is itself information. A versioned memory treats each fact as a series of edits, not a single cell. You can ask not only "what's our current pricing?" but "when did it change, and what was it before?" — the difference between a database row and a decision log.
What versioning gives you
Three things a notepad can't. Auditability — every change has an author and a timestamp. Reversibility — a wrong or malicious write rolls back to the last good state. Traceability — you see how a decision evolved, not just its final form. Together these make memory safe to trust, which is the whole point of persisting it. It's the missing layer behind why file-based memory caps out: a flat file has no history.
Curation needs a merge step
Versioning pairs with curation. New observations shouldn't append blindly — they should be merged into existing pages, the way a commit folds changes into a file. This keeps memory dense instead of long, and keeps a single canonical answer per fact while preserving how it got there.
Why this matters for an AI twin
The value of an AI twin is accumulated judgment, and judgment evolves. Versioned memory lets your agent reason over not just what you believe now but how your thinking changed — which standards you tightened, which bets you reversed. A memory with history is an asset that appreciates; one that overwrites itself is just a snapshot that's always slightly wrong.
Where to start
You don't need to model temporal graphs by hand — you need a store that keeps history instead of overwriting. When you save a fact, prefer a memory that records the change rather than replacing the value, so you can always answer "since when?" and undo a bad edit. The same history that keeps memory accurate is what makes it auditable.
FAQ
Why does AI memory need versioning? Because facts change. A store that only keeps the latest value can't show what changed, when, or why — and can't roll back a wrong or malicious write. Versioning turns memory into an auditable, reversible record instead of a fragile snapshot.
What's the difference between versioned memory and a vector database? A vector DB retrieves the current chunk; it doesn't track how that chunk changed over time. Versioned memory keeps each fact's edit history, so you get auditability and rollback on top of retrieval.
Isn't keeping all that history wasteful? History is cheap and the alternative is expensive: silent drift and unrecoverable bad writes. Curation keeps the current view dense by merging updates, while the version log preserves how you got there.
One workspace to build, host, and keep changing your code
The repository, what the project knows, the rules a change has to follow, and the path to an address — kept together, and reachable by the coding agent your team already uses.