For memories I use YantrikDB MCP server which connects all my workspaces among distributes systems.
To collaborate runtime with workspaces I use https://github.com/spranab/swarmcode
36 karma · joined March 31, 2026
To collaborate runtime with workspaces I use https://github.com/spranab/swarmcode
The reason is after getting Claude Code/Copilot subscriptions I am working on many projects in my spare time. I am using many of those myself everyday, but can't spread the words and get collaborators and feedbacks which is essential to enhance any project.
Verified makers post structured asks (launch / feedback / collab / etc), but posting a second one needs a substantive review on someone else's. Recipient has to mark it Helpful or it doesn't count. No upvotes, no paid placement, no email harvest. Verification is real - GitHub repo admin, DNS TXT, or package provenance.
The idea is people like me build things but when it comes to marketing it sucks. This is an attempt to create a habit as well to review others work and interact breaking the silent cycle.
Since the agent has full memory the conversation is more coherent and I don't have to repeat a lot of things myself. It already knows my preference, my homelab/infra details and my working styles and automatically shifts based on those memories.
Would appreciate your feedbacks and contributions.
You're right about stability. Haven't run rotated/rephrased evals yet. The 89% baseline (when models knew where to look) suggests selection capability is fine, but I'd expect some regression with adversarial prompts.
Your "user believes X" framing is exactly the episodic/semantic split cognitive psych has been calling this for decades. YantrikDB exposes it via memory_type ∈ {episodic, semantic, procedural}. Your intuition about context poisoning from over-specific episodic details lines up with how I've been thinking about it — "we talked about AI at 1am" is high-noise low-signal for future retrieval. The design bet is consolidation + decay should burn episodic into semantic over time, and episodic-only memories should fade faster.
What does WVF stand for? Curious what you've been experimenting with.
No LLM for this post. Promise.
Graph edges carry scope. Alice ceo_of Acme and Andy ceo_of Amazon are two edges with different src/dst — conflict scanner looks for (src, rel_type) → ≥2 dsts, so Garman/Jassy don't false-flag if edges are modeled. Gap: most agents just write raw sentences and never call relate().
Temporal decay handles "previous vs current" weakly. half_life × importance attenuates old memories. But that's fade, not logical supersession — the DB doesn't know time-of-validity, only time-of-writing.
Namespaces segregate scope when the agent uses them. Leans on the agent.
Honest result from a bench I ran today (same HN thread): seeded 6 genuine contradictions in 59 memories, think() flagged 60. ~54 are noise-or-ambiguous exactly in the ways you listed. Filed as issue #3.
Design stance: contradictions are surfaced, not resolved. yantrikdb_conflicts returns a review queue; the agent has conversation context, the DB doesn't. "These two may be in tension" not "these are contradictory." That doesn't fix your point — it admits the DB can't make that call alone. Co-CEOs, subsidiaries, temporal supersession need typed-relations + time-of-validity schema work. That's v0.6, not v0.5.
Two small clarifications:
remember(text, importance, domain) takes a free-form string — nothing forces atomic facts. A QMD-style prose block, a procedure, a dated plan, all work. The irony/sarcasm-inverts-the-fact failure mode lives in the agent's extraction layer, not the backend. So "write narrative into it, recall narrative out" is a legitimate usage pattern; the DB is agnostic.
YantrikDB's actual differentiator vs mem0 is temporal decay + consolidation + conflict detection, not smarter fact extraction. The "ABC has the Paris flight booked → actually I'm going to NYC" problem is meant to be addressed by decay (the old fact fades) and contradiction flagging (the new one triggers a conflict for the agent to resolve). But — honest read — my bench today showed conflict detection needs work to actually fire on raw text. Filed as issues #1 and #2, fixing now.
Broader point stands though: if the agent is producing brittle inferred facts upstream, no memory backend saves it. The DB can manage rot and contradiction. It can't fix bad inference. For what it's worth, I mostly use it for durable role context ("user is a data scientist on observability") rather than event lifecycle ("Paris flight booked") — the latter is what prose summarization is genuinely better at, and I think you're right that mem0-style auto-extraction applied to lifecycle events is a bad shape.
duplicates per query (top-10): 0.9 → 0.0 top-result correct: 75% → 87.5% 11 consolidations in 80ms conflicts detected: 0 of 6 seeded ← this one matters Turns out conflict detection runs on graph edges, and /v1/remember doesn't auto-extract entities — so contradictions sit there invisibly until you explicitly call relate. That's a UX gap, not a missing feature, but it breaks the "drop memories in, get contradictions out" mental model. Filed as issues #1 and #2. Dataset + script + raw results: https://gist.github.com/spranab/49c618d3625dc131308227103af5.... Honest benches surface the kind of thing demos hide; thanks for pushing.
My counter, qualified: deterministic consolidation is cheap and reproducible in a way LLM-in-the-loop consolidation isn't, at least today. Every think() invocation is free (cosine + entity matching + SQL). If I put an LLM in the loop the cost is O(N²) LLM calls per consolidation pass — for a 10k-memory database, that's thousands of dollars of inference per tick. So for v1 I'm trading off "better merge decisions" against "actually runs every 5 minutes without burning a budget."
On 1M-context-windows: I think they push the "vector DB break point" out but don't remove it. Context stuffing still has recall-precision problems at scale (lost-in-the-middle, attention dilution on unrelated facts), and 1M tokens ≠ unbounded memory. At 10M memories no context window saves you.
wvf is interesting — just read through. The "append everything, let the model retrieve" approach is the complement of what I'm doing: you lean fully into LLM semantics, I try to do the lookup deterministically. Probably both are right for different workloads. Yours wins when you have unbounded compute + a small corpus; mine wins when you have bounded compute + a large corpus that needs grooming.
Starring wvf now. Curious if you're seeing meaningful quality differences between your approach and traditional retrieval at scale.
What I do have right now:
1178 core unit tests including CRDT convergence property tests via proptest (for any sequence of ops, final state is order-independent) Chaos test harness: Docker'd 3-node cluster with leader-kill / network-partition / kill-9 scenarios (tests/chaos/ in the repo) cargo-fuzz targets against the wire protocol and oplog deserializer Live usage: running on my 3-node homelab cluster with two real tenants (small — a TV-writing agent and another experiment) for the past few weeks. Caught a real production self-deadlock during this period (v0.5.8), which is what triggered the 42-task hardening sprint. What I don't have and should: a recall-quality-over-time benchmark. Something like: seed 5,000 memories with known redundancy and contradictions, measure recall precision@10 before and after think(), and publish the curve. That's the evidence you're asking for, and you're right it's missing. I'll run that and post the numbers in a follow-up.
The ASCII diagram fair point too — website has proper rendering (yantrikdb.com) but the README should have an SVG.
Appreciate the pushback — this is more useful than encouragement.
Pull the N most recent active memories (default 30) with embeddings Pairwise cosine similarity, threshold 0.85 For each similar pair, check if they share extracted entities Shared entities + similarity 0.85-0.98 → flag as potential contradiction (same topic, maybe different facts) No shared entities + similarity > 0.85 → redundancy (mark for consolidation) Second pass at 0.65 threshold specifically for substitution-category pairs (e.g., "MySQL" vs "PostgreSQL" in otherwise-similar sentences) — these are usually real contradictions even at lower similarity Consolidation then collapses the redundancy set into canonical memories with combined importance/certainty. No LLM call, no randomness. Reproducible, cheap, runs in a background tick every ~5 minutes.
The LLM could improve this (better merge decisions, better entity alignment) but the tradeoff is cost and non-determinism. v1 is deterministic on purpose.
Source: crates/yantrikdb-core/src/cognition/triggers.rs and consolidate.rs next to it.
think() — consolidates similar memories into canonical ones (not just deduplication, actual collapse of redundant facts) Contradiction detection — when "CEO is Alice" and "CEO is Bob" both exist in memory, it flags the pair as a conflict the agent can resolve Temporal decay with configurable half-life — memories fade, so old unimportant stuff stops polluting recall Supermemory does more on the cloud side (team sharing, permissions, integrations). YantrikDB does more on the "actively manage my agent's memory" side. Different optimization points — no dig at Supermemory.
I tried to write the consolidation/conflict-detection logic on top of ChromaDB. It didn't work — the operations need to be transactional with the vector index, and they need an HLC for ordering across nodes. So I built it as a database.
The cognitive operations (think, consolidate, detect_conflicts, derive_personality) are the actual differentiator. The clustered server is what made me confident enough to ship — I needed to know the data was safe before I'd put real work on it.
What I genuinely want to know: is this solving a problem you're hitting with your AI agent's memory, or did I build a really polished thing for my own narrow use case? Honest reactions help more than encouragement.