Open source · MCP-native · Rust

Give your AI Agent
long-term memory

NylonME models memory as a woven structure of multi-strand filaments, not a flat event list or a similarity index. Starting from seed nodes, activation spreads across a mesh memory graph by association strength, context match and live tension — so your agent remembers what it should.

Two-minute setupRead the docsView source
86.0%LoCoMo recall@10
82.9%LoCoMo end-to-end QA
99%LongMemEval-S any-hit
83.0%LongMemEval-S end-to-end

Why NylonME

Memory is not retrieval — it is resonance

Most memory systems treat memories as flat text chunks fetched by top-k similarity. NylonME weaves them into a living network: understood at write time, reflected on when idle, and mutually reinforcing along edges at read time.

Multi-strand filaments

A memory is not one sentence but a weave of fact, affect, time, relation, confidence and frequency strands. Understood at write time, resonated at read time.

Mesh memory graph

Memory nodes are connected by weighted edges into a mesh, not a hierarchy. Relations strengthen, decay and rewire with every weave.

Contextual resonance

Retrieval spreads activation from seed nodes along association strength, context match and live tension, bounded by a global activation budget that stops high-fan-out explosions.

Tension decay

Unused memories settle along a tension-forgetting curve instead of piling up forever. High-frequency, high-consensus and high-affect memories are retained.

Two-layer write

The understanding layer sits on the write side: the LLM is the memory compiler, distilling raw sessions into a retrievable fact layer that coexists with raw leaf events.

Async reflection

Like a brain consolidating memory during sleep: idle-time world-knowledge bridging and persona inference; the latest full run reads 86.0% LoCoMo recall.

Memory Graph

From the current context, activation spreads to related memories

Retrieval starts at seed nodes and spreads along weighted edges. The better the context match, the stronger the relation and the higher the tension, the likelier a memory lights up.

Current contextProject constraintsSimilar factsTimelineRelation webHigh-tension memory

Integrations

Five ways into your agent

Embedded on one machine, zero-binary over HTTP, a shared bridge across machines, straight SDK calls, or right inside a phone app — one engine, one write path.

MCP stdio

nylon-engine mcp embeds the engine in-process: no port, no daemon, one config block for every MCP client.

/mcp HTTP endpoint

Zero binary on the client: a running engine exposes a Streamable HTTP MCP endpoint — one URL plus an API key and you are in.

Remote bridge

Set NYLON_SERVER and multiple machines and IDEs share one memory store, with zero data in client processes.

SDK & integrations

Python SDK (nylon-sdk), LangChain / LlamaIndex retrievers, a DSH plugin, and a fully open gRPC contract.

In-process on phones

nylon-mobile runs inside your Android / iOS app via UniFFI bindings — no port, no network, memories never leave the device.

On-Device

The same engine, in your phone

nylon-mobile compiles the exact same weave / resonate / retrieve implementation (the shared nylon-service core) into Android / iOS apps — no daemon, no port, no network calls. Memories never leave the device. UniFFI generates the Kotlin / Swift bindings.

~55µsper resonate on a real phone (lexical)
24MBquantized on-device semantic model
8/8Chinese queries top-1 hit on-device
0network calls · fully on-device

Optional on-device semantics: a quantized bge-small-zh ONNX model with pure-Rust tract inference — a zero-lexical-overlap probe like "do they have a pet at home" still lands on the right memory. WAL-first writes plus automatic checkpoints (every 32 writes / 300s by default) survive process kills; two lifecycle hooks (onStop → checkpoint, onDestroy → shutdown) cover the rest. Details in Docs · Mobile SDK.

Web Console

Built-in web console, zero install

The engine binary ships with a console and REST API (default http://127.0.0.1:50052). Dark / light themes and an EN / 中文 UI toggle included.

Six views, each with one job: Overview (engine stats, latest memories, activity stream, tension histogram), Memories, Graph (a force-directed map of the memory web), Resonate (query debugging with a one-click answer-quality feedback bar that drives idle reflection), Weave (single + session batch) and Audit. The node drawer can even forget a memory outright.

NylonME web console: overview dashboard

Quick Start

One MCP config, and your agent remembers

nylon-engine mcp speaks Model Context Protocol over stdio with the engine embedded in-process — no daemon, no port, data lands in ~/.nylonme/data automatically.

json
{
  "mcpServers": {
    "nylonme": {
      "command": "/path/to/nylon-engine",
      "args": ["mcp"],
      "env": { "NYLON_OWNER": "my-project" }
    }
  }
}

Want to see it running first? No Docker required — Windows users can grab an archive from Releases and just unzip it; with Docker, one command also brings up the ollama embedding model:

shell
# Option 1 (recommended): no Docker needed — Windows / macOS / Linux
# Download nylonme-windows-x64.zip from GitHub Releases, unzip, then:
nylon-engine.exe serve 127.0.0.1:50051
start http://127.0.0.1:50052
# No Rust toolchain, no key — a single machine runs in open mode out of the box
shell
# Option 2: Docker (also brings up ollama embeddings for semantic recall)
git clone https://github.com/nylon-memory/NylonME.git
cd NylonME
docker compose -f docker-compose.prebuilt.yml up -d
# gRPC on :50051 · web console / REST / /mcp all on :50052
# open http://localhost:50052 to browse your first memories

Architecture

Nine crates, each with one job

The engine is a Rust workspace with clean module boundaries, from the filament data model to the gRPC / HTTP services. Around it: the proto contract, sdk/python, integrations, plugins and a helm chart.

nylon-core

Filament data model + tension decay

nylon-graph

CSR main graph + delta buffer + resonance walk

nylon-vector

HNSW vector index for semantic recall

nylon-embed

ollama / OpenAI-compatible embedding client

nylon-llm

Understanding layer: fact weaving, conflict detection

nylon-storage

RocksDB persistence, WAL + crash recovery

nylon-service

Shared core for server / mobile

nylon-engine

Engine entrypoint + gRPC / HTTP services

nylon-mobile

UniFFI bindings: in-process engine for Android / iOS

Tuning knobs

VariableDefaultEffect
NYLON_MAX_SEEDS20Seed set cap (lexical + vector channels)
NYLON_RERANK_VEC0Weight of query-vector cosine mixed into resonance ranking
NYLON_WORLD_BRIDGES_ASYNCoffAsync reflection: commonsense world-knowledge bridging
NYLON_PERSONA_REFLECToffPersona node extraction during async reflection
NYLON_SESSION_DEDUPoffweave_session reuses nodes for identical events; retry/replay safe
NYLON_HTTP_ADDR127.0.0.1:50052Web console / REST / /mcp listen address (off to disable)
NYLON_CHECKPOINT_SECS600Periodic snapshot interval in seconds (0 to disable)
NYLON_API_KEYS_FILE—API key table file; setting it enables auth (hot-reloaded)

LoCoMo Benchmark

86.0% — earned one explainable step at a time

Full 10-session corpus, 1536 answerable QAs, lexical + vector fused retrieval. Every layer of the experiment delivered a lift we can explain.

47.1%Lexical baseline
70.6%Vector seeds + graph
79.2%Two-layer write
84.6%Query-vector rerank
85.4%Async reflection
86.0%Latest full run

Per-category recall: multi-hop 82.3% · temporal 89.1% · single-hop 89.1% · commonsense 58.7%. End-to-end QA (LLM answers from retrieved evidence, judge-graded): paper metric 82.9% — same weave store and answer model throughout: 76.4% → anti-refusal prompt 80.1% → widened answer context 82.9%.

Second benchmark LongMemEval-S (100-instance slice): evidence recall any-hit 99%, end-to-end 83.0%. Widening the answer context from Top-10 to Top-15 gained +5pp, and the same mechanism reproduced +2.8pp on LoCoMo. Full methodology lives in the two benchmark reports under docs/ in the repo.

Enterprise Ready

From a personal toy to a shared team engine

One resident engine serves the whole team: tenant isolation, three-scope auth, an audit stream and snapshot backup — all already running our own memory in production.

Multi-tenant isolation

Tenant x owner namespaces, where cross-tenant reads are indistinguishable from "node does not exist" — enforced in the engine core.

Three-scope API keys

read < write < admin scopes, hot-reloaded key table, and keys add / list / revoke to hand out keys in one command.

Audit event stream

Flip NYLON_AUDIT on to record who is using the engine and who is hammering it; query anytime via GET /v1/audit.

Snapshots & backup

Periodic checkpoints with WAL truncation support hot backup and restore drills — production deployments stay auditable.

One-command Docker Compose deploy, and a Helm chart for Kubernetes.

Roadmap

From runnable to widely adoptable

Engine · Done

From a 47.1% lexical baseline to 86.0% recall / 82.9% QA, every step explainable and reproducible.

  • WeaveSession two-layer write
  • Hybrid seeds + adaptive depth
  • Query-vector rerank + async reflection

Production · Done

REST/OpenAPI with a web console, Python SDK, framework integrations, tenancy, auth, audit, backup and one-command deploys.

  • REST / console / SDK / integrations
  • Tenancy + API keys + audit + snapshots
  • Docker / Helm / DSH plugin / mobile

Next

Keep pushing the recall ceiling and build academic and engineering evidence for the memory model.

  • Cross-encoder reranker
  • Million-node memory profiling
  • Paper & blog series

Give memory back to your agent

Download a prebuilt binary, add one MCP config block, and two minutes later your agent starts remembering you.

Get started