The memory we have now save the summary and Casual links to a certain extend, what about the reasoning behind it the cause and effect? So i built one myself

CappyBara — Sun, 05 Jul 2026 18:18:01 +0000

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: (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.

Which is better Agent Traversing or Querying their memory?

CappyBara — Wed, 24 Jun 2026 10:45:42 +0000

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:

Why = The Edges (causal relationship between nodes)

What = The Node (events, decisions, issues)

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 (https://github.com/NodeDex/NodeDex-v0.1) run Locally.

Feel free to give a try and tell me what you guys think.

Solo-build 0v0

DEV Community: CappyBara

The memory we have now save the summary and Casual links to a certain extend, what about the reasoning behind it the cause and effect? So i built one myself

Which is better Agent Traversing or Querying their memory?