Your AI bot should remember like Git — designing persistent, Git-backed memory for personal agents

Most AI assistants have a memory problem that has nothing to do with model quality:

• You can't see what they remember.
• You can't fix it when it's wrong.
• You can't roll it back when an update makes it worse.
• You definitely can't diff it.

We ran into this while building personal agent bots — bots that live with you for months, develop a role (researcher, writer, engineer), chat in your group channels, and run scheduled jobs while you're away. For a bot like that, "memory" isn't a nice-to-have embedding trick. It's the bot's long-term state, and long-term state deserves the same treatment we give source code: files you can read, history you can inspect, and versions you can restore.

So in DeepSeekBot — an open-source (MIT) Grok Bot alternative that runs as a plugin on DeepSeek Harness — each bot's memory is not a vector database or a hidden server-side profile. It's an ordinary Git repository.

This post is about why we did that, how it works in practice, and the trade-offs we'd warn you about if you copied the idea.

What "Git-backed memory" actually means

Each bot has its own memory working tree: plain files (Markdown) that hold what the bot knows about you, your projects, and its own role. As conversations happen, the bot updates those files. Because the memory is a Git repo, you get, for free:

• A working diff. Uncommitted memory changes are grouped (new memories vs. updates to existing ones) and shown as diffs you can read before they're part of the bot's history — in the same way you'd review a pull request.
• A commit history. Every memory change lands as a commit. You can click any commit and see exactly which files changed and how, and load older history as far back as the bot has existed.
• Branches. A branch is an alternate line of how the bot's memory evolves. You can branch from an older commit ("from here, remember things differently") without destroying what came after on the original branch.
• Named versions. Any commit can be given a human-readable name, stored as a Git tag — "the draft before the big tidy-up" — so the restore points that matter are findable months later, not buried in a hash list.
• Restore. You can restore the memory to the state of any earlier commit. If there's uncommitted work in the way, it's first saved as its own commit, so restoring never silently deletes anything.
• Automatic backups. Memory changes, the end of a conversation, and any restore operation all trigger a backup, including uncommitted files.

And the most practical consequence: push the memory repo to GitHub, and the same bot — same identity, same memory — can live on more than one machine. Clone it at the office and at home, and it's the same colleague in both places.

Why not just embeddings?

Embeddings are great for recall ("find the snippet about X"). They're bad at accountability.

Question a user actually asks	Vector store	Git repo of files
"What do you remember about me?"	Nothing inspectable	Open the files and read
"That's wrong, fix it."	Re-embed and hope	Edit the file, commit
"You were better last week. Go back."	Not really possible	Restore a tagged commit
"Why do you think that?"	Opaque similarity	A diff, with a date
"Move my bot to another PC."	Export/import tooling	git push / git clone

We still think semantic recall has its place for retrieval inside a conversation. But the source of truth for a long-lived bot should be something a human can audit with tools they already trust. Developers already know how to review a diff; nobody knows how to review 4,096 floats.

The design rules this forced on us

Working with Git as the memory substrate imposed some useful discipline:

1. Memory writes are changes, not mutations. The bot doesn't silently rewrite its state; changes accumulate as reviewable diffs and commits. The UI literally separates "current uncommitted changes" from "committed history."

2. Human overrides are first-class. Because memory is files, a user correction is just an edit. The bot can be wrong and be fixed, not argued with.

3. Every escape hatch gets a safety net. Restore is scary, so restore itself is a commit, pre-restore state is auto-committed, and full-folder backups happen before a backup-restore. You can be bold with history when going back is itself safe.

4. Vocabulary matters. In the product UI, most people never see raw Git terms — changes are grouped as "new memory" vs "memory updates," and only if you flip a setting do the labels switch to unstaged/staged/untracked. Same repo, two mental models.

The honest trade-offs

• Your host has to be awake. DeepSeekBot runs on your own machine via DeepSeek Harness; if the computer is off, your bots aren't working. Git memory doesn't solve availability — it solves trust.
• Remote models still see context. Memory lives on your host, but when a bot calls a remote model provider (you configure your own in Harness — it's not DeepSeek-only), the relevant context goes to that provider. Local memory is not the same as local inference.
• Files don't scale infinitely. A bot that remembers everything forever will accumulate a big repo. Named versions, branches, and the occasional human tidy-up are features of the model, not afterthoughts — but you do have to design for pruning.
• Non-technical users meet Git concepts. Most never need them, and the UI hides them — but power users asking for "undo for memory" are really asking for Git whether they know it or not.

Try it / steal the idea

DeepSeekBot is MIT-licensed and installable from the DeepSeek Harness desktop app (Plugins → Add plugin → deepseekbot@1.4.1):

• GitHub: https://github.com/BotHarness/DeepSeekBot
• Product & docs: https://deepseekbot.app/en/

Each bot also has its own identity and persona, can be @-mentioned in group chats with other bots, can be reached in Slack, Discord, Feishu/Lark, QQ and WeChat, and can create its own scheduled tasks ("every morning at 9, send me a log digest" is a sentence, not a settings page). But honestly, the piece we'd most like other agent builders to copy is the boring one:

State you can diff is state you can trust.

If you're building agents with long-term memory — Git-backed or not — I'd love to hear how you're handling inspection, correction, and rollback in the comments.