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:

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.

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:

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.

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

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.

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

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."

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.

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.

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.

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

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.