What if your sales assistant could write the perfect email…
…but had no idea who the customer was?
That bothered me while building AI sales assistants.
Today, an LLM can write a convincing email in seconds. It can summarize a meeting. It can prepare talking points. It can even sound like it understands a customer.
But there is a fundamental problem:
Most AI assistants don't actually remember the relationship.
A customer tells you something important during a call.
“We're mainly concerned about SOC 2 compliance.”
Three weeks later, you ask your AI assistant to prepare for another meeting.
If that information isn't somewhere in the current context, the assistant starts from zero.
And that's a strange limitation for something that's supposed to assist with relationships.
So I built DealMind around a simple question:
What if every customer had their own persistent AI memory?
There's an important distinction here.
Your CRM might know that:
But knowing what happened isn't necessarily the same as remembering what matters.
Imagine Rahul mentioned a concern about SOC 2 compliance six weeks ago.
A traditional CRM can store that conversation.
But an AI assistant needs to be able to answer a different question:
“Is that old piece of information relevant to what I'm doing right now?”
That's where DealMind's architecture comes in.
The stack is roughly:
The architectural decision I cared about most was this:
CRM storage and AI memory should not be the same thing.
A customer can have:
Each customer gets their own Hindsight memory bank.
So when Rahul says:
that interaction can become part of Rahul's long-term memory.
Later, instead of stuffing Rahul's entire history into a prompt, DealMind can retrieve the information that is relevant to the task at hand.
That's a fundamentally different way of thinking about context.
This became one of the most interesting parts of the system.
I don't think memory should simply mean:
“Search the database and give me everything.”
DealMind separates two ideas:
“What does the system remember about this customer?”
“Given what the system remembers, what does that mean for what I should do next?”
That distinction matters.
Suppose the salesperson says:
{
"use_memory": true,
"meeting_goal": "Agree on evaluation plan"
}
The assistant doesn't need every conversation Rahul has ever had.
It needs the relevant context:
The result is much closer to an actual sales assistant than a chatbot with a CRM attached.
This is where things get interesting.
The memory shouldn't disappear when the meeting ends.
After the meeting, DealMind can generate a follow-up:
{
"channel": "email",
"tone": "professional",
"instructions": "Offer a call Thursday"
}
Generating an email isn't impressive anymore.
LLMs are very good at that.
The interesting question is:
Does the email know why Thursday matters?
If the customer previously mentioned a concern, requested a feature, or agreed to a specific next step, that context can influence the follow-up.
So the flow becomes:
Customer Interaction
│
▼
Retain
│
▼
Customer Memory
│
┌──────────┴──────────┐
▼ ▼
Recall Reflect
│ │
└──────────┬──────────┘
▼
Relevant Context
↙ ↘
Meeting Follow-up
The assistant isn't simply generating text.
It's carrying context forward through the relationship.
What happens when the AI doesn't actually remember anything?
I don't want DealMind to pretend.
If Hindsight isn't available, the application shouldn't quietly generate a response and make it look like the answer came from customer history.
That's why the system exposes information such as:
{
"answer": "...",
"memory_used": true,
"source": "hindsight",
"memories": [...]
}
The UI can distinguish between:
“This answer was generated using customer memory.”
and:
“This is a generic AI response.”
That distinction might seem small.
I don't think it is.
As AI assistants become more embedded into workflows, users need to know not only what the AI said, but also what the AI actually knew when it said it.
One tempting architecture would have been:
Everything → SQLite/Postgres → “AI Memory”
It would work.
But it blurs two very different concepts.
Instead, DealMind separates them:
Postgres / SQLite
│
▼
What happened?
versus:
Hindsight
│
▼
What is worth remembering?
What is relevant right now?
A database is excellent at storing facts.
Memory is about relevance, context, and retrieval.
Those concepts overlap.
They aren't identical.
A timeline tells you what happened.
Memory helps an agent understand what from the past might matter now.
Those are very different capabilities.
I chose one memory bank per customer.
That creates a natural boundary around customer-specific context instead of throwing every customer into one giant pool.
If you wait until later to decide what should become memory, you'll eventually lose important context.
The write path matters.
Interaction
↓
Retain
↓
Customer Memory
Memory shouldn't be an afterthought.
It should be part of the system's architecture from the beginning.
I want to be able to inspect:
What was recalled?
↓
What did the model reason from?
↓
What did it generate?
If those three things are hidden inside one opaque AI call, debugging becomes extremely difficult.
This might be the most important lesson.
An AI saying something confidently doesn't mean it remembered why that information mattered.
So I think AI systems should expose more of their context provenance.
Not necessarily their private chain-of-thought.
But enough information to answer:
“What information did you actually use to produce this?”
Building DealMind made me think about something beyond sales.
We're rapidly moving from:
AI that generates responses
to:
AI that participates in ongoing relationships.
And those are very different systems.
A chatbot can forget you.
A relationship-oriented agent can't afford to behave as if every conversation is the first one.
Because eventually, the real value of the agent may not be its ability to generate language.
It may be its ability to carry context forward.
Conversation
↓
Memory
↓
Context
↓
Action
↓
New interaction
↓
Memory
↓
...
That's the loop I'm interested in.
There are plenty of directions I'd like to explore:
The architecture stays relatively simple:
Customer Interaction
↓
Persistent Memory
↓
Relevant Context
↓
Agent Response
↓
New Interaction
↓
Persistent Memory
The goal isn't to make an AI that remembers everything.
It's to make an AI that remembers the right things at the right time.
And maybe that's the more interesting definition of AI memory.
Repository: DealMind on GitHub
Memory: Hindsight by Vectorize
Documentation: Hindsight Documentation
Agent Memory: Vectorize — What Is Agent Memory?
I'm curious how other people are approaching this.
Do you think an agent's memory should live separately from the application's database?
Or is the database itself already the agent's memory?
And perhaps the bigger question:
If an AI can remember every interaction but can't understand what matters, does it actually have memory or just storage?