Why agent memory shouldn't be a stack of databases

If you're building an agent that has to remember things, you've probably ended up with the same architecture as everyone else: a vector database for semantic recall, a graph database for relationships, and a log or relational store for the raw history of what happened. Three systems, three clients, three sets of credentials - and a surprising amount of your code doing nothing but keeping them in sync.

We think that's backwards. Here's the case for treating agent memory as one consistent store instead of a stack.

The hidden tax of a memory stack

The problem isn't that any one of those databases is bad. It's the seams between them. When a single reasoning step produces a log entry, an embedding, and a couple of new graph edges, you now have to write to three places and hope they all land. They don't land atomically, so you live with windows where your agent's memory is internally inconsistent:

• The vector store has the embedding but the graph doesn't have the edge yet.
• A read that fans out to all three can see a half-written step.
• Deleting an agent means orchestrating deletes across every system - and proving you got them all.

None of this is exotic. It's the ordinary cost of distributed writes across stores that were never designed to agree with each other.

What one store changes

Put logs, vectors, and graph edges behind a single transactional boundary and the seams disappear. A reasoning step becomes one write:

Commit the log, the embeddings, and the graph edges together - or commit none of them. The instant it lands, every part is readable.

And a query becomes one call. Semantic search, graph traversal, and a scan of recent history return a single, externally consistent answer instead of three partial answers you have to reconcile in application code.

Four things that get easier

1. One query across every kind of memory, ranked and consistent.
2. One transaction - no sync lag between stores, read-your-writes everywhere.
3. One snapshot - replay exactly what your agent knew at any past moment.
4. One boundary to secure and audit, and one operation to erase.

The trade-off

This isn't free - a unified store has to be good at all three access patterns at once, which is a hard engineering problem and the reason most teams reach for specialized databases in the first place. That's exactly the problem we're building Jennah to solve: one store per agent, globally consistent, that treats logs, vectors, and graph as first-class citizens of the same transaction.

We're early, and we're learning a lot from the teams building on it. If any of this resonates with what you're wrestling with, we'd love to compare notes.