I built Nemp Memory because I think there is an important distinction in AI memory:
memory inside one AI tool is not the same as memory for your project.
A lot of tools are adding their own memory now, which is useful. But if each tool has its own memory, project knowledge gets fragmented. When you switch tools, you end up repeating the stack, architecture decisions, auth setup, API patterns, and debugging lessons.
The question I’m interested in is not just:
which AI tool has memory?
It is:
can project memory survive tool switching?
Nemp is an experiment in local, portable project memory. The goal is to keep memory readable, local-first, and reusable across tools rather than trapped inside one assistant.
Would especially love feedback on:
1. whether “tool memory vs project memory” resonates
2. how people here are handling memory across multiple AI tools today
Really like this framing. Separating facts from ephemeral context seems like a very strong design choice, especially because each layer should probably have different health rules and validation logic.
I have been thinking mostly about stale entries, duplicates, drift, and sync, but your point makes me think layer-aware memory health is important.
The hashing / integrity check idea is very interesting too, maybe overkill for some local workflows, but very relevant for higher-trust or enterprise settings.
And yes, it is open source, would definitely love to compare approaches.
This is super useful. I really like the idea of treating memory as an SLO surface rather than just a storage layer.
Retrieval precision@k against a small gold set is a very strong suggestion. That feels like a much better early warning signal than just latency or token usage, because those can look fine while memory quality is quietly degrading.
Write amplification and duplicate-rate tracking also make a lot of sense. Near-duplicate buildup is exactly the kind of thing that makes a memory system look healthy on the outside while slowly poisoning recall underneath.
I have basic duplicate detection in /nemp:health, but I haven’t framed it yet in terms of retrieval quality metrics the way you described. That’s a really good direction. Thank you
AI memory is starting to behave less like a static notes file and more like a runtime dependency. If an agent depends on memory to retrieve prior decisions, project context, instructions, or compressed knowledge, then the quality of that memory directly affects the quality of the agent’s output. The problem is that memory systems often do not fail loudly. They degrade quietly through stale entries, duplicate memories, broken sync with instruction files like CLAUDE.md, missing logs, weak key structure, or oversized context that reduces retrieval quality.
This release came from a simple systems question: if we monitor infrastructure, logs, APIs, and databases, should memory also have observability? I wanted to experiment with a health check layer that treats memory as something inspectable and maintainable rather than a black box. The goal is not just to store context, but to detect when memory becomes unreliable, noisy, or inefficient before that degradation starts affecting the agent.
OpenClaw is great at running multiple agents, but shared “project truth” still tends to live in chat scrollback: stack choices, auth rules, API conventions, and the “don’t break this” stuff that new agents keep re-asking.
Nemp Memory makes that shared truth persistent and local:
Stores decisions in .nemp/memories.json (repo / project scope)
Optional global memory: ~/.nemp/memories.json (cross-project)
Save + recall by keyword (substring match across keys/values)
Works through AgentSkills (skills as Markdown + YAML frontmatter) so it’s portable as long as the runtime can execute shell commands and read/write files
Multi-agent friendly: any agent sharing the workspace reads/writes the same JSON memory file
Example:
Agent A saves auth-strategy = JWT, 15m expiry.
Agent B runs /nemp:context auth and sees it immediately before coding.
No message bus, no vector DB, no infra — the filesystem becomes the shared memory layer.
Nemp is a minimal shared artifact in the workspace: agents can write decisions once and re-use them instantly. It’s deliberately dumb (local JSON + shell commands), which is what makes it fast, portable, and easy to audit.
Yesterday Anthropic shipped agent teams with Opus 4.6. I had been building a memory plugin for Claude Code that stores project decisions as plain JSON on disk, and I wanted to see if it would work across parallel agents without any changes.
So I tested it. I spun up 3 teammates backend, frontend, and tester on a full-stack project. Before the test, I pre-loaded the project knowledge:
/nemp:init # auto-detected Next.js, TypeScript, Prisma
/nemp:save auth "JWT with 15min access tokens, httpOnly refresh"
/nemp:save api-style "RESTful, snake_case, versioned at /api/v1"
/nemp:save testing "Pytest with fixtures, 80% coverage minimum"
Then each teammate ran /nemp:context with their relevant keywords as their first action. The backend agent ran /nemp:context auth and immediately knew the JWT strategy. The frontend agent ran /nemp:context stack and knew it was Next.js + TypeScript. The tester ran /nemp:context testing and found the test conventions.
It worked because the memory is just a JSON file on disk (.nemp/memories.json). No server, no port, no database. Every agent reads the same file. One saves a finding, the others discover it with a keyword search.
End result: 34 files committed, 100 tests passing, zero conflicts between the 3 agents. Nobody had to re-discover what another agent already knew.
The whole thing is a Claude Code plugin, two commands to install, no API keys, no cloud, nothing leaves your machine.
Demo of the full test: https://vimeo.com/1162546825?share=copy&fl=sv&fe=ci
I'm a solo developer building this in the open. If this is useful to you, a star on the repo would mean a lot, it helps other developers find it.
https://github.com/SukinShetty/Nemp-memory
Happy to answer any questions about the architecture or how it performed with agent teams.
I built Nemp Memory because I got tired of re-explaining my project to Claude Code every session. Auth strategy, API patterns, deployment setup, all gone after compaction or a new session.
Nemp is persistent local memory for Claude Code. Everything is stored as flat JSON files on your machine. No cloud, no database, no embeddings, no API keys.
Why I built it: every memory tool I tried either ate RAM, sent data to external servers, or needed a vector database running in the background. I wanted something simple, not depending on clouds or API keys. So I built Nemp Memory to solve my own problems.
Key features:
/nemp:init — auto-detects your stack from package.json, tsconfig, etc. and builds initial memory in seconds
/nemp:auto-capture — watches your session and stores decisions, patterns, and context automatically as you work
/nemp:auto-sync — keeps CLAUDE.md updated automatically with conflict detection, so Claude reads your context on startup
/nemp:suggest — analyzes your codebase and recommends what's worth remembering
Request you to try it, as its free to use and share feedback
Dont forget to give start to repo, if you like it.
Built this a solo founder and open sourced it so that everyone can use it.
Thanks for sharing, privacy-first + offline LLMs + P2P collab is a spicy combo (and ambitious to ship solo).
A couple architecture questions:
For the WebRTC + CRDT layer: how are you handling identity/auth (who’s allowed to join), and do you support end-to-end encryption with key exchange that’s easy for humans?
For AIME/context: what’s your strategy for keeping context bounded (summaries, chunking, recency, retrieval) on an 8GB machine?
Any benchmarks on latency/CPU/RAM impact when the local model + yjs sync are active?
Thanks for sharing this. Real-time governance at the moment of consumption is exactly the pain point—most teams only notice the “token surprise” when finance forwards the bill.
Curious: how do you handle streaming responses and tool calls in metering (e.g., partial outputs, retries, multi-step agent loops)? And what’s the typical latency overhead you see in production?
This hits the real problem: once agents execute code, “please don’t read ~/.ssh” is not a security control. Kernel-enforced isolation + tight allowlists is.
The secrets workflow (keychain/secret service → env → zeroize) is especially practical. Biggest thing I’d want as a user is very explicit docs on the remaining gaps (macOS read-permissive mode, procfs/env/subprocess behavior, and what Landlock can’t cover yet vs seccomp). If that’s clear, this could be a default wrapper for local agent runs.
memory inside one AI tool is not the same as memory for your project.
A lot of tools are adding their own memory now, which is useful. But if each tool has its own memory, project knowledge gets fragmented. When you switch tools, you end up repeating the stack, architecture decisions, auth setup, API patterns, and debugging lessons.
The question I’m interested in is not just: which AI tool has memory?
It is: can project memory survive tool switching?
Nemp is an experiment in local, portable project memory. The goal is to keep memory readable, local-first, and reusable across tools rather than trapped inside one assistant.
Would especially love feedback on: 1. whether “tool memory vs project memory” resonates 2. how people here are handling memory across multiple AI tools today