She Never Worked Those Ten Deals. Her Agent Remembered All of Them.

Sreekar KVK — Tue, 29 Sep 2026 06:08:49 +0000

A sales agent on one shared Hindsight memory bank, with one rule that keeps it honest: the model writes the words, code does the math.
Week three. A prospect says finance has frozen new vendor spend. The new rep hasn't said a word yet, but the agent beside her already knows something useful: of the ten past deals that hit the same objection at the same stage, six were lost. It drafts a follow-up based on the four that survived.
She has never worked a single one of those ten deals.
Most teams get hindsight in the post-mortem, after the deal is already dead. I wanted it mid-call. Hindsight, Vectorize's open-source agent memory system, gave me the memory layer to build it.
Sales teams forget how they lose
Sales teams repeatedly lose deals to the same handful of causes: budget freezes, champions changing roles, competitor discounts, missing executive sponsors.
The knowledge exists, but it's scattered across CRM notes, call recordings, Slack threads, and senior reps' heads. When a senior rep leaves, their hard-earned lessons leave too.
Call-intelligence tools can analyze a call or deal. I wanted something different: compare the live deal against the team's entire loss history and produce a specific, evidence-backed warning.
Seven steps, no new workflow for the rep
The agent reads existing calls, emails, and CRM notes. Every event follows:
retain → extract → recall → reflect → score → explain → draft
Retain: closed deals go into one shared memory bank.
Extract: signals such as objections and competitors come from the prospect's turns.
Recall: similar deals are fetched by objection, stage, and deal size.
Reflect: code computes patterns such as "6 of 10 lost at this stage."
Score: a running belief updates as new evidence arrives.
Explain: every change gets a one-line reason tied to the counts.
Draft: when a pattern is sufficiently risky, the agent drafts a follow-up based on deals that survived the same objection.
Hindsight's documentation describes the core operations as retain, recall, and reflect; the rest of the pipeline sits around them.
One shared bank, not one per rep
The most important architectural decision was using one memory bank for the whole team.
A separate bank per rep would give every new hire an empty memory. A shared bank lets them inherit the team's accumulated experience.
I retain structured facts rather than raw transcripts:
BANK_ID = "sales-team-shared"

client.retain_batch(
bank_id=BANK_ID,
items=[
{
"content": render_deal(d),
"context": f"{d.outcome} deal, {d.objection_stage} stage",
"tags": [
f"objection:{d.objection}",
f"stage:{d.objection_stage}",
f"outcome:{d.outcome}",
f"rep:{d.rep}",
],
}
for d in deals
],
)

The structured representation makes recall about the shape of a deal, rather than the exact wording of a transcript.
Tags are important too. Semantic retrieval is great for finding similar memories, but statistics need hard boundaries. Tags let me ask for exactly "budget freeze, Evaluation, lost" instead of relying on similarity to define the dataset.
The model never does the arithmetic
This was the rule that made me trust the system.
An early version let the model describe the pattern. It was fluent, but wrong often enough that I stopped trusting it.
So I took the arithmetic away from the model.
def reflect_pattern(deals, objection, stage):
scoped = [
d for d in deals
if d.objection == objection
and d.objection_stage == stage
]

lost = sum(d.outcome == "lost" for d in scoped)

return Pattern(
    key=f"objection:{objection}@{stage}",
    total=len(scoped),
    lost=lost,
    won=len(scoped) - lost,
)

Code computes the numbers. The model only explains them.
Every generated reason must contain the exact lost / total figures. If validation fails, the system retries and eventually falls back to a template.
Hindsight's reflection output can still be shown, but if it disagrees with the computed counts, the counts win.
The score is a belief, not a recalculation
Instead of recomputing a win probability from scratch after every message, I treat it as a running belief.
Evidence changes the score in log-odds space, with confidence increasing as more historical deals support a pattern.
A signal backed by two deals therefore moves the score less than one backed by ten.
I also hit a real bug here: one competitor had five losses and zero wins. A loss ratio of exactly 1.0 sends logit() to infinity.
Clamping the ratio fixed it. The exact clamp range is a documented engineering choice, not something I claim is mathematically fundamental.
One deal, blow by blow
Here's what the system looks like during a live evaluation-stage deal.

Competitor mentioned. The competitor appeared in seven historical deals, six of which were lost. The score dips slightly because a mention alone is weak evidence.
Finance freezes spend. The score drops significantly: "Dropped 15 pts: budget freeze mentioned, and 6 of 10 past budget_freeze deals at Evaluation were lost."
A follow-up is drafted. The pattern crosses our threshold, so the agent pulls responses from the four deals that survived the same objection and drafts a follow-up offering approaches that worked historically.
The champion wobbles. Another risk signal appears, but because the wording is uncertain, it receives lower weight. The existing draft isn't discarded; the agent adds a heads-up.
The prospect responds positively.
The score recovers. The historical exception remains visible rather than being filtered out.
Nothing changed but the memory
This is probably my favorite behavior.
Add one more lost budget-freeze deal and the next run changes from:
6 of 10
to:
7 of 11
No prompt edit. No retraining.
The memory changed, so the agent's behavior changed.
Never count what you only partly recalled
There is one dangerous trap: using a truncated retrieval result as the basis for a statistic.
Recall is designed to return the best matching memories within a context budget. That's perfect for giving an LLM useful context, but terrible for calculating "6 of 10".
So the system separately reconstructs the complete deal dataset and verifies the totals against known ground truth.
def integrity_check(client, expected):
recalled = fetch_all_deals(client, bank_id=BANK_ID)
got = tally(recalled)

return "COUNTS VERIFIED" if got == expected else "COUNT MISMATCH"

If Hindsight isn't reachable, the system falls back to a local store and explicitly says so. It never pretends to be using a memory backend that isn't available.
Five things I'd tell anyone building on agent memory

Retain facts, not transcripts. Structured records make recall about deal shape rather than vocabulary.
Let code count and the model talk. Numbers users act on should trace back to records.
Choose memory scope based on what you want to transfer. A shared bank lets new hires inherit the team's experience.
Verify recall before trusting aggregates. Retrieval is fine for context and dangerous for statistics.
Don't confuse correlation with causation. "6 of 10 lost" is a pattern in one team's history, not proof that the objection caused the losses. What I like about keeping the memory in Hindsight is that the model can stay small and stateless. The memory does the remembering, so every newly closed deal becomes another piece of experience available to the next call. Which brings me back to week three. A rep is about to hear that finance has frozen spend, and she doesn't need to have worked those ten deals to know what they taught. Whatever happens on her call, it goes into the bank too. Nobody on the team should have to lose the same deal twice. Code: https://github.com/ANIKETHSAI9813/lost_agent.git

DEV Community: Sreekar KVK

She Never Worked Those Ten Deals. Her Agent Remembered All of Them.