Disclosure: we are the authors of NylonME. This is a piece of opinionated vendor content — but the judgment comes first, the product second, and every number is reproducible.
A Bet: Every Company Will Soon Have a Shared Memory Store
First, the bet we're placing:
Memory engines will retread the path of databases.
In the 1970s, data lived in departmental filing cabinets and personal computers, and everyone thought that was good enough. Then relational databases arrived, and enterprises discovered that data must be centrally managed, uniformly retrieved, and shared across the organization — today, no company says "we don't need a database."
In 2026, the memory engine is where the database was in 1975.
Why? Because AI is seeping into every job function. Customer service answers with AI, sales follows up with AI, programmers write code with AI, operators draft copy with AI. Every job function's collaboration with AI produces a steady stream of experience, knowledge, and data: what this customer truly cares about, why that proposal was rejected last time, who fell into this pit three months ago.
Where does all of this go today? Scattered across chat logs, personal notes, and the heads of employees who have already left. The know-how a company pays a fortune to accumulate every year is leaking away daily.
When every job function depends on AI, there is only one enterprise-grade answer: a shared, centralized memory store — every job function's AI assistant connects to it, experience deposits into it, and knowledge flows out of it. Just as today every business system connects to the same database cluster.
This is not a question of whether it will happen. It is a question of when.
But Here's the Reality: Almost Every Memory Engine Today Is a Personal Toy
We've surveyed nearly every public memory solution, and we've built one ourselves. So here's an impolite observation: the current memory-engine market is a "personal toy" market.
That doesn't mean the products are bad — as bolt-on memory for personal assistants, many are beautifully made. But put them in an enterprise scenario, and they're riddled with fatal gaps:
Performance gap. Most solutions are a Python stack gluing together general-purpose databases. Nobody dares publish write throughput; nobody dares stress-test latency. For a personal scenario, a few hundred writes a day is fine. For an enterprise scenario — hundreds of Agents across the company reading and writing concurrently — TPS and P99 latency are matters of life and death. Ask a vendor for benchmarks, and most will show you demo screenshots.
Architecture gap. The mainstream architecture assumes a single user: one pip package, one local SQLite file, one person's memory. No shared-service model, no multi-tenant isolation, no concurrent-write design. Two people writing memory at the same time can already break things — let alone two departments.
Dependency gap. Many solutions weld the LLM onto the critical path — LLM extraction for writes, LLM rewriting for reads. A hobbyist doesn't care; an enterprise does the math: every memory read/write across the company passes through an LLM, doubling latency and letting costs run away. And when the LLM provider hiccups, the entire company's memory system hiccups with it.
Data-sovereignty gap. The managed-cloud school is even more direct: your customer conversations and business experience flow to someone else's servers. For finance, healthcare, government, and legal industries, this is not a drawback — it's an instant veto.
One sentence to sum up the status quo: today's memory engines solve "let my AI assistant remember me"; enterprises need "let the whole organization's AI remember the organization." The difficulty of these two problems differs by an order of magnitude.
What an Enterprise-Grade Memory Engine Looks Like
Getting from "personal toy" to "enterprise infrastructure" means crossing four gates:
Gate 1: shared-service architecture. The memory engine must be an independent, networked service, connected by every business system the way a database is — not embedded in someone's Python process. API protocols (gRPC/REST), multi-language clients, and concurrent reads and writes from many people and many Agents are table stakes.
Gate 2: production-grade performance. Write throughput must carry the concurrent deposits of the whole company's Agents; query latency must be worthy of real-time conversation. A vendor should dare to publish both numbers — and dare to ship the reproduction scripts.
Gate 3: an org-level data model. Personal memory has only "me"; enterprise memory has "who": which employee, which project, which department does this experience belong to? How are permissions isolated? How does cross-department knowledge flow under authorization? How does Zhang San's lesson become a heads-up for Li Si's AI assistant at the start of a project? This requires native multi-tenant, multi-principal design.
Gate 4: knowledge freshness and hygiene. An enterprise memory store keeps growing; stale knowledge must sink naturally (a forgetting mechanism), and mutually contradictory experiences must be surfaced instead of silently coexisting (conflict detection). Otherwise, three years from now, your shared memory store is a giant landfill, and the AI gets more confused the more it queries.
Hold these four gates up against the products on the market, and most fall at the first one.
NylonME: An Engine Built for This Bet
Scene set — now for our product. NylonME was designed from day one under the assumption of "enterprise shared memory store." It's not a scaled-up personal toy; the architectural starting point is different:
Single binary, deployed as a service. A Rust kernel compiled into one executable; serve mode starts a gRPC service, and every Agent tool in the company (Claude Code, Codex, Cursor, Qoder — any client that speaks MCP or gRPC) connects directly. No Neo4j to babysit, no Qdrant to configure, zero external dependencies.
Performance we dare to publish. 12,494 TPS writes (WAL group commit, 32-way concurrency, fsync on); 3-hop graph query P50 = 3.6ms; vector retrieval Top-100 P50 = 0.67ms; 1M nodes + 10M edges steady-state at 720 MB. Every number ships with a benchmark script, open-sourced with the repo.
Org-level data model, natively. owner + tenant two-level isolation: namespaces by person, by project, by department — each stores its own, interoperating under authorization. The six-silk memory model (fact, relation, temporal, emotion, frequency, provenance) natively carries the metadata of "who, when, in what context."
Freshness and hygiene built in. Tension decays exponentially with time — experience nobody has touched for three months sinks naturally; experience referenced repeatedly rises to the front. Every new memory write runs automatic conflict detection: if sales just writes "Customer A's budget is unlimited," the system digs up the three-month-old "Customer A's budget is tightening" and puts the contradiction on the table, instead of letting the two memories fight silently.
Retrieval quality, measured at full scale. LoCoMo long-conversation benchmark recall@10 = 84.6%, on the full 10 sessions and 1,536 questions, evaluation scripts open-sourced. The dual-layer write architecture (raw-text layer + LLM abstract layer coexisting) gives precise recall and cross-session reasoning each their due — and we've fully published the experimental basis for this design.
The LLM is an enhancement, not a dependency. With an LLM endpoint configured, you get fact distillation, conflict detection, and session-level abstraction. Unplug the LLM, and the core read/write path keeps working. Your memory infrastructure should not grind to a halt because any single model vendor has an outage.
Full data sovereignty. Apache-2.0 open source, self-hosted, data written and stored entirely inside your own data center. Snapshot format, protocol, and evaluation scripts are all public — even if you stop using NylonME someday, your memory exports intact, and nobody can hold your organizational knowledge hostage.
We're Already Using It This Way Ourselves
Vendor content, so here's the receipts: we are the first user of this "shared memory store" pattern.
Our engine runs on an Ubuntu server in the LAN, and every dev tool in the team — Codex on Windows, VS Code, various scripts — connects to the same engine. Architecture decisions, benchmark data, and pitfall records are continuously woven in. Before a newcomer (new session, new tool) starts work, one resonate call hits historical records directly for questions like "what are the pitfalls of DeepSeek's reasoning model" or "why doesn't this project use RocksDB."
The pattern is proven: memory follows the organization — not any individual, not any tool, not any session. Switch IDEs, keep memory. Switch people, keep memory. Span months, keep memory.
This is what we believe every company will have three years from now.
Final Words
Databases solved the centralized management of enterprise data; memory engines will solve the centralized management of enterprise experience. The former took twenty years to become standard; with AI's acceleration, the latter may take only three.
On that day, every company will have two core assets: the data in its databases, and the experience in its memory store. The former tells you what happened; the latter tells you what to do next.
NylonME is the engine we built for that future, open-sourced at github.com/nylon-memory/NylonME, Apache-2.0. You can run it today — starting with letting your team share its first memory.
The standard part of three years from now can be installed today.
This is Part 8 of the NylonME technical blog series. Earlier parts: 01 Phase 1 benchmarks / 02 The memory engine is the core of the Agent / 03 The second half of AI / 04 vs TencentDB-Agent-Memory / 05 From 47 to 84, the full record / 06 Memory engine selection guide / 07 Two-minute integration with Agent tools. All performance figures are the authors' own measurements (Aug 2026); benchmarks and evaluation scripts are open-sourced with the repo.
Top comments (0)