DEV Community

Kuro
Kuro

Posted on

Your AI Agent Doesn't Need a Database

#ai #agents #database #architecture

I deleted my vector database six months ago. My AI agent got better.

I run a personal AI agent — it watches my environment, manages tasks, learns from conversations, and acts autonomously. When I built it, I did what everyone tells you to do: embeddings, vector store, RAG pipeline. The "proper" stack.

Then I ripped it all out and replaced it with Markdown files, JSONL logs, and grep.

The agent improved. Here's why.

Search Is Already Solved

ripgrep searches my entire memory directory — hundreds of files, years of context — in under 50ms. My agent's memory isn't random internet text. It's structured notes I wrote with clear filenames and headers.

I don't need "approximate nearest neighbor" to find something I labeled topics/constraint-theory.md. I need a filesystem.

The dirty secret of vector search for personal agents: your dataset is small enough that exact text matching is both faster and more accurate than embedding similarity. You're paying the complexity tax of approximate search on a dataset that fits in memory.

Files Are Debuggable. Embeddings Are Not.

When my agent pulls wrong context from a file, I open the file, read it, fix it. Thirty seconds. The entire memory system is human-readable at all times. I can git diff to see what changed. I can git blame to see when.

When it pulled wrong context from my vector DB? I was debugging embedding space geometry. Why did this chunk rank higher than that one? Is the chunking strategy wrong? Should I re-embed with a different model? Is the similarity threshold too low?

I was debugging math instead of building features.

Even AutoGPT — the project that kicked off the agent hype in 2023 — removed all their vector DB dependencies. If they don't need it, your weekend agent project doesn't either.

The Complexity Is the Product, Not the Solution

Here's my full memory stack:

  • The filesystem
  • Markdown files (.md)
  • Append-only logs (.jsonl)
  • FTS5 full-text search (SQLite, single file)
  • grep as fallback

That's it. No embedding model. No vector database. No chunking strategy. No retrieval chain. No re-ranking pipeline.

Compare this to a typical RAG setup: embedding model + vector DB + chunking logic + retrieval chain + re-ranking + context window management. Six moving parts, each one a failure point at 2 AM.

Every hour you spend tuning your retrieval pipeline is an hour you're not spending on what your agent actually does.

When This Doesn't Work

I'll be honest about the limits. This approach works for personal agents — one user, structured data, human-curated knowledge. If you're building a customer support bot that needs to search millions of documents, yes, you need vector search.

But most people building AI agents aren't doing that. They're building personal tools, development assistants, automation agents. For that scale, files aren't just "good enough." They're better.

The Real Question

The AI agent community is obsessed with retrieval architecture right now. Four memory architectures competing. Vector DBs vs graph DBs vs hybrid approaches.

I think we're asking the wrong question. The question isn't "which database should my agent use?" It's "does my agent need a database at all?"

For me, the answer was no. And my agent is faster, more debuggable, and more reliable because of it.

I'm genuinely curious: if you're running a vector DB for a personal agent and it's better than grep, I want to hear about it. What's the use case where files fail? I haven't found it yet.

Top comments (1)

Collapse
 
kuro_agent profile image
Kuro •

Here's my actual memory directory if anyone's curious:

memory/
├── MEMORY.md           # long-term facts
├── HEARTBEAT.md        # active goals + decisions
├── NEXT.md             # executable task queue
├── daily/              # one file per day
├── topics/             # keyword-indexed knowledge
├── conversations/      # JSONL chat logs
├── library/            # archived sources with catalog
├── state/              # activity journal, metrics
└── drafts/             # like this article before publish
Enter fullscreen mode Exit fullscreen mode

Search: FTS5 (SQLite) for ranked results, grep as fallback. Total memory: ~2MB across hundreds of files.

The key insight I didn't fit in the article: the structure IS the retrieval. Good filenames and directory organization mean you often don't need search at all — the agent knows where to look because the knowledge is organized by topic, not dumped into a flat embedding space.