Deal Mind : AI Sales Assistant

Aamina Syeda — Tue, 29 Sep 2026 19:42:35 +0000

I Built a Sales Assistant That Actually Remembers Customers

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?

The Difference Between Knowing and Remembering

There's an important distinction here.

Your CRM might know that:

Rahul had three meetings.
The last meeting was on September 12.
The deal is in the evaluation stage.
An email was sent yesterday.

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.

Giving Every Customer a Memory

The stack is roughly:

React + Tailwind CSS
FastAPI
SQLAlchemy
SQLite/PostgreSQL for CRM data
Hindsight for long-term agent memory

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:

“We're mainly concerned about SOC 2 compliance.”

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.

Recall Is Not Reflection

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:

Recall

“What does the system remember about this customer?”

Reflection

“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:

What has Rahul already seen?
What concerns has he raised?
What objections appeared previously?
What matters to him?
What commitments were made?
What should we avoid repeating?

The result is much closer to an actual sales assistant than a chatbot with a CRM attached.

The Same Memory Can Follow the Relationship

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.

But Here's the Part I Care About Most

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.

I Didn't Want to Build a Fake Memory Layer

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.

What Building This Changed My Mind About

1. A Timeline Isn't Memory

A timeline tells you what happened.

Memory helps an agent understand what from the past might matter now.

Those are very different capabilities.

2. Memory Needs Boundaries

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.

3. Memory Should Start at the Interaction

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.

4. Retrieval and Reasoning Should Be Observable

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.

5. AI Should Be Honest About Its Context

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?”

The Bigger Question

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.

What's Next?

There are plenty of directions I'd like to explore:

Email integration
Calendar context
Deal-stage memory
CRM integrations
Authentication and per-user memory
Streaming responses
Better memory inspection
Memory debugging and evaluation
More granular memory permissions

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.

Code Snips :

Results :

Resources

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?

DEV Community: Aamina Syeda