Every AI agent framework in 2026 has some form of memory. Store a key-value pair, retrieve it later, maybe add a TTL. Problem solved, right?
Not even close.
The Memory Problem No One Talks About
Here's what happens when you give an agent flat key-value memory:
A digital care coordinator agent monitors a patient's records. It stores findings as separate memory entries: patient_vitals, medication_history, cardiac_risk_factors, sleep_irregularities. Clean, organized.
Meanwhile, a lab assistant agent is optimizing experimental designs for a drug trial. It stores: compound_efficacy, cardiac_biomarkers, dosage_response_curves.
The connection between the patient's cardiac risk factors and the lab's cardiac biomarker research? Gone. Invisible. Two agents sitting on related knowledge with no way to discover it.
This isn't a contrived example. It's what happens every day in every agent system using flat memory stores — in hospitals, research labs, and clinical workflows.
What a Knowledge Graph Changes
A knowledge graph doesn't just store facts — it stores relationships between facts. When an agent writes a note about cardiac risk factors and links it to [[Cardiac Biomarkers]], that connection is a first-class entity in the system. It can be traversed, queried, and discovered.
This changes three things fundamentally:
1. Agents discover what they don't know they know.
With flat memory, an agent can only retrieve what it explicitly searches for. With a graph, it can ask: "What's connected to X within 2 hops?" and find relationships it never explicitly created. A care coordinator could discover that a patient's sleep irregularities are linked to a medication whose cardiac biomarkers are being studied in an active trial — without anyone explicitly making that connection.
2. Multi-agent collaboration becomes natural.
A care coordinator agent flags a patient's worsening vitals. A lab assistant agent logs promising results for a new cardiac compound. If both mention [[Cardiac Biomarkers]], the graph links them automatically. A clinical decision agent can traverse from patient vitals → cardiac biomarkers → compound efficacy and surface a potential treatment option none of them could individually.
3. Knowledge compounds instead of accumulating.
Flat memory grows linearly. A knowledge graph grows combinatorially — each new node potentially connects to every existing node. After 1,000 notes with wiki-links across patient records, lab results, and wearable data, you don't have 1,000 facts. You have a web of clinical relationships that's worth far more than the sum of its parts.
The Current Landscape
The agent memory space is heating up. Mem0 raised $24M and processes 186 million API calls per quarter. Letta (formerly MemGPT) is building OS-inspired memory hierarchies. LangChain has LangMem. Everyone agrees agents need memory.
But here's the gap: almost all of these are flat stores with optional vector search. They're optimized for "remember this, recall that." They're not optimized for "discover connections I didn't know existed."
The enterprise world figured this out years ago. Knowledge graphs power Google's search, Amazon's recommendations, and every pharmaceutical company's drug discovery pipeline. The agentic AI world is still catching up.
What We Built
We built Smriti — a self-hosted knowledge store for AI agents with a knowledge graph at its core.
It's written in Rust (because when agents make millions of memory operations, speed matters), stores everything in SQLite (because self-hosted means no cloud dependency), and speaks MCP natively (because that's becoming the standard protocol for agent-tool communication).
The key design decisions:
Wiki-links as first-class connections. When an agent writes
[[Cardiac Biomarkers]]in a note, that creates a traversable edge in the graph. No separate API call needed. A care coordinator logging patient data and a lab agent logging trial results automatically connect through shared concepts.Graph traversal as a tool. Agents can BFS/DFS through the knowledge graph to find related notes within N hops. This is how a clinical decision agent discovers that a patient's symptoms connect to an active drug trial three hops away.
Self-hosted by default. Your data stays on your machine. No API costs, no cloud dependency, no vendor lock-in. Critical for healthcare use cases where patient data governance and HIPAA compliance are non-negotiable.
MCP server built in. Start with
smriti mcpand any MCP-compatible AI can use it as a knowledge store. 8 tools: create, read, search, list, graph, memory_store, memory_retrieve, memory_list.
Who Is This For?
Developers building agentic workflows who need their agents to:
- Remember across sessions (not just within a conversation)
- Discover connections between stored knowledge
- Share a knowledge base across multiple agents
- Keep all data local and under their control
It's not for everyone. If you need cloud-hosted memory with managed infrastructure, Mem0 is great. If you need deep research-grade memory hierarchies, Letta is interesting.
But if you want a fast, self-hosted knowledge store where agents can build and traverse a knowledge graph — whether for healthcare coordination, lab automation, or any domain where relationships between data matter — that's what we built.
Try It
cargo install smriti
# Care coordinator logs patient data with wiki-links
smriti create "Patient 4721 Assessment" \
--content "Elevated resting heart rate from [[Wearable Data]]. History of [[Cardiac Risk Factors]]. Current medication may affect [[Cardiac Biomarkers]]."
# Lab assistant logs trial findings
smriti create "Trial CB-209 Results" \
--content "Compound shows 40% improvement in [[Cardiac Biomarkers]]. Correlates with [[Dosage Response Curves]]. Monitor [[Patient Vitals]] in Phase 2."
# Discover the connection
smriti graph --note 1 --depth 2
# Start the MCP server
smriti mcp
GitHub: github.com/smriti-AA/smriti
Crates.io: cargo install smriti
Top comments (4)
Great write-up — the flat-store critique is spot on. The "1,000 facts → a web of clinical relationships" framing is exactly why graph topology matters for agents that need to reason, not just retrieve.
Smriti looks like a well-scoped tool for lightweight use cases. If anyone needs this same design — self-hosted, no cloud, MCP-native, knowledge graph at the core — but wants a production-grade foundation, it's worth looking at ArcadeDB (arcadedb.com).
A few reasons it fits this use case directly:
pip install arcadedb-embedded-minimal— runs entirely in-process, no server process, no Java required (JRE is bundled)The main trade-off vs. Smriti: ArcadeDB is a full database (~160MB embedded), not a lightweight Rust binary on top of SQLite. If you need something that ships in 5MB, Smriti makes sense. If you're building something that will actually grow, ArcadeDB removes the ceiling.
Happy to share the embedded Python quickstart if useful.
Thanks for the comments Luca (and also sharing about ArcadeDB)
ArcadeDB is impressive here. Multi-model in one engine + ACID + native MCP is a strong stack, and you're right that the ceiling question matters more than binary size for teams that are actually growing.
The gap I keep running into though isn't at the storage/traversal layer — it's the layer above it. Both Smriti and ArcadeDB answer "how do agents store and query knowledge." What they don't answer is: what happens when agents need to reason about their own memory state?
Concretely: a clinical agent shouldn't just traverse [[Cardiac Biomarkers]] — it should be able to fork its memory state before committing a risky hypothesis, run against the sandbox, and only merge back if it validates. Without fork/merge as first-class primitives, you're one bad concurrent write away from corrupting shared knowledge across an agent fleet — even with ACID underneath.
That's the problem we're building around with Agent Memory Cloud. The storage engine is almost the solved part. The unsolved part is giving agents safe, structured control over their own evolving knowledge.
Curious whether ArcadeDB has thought about exposing fork/branch semantics over the MCP layer — that seems like a natural next step given the ACID foundation you already have.
The ACID multi-agent write argument is the one I find most underrated in these discussions.
Most lightweight graph stores for agents are designed around single-agent read-heavy workloads — the moment you have two agents updating the graph concurrently based on conflicting observations, you need proper transaction semantics or your knowledge base silently becomes inconsistent.
Nobody talks about this until it bites them in production.
The native MCP server in v26.3.1 is interesting — curious how you handle schema evolution over the MCP interface. One of the friction points I keep running into in agent-graph setups is that the agent's mental model of the graph topology drifts as the schema changes under it. Does ArcadeDB expose schema introspection through the MCP layer, or does the agent need to be re-prompted when the graph structure changes?
The 160MB vs. 5MB tradeoff is real but I'd argue it's the wrong axis for most teams choosing at this stage. The ceiling question matters more — what does ArcadeDB's query expressiveness look like when you need to traverse provenance chains? Not just "who knows X" but "who established X, when, based on what evidence, and who has since contradicted it."
Alessandro — thanks for your comments, the schema drift problem is the most underrated failure mode in agent-graph systems right now, and you've framed the provenance question exactly right.
"Who established X, when, based on what evidence, and who has since contradicted it" — that's not a query, that's a memory model. And most stores treat it as an afterthought.
We're building Agent Memory Cloud specifically around that. Every memory write is a first-class episode: agent_id, timestamp, confidence score, source evidence, and a contradiction index that surfaces when two agents write conflicting observations to the same node. The graph doesn't silently merge them — it preserves both, flags the conflict, and lets a resolver agent (or a human) adjudicate. The provenance chain you described is the primary index, not metadata bolted on afterward.
On schema drift: the approach we're taking is schema-soft by default. Agents write what they observe; the graph infers topology from relationship patterns rather than requiring agents to know the schema upfront. When the structure evolves, agents query for what's there rather than assuming what should be there. It's closer to how a knowledge graph should work than how most databases actually work.
You're right that ACID is underrated — but ACID alone only solves the write-collision problem. The harder problem is conflicting truths that are each individually valid from the observing agent's perspective. That's where fork/merge semantics matter: let agents branch before a risky write, validate in isolation, merge only what holds. We're building fork and merge as first-class API primitives for exactly this reason.
Building this in public — happy to share more if you're interested.