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.
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.
Why NylonME
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.
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.
Memory nodes are connected by weighted edges into a mesh, not a hierarchy. Relations strengthen, decay and rewire with every weave.
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.
Unused memories settle along a tension-forgetting curve instead of piling up forever. High-frequency, high-consensus and high-affect memories are retained.
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.
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
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.
Integrations
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.
nylon-engine mcp embeds the engine in-process: no port, no daemon, one config block for every MCP client.
Zero binary on the client: a running engine exposes a Streamable HTTP MCP endpoint — one URL plus an API key and you are in.
Set NYLON_SERVER and multiple machines and IDEs share one memory store, with zero data in client processes.
Python SDK (nylon-sdk), LangChain / LlamaIndex retrievers, a DSH plugin, and a fully open gRPC contract.
nylon-mobile runs inside your Android / iOS app via UniFFI bindings — no port, no network, memories never leave the device.
On-Device
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.
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
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.

Quick Start
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.
{
"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:
# 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# 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 memoriesArchitecture
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.
Filament data model + tension decay
CSR main graph + delta buffer + resonance walk
HNSW vector index for semantic recall
ollama / OpenAI-compatible embedding client
Understanding layer: fact weaving, conflict detection
RocksDB persistence, WAL + crash recovery
Shared core for server / mobile
Engine entrypoint + gRPC / HTTP services
UniFFI bindings: in-process engine for Android / iOS
| Variable | Default | Effect |
|---|---|---|
NYLON_MAX_SEEDS | 20 | Seed set cap (lexical + vector channels) |
NYLON_RERANK_VEC | 0 | Weight of query-vector cosine mixed into resonance ranking |
NYLON_WORLD_BRIDGES_ASYNC | off | Async reflection: commonsense world-knowledge bridging |
NYLON_PERSONA_REFLECT | off | Persona node extraction during async reflection |
NYLON_SESSION_DEDUP | off | weave_session reuses nodes for identical events; retry/replay safe |
NYLON_HTTP_ADDR | 127.0.0.1:50052 | Web console / REST / /mcp listen address (off to disable) |
NYLON_CHECKPOINT_SECS | 600 | Periodic snapshot interval in seconds (0 to disable) |
NYLON_API_KEYS_FILE | — | API key table file; setting it enables auth (hot-reloaded) |
LoCoMo Benchmark
Full 10-session corpus, 1536 answerable QAs, lexical + vector fused retrieval. Every layer of the experiment delivered a lift we can explain.
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
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.
Tenant x owner namespaces, where cross-tenant reads are indistinguishable from "node does not exist" — enforced in the engine core.
read < write < admin scopes, hot-reloaded key table, and keys add / list / revoke to hand out keys in one command.
Flip NYLON_AUDIT on to record who is using the engine and who is hammering it; query anytime via GET /v1/audit.
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 a 47.1% lexical baseline to 86.0% recall / 82.9% QA, every step explainable and reproducible.
REST/OpenAPI with a web console, Python SDK, framework integrations, tenancy, auth, audit, backup and one-command deploys.
Keep pushing the recall ceiling and build academic and engineering evidence for the memory model.
Download a prebuilt binary, add one MCP config block, and two minutes later your agent starts remembering you.