Your CRM Remembers What Happened. We Wanted It to Remember Why.

A sales representative offers a 20% discount. The customer doesn't like and two weeks later, another representative joins the conversation and offers an even better deal.

Problem is nobody remembers that the customer had already explained what was actually bothering them.

The problem wasn't the price. It was the integration they were waiting for.

This is a fairly common situation in sales. It's also an interesting problem to solve with AI, but can it?

https://in.pinterest.com/pin/509469776581405594/

We started building RevenueOS around a simple idea: what if a sales assistant could remember everything a company had heard from a customer, connect conversations across different people and more importantly, use that history to make better decisions?

Not just remember what happened. Remember why it happened.

The problem with giving AI a conversation history

Most AI applications I've worked with have some way of providing context to a model. You can pass the previous messages, retrieve relevant documents, or query a vector database before generating an answer.

That works reasonably well when the information is relatively self-contained.

But customer relationships aren't.

Consider a customer called Halcyon Logistics.

During the first meeting, their CFO mentions that the subscription is expensive and asks for a 15% discount. Their CTO, meanwhile, has a completely different concern: they need SAP integration and want the implementation completed within 30 days.

The sales representative promises to send the integration documentation by Friday.

Two weeks later, another representative speaks to the same customer. This time, the customer says that even a 20% discount isn't convincing enough. The CTO again asks about automated SAP synchronisation.

Now imagine asking an AI assistant:

"Why isn't Halcyon Logistics closing? What should I do next?"

If the assistant only sees the latest conversation, it might recommend another discount.

If it has access to the complete history, it can connect the dots:

The CFO initially raised a pricing concern.
A 20% discount was subsequently rejected.
The CTO's integration concern appeared in multiple conversations.
The implementation timeline remains important.
The integration documentation promised during the first meeting is still outstanding.

The recommendation changes entirely.

Instead of offering another discount, the assistant should recommend resolving the technical concerns and fulfilling the outstanding commitment.

This is the distinction we wanted to explore.

Introducing RevenueOS

We built RevenueOS as a sales intelligence and deal negotiation workspace for B2B sales teams.

The idea is to give every customer a persistent memory that grows with every interaction.

Different representatives can log meetings, calls, emails and uploaded documents. RevenueOS analyses the information, connects it with previous interactions and makes the accumulated context available to anyone working on that account.

The application has a few important parts:

• Revenue Memory: Maintains long-term customer context.
• Deal Negotiator: Uses historical conversations to recommend negotiation strategies.
• Commitment Tracker: Remembers promises made by both the sales team and the customer.
• Memory Explorer: Provides a visual way to explore what the system remembers.
• Negotiation Playbook: Learns from previous won and lost deals.
• Ask RevenueOS: Allows representatives to ask questions about individual customers or the entire sales pipeline.

But the interesting part isn't the number of features. It's how the memory layer connects them.

Why I chose Hindsight

We didn't want to build another chatbot that simply stores previous messages and appends them to the next prompt.

We wanted something that could retain information, retrieve relevant memories later, and consolidate observations over time.

That's what led me to Hindsight, an open-source memory system for AI agents, developed by Vectorize.

*Hindsight provides three operations that became central to RevenueOS:
*

• Retain: Store information as long-term memory.
• Recall: Retrieve relevant memories when needed.
• Reflect: Generate answers using accumulated knowledge.

There's also an important distinction between remembering individual facts and developing a broader understanding from repeated interactions.

For example, one conversation might contain a pricing objection. Another might contain a rejected discount. Over time, the system can develop a more useful observation: discounts aren't resolving this customer's actual blocker.

You can explore the Hindsight documentation to understand its memory architecture in more detail.

We particularly liked the idea that memory should be more than a storage mechanism. It should help an AI system build a progressively better understanding of the information it encounters.

The architecture: structured data and conversational memory

One decision we made early was not to use Hindsight as a replacement for the application's database.

RevenueOS has two different kinds of information.

The first is structured business data:

• Customers
• Deals
• Stakeholders
• Offers
• Objections
• Commitments
• Sales representatives

The second is contextual information:

1. What a stakeholder said during a meeting.
2. Why a particular offer was rejected.
3. How a customer's position changed over time.
4. Which technical requirements keep appearing.
5. What the sales team promised.

I use PostgreSQL for the structured CRM information and Hindsight for long-term conversational memory.

The architecture looks roughly like this:

                Sales Interactions
                       |
                       v
              Interaction Analysis
                       |
             +---------+---------+
             |                   |
             v                   v
       PostgreSQL             Hindsight
       Structured             Customer
       CRM data               Memory
             |                   |
             +---------+---------+
                       |
                       v
                Deal Negotiator
                       |
             +---------+---------+
             |                   |
             v                   v
       Customer Memory      Shared Playbook
             |                   |
             +---------+---------+
                       |
                       v
               Cited Recommendation

We don't need a memory system to calculate the total value of an open pipeline. That's structured data.

But we do need it to understand why a particular deal has been stuck for three weeks.

One memory bank per customer

This was another important architectural decision.

Instead of putting every customer's conversations into one shared memory bank, RevenueOS creates a separate Hindsight bank for each customer.

The implementation is deliberately simple:

customerBank(customerId: string) {
  return `${config.hindsight.bankPrefix}-customer-${customerId}`;
}

Every interaction associated with that customer goes into the same bank, regardless of which representative logged it.

This gives us two things.

First, representatives can share knowledge about an account without manually forwarding meeting notes to each other.

Second, customer memories remain isolated. A negotiation with one company shouldn't accidentally influence an answer about another company's confidential conversations.

There is also a separate memory bank for the negotiation playbook. I'll come back to that because it introduced an interesting problem of its own.

The interesting part: recalling before remembering

One of my favourite implementation decisions in RevenueOS happens when a new interaction is logged.

A naive implementation would take the latest conversation, extract some facts and store them.

But that misses an important opportunity.

Before processing new information, I first retrieve what Hindsight already knows about that customer.

The new conversation is then analysed against the existing memories.

The workflow looks like this:

const bank = memory.customerBank(customer.id);


await memory.ensureCustomerBank(
  customer.id,
  customer.name
);


// Retrieve existing context first.
const prior = await memory.recall(
  bank,
  text,
  { maxTokens: 2500 }
);


// Analyse the new interaction against
// the information already remembered.
const analysis = await llmJson({
  schema: AnalysisSchema,
  system: analysisInstructions,
  user: buildAnalysisContext({
    interaction: text,
    previousMemories: prior
  })
});

This is important because the system isn't analysing the latest conversation in isolation.

It can identify:

• Facts that have already been mentioned.
• New requirements.
• Changes in customer preferences.
• Contradictory statements.
• Repeated objections.
• Commitments that remain unfulfilled.

For example, a customer initially asks for a 15% discount and later says that even 20% isn't enough.

Those two statements mean something different when considered together than when read independently.

I also wanted to preserve the distinction between what the customer promised and what our own sales representative promised.

A customer saying they'll arrange a technical review is not the same as a salesperson promising to send integration documentation.

That distinction matters when determining what is blocking a deal.

The extraction pipeline uses structured schemas to validate the information before it is persisted. This is particularly useful because the system needs more than a paragraph summarising the meeting. It needs identifiable stakeholders, objections, offers, commitments and relationships with previous memories.

A negotiator that can explain its recommendations

Once customer memories start accumulating, the next question becomes:

How do we actually use them?

We didn't want the Deal Negotiator to simply retrieve the top few memories and ask an LLM to generate a generic sales strategy.

A negotiation decision usually depends on multiple dimensions.

For example:

• Pricing history.
• Technical requirements.
• Implementation concerns.
• Previous objections.
• Unfulfilled promises.

So we implemented multi-angle recall.

The negotiator retrieves account memories using multiple queries, merges the results, removes duplicates and ranks the relevant information.

It also retrieves relevant lessons from the shared negotiation playbook.

A simplified version of the retrieval logic looks like this:

const results = await Promise.all(
  queries.map((query) =>
    memory.recall(
      bank,
      `${customer.name}: ${query}`,
      { maxTokens: 1500 }
    )
  )
);


const merged = new Map<string, MemoryHit>();


results.flat().forEach((hit) => {
  const previous = merged.get(hit.id);


  if (!previous ||
      (hit.score ?? 0) > (previous.score ?? 0)) {
    merged.set(hit.id, hit);
  }
});

The important detail is that these aren't five unrelated chatbot conversations.

They are different retrieval angles over the same customer's accumulated memory.

The negotiator then combines:

1. Customer-specific memories.
2. Existing CRM commitments.
3. Anonymised lessons from other closed deals.

The output is a negotiation brief containing the actual blocker, a verdict, recommended strategy, risks, stakeholder-specific actions and supporting evidence.

I also wanted recommendations to be explainable.

Every recommendation should reference the memories or commitments that influenced it.

RevenueOS uses references such as M1 for account memories, C1 for CRM commitments and P1 for playbook lessons.

This makes it possible to trace a recommendation back to the information that produced it rather than treating the model's answer as unquestionable.

Teaching the system from previous deals

This is where RevenueOS becomes more interesting than a system that only remembers individual customers.

Imagine one customer closes a deal because the sales team offers a phased implementation plan.

Another customer is negotiating with us and has similar implementation concerns.

Could the system use the previous experience to make a better recommendation?

We wanted it to.

Whenever a deal is marked as won or lost, RevenueOS records the full outcome in that customer's private memory bank.

It also creates an anonymised lesson in a separate shared playbook bank.

There is a reason for keeping these memories separate.

The system should learn that a particular negotiation tactic worked without exposing the identity or confidential details of the original customer.

For example:

Original deal information:

A specific customer accepted a multi-year contract after the sales team proposed a phased implementation.

Generalised lesson:

Customers concerned about implementation complexity may respond better to phased implementation plans than additional discounts.

The anonymisation process uses an LLM to generalise the lesson, followed by a deterministic sanitisation step.

The latter removes identifiable names, domains, exact amounts and dates that might remain in the generated text.

This is an important distinction: We don't want to share customer conversations across accounts. We want to share the lessons learned from them.

Over time, the playbook can consolidate observations about which tactics tend to work against particular blockers.

You can read more about the broader concept of agent memory and how AI systems learn from past interactions.

Making memory visible

One thing we didn't want was for Hindsight to become an invisible dependency hidden behind an API call.

If persistent memory is the central idea of the application, users should be able to inspect it.

That's why we added Memory Explorer.

It provides two ways to explore customer memory:

A traditional memory list with retrieval information.
An interactive knowledge map built using React Flow.

The knowledge map places the customer at the centre and organises related information into categories such as stakeholders, conversations, negotiations, objections, commitments and deal history.

Users can explore individual memories, see their sources and follow relationships between them.

We find this particularly useful because a memory without provenance is difficult to trust.

If RevenueOS tells me that a customer repeatedly raised an integration concern, we should be able to inspect the conversations that support that conclusion.

The goal isn't just to show that the AI remembers something. It's to make that memory inspectable.

What We've learned building RevenueOS

There were a few things we found particularly interesting while working through this architecture.

1. More context doesn't automatically mean better answers

Passing every previous conversation to an LLM isn't a reliable memory strategy.

It increases the amount of information the model has to process without guaranteeing that the relevant information will be available or interpreted correctly.

Retrieval needs to be intentional. The right memories matter more than the number of memories.

2. Memory and structured state solve different problems

We wouldn't use conversational memory to replace a relational database.

A commitment needs an owner, recipient, due date and completion status. Those are structured business properties.

But understanding why that commitment was made requires conversational context.

Both representations are useful, and they should work together.

3. Customer isolation should be an architectural decision

We didn't want privacy to depend entirely on instructions in an LLM prompt.

Separate customer memory banks provide a stronger boundary for retrieval.

The system also needs to keep shared, anonymised learning separate from private customer history.

4. Recommendations need evidence

An AI-generated negotiation strategy can sound convincing even when it is wrong.

Connecting recommendations to specific memories makes it easier to inspect the reasoning and challenge incorrect conclusions.

We consider this an important requirement for any AI system that influences business decisions.

5. A promise is more valuable when the system remembers whether it was kept

Remembering that someone promised to send a document is useful.

Remembering that the document was eventually sent is equally important.

Otherwise, the system keeps treating resolved issues as outstanding blockers.

The memory needs to evolve with the relationship.

The bigger idea

RevenueOS started with a fairly simple question:

What if a sales representative never had to ask another colleague what happened during the previous meeting?

But the problem turned out to be more interesting than that.

A useful sales assistant shouldn't merely retrieve an old conversation. It should understand how the customer's position has changed, connect information from different people, identify unresolved commitments and use previous deal outcomes to inform future decisions.

That's what we wanted to explore with Hindsight.

I'm still particularly interested in where persistent memory takes AI applications beyond sales. The same underlying problem exists anywhere decisions depend on information accumulated over time.

A system that remembers conversations is useful. A system that understands how those conversations connect is much more interesting.