MemKraft is an integrated memory system for AI agents that I started building out of my own need. It gets smarter on its own the more you talk to it. Two days ago, I posted my v0.1 dev notes.

Since launch, there have been four more updates. For each version, I give the agents a few specific keywords and a direction. The research agent reviews earlier projects on the topic, the planning agent sets the design direction, and the development agent implements it. From there, they ran a dozen or so iterations per version on their own, debugging across various scenarios and handling deployment too.

Figure 01Source Telegram #146

Just a year ago, a project like this would probably have taken at least a few months of full-time work. All I did was exchange a few dozen chats with Zeon in spare moments during work or while on the move. It is hard to even imagine how different the development environment will be a year from now.

Here are the key ideas for each version.

--

v0.2: Same question, different answers

When someone asks, "What did you eat yesterday?" we don't match keywords like Google. We first recall what kind of day yesterday was and who we were with. The answer surfaces within that context. This observation was the starting point for v0.2. Even for the same question, the memories that matter should change depending on what I'm doing now. So I borrowed an idea called Conway SMS. When a search request comes in, the system weights the current goals, changing the ranking of the same facts. Just as textbook material comes to mind first during exams, and restaurant recommendations come first when traveling.

I gave memories types. Who I am, what I believe, what I've experienced. I divided them into eight types, not for the sake of classification, but because each fades at a different rate. I still remember my name after ten years, but this morning's routine will be hazy by next week. I gave each type a different half-life on its decay curve. Simply distinguishing between what fades slowly and what fades quickly changed the texture of memory.

Then there was the problem of contradiction. When people believe "A is right" and encounter evidence that "B is right," they feel confused, but they still compare the two and make a judgment. MemKraft needed to do the same. It compares the similarity of two facts. If they are nearly identical but reach different conclusions, it automatically adds them to a conflict list. I called it dialectics, but in practice it is closer to a notification saying, "These conflict. You decide." Tests went from 112 to 158.

v0.3: Memory grows stronger with use

Memory doesn't wear out with use. It grows stronger. Facts we recall often become clearer and connect to more contexts. But something was missing from a system where retrieval only consumed memories. So I added a feedback loop. Each search increases the access count for the relevant fact and automatically enriches its context. The act of searching itself makes future searches richer. Like compound interest in a bank, the difference is small at first, but over time the gap widens between facts that are used often and those that aren't.

I added another dimension: confidence. Is this a confirmed fact, an experimental observation, or just a hypothesis? I also attached conditions for when it applies. Things like, "This memory is only valid for Python projects." Giving memories context reduced the chances of the wrong memory surfacing in the wrong situation. I also introduced the idea of a health check. It periodically checks for facts without sources, orphan facts with no relationships, and facts that haven't been organized in over a week. It is like sorting through receipts that keep piling up in a drawer.

The implementation was surprisingly simple. It started with adding a single feedback flag to the search function. As it returns results, it also updates the metadata. When the fact was accessed, in what context, and how many times. Each of the five health checks is an independent check function. If all pass, everything is clean. If even one flags something, it produces a report. 198 tests.

v0.4: Why debug the same bug twice?

Think about the debugging process. Most of it happens in your head, and once the problem is solved, it gets compressed into a single line in a commit message. Hypotheses you tried that failed, reasons you rejected them, incidental observations along the way—all disappear. The next time you encounter similar symptoms, you start over. The idea that "debugging is memory" was an answer to this waste. The entire flow—starting a debug session, forming hypotheses, gathering evidence, and rejecting or confirming them—is recorded in the memory system.

Rejected hypotheses were especially important. A record that says "It wasn't this" can tell the next person heading down the same path, "We've already been there. It's a dead end." It is like maintaining a list of differential diagnoses in medicine. Accumulating knowledge that says, "With these symptoms, it isn't this." Rejected hypotheses are indexed separately for retrieval, serving as an anti-pattern library. If hypotheses fail twice in a row, a notification also asks, "Could the direction itself be wrong?" Tests grew from 198 to 277, the biggest jump across the four versions.

v0.5: Every memory snapshot needs git

"What I know now" matters, but sometimes "what I knew a week ago" and "what changed in between" matter more. Just as code has git, memory needed version control. Only at v0.5 did I find the last missing piece.

A snapshot freezes the entire memory at a particular moment. A diff shows what was added, deleted, and changed between two points in time. Time travel lets you run searches against a past memory state. A system that can answer, "What did I know about this project as of three days ago?" It is like opening an old diary and looking back: "So that's how I thought about this then."

328 tests, still zero external dependencies. As I dug deeper into memory, it turned out to be a question of time. It had to understand context, grow stronger with use, record failures, and be able to look back at the past. Only at v0.5 did MemKraft become able to handle time.

--

Existing agent memory systems each have different strengths. Decay-based, graph-based, vector-search-based, session-summary-based. MemKraft is an attempt to absorb those concepts into a single system with as little conflict as possible. There is still a way to go, but the direction is clear.

MIT license, forever. Use it however you like. Stars, forks, and PRs are all welcome!

seojoonkim/memkraftUltimate zero-dependency compound knowledge system for AI agents. Auto-extract, classify, search, and maintain memory in plain Markdown.GitHub · github.comOpen