How I Built an AI Sales Agent That Learns Across Deals

Most AI sales agents can remember what happened with a customer.

I wanted to build something different: an agent that could learn from one deal and apply that knowledge to a completely different deal.

That sounds simple until you try to define what the agent should actually remember.

A useful sales memory isn't just a transcript. It's an objection, a competitor, a successful response, or a tactic that worked in a particular situation. More importantly, that knowledge should remain useful after the original deal is finished.

That became the central idea behind my Deal Intelligence Agent.

The problem with treating memory as chat history

Consider a sales representative working on Deal A.

During a call, the prospect raises an objection about pricing. The representative handles it successfully, and the deal eventually closes.

Now imagine another representative starting Deal B several weeks later.

The second representative has never spoken to the first prospect.

Traditional conversational memory doesn't help much here because the relevant information belongs to another conversation.

I wanted the agent to recognize that the successful tactic from Deal A might be useful for Deal B.

So instead of thinking about memory as:

User → Conversation → Memory

I designed the system around:

Company
↓
Collective Memory
↓
Calls + Objections + Competitors + Winning Tactics
↓
New Deal
↓
Relevant Knowledge
↓
Generated Brief

This is where Hindsight became an important part of the architecture.

What the agent actually remembers

The application has two different kinds of information.

The first is ordinary application data: deals, people, calls, and other structured information needed by the UI.

The second is long-term agent memory.

Every important call is written into Hindsight using retain().

Winning deals also produce reusable tactics that are retained separately.

That distinction matters.

A raw call transcript tells the agent what happened.

A retained tactic can tell the agent what was learned.

The flow looks roughly like this:

Sales call
↓
Speech-to-text
↓
Structured extraction
↓
Call + objections + competitors
↓
Hindsight retain()

When a deal is won, the system extracts a more general lesson from that outcome.

For example:

Specific:
"Acme rejected the annual contract because of budget concerns."

Reusable:
"When a prospect has budget concerns, positioning the contract
around measurable cost savings can help address the objection."

The second piece is much more valuable as long-term memory.

The interesting part happens on a new deal

The most interesting behavior happens when a completely new deal arrives.

Suppose Deal B has its first call.

The agent doesn't have a history with this prospect.

Normally, that means there is very little context available.

Instead, the application asks Hindsight to reflect across the company's memory.

New Deal B
↓
reflect()
↓
Search company memory
↓
Relevant past calls + tactics
↓
Generate preparation brief

This is different from simply retrieving the previous conversation.

The agent can discover that something learned from Deal A is relevant to Deal B.

The generated brief also exposes where the information came from, so the recommendation isn't just a mysterious LLM output.

That was an important design decision for me.

Making memory explainable

One problem with AI-generated sales advice is trust.

If an agent says:

"You should address pricing concerns by emphasizing ROI."

the natural question is:

Why?

The application uses Hindsight's returned source information to surface the origin of the knowledge behind the generated brief.

Instead of hiding the retrieval process, the UI can show something like:

Based on:
FashionHub Retail — Call 4

That makes the generated recommendation much easier to investigate.

The agent isn't simply saying:

"Trust me."

It can show:

"This came from something your company previously learned."
The technical pipeline

The application is built with Next.js and TypeScript.

For extraction and generation, I use Groq models, while Groq Whisper handles speech-to-text.

The main pipeline looks like this:

Audio / Transcript
↓
Groq Whisper
↓
Call extraction
↓
Structured call data
↓
Hindsight retain()
↓
Company memory
↓
Hindsight reflect()
↓
Brief / Follow-up email

The application separates structured CRUD data from agent memory.

The local database contains things such as:

Deals
People
Calls
Workspaces

Hindsight handles the longer-lived knowledge that the agent needs to reason across those records.

This separation keeps the responsibilities relatively clear.

Why I chose Hindsight for the memory layer

I didn't want to build another vector-search layer and call it "memory."

The interesting requirement was not simply:

Find something similar to this text.

It was:

Find something from the company's past that could change what the agent recommends now.

That's a much more useful definition of agent memory.

Hindsight provides the retain() and reflect() primitives that fit this workflow well.

I use retain() when information becomes part of the company's long-term memory.

I use reflect() when the agent needs to reason over that accumulated memory.

The Hindsight documentation goes deeper into how this memory model works.

Before and after

The behavioral difference is easiest to see with a simple example.

Before memory

A new representative opens a new deal.

Agent:
"I don't have enough information about this prospect yet."

The representative has to manually search through previous calls, CRM notes, and old deals.

After collective memory

The same representative opens a new deal.

Agent:
"A similar objection was successfully handled in another deal.
Here's the tactic that worked and the previous call it came from."

The prospect is new.

The deal is new.

The knowledge isn't.

That is the behavior I wanted to build around.

What I learned

1. Memory should store lessons, not just conversations

Keeping every transcript isn't automatically useful.

The valuable part is extracting information that can influence future decisions.

1. Cross-context memory is more interesting than personal memory

Remembering the current user is useful.

Learning from completely different deals is where the system starts behaving more like organizational memory.

1. Retrieval should have a visible source

Generated recommendations become much easier to trust when users can inspect where they came from.

1. Structured data and agent memory have different jobs

The application database answers questions about the application.

The memory layer answers questions about what the company has learned.

Keeping those responsibilities separate made the architecture easier to reason about.

1. The real test of agent memory is changed behavior

A memory system shouldn't be judged only by whether it can retrieve an old fact.

The more useful question is:

Did something the agent remembered actually change what it did next?

For this project, the answer is visible when knowledge from one closed deal influences preparation for an unrelated deal.

That's the behavior I was ultimately trying to build.

What's next

The natural direction is making the memory increasingly useful without making it intrusive.

The agent should learn from more interactions, identify reusable patterns more reliably, and provide increasingly relevant context while still showing why a recommendation was made.

The core architecture stays simple:

Experience
↓
Retain
↓
Collective memory
↓
Reflect
↓
Better decisions

That's the part I find most interesting about building agents with persistent memory.

The goal isn't to make an agent remember everything.

The goal is to make sure it remembers the right things, and that those memories actually change what it does next.

If you're interested in the memory layer, check out the Hindsight GitHub repository and Vectorize's overview of agent memory.