When LLM fine-tuning was the hot topic, it felt like we were making models smarter. But the real challenge now? Making them remember, Giving proper Contexts.
AI forgets too quickly. I asked an AI (Qwen-Code CLI) to write code in JS, and a few steps later it was spitting out random backend code in Python. Basically (burnt my 3 million token in loop doing nothing), it wasn’t pulling the right context from the code files.
Now that everyone is shipping agents and talking about context engineering, I keep coming back to the same point: AI memory is just as important as reasoning or tool use. Without solid memory, agents feel more like stateless bots than useful asset.
As developers, we have been trying a bunch of different ways to fix this, and what’s important is - we keep circling back to databases.
Here’s how I’ve seen the progression:
Prompt engineering approach → just feed the model long history or fine-tune.
Vector DBs (RAG) approach→ semantic recall using embeddings.
Graph or Entity based approach → reasoning over entities + relationships.
Hybrid systems → mix of vectors, graphs, key-value.
Traditional SQL → reliable, structured, well-tested.
Interesting part?: the “newest” solutions are basically reinventing what databases have done for decades only now they’re being reimagined for Ai and agents.
I looked into all of these (with pros/cons + recent research) and also looked at some Memory layers like Mem0, Letta, Zep and one more interesting tool - Memori, a new open-source memory engine that adds memory layers on top of traditional SQL.
Curious, if you are building/adding memory for your agent, which approach would you lean on first - vectors, graphs, new memory tools or good old SQL?
Because shipping simple AI agents is easy - but memory and context is very crucial when you’re building production-grade agents.
I also wrote down the full breakdown, if someone wants to read!
AI forgets too quickly. I asked an AI (Qwen-Code CLI) to write code in JS, and a few steps later it was spitting out random backend code in Python. Basically (burnt my 3 million token in loop doing nothing), it wasn’t pulling the right context from the code files.
Now that everyone is shipping agents and talking about context engineering, I keep coming back to the same point: AI memory is just as important as reasoning or tool use. Without solid memory, agents feel more like stateless bots than useful asset.
As developers, we have been trying a bunch of different ways to fix this, and what’s important is - we keep circling back to databases.
Here’s how I’ve seen the progression:
Prompt engineering approach → just feed the model long history or fine-tune. Vector DBs (RAG) approach→ semantic recall using embeddings. Graph or Entity based approach → reasoning over entities + relationships. Hybrid systems → mix of vectors, graphs, key-value. Traditional SQL → reliable, structured, well-tested. Interesting part?: the “newest” solutions are basically reinventing what databases have done for decades only now they’re being reimagined for Ai and agents.
I looked into all of these (with pros/cons + recent research) and also looked at some Memory layers like Mem0, Letta, Zep and one more interesting tool - Memori, a new open-source memory engine that adds memory layers on top of traditional SQL.
Curious, if you are building/adding memory for your agent, which approach would you lean on first - vectors, graphs, new memory tools or good old SQL?
Because shipping simple AI agents is easy - but memory and context is very crucial when you’re building production-grade agents.
I also wrote down the full breakdown, if someone wants to read!