AI Deal Intelligence & Win-Loss Recommender
Building evidence-backed sales intelligence with Hindsight memory
Author: K. Hari Krishna | GitHub: KHarikrishna2006
The Problem: Sales Data Remembers Records, Not Context
A CRM can tell a sales team what happened to a deal: its amount, stage, owner, competitors, objections, interactions, and final outcome. The harder question is what happened across many deals that looked similar, and what those historical experiences should mean for the opportunity in front of a seller right now.
That gap is the problem I wanted to explore. Instead of building another chatbot over CRM tables, I built the AI Deal Intelligence & Win-Loss Recommender: a B2B sales intelligence application that combines structured PostgreSQL data with persistent contextual memory in Hindsight.
The system is designed around a simple workflow: capture the current deal context, retrieve comparable historical evidence, recall relevant customer and deal memories, identify patterns and risks, and produce a next-action recommendation that can be traced back to recorded evidence.
What I Built
The project is a full-stack application with a React/TypeScript frontend, a FastAPI backend, PostgreSQL for structured CRM records, Hindsight for contextual memory, and an OpenAI-compatible local LLM interface. The repository also includes Docker Compose configuration, database migrations, seeded demo data, and automated backend tests.
Visual: System Architecture
The Architectural Decision That Matters
PostgreSQL is the source of truth
Structured entities such as organizations, users, customers, deals, interactions, competitors, objections, outcomes, recommendations, feedback, and audit records live in PostgreSQL. This keeps business state queryable, constrained, and explicit.
Hindsight is the contextual memory layer
Hindsight is not treated as a replacement database. The application retains distilled, contextual experiences such as customer conversations, objections, competitors, pricing context, commitments, requirements, and deal outcomes. A local MemoryReference table keeps pointers and metadata so the application can inspect and reconcile the memory layer without copying the entire relational database into it.
The LLM is the reasoning layer
The language model receives structured current-deal context, historical deal evidence, detected risks, and recalled memory. It generates structured analysis, but its output is not trusted blindly.
How Hindsight Is Integrated
I centralized Hindsight access in a dedicated HindsightService. The service controls bank naming, memory metadata conventions, retain/recall/reflect operations, and failure handling. Each organization maps to its own Hindsight bank using an organization-scoped identifier.
When an interaction is turned into memory, the application creates a contextual representation rather than dumping the entire SQL row. The retained memory can include the customer, deal, stage, amount, interaction content, competitors, objections, pricing information, commitments, requirements, and recorded outcome.
This is the key distinction in the project: PostgreSQL stores structured business facts, while Hindsight preserves the contextual experience that can later be recalled for a different but related deal.
[INSERT IMAGE — Terminal/code screenshot of Hindsight retain/recall calls]
Finding Similar Deals
The similarity engine combines two sources. First, it uses structured PostgreSQL attributes such as customer, stage, deal size, competitor, and objection overlap. Second, it can query Hindsight with contextual questions around similar customers, objections, competitors, pricing, procurement, and historical winning actions.
Every comparable deal is accompanied by a human-readable explanation of why it was considered relevant—for example, the same competitor, the same objection, a comparable deal size, the same industry or segment, or reaching the same pipeline stage.
[INSERT IMAGE — Similar Deals section screenshot]
Win/Loss Intelligence
The win/loss layer is deliberately conservative. It computes metrics and patterns from recorded PostgreSQL outcomes and explicitly checks whether enough closed history exists for meaningful analysis. For the current implementation, at least three closed deals are required before the service marks historical pattern analysis as sufficient.
The analytics include win rate, average deal size, average sales cycle, common objections, common competitors, loss reasons, win reasons, stage failure rates, competitor outcomes, pricing-related losses, competitor-related losses, and recurring requirements.
When the history is too thin, the application reports insufficient historical data instead of manufacturing statistics.
[INSERT IMAGE — Win/Loss analytics screenshot]
Evidence-Backed Recommendations
The recommendation engine is where the project moves from retrieval to action. A current deal is analyzed using similar closed deals, recalled memories, and detected risks. When an LLM is available, it is asked to return structured JSON with a summary, similar patterns, recommended actions, evidence deal names, and unknowns.
A critical guardrail happens after generation: every recommended action must cite a historical deal returned by the similarity engine. The backend validates the cited deal names against the actual evidence set and discards actions that cannot be tied to recorded evidence.
That means the model can propose language, but the backend decides whether the proposal is grounded enough to persist as a recommendation.
[INSERT IMAGE — Recommendation panel screenshot]
Example Recommendation Flow
Suppose a live enterprise opportunity contains a pricing concern and a procurement requirement. The system can identify historical deals with similar objections, deal size, competitors, and stages. The recommendation layer then uses those records to produce an action such as clarifying procurement requirements before making another discount concession—provided that historical evidence actually supports that pattern.
Risk Detection and Graceful Degradation
The application does not assume that Hindsight or the LLM will always be online. If Hindsight is unavailable, core PostgreSQL-backed CRM features still work and the API exposes the memory-unavailable reason. If the LLM is unavailable, recommendations fall back to a deterministic evidence engine.
This mattered because the application should degrade in a controlled way rather than pretending that a missing model or memory service produced intelligent output.
Deal Copilot Without Unrestricted Database Access
The Deal Copilot supports questions such as: What happened in similar deals? Why did we lose deals like this? What objections appeared before? Which competitors were involved? What should I investigate next? Why are you recommending this?
The important implementation detail is that the copilot does not receive unrestricted SQL access. The backend exposes a small set of read-only tools that return structured deal, analytics, memory, and recommendation data. The resulting answer includes citations back to deals or memory items where applicable.
[INSERT IMAGE — Deal Copilot screenshot]
The Safety Model
The project treats AI output as untrusted input. The model does not directly mutate deal amount, pipeline stage, customer ownership, pricing, or permissions. Business state changes remain behind authenticated backend operations and validation.
The same principle applies to evidence. If historical data is unavailable or too weak, the system uses an explicit insufficient-evidence state instead of inventing confidence percentages.
Technology Stack
• Frontend: React 18, TypeScript, Vite, React Router, TanStack Query, Tailwind CSS, Lucide React, Recharts.
• Backend: Python, FastAPI, Pydantic, SQLAlchemy, Alembic.
• Data: PostgreSQL 16.
• Memory: Hindsight via hindsight-client.
• LLM: OpenAI-compatible endpoint, configured by environment variables; Docker development defaults to Ollama with llama3.2:3b.
• Infrastructure: Docker and Docker Compose with dedicated PostgreSQL, Hindsight, API, and web containers.
• Testing: Pytest-based backend tests covering authentication, deals, memory, recommendations, isolation, evidence handling, and degradation paths.
Testing and Failure-Path Thinking
The repository includes backend tests that deliberately disable Hindsight and the LLM so that the application’s fallback behavior is exercised. This verifies that the system can still return deterministic evidence-backed answers, enforce organization isolation, handle permissions, and report insufficient history.
What I Learned
• Long-term agent memory is not the same thing as storing chat history. Useful memory needs context, provenance, metadata, and retrieval paths that connect it to current work.
• A relational database and an agent memory system solve different problems. Trying to force one to replace the other makes the architecture harder to reason about.
• The most valuable AI guardrail in this project is evidence validation. The model is allowed to reason, but its recommendation is only persisted when it can be tied to actual historical records.
• Graceful degradation is part of AI engineering. A system that clearly says memory or model services are unavailable is more useful than one that silently fabricates continuity.
Project Links
GitHub: https://github.com/KHarikrishna2006/Deal-Intelligence-Win-Loss-Recommender
Hindsight GitHub: https://github.com/vectorize-io/hindsight
Hindsight Documentation: https://hindsight.vectorize.io/
Agent Memory — Vectorize: https://vectorize.io/what-is-agent-memory
Screenshot Checklist Before Publishing
Suggested Dev.to Structure
Keep the published article focused on the engineering story. Use 4–6 of the strongest screenshots, one architecture diagram, and one Hindsight code/terminal image. Link the GitHub repository near the beginning and again in the closing section. Do not add performance claims or benchmark numbers unless you have measured them.
Closing
The central idea behind this project is simple: a sales intelligence agent becomes more useful when it can remember experiences, not just query records. By separating structured business truth in PostgreSQL from contextual memory in Hindsight, the system can retrieve comparable history, connect it to the current deal, and turn that history into evidence-backed next actions.
The most interesting part was not adding an LLM to a CRM. It was designing the boundaries around memory, evidence, and control so that the AI could reason over history without becoming the source of truth.
Top comments (0)