You’ve probably done it. You built an AI agent, realized it needed memory, and immediately reached for a vector database. You spun up Pinecone. You embedded everything. You felt sophisticated.
And then your agent forgot what it was doing mid-task. Again.
Here’s the uncomfortable truth: Most agent memory isn’t a retrieval problem. It’s a bookkeeping problem dressed up in embeddings.
A project called Worklog just called the bluff. It stores an agent’s entire memory in a single SQLite table. No vectors. No embeddings. No similarity search. Just structured rows: what the agent did, when it did it, and what context mattered at the time.
And honestly? It works. Not because it’s technically superior to a vector store in every dimension — it’s not. It works because it solves the actual problem most developers have, which is not semantic search over a million documents. It’s: “What the hell is my agent doing right now, and why did it just do that?”
A vector database tells you what’s similar. A worklog tells you what’s true.
Think about what your agent actually needs to remember during a task. It needs to know the steps it’s already taken. It needs to know what it committed to. It needs a working memory — not a semantic fuzzy-match engine pulling in vaguely related paragraphs from a knowledge base.
The Worklog approach draws a line that most agent architectures blur completely: there’s your knowledge base (what the agent knows), and there’s your worklog (what the agent is doing right now). These are fundamentally different problems. Conflating them into a single vector store is why your agent feels like it has amnesia with a PhD.
When you use a single SQLite table for working memory, something magical happens. You can open it. You can read it. You can query it with plain SQL. You can see exactly what the agent logged, in what order, with what context. Debugging goes from archaeology to inspection.
If you can’t read your agent’s memory with a SELECT statement, you don’t own its behavior — you’re just hoping it works.
Now, the obvious objection: what about semantic retrieval? What about finding relevant information across a large corpus? Fair. Vector databases exist for a reason. But here’s the thing — that’s a different layer. That’s your knowledge base. Your agent’s working memory — the thing it needs to not lose the plot mid-task — doesn’t need cosine similarity. It needs structure, sequence, and clarity.
The AI agent space has a chronic over-engineering problem. Every demo project comes with a RAG pipeline, a vector store, an embedding model, a reranker, and three orchestration frameworks. Half of them exist because someone read a blog post about “production-grade agent memory” and panicked.
Worklog is the antidote to that panic. It’s one file. One table. One SQL query between you and understanding your agent’s entire state.
The best infrastructure is the infrastructure you can delete without crying.
If you’re building agents and you haven’t questioned your vector database dependency, do it now. Ask yourself: is my agent failing because it can’t find semantically similar information? Or is it failing because it lost track of what it was doing three steps ago?
If it’s the latter — and it usually is — you don’t need more embeddings. You need a log.
FAQ
Q: But what about semantic search? Doesn't my agent need embeddings?
A: For your knowledge base, maybe. For working memory — tracking what the agent is actively doing — no. These are two different layers. Worklog separates them. Use vectors for retrieval across large corpora; use a structured log for task state. Don't conflate them.
Q: How is this different from just using a regular database?
A: It IS just a regular database. That's the point. The insight isn't a novel data structure — it's the realization that most agent memory problems are bookkeeping problems, not semantic retrieval problems. A single SQLite table with action logs, timestamps, and context is sufficient, inspectable, and trivially debuggable.
Q: Isn't this too simple to scale for production agents?
A: Simple doesn't mean unsophisticated. It means the complexity lives where it should — in your agent logic, not in your memory infrastructure. If you hit a wall where structured logging genuinely isn't enough, add complexity then. But most developers add vector stores preemptively, solving a problem they don't have yet while ignoring the one they do.