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 (0)