Hello, I'm Rijul, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
When we think about memory as humans, the first things that come to mind are usually past conversations, past events, experiences, and things we have learned.
So it is easy to assume that when an AI agent "remembers" something, it simply looks back through an array of previous chat messages.
But there is more to it than that.
To understand how agents remember things, we need to understand two concepts that are often used interchangeably:
Chat history and agent memory.
Let's start with chat history.
1. Chat history
Suppose you start a conversation with an agent:
You: I'm building a fitness tracking app.
Agent: Nice. What stack are you using?
You: React and FastAPI.
Agent: Got it. What database?
You: PostgreSQL.
Now, in this conversation, I can ask again which database I'm using.
The agent can infer from the conversation that the database is PostgreSQL.
So basically:
┌─────────────────────────────┐
│ Chat History │
├─────────────────────────────┤
│ User: I'm building... │
│ Agent: Nice... │
│ User: React and FastAPI │
│ Agent: What database? │
│ User: PostgreSQL │
└─────────────────────────────┘
↓
LLM sees context
Now, if you start a new conversation and ask a question like:
You: What's a good database for my app?
If the new conversation only has its own history:
┌─────────────────────────────┐
│ New Chat History │
├─────────────────────────────┤
│ User: What's a good │
│ database for my app? │
└─────────────────────────────┘
The agent doesn't automatically know:
React
FastAPI
PostgreSQL
fitness tracking app
Those belonged to the previous conversation.
This is where memory comes in.
2. Agent memory
So far, what we saw is that specific information, like the database we use, is scoped to the current conversation and doesn't necessarily go beyond it.
But agent memory allows the agent to preserve useful information beyond the current conversation.
For example, the agent could store:
User prefers PostgreSQL.
User is building a fitness tracking app.
User uses React + FastAPI.
Now, when we start a new conversation, the agent can retrieve these memories and use them as additional context.
Conceptually:
┌───────────────┐
│ New message │
└───────┬───────┘
↓
┌─────────────────┐
│ Memory retrieval│
└────────┬────────┘
↓
┌─────────────────────┐
│ Relevant memories │
│ │
│ React │
│ FastAPI │
│ PostgreSQL │
└──────────┬──────────┘
↓
┌─────────┐
│ LLM │
└─────────┘
The important thing to understand is that memory is not the same thing as chat history.
Chat history contains the messages from a conversation.
Memory contains information that the agent has decided is useful to preserve and potentially use later.
3. How do they work together?
In a real agent, these two usually work together.
Imagine you start a new conversation:
You: I want to add authentication to my app.
The current chat history might only contain:
You: I want to add authentication to my app.
But the memory system might retrieve:
User is building a fitness tracking app.
User uses React + FastAPI.
User prefers PostgreSQL.
The agent can then combine both pieces of information:
┌─────────────────┐
│ Chat history │
│ │
│ Current │
│ conversation │
└────────┬────────┘
│
│
┌────────▼────────┐
│ Memory │
│ │
│ Previous useful │
│ information │
└────────┬────────┘
│
▼
┌───────────┐
│ LLM │
└─────┬─────┘
│
▼
Response
This gives the LLM more useful context than either source could provide on its own.
The chat history tells the agent:
What are we talking about right now?
Memory tells it:
What do I already know that might be useful here?
4. But how does an agent create a memory?
This is where things get a little more interesting.
An agent doesn't necessarily save every single message as a memory.
For example:
You: My name is Alex.
You: I'm building an e-commerce application.
You: I'm using Django and React.
You: I had pizza for lunch today.
It probably doesn't make sense to permanently remember:
Alex had pizza for lunch.
But these could be useful:
User's name is Alex.
User is building an e-commerce application.
User uses Django and React.
So a memory system can take information from the conversation, identify what is useful, and store it separately.
Conceptually:
Chat history
│
▼
┌───────────────────┐
│ Memory extraction │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Useful information│
└─────────┬─────────┘
│
▼
Persistent memory
Later, when another conversation starts, the system can retrieve the relevant memories.
5. Where is this memory stored?
Agent memory needs some kind of persistent storage.
It could be stored in:
PostgreSQL
Redis
MongoDB
Vector databases
or even a combination of these.
For example, a simple memory table could look like:
user_id memory
------- ----------------------------------
123 User prefers PostgreSQL
123 User uses React and FastAPI
123 User is building a fitness app
For more advanced systems, memories can also be converted into embeddings and stored in a vector database.
This allows the agent to retrieve memories based on semantic similarity.
For example, if the user later asks:
What's a good database for my project?
the system can search its memories and find:
User prefers PostgreSQL.
User is building a fitness tracking app.
Those memories can then be added to the context given to the LLM.
So a vector database is not itself "the memory".
It is simply one possible technology used to store and retrieve memories.
6. The simple mental model
At this point, you can think of an agent as having three different sources of context:
┌─────────────┐
│ LLM │
└──────┬──────┘
│
Context
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Chat history Memory RAG
│ │ │
▼ ▼ ▼
Current context User-specific External
information knowledge
Chat history tells the agent what is happening in the current conversation.
Memory allows the agent to carry useful information across conversations.
RAG allows the agent to retrieve external information that it doesn't already know.
And ultimately, all three have the same purpose:
Give the LLM the right context at the right time.
That's what makes an agent feel like it can remember things instead of treating every conversation as if it were starting from zero.
Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.
I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.
Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.
Spend code review effort where business risk is highest — not spread evenly across every diff.
⭐ Star it on GitHub:
HexmosTech
/
LiveReview
Blast-Radius Aware AI Code Review for Business-Critical Systems
LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems
LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.
The exact math, not a black box
Visualize blast radius at a glance
Every factor that feeds the score
Here's the goal:
- A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.
- A 300-line UI change in one file, fully covered by…
Click below to try LiveReview with your codebase:
Top comments (3)
The retrieval step is where long-term agent memory usually causes strange bugs in production. When an agent extracts facts automatically from past turns and stores them in a vector database, it easily turns temporary workarounds or speculative guesses into permanent truths.
If a developer mentions using SQLite for a quick local test in one session, a naive memory retriever might pull that note weeks later and insist on SQLite for a distributed production service. Without explicit provenance tags like the source session timestamp, project boundary, and an invalidation rule, semantic memory ends up injecting stale assumptions directly into fresh prompts.
I like treating memory as a separate, testable subsystem rather than letting the prompt grow forever. A small retrieval set plus explicit write rules makes latency and failure behavior much easier to reason about.
The write-versus-retrieve boundary is where I’d add tests. I’d keep a small set of durable facts, log why each memory was saved, and make deletion explicit so stale context doesn’t quietly shape later runs.