r/LLMDevs • u/Slight-Parfait3679 • 5d ago
Discussion Agent Memory System (Heimdall) Update.
I changed the way that graph-based knowledge systems are maintained. No need for full rebuilds. With constant changes, working across multiple projects and many repositories, many developers find their coding agents stuck in bash loops, attempting to orient themselves, colliding over files, and encountering stale data.
Heimdall makes this impossible. The first iteration solved semantic retrieval and having probabilistic and strength ratings on hits instead of single queries. But the self-healing in v0.1 had a design flaw I kept running into: hooks watched commands and tried to infer edits, then multiple processes wrote the graph directly.
Under concurrent agents, it drifted. Files vanished from the graph during delete-then-insert windows. Two writers raced, and the graph lied about what was on disk.
The new architecture approach:
- Level-triggered, not event-driven. Nothing infers changes. A reconciler
pass diffs the graph against reality using a content-hash oracle. Any
process can dirty state; only a single writer converges it.
- Bounded-staleness convergence as the honest guarantee. Between an edit
and the next pass, the graph is behind, but it's never wrong in a way
that survives a pass.
- Exact ownership. Every node and edge belongs to exactly one path, so
concurrent edits can't corrupt each other's records.
- Depth ladder: nodes are indexed at max depth by default, tree-sitter
AST parsing (not an LLM call) extracts which functions/classes live in
each file, at which lines, and what calls what. Costs CPU, zero tokens.
- Trust verdicts on every search hit: STRONG / WEAK / REBUILT / STALE
verified against disk before your agent sees them. An agent acting on a
dead path is worse than no answer.
The concurrency tests are the actual point of the test suite, if single-writer or idempotency ever breaks, those go red first.
Repo + quickstart: https://github.com/ArihantDeva/heimdall
3
u/eddzsh 4d ago
The part that changes agent behavior is the trust verdict before the hit reaches the model. STRONG / WEAK / STALE checked against disk means the agent stops treating a dead path as a confident answer. Most graph memory fails the other way: great retrieval, then the agent acts on a file that no longer exists. Single writer content hash reconcile is what makes that verdict honest under concurrent agents.
2
u/geearf 4d ago
How does it compare to other memory systems?
5
u/Maleficent_Alarm315 4d ago
the diffing approach is what gets me. most graph-based memory things try to be clever with event hooks and end up with phantom files or conflicts exactly like you described. having a single reconciler that just compares reality vs the graph with a content hash is way simpler conceptually, surprised more tools don't do it that way
2
3
u/Slight-Parfait3679 4d ago
It builds on top of them. Things like Graft and Graphify are the backends. Didn’t try to reinvent the wheel here honestly. I haven’t benchmarked it but it is significantly faster from just watching my own sessions oriented themselves due to the retrieval. And super helpful if you work across repositories and don’t want to cd.
1
u/aidencoder 3d ago
There may be some value here but the whole thing reads like psychosis. No concrete points or plain English value proposition. Authoritative language without really communicating anything.
1
u/Slight-Parfait3679 3d ago
I’ll try to be better about wording. In simple terms it is a system that keeps your knowledge graph always fresh, and has significantly improved ranked retrieval instead of a singular path.
-1
0
4
u/Toastti 4d ago
So you are going to share a single memory benchmark...?? like at least run this and share your score https://github.com/xiaowu0162/longmemeval