DEV Community

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

Posted on

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

NylonME Memory Engine concept


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:

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

The four layers of intelligence

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)
Enter fullscreen mode Exit fullscreen mode

Architecture comparison

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
Enter fullscreen mode Exit fullscreen mode

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

This inversion is fundamental:

  1. 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.
  2. 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.
  3. 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.
  4. 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

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

Contextual Resonance Retrieval

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

  1. Start from a set of seed nodes (dual-channel: lexical match + vector match)
  2. Multi-hop diffusion along the relation graph
  3. At each step, decay by the tension formula: T(t) = T0 * e^(-λt) * (1 + alpha * freq) * emotional intensity
  4. Branches whose tension drops below the threshold are pruned automatically
  5. 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.

Top comments (0)