The determinism trade-off is genuinely interesting — auditability over fuzziness is a real design philosophy, not just a limitation.
We've been building something that tries to avoid forcing that choice. Engram uses three strategies in parallel: vector embeddings (nomic-embed-text via Ollama, local-first), BM25 keyword, and temporal recency — merged with Reciprocal Rank Fusion. Each result comes back with an explicit similarity score and the tier it came from (working memory / long-term / archived), so the retrieval path is still traceable even when it's fuzzy.
We also layer on a graph component similar to yours — entity-relationship extraction that augments top results with connected context. The difference is that graph is additive on top of embedding retrieval rather than the primary mechanism.
The place your approach wins clearly is corpus-specific precision. If the graph is built from your actual usage (your JWT/authentication example), tag traversal will reliably surface relationships that vectors would miss or dilute with internet priors. That's a real advantage for execution traces and project memory.
Still working through the right defaults for consolidation (when to summarize old working memories vs keep them granular). Curious whether you've thought about memory aging in your model.
The inspectability angle is genuinely useful, being able to trace exactly why something was retrieved is something vector search can't offer, and the tag-receipt approach is clean for structured knowledge.
One thing I'm trying to understand: the README calls this "semantic" retrieval, but looking at the Unified Field Equation in the whitepaper, the core scoring is tag intersection with temporal decay: W(q,a) = (shared tags) × γ^(graph distance) × (recency). That's weighted keyword matching, which is deterministic precisely because it's lexical, not semantic.
The vector.ts also has MockSoulIndex as a no-op stub with a note saying dense vector search is "optional augmentation" that's currently disabled so no embeddings are running in practice.
I've been building in this space with hand-written TypeScript (no AI codegen) and the line between "semantic" and "keyword" matters a lot to users. If someone stores "the JWT conversation" they won't find it by querying "authentication."
Is the tag extraction smart enough to bridge that, or is explicit tagging on the user to handle?
The /compact trigger is a clean pattern — agent-initiated but human-confirmed. Makes the interface feel more like a review than an interruption.
The retroactive feeding of recorded sessions is underrated. That's basically supervised compaction - you're labeling what mattered in hindsight, which is almost always cleaner signal than in-flight decisions.
I suspect the labs are doing something like this at scale but the hard part is that "what mattered" is user-specific. A generic compaction model trained on aggregate data probably smooths over the individual coherence preferences that make it actually useful.
We ended up open-sourcing the memory layer as an MCP server (engram-mcp) if youre interested at how we handled the certainty/recall side.
Interested in what your session recordings look like structurally or are they raw transcripts or do you extract structure before feeding them in?
Interesting approach with the hierarchy. I went the opposite direction with engram-mcp — flat structure, 5 tools, semantic search via Ollama (nomic-embed-text) with keyword fallback when Ollama isn't running. SQLite-backed. The bet is that most agents don't need tiered recall, they just need "find the thing I said about X." npx -y @cartisien/engram-mcp if you want to try it.
Curious how the L0/L1 hierarchy plays out in practice - do agents actually use the deeper levels?
> I’m sticking with humans for the moment
Haha totally get this statement.
The HitL fine-tuning angle is exactly right. The labeled dataset you're building (good/bad/stylistically-wrong memory events) is probably worth more than the compaction itself. Coherence preferences are surprisingly personal — what reads as "not correct based on my style" is hard to spec without examples.
The loop-pruning maps really cleanly to the contradiction detection in our setup. A model circling the same state N times is often because it stored an inconclusive result with the same confidence as a resolved one they look identical at recall time. Tagging memory entries with a status [open, resolved, or contradicted] before they go in cuts a lot of that.
On the autonomy question: we ended up treating certainty as continuous rather than binary. Low-certainty memories stay soft, high-certainty ones get promoted. Automatic compaction only operates on the low end, higher certainty entries are off-limits without explicit override. That lets you keep the autonomy without the coherence risk. The failure mode shifts from "deleted something important" to "kept something stale too long," which feels more recoverable.
Would be curious what your pruning signal looks like at the turn level — are you scoring relevance per-turn retroactively, or flagging at write time?
Been saying this for a while. Vector similarity is the wrong primitive for agent memory. It finds things that sound related, not things that are actually relevant given current context and what the agent already knows.
The "ditching vector databases" framing is a bit dramatic since you still need embeddings somewhere, but the point stands that a raw vector store with no resolution layer is basically a pile of notes your agent can't reason about. You need conflict detection, certainty weighting, temporal scoping. Otherwise you're just building a fancier version of the same problem
Concurrent writes are the right problem to be solving. Most agent memory implementations assume a single writer and fall apart the second you have parallel tool calls or multi-agent setups hitting the same store.
Curious how you're handling write conflicts at the semantic level though, not just the database level. Two agents writing contradictory facts concurrently is a different problem than two agents writing to the same row. Does the resolution happen at the DB layer or does the application need to handle it?
You're right, and it's the part that keeps me up. We handle it with versioned writes — each memory has a createdAt, observedAt, and a validUntil that can be set explicitly or inferred from context. Temporal scope gets embedded as metadata: "as of last session" vs "persistent fact."
Causal ordering is harder. Right now we surface both conflicting versions during retrieval with timestamps and let the agent reason about which is authoritative. It's not a complete solution — the agent can still pick wrong without the right reasoning context.
What you're describing is architecturally the right answer. We haven't built proper write-ordering yet. That's probably where the next cycle goes.
Human-driven compaction is interesting — you sidestep the "what's worth keeping" problem by putting a person in the loop. The tradeoff I've hit is that agents running autonomously need it to happen automatically or coherence degrades fast between sessions.
For pruning we landed on a last-touched timestamp + recall frequency counter per memory. Things not accessed in N sessions that were weakly formed to begin with get soft-deleted. Human review before hard delete is probably better UX if your setup allows it.
Curious what "dead ends" look like in yours; conversational chains that didn't resolve, or factual ones?
The scoring layer sits between ingestion and storage. Incoming items get evaluated on a few axes: source reliability (did the agent observe this directly or was it told?), semantic distance from existing memories, and recency weighting for time-sensitive facts.
Contradiction detection runs as a separate step - we embed the incoming memory, similarity-search against existing ones, and score the pair for logical consistency. If it trips a threshold, it gets stored with a conflict flag and a link to the contradicting memory rather than silently overwriting.
The agent sees both during retrieval and reasons about which to trust in context. Sounds like overhead but it's fast — the scoring is a simple feedforward pass, not another LLM call.
One thing I've been wrestling with building persistent agents is memory quality. Most frameworks treat memory as a vector store — everything goes in, nothing gets resolved. Over time the agent is recalling contradictory facts with equal confidence.
The architecture we landed on: ingest goes through a certainty scoring layer before storage. Contradictions get flagged rather than silently stacked. Memories that get recalled frequently get promoted; stale ones fade.
It's early but the difference in agent coherence over long sessions is noticeable. Happy to share more if anyone's going down this path.
The determinism trade-off is genuinely interesting — auditability over fuzziness is a real design philosophy, not just a limitation.
We've been building something that tries to avoid forcing that choice. Engram uses three strategies in parallel: vector embeddings (nomic-embed-text via Ollama, local-first), BM25 keyword, and temporal recency — merged with Reciprocal Rank Fusion. Each result comes back with an explicit similarity score and the tier it came from (working memory / long-term / archived), so the retrieval path is still traceable even when it's fuzzy.
We also layer on a graph component similar to yours — entity-relationship extraction that augments top results with connected context. The difference is that graph is additive on top of embedding retrieval rather than the primary mechanism.
The place your approach wins clearly is corpus-specific precision. If the graph is built from your actual usage (your JWT/authentication example), tag traversal will reliably surface relationships that vectors would miss or dilute with internet priors. That's a real advantage for execution traces and project memory.
Still working through the right defaults for consolidation (when to summarize old working memories vs keep them granular). Curious whether you've thought about memory aging in your model.
Repo if curious: github.com/Cartisien/engram (http://github.com/Cartisien/engram)