I Stopped Feeding My Agent More Context and Gave It Memory

A sales agent may process six months of customer history and still struggle with a basic question like "What matters most for my next call?" The issue isn't necessarily the quantity of information, but rather that a deal isn't just a collection of standalone facts. It's a sequence of events, with objections being raised, responses given, objections evolving, stakeholders joining, competitors entering the picture, and certain concerns gaining greater importance.

If an agent receives the full history each time, it must reconstruct the sequence from scratch. The goal is for the agent to emulate what a seasoned salesperson does: remember the past and bring the pertinent parts forward when needed. This is where persistent memory proves more advantageous than merely piling on additional context.

A sales deal evolves over time. For instance, imagine a deal with this history: in January, the CFO expressed that the pricing was too high. In March, the CTO found the product promising but had concerns about integration. In April, the sales team proposed a discount. By May, the CFO no longer viewed budget as the main issue. In June, a competitor offered a lower upfront price.

In July, the CFO requested a three-year cost comparison. A conventional CRM can store all of this data, as can an LLM given all of this. However, a salesperson preparing for the July call doesn't strictly require a chronological dump. Instead, they need something akin to: "Current concern: Three-year cost comparison. Previous concern: Pricing was initially a blocker, but the CFO later stated that budget was no longer the main issue.

Internal support: The CTO is positive about the product. Competitive pressure: Competitor X has a lower upfront price." The distinction lies in the subtle representation of the current state of the relationship. This is the behavior I aimed to instill in the agent.

Introducing more context can generate more work for the model. The typical architecture for a sales agent is as follows: CRM history | v Large context | v LLM | v Sales briefing. While simple to comprehend and prototype, the model now has two tasks: answering the salesperson's query and determining which parts of the historical context remain relevant.

As the history expands, these tasks become increasingly intertwined. For a minor deal, this might not matter. But for a long-running deal, it becomes crucial. A January objection and a July objection may both relate to the same topic but symbolize entirely different states of the customer relationship. I didn't want the agent to treat the CRM like a transcript. I wanted it to view the history as experience. Memory gives the history somewhere to reside.

The architecture I employed separates persistent memory from model reasoning. Interaction | v retain() | v Persistent memory | | later v recall() | v Relevant history | +---- Current question | v LLM | v Current answer. I utilized Hindsight Cloud via hindsight-client for the persistent memory layer. The concept is straightforward: interactions become persistent memories, future queries can retrieve relevant memories, and the recalled information serves as context for the LLM, which then reasons over that information.

The model does not need to permanently store the customer history. That responsibility lies with the application. By keeping the two concepts distinct, the system becomes easier to grasp. The deal serves as the unit of memory.