Git for Memory: Why We Built Version Control for AI Agents

While everyone is rushing to integrate AI into their apps, and investors flock to fund projects using agents, there's one specific problem which made its way into YC's top startup ideas this year: data management for companies. Businesses hold structured and unstructured data; messy, fragmented pieces held across the cloud, desperate to consolidate them into one centralised platform.

Yet, the reality of implementing something to this level is not as easy as it may seem. As one tries to implement a RAG system for a business, some key questions come up. How can this data be organised? How does the agent access this information? And most crucially, how can it remember everything? Just getting an agent to remember emails is one thing, but what about when you have 500 financial reports with nearly all the same content and tiny changes which take analysts entire days to get through?

Developers have hit what we call the scaling wall. Even the best LLMs score relatively poorly on the top benchmarks for RAG, mainly because they rely heavily on semantic search, which reaches its limit fast. Semantic search can work for some use cases, but when numbers, complex data, or different structural data comes into play, it becomes much harder. When a new piece of data comes in, standard RAG just stores it as a number. That number is compared with other numbers, and magically, something that feels kind of similar to the original query pops out. A greatly oversimplified explanation, but the point still stands. What happens when you start developing something in Python, and then change to Rust? The AI loses the context. Much like chopping a book into pages and mixing them up, it becomes impossible to piece together the narrative. These questions and limitations are the reason we decided to build a version of Git, but for memory.

Twenty years ago, software had the same problem. You'd save a file and overwrite the previous version. Bug appears? Good luck figuring out what changed.

Then Git happened. Deterministic history. Diffs. Rollback. Blame.

We applied the same principle to AI memory. Structured, temporally aware agent memory which can pull information from company data and from its own conversations, without losing the thread. Many memory-as-a-service companies hide their graph features behind hundreds of dollars in paywalls, but we believed there is a way to develop this type of infrastructure while giving everyone access to graph memory.

How Zymemory Versions Context

When you send a conversation to Zymemory, we don't just embed and forget. We treat the memory graph like a repo.

HEAD state

When a user says "Actually, I'm switching to AWS," we don't store both "uses GCP" and "uses AWS" and hope for the best. We create a new version, mark it HEAD, and the old fact becomes history - queryable, but not active.

Time-travel debugging

Agent giving wrong answers? Open the dashboard. See exactly which conversation mutated which memory node, and when. No more grepping through JSON logs.

Audit trail

For regulated industries, healthcare, legal, finance, you need to prove what the AI knew at decision time. Every version is AES-256 encrypted.

The Dashboard

This isn't theoretical. You can see it:

Click any version. See what changed. Revert if needed.

Three Lines

pip install zymemory

from zymemory import ZymemoryClient

client = ZymemoryClient(api_key="your-key", org_email="org@example.com")
client.store_conversation(user_input, assistant_output)

The versioning happens automatically. You don't manage it. The engine handles supersession, branching, and HEAD resolution.

Or Run It Yourself

We open-sourced the core. Pull zymemoryfree from GitHub, run it with Docker and Ollama, keep everything local. No cloud dependency.

AI is chaotic. Memory doesn't have to be.