DEV Community: Michael Deng

The Enterprise Coming-of-Age of a Memory Engine: Multi-Tenancy, Auth, Audit, and Backup Drills

Michael Deng — Tue, 08 Sep 2026 08:32:17 +0000

Every feature described here is live in production (on our own servers). Commits: 8e9a83c / 138c663 / cbf9958, verifiable in the public repo.

The Flag We Planted Two Weeks Ago, Delivered

In post #8 of this series we said something harsh: most memory engines on the market are personal toys, and to cross into enterprise territory you have to pass four gates — shared-service architecture, production-grade performance, an org-level data model, and freshness and governance of knowledge.

At the time we had cleared the first two (single-binary gRPC service, 12,494 TPS); the last two were still predictions. Over the past two weeks we built the remaining gates: enforced multi-tenant isolation, three-tier API key authentication, an audit event stream, and periodic checkpoints with backup drills — all shipped and deployed on our own production servers.

As usual, this post is not a feature list. It covers how the four things were done, and two problems we discovered along the way that sent a chill down our spines.

Multi-Tenant Isolation: Starting from a Real Leak

In enterprise settings, one memory store serves multiple departments and multiple projects. Isolation is not "stored separately in principle" — isolation must be enforced on every single retrieval path.

While building L2.1 we found a real leak: the HNSW global vector index does not filter by tenant. Vector seeds and Search RPCs queried the global index directly and only filtered by owner/tenant afterwards. Which means a query vector from tenant A was effectively running similarity computations over tenant B data. The results would be filtered after the fact, but "over-fetch 4x and filter" already exposes the retrieval space to a query that should never see it.

The fix makes every seed channel (vector, lexical, task, recent-fallback) filter by tenant+owner at the source, with a second tenant guardrail on the final results. Cross-tenant GetNode simply returns 404 — not even "does this node exist" is exposed, because existence itself is information.

A related piece done along the way: a zero-migration data format upgrade. The persistence format moved from NYL0 to NYL1 (nodes now carry tenant_id), and old data is backfilled with the default tenant automatically at decode time. 70 nodes and 63 edges in production migrated on restart without losing a single one.

Three-Tier API Keys: Security Must Not Be a Breaking Change

The biggest enemy of an authentication system is not attackers — it is existing users. If turning on auth requires every client to change its config, auth will never get rolled out.

Our design has three tiers of keys: read / write / admin, each key bound to a tenant (admin can use the wildcard *). But the most important switch is this: without NYLON_API_KEYS configured, the engine runs in open mode, behaving exactly as before. Our own Qoder and Codex clients noticed nothing after the server upgrade — the security capability was in place, and nobody was forced to change configs on a Friday night.

One implementation detail worth mentioning: on the gRPC side, authentication happens in an x-api-key interceptor, but tier checks live in the handlers — because tonic Requests carry no URI, the interceptor does not know which method you are calling. It can only establish who you are; each handler then decides whether who you are qualifies you for what you are trying to do. On the HTTP side, both x-api-key and Bearer are accepted. The MCP bridge and CLI pass NYLON_API_KEY through, so clients add exactly one variable. We also added a genkey subcommand that mints a new key in one line.

The Audit Event Stream: Who Touched Which Memory, When

Among the questions enterprise customers ask about a memory system, one of the most frequent is: "If something goes wrong, can I look it up?"

L2.3 answers with audit.jsonl, an append-only audit file in the data directory. Weave, WeaveSession, Resonate, Search, and DeleteNode are all instrumented — even auth rejections leave a trace. Whoever probed what with a wrong key is one query away.

Two engineering decisions:

Audit writes never do disk IO on the request path. Events go to a background writer thread, so RPC paths carry zero disk overhead. A 5,000-entry in-memory ring buffer serves fast queries, preloaded from the tail of the file at startup, so the audit page is not blank after a restart.
Tenant isolation extends to the audit log itself. A tenant-bound key calling GET /v1/audit sees only its own tenant events — audit logs are not the administrator private property, and they must not become a cross-tenant information channel.

The web console gained an audit tab (bilingual, Chinese and English) with filtering by operation type and relative timestamps. NYLON_AUDIT=off disables it entirely.

Backup Drills: We Found Our Production Engine Had Never Checkpointed

This is the most important thing from the past two weeks — not because of technical difficulty, but because it nearly went undiscovered.

Our persistence is WAL (write-ahead log) + snapshots (checkpoints). By design, a checkpoint freezes the in-memory graph into graph.snp and truncates the WAL, so restarts replay fast and hot backups have a clean baseline. L2.4 added periodic triggering (NYLON_CHECKPOINT_SECS, default 600 seconds) and manual triggering (POST /v1/checkpoint, admin tier).

Then we ran a drill following our newly written Backup and Restore Manual (docs/BACKUP_RESTORE.md): copy production data to a replica instance, start it, compare stats.

The drill exposed a fact: until that moment, the production engine had never triggered a single checkpoint. It had been running naked on the WAL the whole time — no data loss, but the WAL growing without bound, restart replays getting slower and slower, and no baseline for hot backups. Without this drill, the problem would have stayed dormant until it exploded during a real recovery.

Drill results: the replica instance came up fully consistent with production (70 nodes / 63 edges), the first checkpoint wrote graph.snp to disk successfully (313 KB), and the WAL truncated to zero.

This deserves a sentence of its own: a backup plan that has never been drilled equals no backup at all. Every company operations manual has a backup procedure; the only difference is whether you have actually restored something once.

For Kubernetes users we prepared a Helm chart (helm/nylonme): single-writer Deployment + PVC + Service + Secret, with optional embedded ollama that pulls the embedding model automatically after install.

Meanwhile: One More Piece of the Ecosystem Puzzle

In the same batch of work, the LangChain and LlamaIndex adapters were completed and published to PyPI (nylonme-integrations): on the LangChain side, invoke returns standard Documents; on the LlamaIndex side, retrieve returns NodeWithScore. Both verified against the production engine. If your agent is built on either framework, you no longer need to configure MCP at all — pip install and attach.

In Closing

Two weeks ago we wrote that "four gates stand between a toy and infrastructure." Now we can say it more precisely:

The difference between a toy and infrastructure is not in the feature list — it is whether you dare to entrust it with company data.

Whether you dare depends on four things: can it see other people data (multi-tenancy), do you recognize who comes in (authentication), can you look things up when something goes wrong (audit), and can you recover when the worst happens (backup). Two weeks ago the answer to these four questions was "planned." Now it is "running in production."

The memory engine coming-of-age ceremony is over. Next up is the deep water of enterprise adoption: high availability, horizontal scaling, and the continuous evolution of memory quality itself.

NylonME is open source at github.com/nylon-memory/NylonME, Apache-2.0. All features described here are on the main branch; the backup manual is at docs/BACKUP_RESTORE.md.

This is post #10 in the NylonME technical blog series. Previous posts: 01 Phase 1 benchmark / 02 The Memory Engine Is the Core of AI Agents / 03 The Second Half of AI / 04 vs TencentDB-Agent-Memory / 05 From 47 to 84, the Full Record / 06 Choosing an Agent Memory Engine / 07 Two-Minute Agent Integration / 08 Memory Engines, the Next Database / 09 Async Reflection.

Teaching a Memory Engine to Sleep: Async Reflection Pushes LoCoMo to 85.3%

Michael Deng — Tue, 08 Sep 2026 08:28:58 +0000

All numbers in this post come from reproducible evaluation scripts. Protocol: full LoCoMo benchmark, 10 sessions, 1536 answerable QA pairs, recall@10. Public repo at commit ad04fb2.

The Human Brain Does Not Organize Memories While Awake

Here is a well-known fact from neuroscience: memory consolidation happens during sleep. Events from the day are first stored in raw form in the hippocampus; once you fall asleep, the brain starts "replaying" them — connecting isolated fragments of experience and stitching them into the existing network of knowledge. When you wake up feeling that you "figured it out," it is actually your brain doing the work for you overnight.

Mainstream memory engines have no such mechanism. Write is the end; retrieval is everything — from the moment a memory hits disk, it is dead, waiting to be looked up.

Last week we installed this "sleep module" in NylonME. Internally it is called Async Reflection. The result: full-benchmark LoCoMo recall@10 went from 84.6% to 85.3%, and the hardest category — commonsense reasoning (Cat3) — reached its all-time best of 60.9%.

This post explains three things: why Cat3 needs a new mechanism, how async reflection works, and which two paths we tried that turned out to be wrong.

First, the Medical Record: Why Cat3 Is the Last Weak Spot

Our LoCoMo scores have climbed steadily, but Cat3 (commonsense reasoning) has always been the weakest of the four categories. In the run that hit 84.2% overall, Cat1 was 80.5, Cat2 86.6, Cat4 88.0 — and Cat3 only 53.3.

The cause lies in the nature of Cat3 questions. A typical example:

The dialogue says "she quit coffee after getting pregnant," and another segment says "she ordered a decaf americano yesterday." Question: "Why does she not drink regular coffee now?"

The answer requires a piece of knowledge nobody ever said out loud: pregnant women should avoid caffeine. That sentence is not in the dialogue. No retrieval technique — lexical, vector, or graph diffusion — can find an answer in words that were never spoken. No matter how strong the retrieval system is, it cannot retrieve a bridge that does not exist in the corpus.

This is not a retrieval problem. It is a knowledge gap problem. Either give up, or make the engine build the bridge itself.

Async Reflection: Consolidating Memories During Idle Time

We chose the second option, with one strict engineering constraint: bridge-building is heavy work and must never sit on the write path.

That gave us the full async reflection pipeline:

WeaveSession writes session facts
    → reflection task enters the queue (occupies no request thread)
    → engine idle for 10 minutes (NYLON_REFLECT_IDLE_SECS=600)
    → background task starts: LLM distills 1-3 neutral commonsense facts from the session
    → each fact becomes a special node, linked to every fact of that session

A concrete example: for a dialogue, the LLM distilled bridge nodes like "pregnant women should generally avoid caffeine" or "people on business trips usually value window seats" — neutral, self-contained world knowledge that contains no private information.

These nodes have three special design properties in the graph:

Tagged __world_knowledge__: they exist as an intermediate layer for graph diffusion and never enter the final recall results themselves — a bridge is for walking on, not for looking at.
Low confidence, low tension, slow decay: confidence 0.6, tension 0.6, decay rate 0.01 — they are auxiliary structure and should never overpower real memories.
Edges of weight 0.8 to the whole fact bundle: stronger than auto-built edges (0.5), weaker than explicit inter-layer edges (1.0) — enough to conduct activation, not enough to steal the show.

At retrieval time, two previously isolated fact nodes ("quit coffee," "decaf americano") are now connected through a shared commonsense bridge node. A Cat3 question activates one of them as a seed; diffusion travels across the bridge to the other, and the context is complete.

Why must it be async? Because LLM distillation is slow and expensive. Put it on the synchronous write path and write latency doubles, while handing LLM providers a hand around your throat. And reflection is not urgent by nature — consolidation happens offline, not at the moment of experience. Let the engine think slowly when it is idle, and hang the results up when they are ready. This continues our old principle: the LLM is an enhancement, not a dependency; if the LLM goes down, the engine keeps reading and writing.

The Data: 85.3%, and One Piece of Key Evidence

Full benchmark: 10 sessions, 1536 questions, official results:

Category	Score
Cat1 multi-hop reasoning	84.8%
Cat2 temporal	86.6%
Cat3 commonsense reasoning	60.9% (previous best 59.8%)
Cat4 single-hop detail	87.6%
Overall recall@10	85.3% (1310/1536)

Beyond the numbers, there is a more interesting piece of evidence. In this experiment the seed recall for Cat3 was 64.1% — lower than the keyword-expansion scheme we had tried (66.3%) — yet the final recall ended up higher.

This shows the gain does not come from "finding more seeds." It comes from the graph structure itself after bridging: the seeds are the same seeds, but there are more places you can reach from a seed. Mechanism and data line up, which is why we dared to lock in this result.

(A pitfall worth recording: always probe the API once before running an LLM evaluation. When the DeepSeek account balance runs out it returns HTTP 402, session fact writes silently become +0, the whole benchmark score is void, and an hour of compute is wasted.)

Two Failed Paths, Worth Publishing Just the Same

The tradition of this series: the failure list is as long as the success list. After locking in 85.3%, we tried two "obviously better" directions. Both died:

Failure one: precise linking. Intuitively, a bridge should not link to every fact in a session — only the few it truly supports. We had the LLM output source_fact_indices for precise linking. Result: 85.1% overall, -0.2 total, Cat3 -2.2. Rejected. The lesson is counterintuitive: the value of a bridge comes from its connectivity. Narrowing the links narrows the bridge. Coarse linking is noisy, but it contributes more to reasoning.

Failure two: confidence-weighted edges. Weighting bridge edges by the confidence the LLM reports should, in theory, make "reliable bridges" louder. Quick 2-session test: 78.8%, no positive gain. Withdrawn.

After two rounds of failure, our judgment is: stop piling up prompt tricks and linking tricks. The next optimization surface is the quality of the bridge text itself (dedup, filtering out vacuous bridges — a "people have preferences" bridge is nonsense and must be blocked) and the trigger policy (switch from "reflect on every session" to "only reflect on sessions with high perplexity and low recall," saving LLM calls). These are already queued on the engine optimization branch.

The Full Picture Now

With async reflection, the NylonME memory lifecycle is complete:

At write time: LLM weaving and decomposition, six-thread structuring, dual-layer graph writes (raw text + abstracted facts)
At idle time: async reflection, LLM-built commonsense bridges, isolated facts stitched into a network
At retrieval time: dual seed channels → adaptive-depth diffusion (bridge nodes as intermediate layer) → tension scoring → vector reranking
Throughout: natural tension decay, conflict detection on write, automatic fallback if the LLM is absent from any step

From the 47.1% lexical baseline to 85.3% — every point of the 38-point gain has a controlled experiment and a public script behind it. All evaluation switches are environment-variable-driven (NYLON_WORLD_BRIDGES_ASYNC=1 reproduces this result), the code is at ad04fb2, and we welcome being proven wrong.

Cat3 at 60.9% is still a weak spot, and we do not intend to hide it. But the account of the direction is settled: what a memory system is missing is not stronger retrieval — it is the knowledge that retrieval cannot reach. And the way to fill it is to let the engine do the thinking for you while it sleeps.

The human brain spent hundreds of millions of years evolving sleep. The memory engine learned this lesson in one week.

NylonME is open source at github.com/nylon-memory/NylonME, Apache-2.0. pip install nylon-sdk is also live on PyPI.

This is post #9 in the NylonME technical blog series. Previous posts: 01 Phase 1 benchmark / 02 The Memory Engine Is the Core of AI Agents / 03 The Second Half of AI / 04 vs TencentDB-Agent-Memory / 05 From 47 to 84, the Full Record / 06 Choosing an Agent Memory Engine / 07 Two-Minute Agent Integration / 08 Memory Engines, the Next Database. Performance numbers are self-measured by the author (2026-08); evaluation scripts are open-sourced with the repo and reproducible.

The Memory Engine Will Become the Enterprise's Next Database

Michael Deng — Tue, 08 Sep 2026 08:15:15 +0000

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.

Choosing an Agent Memory Engine: A Six-Dimension Evaluation Framework

Michael Deng — Tue, 08 Sep 2026 08:04:29 +0000

Disclosure: we are the authors of NylonME. This is naturally a bit of "the seller praising their own melons" — but we will lay the evaluation framework, the measured data, and when you should NOT choose us all out on the table. The choice is yours; our job is to give you all the facts.

Think First: What Are You Paying For?

In 2026, building an Agent, the memory layer is no longer a "whether or not" question — it's a "which one" question. But most teams' selection process is a mess: read three vendor blogs, run one demo, and decide. Six months later, when memory volume grows and query types get complex, they discover the ceiling of their choice was right above their heads the whole time.

So before talking products, let's talk about the evaluation framework. Whether a memory engine is worth choosing comes down to six dimensions:

Memory model — how does it organize information? A flat list, tiered compression, or a graph network? This caps retrieval quality.
Retrieval quality — are there measured numbers on public benchmarks? Full-run basis? Reproducible?
LLM dependency — if the LLM goes down, times out, or raises prices, does your memory system still work?
Production performance — write throughput, query latency, resource footprint: can it carry real load?
Deployment and data sovereignty — can you self-host? Does data leave your data center?
Long-term risk — license, vendor lock-in, project sustainability.

Below, we walk through the mainstream options along these six dimensions, then state clearly where NylonME stands on each — including our weaknesses.

The Five Types of Solutions on the Market

As of August 2026, Agent memory solutions fall into roughly five schools:

Type 1: DIY RAG assembly. A vector database + prompt templates — shippable in two weeks. The problem is the ceiling arrives just as fast: no concept of time, no conflict detection, no forgetting mechanism. "The user said last week they don't eat spicy food; this week they can't live without it" — in such a system, those two memories fight forever. Fine for validation; not for production.

Type 2: Managed memory cloud services (Mem0, Zep, etc.). Fastest to integrate, friendly SDKs. The price is data leaving your domain — your users' conversations flow to someone else's servers, which is an instant veto for finance, healthcare, government, and legal scenarios. And under the high-frequency read/write patterns of Agent architectures, the metered pricing model deserves a careful look at the cost curve.

Type 3: Framework-builtin memory (Letta/MemGPT family). Memory is deeply bound to the framework — works out of the box. But choosing the framework means choosing the whole stack: if you ever want to switch LLM orchestration frameworks, the memory layer gets kidnapped along with it.

Type 4: The tiered-compression school (TencentDB-Agent-Memory as the representative). L0–L3 progressive compression; the token-saving is real, and pip install with zero dependencies is genuinely convenient. We analyzed the structural problems in detail in Part 4 of this series: compression is lossy, and letting the abstract layer replace the raw layer in retrieval loses details — in our own ablation, keeping only the abstract layer cost 3.4 recall points.

Type 5: The heavy academic stack (MemOS as the representative). Neo4j + Qdrant combo, theoretically complete — but deploying it means maintaining a graph database cluster plus a vector database cluster. Small teams, beware.

Where NylonME sits: the graph-network school — single binary, self-hosted, with all benchmark numbers published. Let's go dimension by dimension.

Dimension 1: Memory Model — the Cap Is Set by Structure

The ceiling of a flat structure is "find what looks similar." The ceiling of tiered compression is "find what the summaries kept." The ceiling of a graph network is "find what is related."

NylonME weaves its graph with the six-silk model: every memory carries six silks — fact, relation, temporal, emotion, frequency, provenance — and memories are explicitly linked to each other through relation silks. Retrieval is "contextual resonance": diffuse from seed nodes along the graph, ranked by tension.

This structure delivers three capabilities no other model provides:

Associative recall: "my internet is lagging" can activate a broadband-outage work order from three months ago, because they're connected by an edge in the graph — no keyword hit required.
Conflict detection: when a new memory is written, it's automatically checked against existing memories for contradictions, and contradictions are returned with the response instead of silently overwriting.
Natural forgetting: tension decays exponentially with time; frequently mentioned memories resist forgetting — no manual database cleanup needed.

Plus one architecture upgrade that landed in August: dual-layer writes. The leaf layer stores verbatim turns; the abstract layer stores LLM-distilled session-level facts; both coexist and both participate in retrieval. This design came directly from experimental lessons (see Part 5): the abstract layer cannot replace raw text — compressed artifacts are an increment, not a replacement.

Dimension 2: Retrieval Quality — Full-Run Basis, Open Scripts

This is the dimension we most welcome being scrutinized on.

LoCoMo long-conversation memory benchmark: recall@10 = 84.6%, on the full 10 sessions, 1,536 answerable questions. The evaluation scripts are open-sourced with the repo; the embedding model is bge-m3 (1024 dimensions, runnable on a LAN Ollama) — anyone can reproduce it.

We deliberately refuse to speak on small-sample bases. This field has too much "90% on 2 sessions" marketing — with a small sample, the variance of 11 questions can lie to you at will; the full run is the mirror that reveals the demon. Our own 2-session figure was 80.1%; pushing to the full run actually rose to 84.2% — but even that "actually" contains noise: the HNSW index fluctuates ±1.5 points, and we label this honestly in the blog.

From the 47.1% lexical baseline to 84.6%, every step has a controlled experiment on record, including four failed designs (LLM query expansion, explicit inter-layer edges, tension floor, reserved seed quotas). The failure list is as long as the success list — that's what real research looks like.

Dimension 3: LLM Dependency — an Enhancement, Not a Dependency

Many memory systems put the LLM on the critical path: LLM extraction for writes, LLM rewriting for reads. That means LLM jitter = memory-system jitter, LLM bill = memory-system bill.

NylonME's principle is pluggable, fallible LLM:

With an LLM endpoint configured (any OpenAI-compatible API; we tested with DeepSeek): you get three enhanced capabilities — weaving decomposition, conflict detection, and session-level abstraction.
Without one, or when the endpoint fails: automatic fallback to heuristic decomposition and rule-based detection; the core read/write path is unharmed.

Your memory engine should not go down because your LLM provider went down. That sounds like a truism — but go check the solution you're using now and see if it dares to run with the LLM unplugged.

Dimension 4: Production Performance — Hard Numbers from a Rust Kernel

All figures measured on a development machine (release build; numbers reproducible via the repo's benchmarks):

Metric	Measured	Notes
Write throughput	12,494 TPS	WAL group commit, 32-way concurrency, fsync on
3-hop graph query	P50 = 3.6ms / P99 = 7.2ms	100K-node scale
Vector retrieval	Top-100 P50 = 0.67ms	Self-built HNSW, recall@10 ≥ 0.9
Memory footprint	720 MB (real text) / 432 MB (minimal)	1M nodes + 10M edges
Deployment form	Single binary	Zero external dependencies; embeddable or as a service

The cost of a Rust kernel is ours to bear (slower development); the benefits are yours (single binary, no GC jitter, predictable memory). Compared with the "install Neo4j, then install Qdrant" school, the operational complexity is not on the same order of magnitude.

Dimension 5: Deployment and Data Sovereignty

Self-hosting: a single binary, served via gRPC + REST gateway, or embedded as a library in your process. Data never leaves your data center.
Embedding-model freedom: swap any OpenAI-compatible endpoint at will — official API, Azure, or bge-m3 on a LAN Ollama. Our production setup runs Ollama on an Ubuntu box in the LAN: zero API cost.
Multi-client access: the gRPC protocol is public; clients can be generated in any language. We've already wired it into our own Codex workflow — resonate for historical decisions at the start of each task, weave to deposit new facts at the end. 29 project memories in service. Using your own system to dig up your own memories is the harshest test of whether it works.

Dimension 6: Long-Term Risk

License: Apache-2.0 — an enterprise-friendly permissive license, no restrictions on commercial use.
CLA: CLA Assistant is configured; the IP chain of community contributions is clean. Your legal team will like this.
Lock-in risk: the data format (.nylon snapshots), the gRPC protocol, and the evaluation scripts are all open-sourced. Even if you abandon NylonME tomorrow, your memory data exports intact — no hostage situation.
Sustainability: this is the most honest item — we are a new project; our star count and ecosystem richness can't compare with big-vendor projects. Choosing us means choosing to grow alongside a project. What we can commit to: development activity, data transparency, and the fact that we ourselves use this path every single day.

When You Should NOT Choose NylonME

The melon-selling is over; here comes the dissuasion. In the following situations, we'd suggest looking elsewhere:

You're a Python full-stack team shipping in two weeks. Choose TencentDB-Agent-Memory or Mem0 — pip install really is fast. Our Python SDK is still on the way.
You want a managed service and don't want to operate any process. Choose the cloud-services school. NylonME's cloud version is still on the roadmap.
You need team-shared memory (multi-user sharing, permission isolation). We don't have that yet; Tencent's Team Memory is production-ready.
Your scenario is purely "save tokens for the LLM," and you don't care about the retrieval-quality ceiling. The tiered-compression school fits better — their 61% token compression is real.
You can't afford to bet on a new project. Understandable. Take our evaluation scripts and run them — until the numbers convince you, no commitment is needed.

There is no silver bullet — only fit. We write out our weaknesses because trust in the selection process is worth more than conversion.

Decision Cheat Sheet

Your situation	Recommendation
Hard self-hosting requirement; data must not leave your domain	NylonME (or build your own)
Pursuing the retrieval-quality ceiling with complex query types	NylonME (84.6% full-run, reproducible)
Production load with high-concurrency writes and low-latency queries	NylonME (12K TPS / millisecond queries)
Python team, quick validation	TencentDB-Agent-Memory / Mem0
Want a managed service with zero ops	Mem0 / Zep Cloud
Team-shared memory	TencentDB (Team Memory)
Academic-grade completeness, dedicated ops staff	MemOS

A POC Path: Verify Our Claims in Half a Day

Run it (10 minutes): clone the repo, cargo build, start the single binary.
Reproduce the numbers (1 hour): run the open-sourced LoCoMo evaluation scripts and see with your own eyes how 84.6% comes about.
Pour in your data (2 hours): connect a slice of real conversation logs via gRPC or REST, and watch how resonance retrieval performs on your own distribution.
The unplug test (5 minutes): cut both the LLM endpoint and the embedding endpoint, and confirm the core path is still alive.

After these four steps, you'll know whether to choose it more clearly than after reading ten blog posts (including this one).

Final Words

A memory engine is the foundation of an Agent, and a foundation chosen wrong will reveal itself in the most expensive way, six months later. Our advice is not "choose NylonME blindly" — it's: choose with a framework, verify with data, decide with a POC.

If you try it and find something wrong, open an issue on GitHub and tell us — that feedback, like the 84.6%, is a real part of this project.

NylonME is open-sourced at github.com/nylon-memory/NylonME, Apache-2.0.

This is Part 6 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. All performance figures are the authors' own measurements (Aug 2026, development machine); evaluation scripts are open-sourced and reproducible. Competitor descriptions are based on public information as of Aug 2026; where discrepancies exist, each vendor's official statements prevail.

From 47 to 84: The Full LoCoMo Benchmark Record of the NylonME Memory Engine

Michael Deng — Tue, 08 Sep 2026 08:02:01 +0000

Every number in this article comes from reproducible evaluation scripts. Measurement basis: LoCoMo evidence-recall recall@10, lexical+vector fused retrieval, 1,536 answerable QA pairs.

The Starting Point: An Honest 47.1%

In our previous benchmark post, we published a number that wasn't pretty: LoCoMo evidence-recall recall@10 = 47.1%.

That was a pure lexical-matching baseline — ask "when did the user book the flight?", and the system only looks for literal overlaps in the memory text. What it finds is whatever happens to contain the exact words of the question; what it misses is the same fact phrased differently.

Two weeks later, that number became 84.6% (1294/1536 → 1299/1536 across two full runs). And if you look one stage earlier — at the retrieval stage, the seed-layer recall — we're already at 90%+. Among open-source memory engines that publish full-run LoCoMo results, these two numbers put us firmly in the first tier.

This article makes no attempt to sugarcoat anything. It is a complete record of every gain and every failed experiment along the way. Far too few people in the memory-systems field publish real data. We'd like to be the exception.

The Big Picture: Five Steps

Stage	Seed-layer recall	Final recall@10	Key move
Lexical baseline	~47%	47.1%	Pure lexical matching (at Phase 1 completion)
+Vector+graph	~75%	70.6%	bge-m3 embeddings in; lexical/vector dual-channel seed fusion
+Dual-layer write	~85%	79.2%	Leaf-layer raw text + abstract-layer LLM-distilled facts coexist
+Adaptive depth	~88%	80.1%	Simple queries skip graph diffusion (Cat4 max_hops=0)
Full validation	90%+	84.2%	2 sessions → 10 sessions, squeezing out small-sample inflation
+Vector rerank	90%+	84.6%	Query vector scores the activated set directly, blended into ranking

Step 1: Embeddings In, 47 → 70.6

In Phase 1, the embedding channel was a reserved interface; seeds came purely from lexical matching. After plugging in bge-m3 (1024 dimensions, running on Ollama on an Ubuntu box in our LAN), retrieval became dual-channel: the lexical channel handles exact entities (names, places, numbers), and the vector channel handles semantic approximations ("booked a flight" and "bought a plane ticket to Shanghai").

Each channel produces its own seeds, with the vector channel holding reserved quota (8 slots) so it doesn't get squeezed out by lexical seeds. After fusion, recall jumped from 47.1% to 70.6%.

That was an expected gain, not a surprise. The real fight starts above 70.

Step 2: Dual-Layer Writes, 70.6 → 79.2

This is the single most important architectural decision of Phase 2, and it deserves a full explanation.

Our initial approach was intuitive: a conversation comes in, the LLM decomposes each session into structured facts, and the facts go into the graph. It sounded great — until the ablation experiment delivered a blow to the head: using only the abstract-layer facts, the score actually fell from 79.2% to 67.3%.

The reason is simple: LLM distillation is necessarily lossy. The user says "the hotel I stayed in last time had poor soundproofing, but the breakfast was decent" — distilled into "user unhappy with hotel soundproofing." The breakfast detail is gone, and so is the temporal anchor "last time." A query asking "how was the breakfast?" can never find its answer in the abstract layer.

So the final architecture is dual-layer writes:

Leaf layer: each conversation turn's raw text is stored verbatim, not a character changed — this preserves precise recall (the foundation for Cat2 temporal and Cat4 single-hop questions)
Abstract layer: when a session ends, the LLM distills structured facts and attaches relation tags — this preserves reasoning power (the foundation for Cat1 multi-hop and Cat3 commonsense questions)

Both layers coexist, each serving its own question types. Along the way, this established a design principle: the understanding layer lives on the write side, not the read side. The LLM is the "compiler" of memory — at write time it compiles raw events into retrievable structures; at query time, no LLM is involved. We also tried query-side LLM query expansion (rewriting the question into keywords before retrieval) — the measured gain was net zero, because the write-side understanding had already done the job.

Step 3: No Diffusion for Simple Queries, 79.2 → 80.1

Our core retrieval mechanism is called contextual resonance: start from seed nodes, diffuse multi-hop along the relation graph, and decay by tension as you spread. For multi-hop reasoning ("how is what A mentioned related to what B did later?"), this mechanism is essential.

But the data told us it is a negative optimization for single-hop queries: for a question like "what phone number did the user mention in the third conversation?", the answer is already in the seed node — diffusion just drags irrelevant neighbors into the Top-10 and squeezes the correct answer out. Cat4 (single-hop) was stuck around 60 points for a while.

The fix was neither to cut diffusion nor to build a separate query engine. It was to add routing inside the resonance engine: adaptively adjust associative depth by query type — Cat4-style queries get max_hops=0 (return seeds only, precise recall), Cat1-style queries get max_hops=4 (full association). Same engine, same interface; diffusion depth becomes a tunable parameter.

The outward story stays unified: contextual resonance adaptively adjusts associative depth to query complexity.

Step 4: Full Validation — Squeezing Out the Small-Sample Bubble

All previous iterations ran on 2 sessions (231 questions) because it was fast. After hitting 80.1%, we ran the full 10 sessions (1,536 questions, about an hour). The result: 84.2% — the total score rose, but the per-category data underwent a dramatic redistribution:

Category	2 sessions	Full 10 sessions
Cat1 multi-hop	67.4%	80.5%
Cat2 temporal	93.7%	86.6%
Cat3 commonsense	72.7%	53.3%
Cat4 single-hop	78.1%	88.0%

Cat3 fell from 72.7% to 53.3% — it has only 92 questions, and with a small sample, the variance of 11 questions is big enough to lie to you at will. This is why we insist on "full-run" as the only trustworthy basis: anyone can produce pretty numbers on a small sample; the full run is the mirror that reveals the demon.

Step 5: From Seed Layer to Final Answer, 90%+ → 84.6%

The full-run data exposed a key fact: seed-layer recall has reached 90%+, while final-answer recall sits at 84.6%. This means the vast majority of correct answers already make it into the candidate set — the problem is no longer "can we find them" but "can we rank them at the front."

Consider one comparison: for Cat4 single-hop queries, seed-layer recall is 93.2%, final recall 88.0% — a 5.2-percentage-point gap that is purely ranking-stage loss. The answer is already in the candidate set, yet ranking squeezes it out of the Top-10.

This gap gives us a very clear signal: NylonME's retrieval capability has entered the first tier of open-source memory engines — a 90%+ seed-layer recall is among the top of systems with public full-run LoCoMo results. The next battlefield is ranking.

We first tried two "obviously correct" ranking optimizations. Both failed:

Tension floor (stop old memories from being squeezed out by decay): zero effect. Because every node in the benchmark is freshly written, its tension is ≈ 1 to begin with — the premise was wrong.
Reserved seed quotas (hold top-N slots for seeds): zero effect. The 28 seeds nearly fill the activation budget of 32; diffusion nodes barely get in anyway — mechanically a no-op.

What finally worked was vector reranking: after resonance completes, compute cosine similarity between the query vector and every node in the activated set, and re-rank with a 0.5-weight blend with the resonance score. Cat1 multi-hop +2.5 points (80.5 → 83.0); total +0.4.

Why is the gain limited? Because Cat4's remaining ranking gap is the ceiling of bge-m3 embedding quality: distractor conversations and the evidence share large numbers of entities (both are about travel, both are about fitness), which can't be separated at the embedding level. No ranking algorithm can fix this; it needs a cross-encoder-style reranker or a stronger embedding model.

The Failed-Experiments List (Just as Important)

Honesty is a tradition of this blog series. The designs rejected this round:

LLM query expansion: rewriting the question into keywords before retrieval. Net-zero gain — cut.
Explicit inter-layer derived edges (abstract fact → raw leaf, weight 1.0): measured negative on Cat2/Cat3 — off by default; implicit automatic edges (weight 0.5) are sufficient.
Tension-floor ranking: premise failed (no old memories in the benchmark).
Reserved seed quotas: mechanically a no-op.

Every failure tightened our understanding of "what this system actually wins on": write-side understanding depth + dual-channel seed quality + adaptive associative depth. Just these three things.

A Milestone on the Side: It Started Working for Us

Beyond benchmarking, NylonME has been deployed to a LAN server (192.168.1.5, gRPC :50051, RocksDB on disk) and wired into our own development workflow: Codex resonates for historical decisions at the start of every task via a plugin, and weaves new facts at the end. 29 project-history memories (architecture conclusions, benchmark data, pitfall records) have been woven in — a query like "what are the pitfalls of the DeepSeek model" precisely hits the bug record from that time.

Using your own system to dig up your own memories is the harshest test of whether it works.

Industry Coordinates: Where We Stand

Among open-source memory engines that publish full-run LoCoMo results, NylonME's 90%+ seed-layer recall and 84.6% final-answer recall place us in the first tier. These are 10-session, 1,536-question, fully reproducible numbers — not a "best result" cherry-picked from small samples.

The 90%+ seed-layer recall shows the retrieval architecture itself already covers the vast majority of query scenarios; the 84.6% final score shows the ranking stage still has room to improve — but that is a concrete next step, not a vague "lots more work needed."

The engine and protocol are fully open-sourced (Apache-2.0): github.com/nylon-memory/NylonME. Whether the numbers look good or bad, they will keep being updated on this blog.

Memory is the last foundation of an Agent. The second layer is done, too.

NylonME vs TencentDB-Agent-Memory: A Collision of Two Memory Philosophies

Michael Deng — Tue, 08 Sep 2026 07:58:19 +0000

On the same day v2 was finalized, we finished the full 10-session validation run and stacked vector reranking on top: NylonME's official LoCoMo recall@10 moved from 60.2% to 84.6%. This article has been rewritten with the latest data and the complete experiment chain.

Opening: Why Compare These Two?

In China's AI Agent memory track, three forces are most worth watching right now:

MemOS (memory tensors): advised by CAS academicians, nearly ¥100M in angel funding, a Neo4j + Qdrant heavy-stack system, academia-first.
TencentDB-Agent-Memory (Tencent Cloud): built by a big-tech team, an L0–L3 four-tier progressive architecture + zero-dependency local deployment on SQLite, 9,300+ GitHub stars — the signature work of engineering pragmatism.
NylonME (Nylon Memory Engine): what we're building — Rust-native, six-silk memory model, contextual resonance retrieval — an engine that treats memory as the core of the architecture, not a bolt-on for the LLM.

We've already compared the first two in an internal report. This article goes straight to the point: what is the essential difference between NylonME and TencentDB-Agent-Memory? This time, we bring experimental data.

1. Architectural Philosophy: What Sits at the Center?

This is the most fundamental divergence.

The TencentDB-Agent-Memory architecture is:

LLM reasoning → context offload → tiered memory storage (L0–L3) → inject before next reasoning

Memory works on the periphery of the LLM. Its core value is "saving tokens for the LLM" — compressing conversation history into L1 Atom facts, L2 Scenario blocks, and L3 Persona profiles, so that only the relevant compressed versions get injected on the next LLM call. A 61%+ token saving (vendor's own measurement) — that capability is real.

The NylonME architecture is:

Input → memory engine (contextual resonance) → LLM reasoning → results written back to memory

Memory sits in front of the LLM. The LLM is an inference peripheral of the memory engine — not the other way around.

One example makes the difference clear:

The Tencent approach: the user asks "what was the outcome of my broadband outage last time?" → the LLM receives the prompt → the LLM calls a memory-retrieval tool → gets back a few L1 Atoms → the LLM summarizes an answer.
The NylonME approach: user input arrives → the memory engine identifies the user ID → resonates out the complete context network along the relation graph (work order + modem model + technician visit time + emotional intensity + related preferences) → hands the contextual bundle to the LLM → the LLM reasons → the conclusions are written back to memory.

In one sentence: in the Tencent architecture, memory is a tool invoked by the LLM; in the NylonME architecture, memory is the context engine that drives reasoning.

2. The Key Experiment: Can the Abstract Layer Replace Raw Memories?

Tencent's L0→L3 model carries an implicit assumption: information can be compressed tier by tier, and the compressed high-tier representations can replace low-tier details in reasoning. The L0 raw conversation is kept mainly for retrospective drill-down; what actually feeds the LLM is the compressed Atom / Scenario / Persona. This is the natural corollary of the "save tokens" goal, and it is the mainstream practice in tiered memory design today.

We were preparing to do exactly the same. On 2026-08-11, we integrated DeepSeek for LLM weaving and ran a set of ablation experiments on the LoCoMo long-conversation memory benchmark (bge-m3 embeddings, one-session controlled comparison on the same QA set):

Experiment	Write strategy	recall@10
E1	Heuristic baseline (single-layer raw memories)	70.7%
E2	LLM per-turn decomposition, replacing heuristics	70.7% (net zero)
E3	LLM session-level abstraction, abstract layer only	67.3%
E4	Dual-layer coexistence: leaf layer = verbatim turns + abstract layer = session facts	78.7%

E3 is the most informative. The abstract layer did lift multi-hop reasoning questions (Cat1/Cat3) noticeably — but detail-precision questions (Cat2/Cat4) fell in lockstep, and the overall score dropped 3.4 points. The reason is not complicated: compression is lossy, and somewhere in the discarded details there is always a piece that happens to be the answer to some question. When the user asks "which floor was that restaurant we talked about on?", a session-level summary most likely retains only "the user discussed a restaurant."

E4 gives the correct solution: the abstract layer does not replace the leaf layer; both coexist and both participate in retrieval. The leaf layer preserves detail precision, the abstract layer supports cross-turn reasoning, and all four QA categories beat the baseline.

We then pushed this configuration to the full benchmark and added one final ranking optimization — vector reranking (candidates activated by resonance get a second cosine-hybrid scoring pass against the query vector). The complete experiment chain (LoCoMo recall@10):

Stage	Configuration	Result
Starting point	Lexical retrieval baseline	47.1% (full 10 sessions)
Semantic	bge-m3 embeddings + lexical/vector dual-seed channels	60.2% (full 10 sessions)
Retrieval tuning	Seed fusion + weighted scoring	70.6% (2-session basis)
Dual-layer write	Leaf layer + abstract layer coexistence	78.7% (1-session ablation)
Adaptive depth	0 hops for detail questions / 4 hops for reasoning questions	80.1% (2-session basis)
Same config, full run	—	84.2% (full 10 sessions)
Vector rerank	Query-vector cosine hybrid scoring (weight 0.5)	84.6% (full 10 sessions — current official figure)

From 47.1% to 84.6% — every one of the 37.5 points gained has a controlled experiment behind it. The last vector-rerank step looks worth only 0.4 points, but its structure is beautiful: multi-hop reasoning questions (Cat1) rose from 80.5% to 83.0% — graph diffusion recalls more candidates, and vector reranking moves the most on-point ones to the front.

This set of experiments also rules out two wrong hypotheses, worth recording:

A tension floor does nothing. We had assumed old memories would need a tension floor to guard against decay over-penalizing them — measurements showed the benchmark's nodes are all freshly written, with tension ≈ 1 to begin with. The premise didn't hold.
Guaranteed seed quotas are a no-op. We had assumed vector seeds would need reserved quota slots — measurements showed the 28 seeds nearly fill the diffusion budget of 32, leaving almost no room for diffusion nodes to claim a quota anyway.

And one honest admission about the ceiling: detail-distraction questions (Cat4) remain about 5 points from the theoretical upper bound. Our judgment is that this is the limit of bge-m3 — distractor conversations and the evidence share entities, so they can't be separated at the embedding level. Moving this will take a cross-encoder reranker (e.g., bge-reranker-v2-m3).

Measurement note: 84.6% is recall@10 on the full LoCoMo benchmark of 10 sessions and 1,536 answerable questions; the HNSW index carries ±1.5 points of noise. All evaluation scripts and switches are open-sourced and reproducible. Tencent has not published LoCoMo results, so a direct side-by-side comparison isn't possible.

The lesson for tiered memory design: it's not the tiers that are wrong — it's "tier replacement" that's wrong. Raw text must not live only in a retrospective corner; it must stay on the retrieval path. Compressed artifacts are an increment, not a replacement.

To be fair, Tencent keeps the L0 raw text for drill-down — more prudent than pure replacement. But at the critical step of "what gets fed to the LLM," its retrieval path still centers on the compressed tiers — precisely the pit we fell into with E3.

3. Memory Representation: Tiered Tree vs Graph Network

Tencent's four-tier model (L0 Conversation → L1 Atom → L2 Scenario → L3 Persona) is currently the most meticulous tiered design in the industry, and its strengths are obvious:

Each tier is independently replaceable (swapping L2 doesn't affect L3)
Data is traceable (an L3 profile can be drilled all the way back to the L0 raw conversation)
White-box and readable (Markdown / JSONL, human-friendly)

But a structural cost remains: the tiers are vertical; there are no horizontal associations. "The user prefers window seats" and "the user went to Tokyo last month" are two isolated Atoms — the connection between them can only be inferred by the LLM at retrieval time, not built at write time.

NylonME's six-silk graph model takes a different path. Every memory is woven from six silks (fact, relation, temporal, emotion, frequency, provenance), and memories are explicitly linked to each other through relation silks — not a tiered tree, but a directed, weighted graph:

[Broadband outage work order #1024]
    |-- relation silk --> [Modem model: Huawei HG8245]
    |-- relation silk --> [Customer emotion: anxious, 0.8]
    |-- relation silk --> [Preference: latency-sensitive]
    |-- temporal decay --> tension naturally drops after 30 days
    |-- frequency silk --> mentioned 3 times, +0.3 forgetting resistance

This week's architecture upgrade added a second level to this graph: dual-layer writes. Leaf-layer nodes store verbatim turns; abstract-layer nodes store LLM-distilled session-level facts. Both coexist in the same graph and both participate in recall — this is exactly the productization of the Section 2 experiment conclusion. The engine has a built-in WeaveSession RPC: when a session ends, it automatically completes the full flow of "write each turn to the leaf layer → LLM abstraction into the abstract layer → conflict detection."

In one sentence: the Tencent approach uses the LLM's reasoning to compensate for the storage layer's missing relations; the NylonME approach builds relations into the storage layer and lets raw text and abstractions coexist there. The LLM receives an already-organized, dual-granularity context network.

4. Where the LLM Sits: Compression Pipeline vs In-Engine Understanding

Both systems use LLMs to process memory, but the LLM stands in a completely different place.

Tencent's LLM is inside a compression pipeline: it symbolically compresses conversations into Atom / Scenario / Persona (including compressing process descriptions into Mermaid syntax), with the goal of reducing token consumption.

NylonME's LLM does three things inside the engine:

Weaving decomposition: at write time, it extracts structured six-silk elements from raw events (fact, relations, emotional valence and intensity, confidence), replacing the early heuristic rules.
Conflict detection: when a new memory is written, the engine first uses HNSW under a lock to find the top-4 candidates with the same subject, then lets the LLM judge — outside the lock — whether they contradict; contradicting nodes are returned with the response — "the user said last week they don't eat spicy food, this week they can't live without it" won't be silently overwritten.
Session-level abstraction: the abstract layer of dual-layer writes, distilled by the LLM when a session ends.

The key design constraint: the LLM is an enhancement, not a dependency. When the LLM endpoint is unavailable, the engine automatically falls back to heuristic decomposition and rule-based detection; the core read/write path is unaffected. We don't believe a memory engine should go down because an LLM went down.

5. Retrieval: Hybrid Recall vs Contextual Resonance

Dimension	TencentDB-Agent-Memory	NylonME
Retrieval entry	Keyword / vector / hybrid (RRF fusion)	Lexical + vector dual-seed channels
Recall strategy	BM25 + embedding → Top-K	Seed nodes → graph diffusion → tension ranking
Diffusion depth	No graph structure, N/A	Adaptive by question type (0–4 hops)
Candidate reranking	None	Query-vector cosine rerank (optional, weight tunable)
Association	Inferred by the LLM after retrieval	Pre-built into the graph at write time
Forgetting	None (or manual deletion)	Exponential decay T(t) = T0·e^(−λt)
Emotional weighting	None	Emotion-silk intensity weighting
Frequency promotion	None	High-frequency memories gain forgetting resistance

Tencent's BM25 + vector + RRF is the industry-standard approach — mature and reliable. But two old questions remain unanswered:

How do you recall memories "associated with the current context but whose keys don't match"? The user asks "my internet has been lagging lately" — if no L1 Atom contains the keywords "internet" or "lag", and vector similarity misses too, that valuable outage memory sinks without a trace. NylonME's graph diffusion can: the earlier work order is linked via relation silks to a "latency-sensitive" tag; "laggy internet" lexically hits "latency", activates the tag, and diffuses along the graph to the work order.
How do you rank "which of the ten relevant memories matters most"? Tencent relies on the fused BM25 + cosine similarity score. NylonME ranks in three stages: tension scoring (encoding temporal decay, emotional intensity, frequency bonus) → adaptive diffusion by question type → query-vector cosine rerank. That last stage was added this week, specifically to fix "graph diffusion recalls plenty but the most on-point result isn't ranked first" — a measured +2.5 points on Cat1 multi-hop reasoning questions.

Adaptive associative depth comes from a hard-learned lesson: running multi-hop diffusion on every question hurts detail-precision questions (diffusion introduces noise). Detail questions now get depth 0 (only direct seed associations), reasoning questions up to 4 hops. Retrieval strategy should vary with question type — something we haven't yet seen in any comparable open-source project.

6. Tech Stack and Deployment: Python vs Rust

Dimension	TencentDB-Agent-Memory	NylonME
Core language	Python	Rust
Local storage	SQLite + sqlite-vec (zero-dependency default)	Embedded CSR + HNSW + WAL (in-process)
Vector index	sqlite-vec / Tencent Cloud VectorDB	Self-built HNSW
Graph storage	None (pure tiered index)	Self-built CSR compressed graph
Deployment	pip install (lightweight)	Single binary (even lighter)
Write TPS	Not disclosed	12,494 (WAL group commit, measured at 32-way concurrency)
Memory (1M nodes + 10M edges)	N/A (no graph structure)	720 MB real text / 432 MB minimal basis
Cloud service	Tencent Cloud VectorDB (optional)	On the roadmap

Tencent's zero-dependency design is very clever — one pip install and it runs; SQLite is bundled, no database to install. This is a big reason its GitHub stars shot past 9,300.

NylonME went to the other extreme: a Rust kernel, CSR graph structure + HNSW vector index all embedded in-process, compiled into a single binary — even lighter than pip install. The trade-off is development speed and ecosystem richness far below Python's.

There's no absolute "better" here — only what fits your stack: Python full-stack teams integrating quickly should pick the Tencent option; teams with hard requirements on memory, latency, and throughput who are willing to tangle with Rust will find NylonME the better substrate.

7. Current State and Differences at a Glance

Dimension	TencentDB-Agent-Memory	NylonME
License	MIT	Apache-2.0
Core language	Python	Rust
Memory model	L0–L3 four-tier progressive	Six-silk graph network + dual-layer writes + tension decay
Relation storage	None (tiered index)	CSR directed weighted graph
LLM's role	Compression pipeline (save tokens)	Weaving decomposition + conflict detection + session abstraction (with fallback)
Retrieval	BM25 + Vector + RRF	Contextual resonance (dual seeds + graph diffusion + tension ranking + vector rerank)
Associative depth	N/A	Adaptive 0–4 hops by question type
Forgetting	Manual	Adaptive exponential decay
Emotion modeling	None	Emotion silks + intensity weighting
Team memory	Yes (Team Memory)	On the roadmap
Deployment	pip install (zero-dependency SQLite)	Single binary (zero-dependency)
Write TPS	Not disclosed	12,494
LoCoMo recall@10	Not disclosed	84.6% (full 10 sessions: dual-layer writes + adaptive depth + vector rerank)
GitHub stars	~9,300+ (Aug 2026 snapshot)	New project
Cloud service	Tencent Cloud VectorDB (optional)	On the roadmap

Final Words

Putting the two side by side is not about declaring a winner. Frankly, the Tencent team is still far more mature in engineering execution than we are — the four-tier model, symbolic compression, white-box traceability, Team Memory: every one of these is a battle-tested design. The 9,300 stars didn't come from nowhere.

But this week's experiments turned the closing line of our first version into data. Back then we said: "there are always things compression loses, and what gets lost happens to be critical information in some context." At the time, that was intuition. Now it's an experiment: keep only the abstract layer, and recall drops 3.4 points; let both layers coexist, and all four QA categories rise; add adaptive depth and vector reranking, and the full benchmark reaches 84.6%.

Memory should not be a mere accessory to the LLM. A compression pipeline lets the LLM read summaries ever more cheaply, but what an agent truly needs is a memory system that associates, forgets, detects contradictions, and moves freely between raw text and abstraction.

The two paths will ultimately lead to two different product shapes. Which one is right — time and the market will tell.

NylonME is open-sourced at github.com/nylon-memory/NylonME, Apache-2.0, evaluation scripts included in the repo. Criticism is welcome — and reproductions even more so.

This is Part 4 (v3, 2026-08-12) of the NylonME technical blog series. TencentDB-Agent-Memory data in this article comes from its public GitHub repository and official articles (Aug 2026 snapshot); performance figures are vendor self-tests, not independently reproduced. All NylonME experiment configurations and measurement bases are itemized in the article.

The Second Half of AI: Memory Engines Matter as Much as Large Models

Michael Deng — Tue, 08 Sep 2026 07:55:49 +0000

Everyone Talks About LLMs — But AI Is Not Just LLMs

There's a funny phenomenon in the AI world of 2026: when people talk about AI, they're actually talking about large language models. And when they talk about large language models, they're actually talking about OpenAI, Kimi, DeepSeek — as if the history of AI were nothing more than the product release notes of a handful of companies.

Frankly, that framing is far too narrow.

AI is not equal to LLMs, and certainly not equal to OpenAI, Kimi, or DeepSeek. A large language model is one pillar of the AI edifice — an important one, but neither the only one nor the foundation. Treating "LLM" as a synonym for "AI" is like treating an engine as the whole car, a GPU as the whole computer, or the heart as the whole human body. This cognitive bias is inflicting enormous industry costs: legions of teams try to deliver AI Agents with "model selection + prompt engineering + tool-chain tuning," only to discover that what they deliver —

Can't remember who the user is
Can't remember where the last conversation left off
Can't remember the preferences the user stated
Treats every turn like a first meeting

This is not because the model isn't big enough. GPT-5 wouldn't fix it either. Because this is not a model problem — it's an architecture problem.

The Real Bottleneck of AGI: Not Reasoning, but Long-Term Memory

Let's look at a simple comparison.

Today's strongest reasoning models — Claude, GPT-5, DeepSeek-V3 — already outperform most humans at math competitions, code generation, and logical reasoning. Judged on "reasoning" alone, large models have touched the threshold of AGI.

But have you noticed something odd? These models behave like geniuses in a chat box, yet the moment you place them in a real-world scenario that requires sustained interaction — customer service, personal assistants, tutoring, medical follow-ups — they immediately degrade into a forgetful intern.

Where's the gap?

Long-term memory.

Human intelligence has never been an "island of reasoning." You wake up remembering yesterday's conversation with a colleague, the conclusion of last Friday's meeting, that your child is allergic to peanuts, that one client of yours prefers phone calls after 3 p.m. These memories aren't temporarily "retrieved" from a hard drive each time they're needed — they stay continuously active in the background, automatically building associations, automatically weighting their salience, automatically surfacing when you need them.

Large models have no such layer. Every round of LLM reasoning is the dawn of a brand-new epoch. The context window is its only temporary sticky note — and when the conversation closes, the note is torn up.

So the true path to AGI is not blocked by reasoning — we're already very good at reasoning. It's blocked by how to make AI remember like humans do:

Memory needs structure — not a loose pile of text blocks, but a network with strands, graphs, and associations.
Memory needs evolution — not "write once, never change," but decaying with time, weighted by emotion, promoted by frequency.
Memory needs resonance — not one-sided retrieval by query, but automatic surfacing triggered by context.
Memory needs forgetting — not remembering everything, but forgetting what should be forgotten, letting the important float up.

Of these, the LLM itself can do exactly none.

The Dividing Line of the Second Half: Memory Engines Will Decide Which AI Applications Live or Die

I'll make a prediction: before the end of 2026, the entire industry will collectively realize this problem.

Why now? Because the low-hanging fruit of the first half has been picked.

What was the first half? It was the paradigm of "give me a prompt, I'll give you an answer." Chatbots, AI search, code completion, document summarization — none of these scenarios need memory. Every interaction is independent, stateless, and parallelizable. Large models thrive in this paradigm, because their capability boundary happens to cover exactly these scenarios.

But the second half is Agents. The defining feature of an Agent is not stronger reasoning — it's continuity and personalization: it can remember you, accumulate experience, and grow through repeated interaction. After an Agent has worked with you for a week, a month, a year, it should understand you better than on day one — not be dumber than on day one (because the context window is stuffed with stale garbage).

The dividing line of this second half is the memory engine. Whoever builds the memory layer first will see their Agents actually ship. Whoever keeps their Agents at "in-session reasoning" will keep watching their deliveries blow up.

By the end of this year, when the first wave of Agent products propped up by memory engines begins to deliver — while the vast majority of teams are still grinding on prompt tuning — this conclusion will be brutally validated by the market.

NylonME: We're Building the Infrastructure for AI's Second Half

That is NylonME's positioning.

We don't build large models. We don't build chatbots. We don't build prompt-optimization tools.

What we build is a memory engine — the memory-layer infrastructure for AI Agents.

Specifically, NylonME provides a complete implementation of a human-like memory system:

The Six-Silk Memory Model: every memory is woven from six silks — fact, emotion, temporal, relation, confidence, frequency. Not a text block, not a vector — a structured information unit.
Contextual Resonance Retrieval: retrieval is not "query -> embedding -> Top-K." It's multi-hop diffusion from seed nodes along the relation graph, ranked by tension decay. Tension is jointly determined by the Ebbinghaus forgetting curve, emotional intensity, and mention frequency — mimicking the brain's associative circuits.
Automatic weaving and evolution: LLM reasoning results are automatically decomposed into six-silk fields and written into the memory network. Decay, index updates, and conflict detection run continuously in the background. Memory is growing — not merely being queried.
Open source + protocol first: the Rust engine is open-sourced under Apache-2.0, the proto3 interface contract is public, and the evaluation pipeline is fully open.

So far, we have completed:

CSR graph engine + self-built HNSW vector index; a single node holds a million nodes in under 300 MB of memory
WAL group commit: write TPS from 452 to 12,494 (27.6x)
Embedded semantic channel (bge-m3): LoCoMo semantic recall@10 = 60.2% (lexical baseline 47.1%)
Relation-silk inverted index: edge weaving dropped from O(N) full-graph scans to index-based candidate lookup

All code is at github.com/nylon-memory/NylonME.

Final Words

In the second half of AI, memory engines matter as much as large models. That statement may sound a bit ahead of the curve today, but I believe it will be common consensus by year-end.

AGI is not a bigger LLM. AGI is a system that understands you, remembers you, and happens to recall exactly what you need when you need it. The large model handles "reasoning"; the memory engine handles "remembering." Both wheels must turn together for the car to move.

We chose to start with the memory wheel.

Come take a look: github.com/nylon-memory/NylonME.

This is Part 3 of the NylonME technical blog series. Part 1, "Building a 'Nylon' for AI Agents: Memory System Phase 1 Complete, with Real Benchmarks," and Part 2, "Why Your AI Agent Can't Deliver — The Architecture Was Wrong from Day One," are in the same directory.

NylonME AI Memory Engine: Why Your AI Agent Can't Deliver — The Architecture Was Wrong from Day One

Michael Deng — Tue, 08 Sep 2026 07:52:49 +0000

An Awkward Reality

In 2025, nearly every tech company was building AI Agents. In 2026, nearly every one of them is struggling.

Not because the demos don't work — the demos are all beautiful. It's because they can't deliver. When the customer runs acceptance tests, the Agent either answers the wrong question, asks the same question over and over, or completely forgets what the customer said five minutes ago. The most deadly part: the customer can't articulate what's wrong — they just feel "this thing isn't usable."

Take AI customer service as an example. A customer calls in: "I reported a broadband outage last month, a technician came and replaced the optical modem, and now it's down again." A competent AI agent should immediately pull up last month's work order, confirm the modem model, and make a diagnosis based on the current symptoms. But what most AI customer service agents actually say is — "Hello, how may I help you?"

It simply doesn't remember anything from last month.

This is not a capability problem of any particular model. This is an architecture problem.

The Nature of Intelligence Has Been Misunderstood

Over the past two years, the entire industry has fallen into a collective cognitive bias: equating large language models with AI, and AI with intelligence.

That equation is dead wrong.

What is a large language model? It's an inference engine. It takes tokens in and puts tokens out, doing probabilistic reasoning in parameter space. It doesn't store, doesn't remember, doesn't accumulate. Every call is a brand-new computation; the context window is expensive scratch paper that gets thrown away the moment the conversation ends.

But intelligence is far more than inference. Let's briefly break down human intelligence:

Reasoning: logical operations, causal inference, planning — this is the layer LLMs are best at.
Memory: the storage, organization, and retrieval of experience — a layer LLMs simply do not have.
Intuitive emergence: pattern recognition formed automatically from vast experience in high-dimensional space — it requires memory as its substrate.
Emotional context: valence judgment, emotional tagging, social-context awareness — it requires memory as its frame of reference.

See the problem? The LLM-centric architecture treats reasoning as the entirety of intelligence, and outsources the other three layers to "stuffing history into the context window" and "attaching a vector database for semantic search." These two substitutes are, in essence:

Stuffing the context: cost grows linearly with conversation turns, and the information is merely "stuffed in" — not organized, not connected, not forgotten.
Vector search: it can only answer "which memories look similar to the current query," not "which memories are relevant to the current context," let alone handle temporal decay and emotional weighting.

This is like a person who has logical reasoning but no memory — he can solve calculus, but he can't remember his own name, can't remember who he met yesterday, can't remember what made him happy or what made him wary. Would you put such a person on a customer service desk?

Yet that is exactly what the entire industry is doing.

Why the LLM-Centric Architecture Is Doomed to Fail

Let's review the mainstream AI Agent stack today:

User Input -> Preprocessing -> LLM (Reasoning) -> Tool Calls -> Postprocessing -> Output
                                    |
                            Vector DB (Semantic Search)
                                    |
                            Chat History (Context Injection)

This architecture has a fundamental flaw: the LLM is the center, and memory is a bolt-on accessory.

What does "bolt-on" mean? It means the memory module and the reasoning module are loosely coupled. When the LLM calls on memory, it "queries" an external system, gets a few results, stuffs them into the prompt, and goes back to reasoning. Between calls, memory is static — it doesn't update automatically because of this conversation, doesn't decay with time, doesn't reorganize itself when new information arrives. It's a passive retrieval vault.

This produces the chronic diseases shared by all AI Agent products:

Forgets people: the conversation ends, user information resets to zero. Every meeting starts from scratch.
Forgets events: work order history, preference records, interaction trails — all "sink to the bottom" of the vector store, never to be retrieved again unless the query happens to hit the right keywords.
Never grows: the Agent is exactly as dumb on its ten-thousandth use as on its first, because its memory isn't growing.
Never reflects: a memory is wrong, outdated, or contradicts another one — the Agent doesn't know, and has no ability to fix it.

A customer pays a hefty price for a system that can't even match a human intern (an intern at least remembers what the boss asked for last week). Why would they sign off on that?

Memory Should Be the Core of the Architecture

The correct architecture should be:

User Input -> Memory Engine (Contextual Resonance) -> LLM (Reasoning) -> Tool Calls -> Output
                    |                                |
            Memory Weaving + Update            Results written back to memory

The memory engine is the center; the LLM is an inference peripheral of the memory engine.

This inversion is fundamental:

User input passes through the memory engine first: instead of calling the LLM right away, the system first searches memory for "who is this user, where did we leave off last time, which historical memories are connected to the current context." What the LLM receives is not raw input, but input wrapped in memory context.
Reasoning results are written back to memory: the LLM's output is not the end. Important conclusions, user preferences, and key facts from this interaction are automatically woven by the memory engine into structured memory strands and stored in the memory network.
Memory keeps evolving in the background: temporal decay, emotional weighting, relation index updates, conflict detection — all of these run automatically in the background, without the LLM's involvement.
By the next interaction, memory is already different: the Agent is genuinely "accumulating experience."

Back to the AI customer service example: the customer calls a second time, and within 3 ms the memory engine has done all of the following — recognized the customer ID, pulled up the complete memory network of last month's broadband outage (work order contents + modem model + technician visit time + the customer's emotional intensity at the time), diffused along the relation graph and discovered a preference memory that "this customer is sensitive to network latency," and handed this contextual bundle to the LLM. The LLM's first sentence is: "Hello Mr. Wang — the optical modem we replaced in March is down again? Let me check the current status of the base station covering your neighborhood first."

That is what customers will pay big money for.

NylonME: A Memory Engine Born for Agents

This is exactly what we're building.

NylonME (Nylon Memory Engine) is an open-source, Rust-native memory engine that provides AI Agents with a human-like memory layer.

Its core design philosophy is exactly what we said above — memory should not be bolted on; memory should be the core of the architecture.

The Six-Silk Memory Model

In NylonME, every memory is not a text block, not a vector, but a strand twisted from six "silks":

Silk	Meaning	What it's for
Fact Silk	The content of the memory itself	Storage and display
Emotion Silk	Valence (positive/negative) and intensity	Emotion-weighted retrieval; high-emotion memories resist forgetting
Temporal Silk	Creation time and decay rate λ	Ebbinghaus exponential decay; old memories sink naturally
Relation Silk	Entity tags and cross-memory links	Graph diffusion — one memory hooks a chain of related ones
Confidence Silk	Reliability	Low-confidence memories weigh less in resonance
Frequency Silk	Mention count	High-frequency memories get promoted, resisting decay

Contextual Resonance Retrieval

Retrieval doesn't follow "query -> embedding -> Top-K." It follows Contextual Resonance:

Start from a set of seed nodes (dual-channel: lexical match + vector match)
Multi-hop diffusion along the relation graph
At each step, decay by the tension formula: T(t) = T0 * e^(-λt) * (1 + alpha * freq) * emotional intensity
Branches whose tension drops below the threshold are pruned automatically
Return results ranked by accumulated tension

This mimics human associative recall: a cue doesn't trigger the memories that "look most similar" — it triggers the chain with the highest tension in the current context.

Engineering Choices

Rust engine (open source under Apache-2.0): CSR-compressed graph structure + self-built HNSW vector index + WAL persistence; a single node handles millions of nodes in under 300 MB of memory.
Embedded semantic channel: works with any OpenAI-compatible embedding endpoint (local Ollama bge-m3 / cloud), fusing lexical and vector dual-channel seed recall.
LLM weaving: DeepSeek-driven automatic silk-splitting and conflict detection — from raw event to structured six-silk fields, fully automatic.
Protocol first: proto3 defines the interface contract; engine and gateway are decoupled.
Open evaluation: fully benchmarked on the public LoCoMo benchmark — semantic channel recall@10 = 60.2% (lexical baseline 47.1%, +13.1pp), with the entire data pipeline open-sourced.

What We've Done (Phase 1 & 2 Complete)

As of August 2026, the public NylonME repository already includes:

A complete Rust workspace: graph storage engine + HNSW vector index + embedding module + WAL group commit
Semantic retrieval channel: Ollama bge-m3 / any OpenAI-compatible endpoint
Full LoCoMo evaluation pipeline: 10 sessions, 1536 QA pairs, lexical 47.1% -> semantic 60.2%
Write TPS: 452 -> 12,494 (WAL group commit + inverted index optimization, 27.6x)
Relation-silk inverted index: edge weaving dropped from O(N) full-graph scans to index-based candidate lookup

All code is open-sourced at github.com/nylon-memory/NylonME under Apache-2.0.

Closing: Think in a Different Direction

If your AI Agent project is stuck in delivery hell, stop and ask yourself one question:

In your system, is memory the first-class citizen — or is the LLM?

If the answer is the LLM — you may need to re-examine the foundation of your architecture. A large model is the engine of this AI wave, but an engine is not the whole car. A race car without a steering wheel, no matter how fast, will never reach its destination.

Memory is the steering wheel of AI Agents.

NylonME has just gotten started — the foundation is poured. Come take a look: github.com/nylon-memory/NylonME. Criticism, issues, and code contributions are all welcome.

This is Part 2 of the NylonME technical blog series. Part 1, "Building a 'Nylon' for AI Agents: Memory System Phase 1 Complete, with Real Benchmarks," is in the same directory.