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
supersedesedge 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: (Repo in comment)
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.
Top comments (8)
Quick one on the dead ends. They're stored with their why, but the why can expire. Say the graph has "ruled out keeping counters in Redis because we only had one server", and later the project adds a second server. The reason is gone, but the dead end still looks closed. Does the agent get nudged to check whether the original reason still holds, or is a dead end final? If it's final, the graph could end up confidently blocking an approach that has become the right answer, which is the mirror image of the stale decision problem you built this for. The supersedes edge keeping old truth around instead of deleting it feels exactly right, for what it's worth.
Good question and instinct.
A dead end isn't stored as final it's evidence bound. The "why" isn't prose, it's actual edges pointing at the constraint or fact that killed it. In your example, the dead end points at the "single server only" constraint as a node in the graph. When the project adds a second server, that constraint gets superseded the old one stays but carries a marker naming what replaced it. So the dead end's justification chain now visibly contains a dead premise, and the agent's standing instruction for a matching dead end is: cite it, propose differently, or say what changed. Dead ends can also themselves be superseded when a project re opens them permanent means never forgotten, not never reversed.
You did find a real weakness though: that stale marker used to live one hop away on the constraint, not the dead end so an agent reading the dead end alone saw a closed door and nothing forced the walk to the premise. That made me realize after reading your comment that I changed it: edges now carry the neighbor's currency inline, so the dead end's own view reads based_on → single-server-constraint (superseded_by: …). Zero hops to see the rot.
The fully mechanical version auto flagging everything that rested on a block when it gets superseded I'm treating as a review flag rather than auto invalidation: a dead end can rest on several premises, and killing one hinge doesn't always open the door. Someone still has to judge whether it's dead for the other reasons.
Appreciate this one it's the kind of edge case that only shows up when someone actually thinks through the model.
Thanks for sharing!
I like the split between memory and decision status. “We tried this and rejected it” is not just another remembered fact; it needs state, reason, and maybe expiry/revalidation. Otherwise the agent can avoid stale decisions but create stale dead ends.
Yes its different from memory , but its still memory and the community is already sick and tired of memory system , so im not sure what to position this as🥲
I would probably avoid positioning it as another "memory system" then.
The stronger framing might be decision trace or reasoning ledger. Memory sounds like "store more context." What you are describing is closer to "preserve why a decision happened, what evidence supported it, and what changed later."
That distinction matters because people are tired of vague memory promises, but they still need auditability. "The agent remembers things" is weak. "The agent can explain which prior decision caused this action" is much sharper.
I would avoid positioning it as another "memory system."
The stronger framing might be decision trace or reasoning ledger. Memory sounds like "store more context." What you are describing is closer to "preserve why a decision happened, what evidence supported it, and what changed later."
That distinction matters because people are tired of vague memory promises, but they still need auditability. "The agent remembers things" is weak. "The agent can explain which prior decision caused this action" is much sharper.
Repo : github.com/NodeDex/NodeDex-v0.1