Agent Memory Product: How We Built mem9 on TiDB Cloud

Millions of agent branches. One database. Join us at TiDB SCaiLE Europe - June 4, 2026.Register Now

Sign In<br>Start for Free

Start for Free

How We Built mem9: Lessons From Shipping Persistent Memory for AI Agents

2026-05-01<br>Product

Bosn Ma<br>Director of Engineering

Key Takeaways

mem9 started as a customer request in March 2026, not a roadmap. We shipped a prototype before we wrote a plan.

Agent memory is not a storage problem. It is an engineering problem at the intersection of ingestion, ranking, evaluation, and product judgment.

A memory API alone is not a product. People want to see, inspect, trust, and correct what an agent remembers.

mem9 runs on TiDB Cloud, the same substrate behind TiDB Cloud Zero.

In early March 2026, a customer asked us for something that sounded simple and turned out to be one of the hardest problems in the agent stack: Make agents remember.

We did not start with a polished roadmap, a heavyweight architecture review, or a six-month product plan. We started the way many products do: With a concrete user pain, a rough prototype, and a very short distance between “this is interesting” and “we need to ship this.”

That was the beginning of mem9.

Looking back now, mem9 feels less like a conventional software project and more like a compressed startup year. What began as a fast customer-driven prototype quickly became a product, then a platform, and then a much deeper exploration of what agent memory actually requires in production. The visible features changed quickly, but the core question stayed the same. How do you help an agent remember what matters, without overwhelming it with everything else?

This is what we have learned so far.

It Started With a Real Problem, Not a Market Thesis

The real beginning of mem9 was not a category map or a strategy deck. It was a customer asking a practical question. If an agent could keep durable memory across sessions, would the user actually feel the difference?

We believed the answer might be yes, but belief was not enough. We needed to make the value obvious, fast.

So we took the shortest path to proof. We built a rough but convincing version, put it in front of a customer, and watched for the reaction. That prototype did exactly what it needed to do. It made the value legible. Once people could see an agent remember something it would normally forget, the conversation changed immediately. We were no longer talking about an interesting capability. We were talking about a product the market was ready for.

That early moment shaped everything that followed. mem9 has always felt like an agent-era product to us because it was born from workflow pain rather than abstract positioning. It was validated almost immediately, and once it was validated, the pace changed. The project stopped behaving like an experiment and started behaving like a startup.

In the first few days, we assembled the core of the system surprisingly quickly: A Go server, memory APIs, TiDB Cloud for storage, search, auth, rate limiting, and the first plugin integrations. Almost immediately after that, support expanded across agent environments such as OpenClaw, OpenCode, and Claude Code, while onboarding improved, multi-tenant foundations landed, and the first mem9.ai site went live. We were not following a neat sequence from infra to product to growth. In reality, all of those tracks were moving at once, because once the value was obvious, hesitation became more expensive than momentum.

Memory Is Not a Storage Feature

Early on, one thing became clear: We were not trying to build “a vector database for agents.” We were trying to build memory that actually improves agent behavior.

That is a small change in framing with very large architectural consequences.

A lot of discussions about agent memory still frame the problem as storage plus retrieval. In practice, that framing is too shallow. The hard part is not whether information can be stored. The hard part is whether the right information comes back at the right time, in the right amount, under real production constraints.

Too little recall and the agent forgets the one detail that matters. Too much recall and the context gets polluted with irrelevant baggage. If recall becomes noisy as the memory corpus grows, trust disappears. So the challenge is not persistence by itself. The challenge is precision.

That insight pushed mem9 very quickly beyond a basic memory store. What started as durable memory soon became a more opinionated system for ingestion, extraction, reconciliation, ranking, and retrieval. We moved toward a server-centric architecture because we wanted integrations to stay thin while the memory logic could evolve centrally. That decision mattered. It let us improve behavior at the core instead of pushing complexity into every plugin or runtime.

This is the part of the category that we think is still underestimated. Memory quality is not mainly a...