Thomas Connally, Perseus Computing · July 2026
Six months ago my AI agent couldn't find anything in my 2,000-note Obsidian vault. Today it has perfect recall across tens of thousands of facts, runs fully offline, and fits in a single 8MB binary. Here's what I learned building the thing that replaced it.
I was an Obsidian true believer. 2,000+ notes, bidirectional links, daily journals, the whole thing. When MCP support landed for Obsidian, I wired it up to my Hermes agent and felt like a genius. My agent could read my notes, search my vault, and pull context from years of accumulated knowledge.
Then the vault crossed ~1,500 notes and everything fell apart.
Search degraded to unusable. My agent started hallucinating file contents. Context windows ballooned with irrelevant markdown. The "memory" that worked beautifully at 200 notes became an active liability at 2,000. Every session burned tokens re-reading files it had already read a dozen times. There was no concept of importance — a grocery list and a critical architecture decision carried equal weight in search results.
The fundamental problem wasn't Obsidian. Obsidian is an incredible note-taking app — for humans. Humans can skim, prioritize, and context-switch. AI agents can't. They need memory that's structured for machine consumption, not prose organized for human browsing.
After six months of building and iterating, here's what I found agents actually require from a memory layer — none of which a note-taking app provides out of the box:
1. Hybrid search that actually works. Keyword search (grep) fails on paraphrased queries. Pure vector search hallucinates relevance on edge cases. You need FTS5 + dense embeddings with reciprocal rank fusion. My agent asking "what's our deployment strategy for Lambda?" should match a note titled "AWS Lambda provisioning playbook" even though they share zero keywords.
2. Importance and decay. Not all facts are equal. A production database password matters more than what I ate for lunch. Memory needs a weighting system — and facts should naturally decay unless reinforced. An agent shouldn't still be referencing a three-month-old bug workaround that was fixed two months ago.
3. Deduplication. Agents love to re-remember the same facts. Without content-aware dedup, your memory store becomes an echo chamber of near-identical entries, each one diluting search quality.
4. Bi-temporal history. Facts change. You need to know what was true then versus what's true now. An agent debugging a production incident needs to see the config as it existed at 3:14 PM, not the version you patched at 3:17 PM.
5. Encryption at rest. If your agent's memory contains API keys, architecture docs, and business logic, it needs to be encrypted. Not "encrypted in transit to someone's cloud." Encrypted on disk, with keys you control.
Perseus Vault is a single Rust binary. No Docker, no Postgres, no Python environment, no cloud dependency. It ships as an MCP server — drop it into any MCP-compatible agent (Claude Code, Cursor, Cline, Hermes, anything) and it exposes 57 tools for remember, recall, reflect, and search.
The design constraints were brutal and deliberate:
I don't trust benchmark numbers I can't reproduce, so the entire harness is offline and re-runnable. Here's what it looks like on real workloads:
For comparison, naive keyword search on the same paraphrased queries hits 4.2% recall@1. That's the difference between an agent that remembers and an agent that's guessing.
Every engineering decision is a tradeoff. Here are the ones I made that you should know about before adopting:
FTS5 index sits over plaintext. The underlying records are AES-256-GCM encrypted, but the FTS5 search index operates on plaintext for performance. If full disk encryption is part of your threat model this is a non-issue, but if you need search-index-level encryption, this is a gap. I'm upfront about it in the docs rather than hand-waving.
Bundled embeddings are smaller models. The offline embedding model that ships in the binary is fast and zero-dependency, but it won't match the semantic quality of a massive cloud-hosted embedding model. If you need maximum recall quality and have the infrastructure, you can point it at an external Ollama endpoint with a larger model.
It's an MCP server, not a database. Perseus Vault isn't trying to replace Postgres or SQLite for general-purpose storage. It's purpose-built as the memory layer for AI agents, exposed through MCP tools. If you need a general-purpose database, use one.
# Download the binary (Linux x86_64)
curl -L https://github.com/Perseus-Computing-LLC/perseus-vault/releases/latest/download/perseus-vault-linux-x86_64 -o perseus-vault
chmod +x perseus-vault
# Start it
./perseus-vault serve --db memory.db
# Wire it into your MCP client
# Add to your mcpServers config:
# {
# "perseus-vault": {
# "command": "perseus-vault",
# "args": ["serve", "--db", "~/.mimir/data/perseus-vault.db"]
# }
# }
Your agent can now remember, recall, and search across sessions. No Obsidian vault required.
If you're building agents in environments where cloud-only memory is a non-starter — defense, healthcare, finance, or just a homelab where you want control — we do integration pilots: we deploy into your environment and prove recall quality on your own data in 2–4 weeks.