Introduction
Sales teams generate a large amount of information during the sales process: customer conversations, requirements, objections, competitor comparisons, negotiations, decisions, and final outcomes.
The challenge is not simply storing this information. The bigger challenge is using previous deal experience when a similar situation appears in a new opportunity.
For example, a customer may be worried about migration risk. A previous customer may have had the same concern and successfully moved forward after a phased rollout and technical workshop. Another customer may have been lost because the migration concern was not addressed clearly.
A traditional CRM can store these interactions, but we wanted to build an agent that could go one step further: remember relevant experiences, retrieve them when needed, reason over the evidence, and learn from the outcome of its recommendations.
This led us to build an Evidence-Driven Deal Intelligence Agent using persistent AI memory.
Understanding the Deal
Before explaining the application, it is important to understand what a deal represents.
A deal is a potential business opportunity between a company and a customer. It usually moves through stages such as:
Lead → Qualification → Discovery → Evaluation → Proposal → Negotiation → Closed Won/Lost
During these stages, the salesperson collects information about the customer's requirements, problems, budget, competitors, objections, and decisions.
Our application represents this information as a structured deal while also capturing the experiences surrounding it.
For example, our demonstration uses:
Customer: Acme Migration Corp
Opportunity: Acme CRM Migration
Value: $50,000
Stage: Negotiation
Competitor: Salesforce
The customer is concerned about migration time, implementation risk, and minimizing disruption.
The Problem
A salesperson working on the Acme opportunity may ask:
"Have we faced this type of migration concern before?"
A normal CRM can help search for old records, but finding the most relevant experiences and understanding what happened in those deals still requires manual effort.
An AI model without persistent memory has another limitation: it can generate a recommendation based on the information provided in the current conversation, but it does not automatically have access to the organization's previous deal experiences.
We wanted to bridge this gap.
Our core question became:
Given what is happening in this deal, what happened in comparable deals, what evidence supports the pattern, and what should the salesperson consider doing next?
Our Approach
The application combines three layers:
- PostgreSQL
PostgreSQL stores the application's structured business data:
Companies
Contacts
Deals
Interactions
Recommendations
Actions
Outcomes
- Hindsight
Hindsight provides the persistent AI memory layer.
Important deal experiences can be retained and later recalled based on the context of a new opportunity.
- LLM-based reasoning
The reasoning layer uses the current deal context and recalled historical experiences to generate structured analysis and recommendations.
This separation gives us a clear distinction:
PostgreSQL stores what the application knows. Hindsight stores what the agent has experienced.
Architecture
The application follows this architecture:
React + TypeScript
│
▼
FastAPI API
/ \
/ \
▼ ▼
PostgreSQL Hindsight
Business Data AI Memory
│
Recall / Reflect
│
▼
LLM Reasoning
│
▼
Recommendation
The frontend provides the user interface, while FastAPI manages the application logic and connects the structured database with the memory layer.
Hindsight Memory
The central concept of our system is the memory loop:
RETAIN → RECALL → REFLECT → ACT → OUTCOME → RETAIN
RETAIN
When a meaningful interaction is created, the application can retain the experience in Hindsight.
For example:
"Acme is worried about migration timeline and wants minimal disruption. They are also comparing us with Salesforce."
This gives the memory layer context about the customer situation.
RECALL
When the salesperson asks the agent to analyze the deal, the system constructs a contextual query based on the current opportunity.
The goal is to find historical experiences that are relevant to the current situation.
For example, previous experiences might involve:
Migration concerns
Similar objections
Competitor comparisons
Negotiation situations
Successful or unsuccessful actions
REFLECT
After retrieving relevant experiences, the reasoning layer can analyze the evidence and produce structured insights such as:
Patterns
Recommendations
Risks
Alternative actions
Unknowns
The important principle is that the recommendation should be connected to historical evidence rather than being presented as an unexplained AI answer.
Example: Acme CRM Migration
Consider our current opportunity:
Acme CRM Migration
The customer is concerned about migration risk and is comparing our product with Salesforce.
Suppose historical memory contains two relevant experiences.
Previous successful deal
A previous customer had a similar migration concern.
The sales team:
Migration concern → Phased rollout → Technical workshop → Won
Previous unsuccessful deal
Another customer had a similar concern, but the migration risk was not addressed clearly.
Migration concern → No clear migration plan → Lost
The current Acme situation can then be analyzed against these experiences.
The agent may identify a pattern such as:
A phased migration approach and technical discussion may help address the customer's concerns.
The salesperson can then decide whether to act on that recommendation.
This is the difference between simply generating an answer and reasoning from organizational experience.
The Human Decision Layer
We intentionally did not design the system so that the AI automatically makes the final business decision.
Instead, the workflow is:
Historical Evidence
↓
AI Analysis
↓
Recommendation
↓
Human Decision
↓
Action
A salesperson can accept or reject the recommendation.
This keeps the human involved in an important business decision while allowing the AI to provide relevant historical context.
Learning From Outcomes
The final part of the system is the outcome loop.
Suppose the salesperson accepts a recommendation to arrange a technical migration workshop.
The system records the action.
Later, the customer might:
Respond positively
Respond negatively
Request additional information
Move forward with the deal
Stop the evaluation
That outcome becomes another piece of experience.
The complete cycle becomes:
Current Deal
↓
Historical Evidence
↓
Recommendation
↓
Human Decision
↓
Action
↓
Outcome
↓
New Experience
↓
Future Recall
This is what makes the architecture a closed-loop experience system rather than a simple question-and-answer chatbot.
Technology Stack
The current implementation uses:
Python
FastAPI
React
TypeScript
PostgreSQL
Hindsight
LLM-based reasoning
SQLAlchemy
Alembic
Docker
The backend exposes REST APIs for companies, deals, interactions, intelligence analysis, recommendations, actions, and outcomes.
The frontend provides the dashboard and deal intelligence interface.
Engineering and Verification
We also focused on keeping the application maintainable rather than building only a visual prototype.
The project includes:
Backend unit tests
Database migrations
Environment-based configuration
API/service separation
Frontend linting
Production frontend build
Docker configuration
Security checks to prevent credentials from being committed
The current local verification completed with 22/22 backend tests passing, and the frontend lint and production build also passed during our repository preparation.
What We Learned
One of the biggest lessons from building this system was that AI memory is more useful when it is connected to a meaningful workflow.
Simply adding memory to an application does not automatically make it intelligent.
The useful part comes from connecting:
Memory → Context → Evidence → Reasoning → Decision → Outcome
We also learned that business data and AI memory serve different purposes.
A relational database is excellent for structured facts such as deal value, stage, company, and timestamps.
A memory system is useful for retaining experiences that can later be recalled in a contextual way.
Keeping these responsibilities separate made the architecture easier to reason about.
Current Limitation
The application has been integrated with Hindsight's memory operations, but live Hindsight Cloud Recall/Reflect execution depends on an available Hindsight Cloud credit balance.
During the current development environment, the Cloud API returned a 402 Payment Required response because the available credits were exhausted.
We therefore do not present unavailable Cloud operations as currently live functionality in this article.
The project architecture and integration remain designed around the Hindsight memory workflow.
Conclusion
The goal of our Deal Intelligence Agent is not to build another chatbot for sales teams.
The goal is to create an agent that can remember deal experiences, retrieve relevant historical evidence, reason about the current opportunity, support a human decision, and retain the resulting outcome for future use.
The core idea can be summarized as:
Don't just ask AI what to do. Give it relevant experience to reason from.
Project
https://github.com/DNSRamprasad55/deal-intelligence-agent
Hindsight
Top comments (0)