In agentic systems, is the process just as valuable as the outcome? We obsess over 'what happened,' but should we care more about the 'why'? When does causality outweigh the event itself and crucially, and are there any memory architectures that store causal thread not just the raw output?
The thing that finally broke me wasn't my agent forgetting stuff. Forgetting is
annoying but it announces itself the agent asks again, you sigh, you re-explain.
What broke me was the silent version: my agent confidently re-proposed an
approach we'd tried and abandoned a month earlier. Another time it planned
against a decision we'd replaced two weeks before the old decision was still
sitting in its notes, looking exactly as authoritative as the new one. Nothing
failed loudly. It just quietly burned the hours again.
Generic memory fixes forgetting. Nothing I tried fixes being confidently
wrong about the past because that's not a recall problem, it's a status
problem. "We ruled this out," "this was replaced," "this is still unverified"
that's not what a similarity search returns. So I spent 3 months building the
other half:
NodeDex a local graph of your project's reasoning, built automatically
from your agent's conversations by a background pipeline (the agent never has
to remember to save):
- dead-ends are first-class: an enumerable list of what was tried and
abandoned, with the why the agent is taught to check it BEFORE proposing
- decisions carry their why + the alternatives that lost
- when something gets replaced, nothing is deleted — a `supersedes` edge
points old truth → current truth, so the agent can't mistake stale for current
To be clear about what it's NOT: it doesn't replace Claude's native memory or
your fact store those remember *notes and preferences*, and they're good at
it. This is a different job (the project's decision history). Run both.
You can poke it in 60 seconds, no API key:
```
npx nodedex demo
```
That serves a small sample project graph over MCP. Point Claude (or any MCP
agent) at it and ask: *"Is 'keep the counters in Redis' still the current
decision?"* then watch it follow the supersede edge and answer with the
replacement instead of the stale one. That moment is the whole product.
Honest limits, before you find them:
- the dead-end check is a strong nudge (server instructions + a skill), not a
hard block a pre generation hook gate is on the roadmap
- extraction needs a smart, big context model (Gemini Flash-Lite ≈ half a cent
per session; my 12B local test *understood* everything but failed the strict
structured passes floor is ~27-30B local with real 16k+ context)
- it's early and solo-built (1196 tests pass, but it's been on npm for three days)
Local SQLite, AGPL, graph never leaves your machine. Repo: [link]
I'd love for people to break it especially: does your agent actually check
the dead ends unprompted in your setup, or does it need the nudge? That's the
question I most need real world answers to.
Which do yall use? The Agent Traverse or Query. My take is traversal.
Since querying is fuzzy and noisy. Traverse get your agent the info they want and need, but not traverse aimlessly.
My approach is saving the why and what:
Together it make the whole causal chains.
Where do the Agent start in the graph? Based on its current task/etc, the Agent can traverse and understand the topic fully or view the causal chains which contain the Root node to the leaf node.
The Graph evolve with your Agent and your Agent Experience Compound.
Repo in comment, run Locally.
Feel free to give a try and tell me what you guys think.
Solo-build 0v0
TL;DR — most "agent memory" stores what your agent said. I wanted one that stores what it figured out: what it tried, why it ditched it, what it decided as a graph the agent walks. Open-source, local-first.
The thing that actually wastes my agent's time isn't forgetting facts — it's re-deriving. It re-proposes an approach it tried and abandoned three sessions ago. It re-investigates a cause it already ruled out. Facts survive a context reset; the reasoning doesn't.
So NodeDex stores the reasoning residue as a graph you traverse, not query:
- dead-ends are permanent nodes — the approach plus why it was dropped
- decisions keep their reason and what they were based on
- causal chains link problem → solution
What that looks like (the screenshot): I fed it a transcript of someone debugging a CRISPR knockout stuck at 5% efficiency. A fresh agent walking the graph immediately sees — the vector backbone was already ruled out (the control hit 75%), exon-2 methylation was dismissed, two guides got thrown out for seed-matching an enhancer → so the call was eSpCas9 + a redesigned guide. One ~29-step chain, dead-ends frozen as nodes, so the next session won't repeat them.
It's not a mem0 / RAG replacement. Those recall what's true; this captures the reasoning around it — you'd run both.
ince it's early and solo-built: extraction quality is model-bound (I run Gemini Flash / local models). It can over-segment one conversation. Capture runs as a background pipeline, so setup has a couple of moving parts. And no clean benchmark yet — retrieval scores (LoCoMo etc.) measure fact-fetch, which isn't what this does; if you know a benchmark for "did the memory stop the agent repeating a dead-end," I'd love the pointer.
Repo (AGPL, local-first): https://github.com/NodeDex/NodeDex-v0.1
Try to break it point it at your messiest agent logs and tell me where the extraction is dumb. Genuinely curious: does "traverse, don't retrieve" hold up in your workflow, or is top-k retrieval just good enough?
Repo: https://github.com/NodeDex/NodeDex-v0.1
What it is
NodeDex save what your agent did/learn/etc through extracting the Cot/output/user output and feeding it through a multi step pipeline that extract the casual chains/relationship between things and then linking it together and forming a chain where it include the root of a thing to the leaf and it evolves over time
how it's different from RAG or another memory system
RAG stores text and finds the bits similar to your question — it remembers what your agent knows. NodeDex remembers what it tried — including the dead-ends and why. Recall vs. experience.
Runs on your own model — local (Ollama/LM Studio) or cloud (OpenRouter). Self-hosted.
Still early + solo-built, feel free to try it out OvO ,would love feedback on whether this is a real pain for anyone else running local agents.
WebUI Preview(coming soon)fell free to give suggestions.
