Sales copilots with full deal context

A good account executive carries the deal in their head. They remember the offhand comment the CFO made on the second call, the integration the champion cares about, the objection that nearly killed it in March and how they got past it. A sales copilot is supposed to do the same job, except most of them start every conversation having forgotten all of it.

The model can handle the reasoning fine. The trouble is it has nowhere to keep what it learns between conversations, so each call, email, and meeting lands in a vacuum. This page is about giving it the memory a good rep already has, plus the ability to search everything that's been said and sent across the whole deal.

The problem

The CRM was supposed to solve this, and in a sense it's the problem. Reps don't log half of what matters, and what they do log is structured fields, not context. "Stage: negotiation" doesn't tell the copilot that the economic buyer went quiet after the pricing call, or that legal flagged the data-residency clause, or that the champion promised to push internally and then didn't.

So a copilot leaning on the CRM walks in with the paperwork but none of the story. You can try feeding it the full history on every turn, but a real deal spans months, dozens of emails, a handful of calls, and several meetings. That overflows the context window quickly, and once it does, the copilot is choosing what to forget at random. Worse, deals change. The budget that was approved in Q2 gets frozen in Q3. If the copilot keeps treating the old fact as current, it gives the rep advice that's confidently wrong, which is the kind of memory drift that erodes a rep's trust in the tool fast.

There's also a retrieval problem hiding underneath. The answer to "what did they say about procurement timelines?" might be one line buried in a 40-minute call transcript from six weeks ago. Keyword search over a pile of transcripts won't reliably surface it, because the useful sentence rarely contains the words you searched for.

What Exabase unlocks

Give the copilot real memory and real search, and it starts behaving like the rep's second brain rather than a notetaker.

Before a call, the rep asks for a prep brief. The copilot pulls together everything that matters: who's on the account, what each stakeholder cares about, the objections raised so far and how they were handled, the commitments made on both sides, and the current state of the deal as opposed to the state three calls ago. None of that was manually logged. It was extracted from the conversations as they happened.

Mid-deal, a new stakeholder appears, a VP nobody's spoken to. The rep asks what the copilot knows about them. It surfaces the two times they were cc'd, the concern they raised in writing, and the fact that they report to the economic buyer. That's the kind of connective tissue that usually lives only in the rep's memory, if it lives anywhere.

A deal that went dark six months ago comes back to life. Instead of the rep re-reading every thread to reconstruct where it stalled, the copilot already holds the thread: the sticking point, the last commitment, the reason it paused. The rep picks up mid-sentence rather than from scratch.

How it works

Three primitives carry a sales copilot. You're not using the whole platform, just these.

Memory

Exabase Memory holds the deal narrative: stakeholders and what they care about, objections and resolutions, commitments, budget, timeline, the current state of play. You send in call transcripts, email threads, and meeting notes, and Exabase extracts the facts worth keeping. You don't have to define a schema for "objection" or "stakeholder preference" in advance; it pulls them out for you.

The part that matters most for sales is contradiction handling. When the budget changes or a champion is replaced or a timeline slips, the new fact supersedes the old one rather than sitting beside it. The copilot reasons from where the deal actually is now. This is the difference between a memory layer and a transcript archive, and it's why a vector database on its own isn't enough.

Resources

Resources are where the raw deal material lives: the call transcripts, the proposals, the email threads, the one-pagers you sent across. Memory holds the distilled facts; Resources hold the source documents those facts came from, stored and indexed so the copilot can go back to the original when the rep wants the exact wording rather than the summary.

Deep Search

Deep Search is how the copilot finds the specific thing inside all that material. It searches at the paragraph level, by meaning rather than keyword, so "what did they say about procurement timelines?" surfaces the relevant moment in a call transcript even if the rep's phrasing matches nothing in the actual words spoken. Results come back as scored chunks, ready to drop into the copilot's context.

Example architecture

The wiring is straightforward.

Scope per deal or per account. Most teams create one Base per account so memory and material stay cleanly separated between deals, though a single shared workspace works fine if you'd rather query across the whole book of business. (If you're running a multi-tenant sales product for other companies' reps, see multi-tenant memory for SaaS for the isolation pattern.)

After every interaction, send the artefact through. Call transcripts, email threads, and meeting notes go to Memory for fact extraction, and the raw documents get stored as Resources. If your transcripts arrive as audio or video, run them through Extract first to turn them into text, the same pattern the meeting assistants use.

Before every interaction, the copilot retrieves memory for the deal narrative and runs a Deep Search across the stored material for anything specific the rep is asking about. Both go into the prompt.

So material flows in after each touchpoint, gets distilled into memory and kept as source, and gets read back before the next one. The deal context accrues on its own.

What compounds over time

The case for infrastructure here is the same case a sales leader makes for good CRM hygiene, except it happens automatically.

Every call and email makes the copilot's picture of the account more complete, and because the memory self-organises, more material sharpens it rather than cluttering it. A deal six months in has a richer, cleaner context than a deal six weeks in, which is exactly backwards from how it works when context lives in a rep's head and degrades with time and turnover.

That last point is the real one. When a rep leaves, their deals usually leave with them, because the context was never written down in any usable form. A copilot built on persistent memory keeps the deal narrative regardless of who's holding the account this quarter. The institutional knowledge stops walking out of the door.

Who's building this

Teams building sales copilots, revenue intelligence tools, and AE assistants are the obvious fit, anywhere an agent needs to carry deal context across a long, multi-touch cycle.

The sales memory copilot example is the most direct starting point. It builds exactly this pattern end to end, so it's worth reading before you design your own.

Get started

Start with the getting started guide, then the sales memory copilot example for the full pattern. Creating memories and retrieving memories cover the core loop, and there's a free tier to build against.

FAQs

Does this replace our CRM?

No, it sits alongside it. The CRM holds structured deal data, stages, amounts, close dates. Exabase holds the unstructured context the CRM was never good at: what people said, what they care about, what was promised. Most teams feed memory from the same sources the CRM draws on and use the copilot to surface context the CRM fields can't capture.

How does it handle a deal that changes, like a frozen budget or a new decision-maker?

The new fact supersedes the old one through entity resolution. A budget that gets frozen replaces the approved figure rather than coexisting with it, so the copilot advises from the current reality rather than averaging two contradictory states.

Our calls are recordings, not text. Can it still use them?

Yes. Run the audio or video through Extract to get a timestamped transcript, then send that to Memory and store it as a Resource. The meeting assistants use case covers this flow in more detail.

Can it search across all our deals at once, not just one account?

Yes, if you store deals in a shared workspace rather than isolating each one in its own Base. That lets you ask cross-deal questions like "which open deals have raised data-residency concerns?" The trade-off is isolation, so the choice depends on whether you want strict per-deal separation or fleet-wide search.

What stops it surfacing stale advice from early in the deal?

Contradiction resolution. When a fact changes, the superseded version stops being treated as current, which prevents the memory drift that makes a copilot quietly unreliable over a long cycle.

How is this different from RAG over our call transcripts?

RAG over transcripts gives you search, which is genuinely useful and is what Deep Search provides. What it doesn't give you is a maintained, contradiction-resolved model of the deal's current state. You'd be retrieving raw chunks and asking the model to reconstruct the situation every time. The difference between RAG and agent memory goes into this properly.

Is retrieval fast enough to use live on a call?

Simple memory retrieval runs around 200ms, fast enough to power a real-time prep panel or in-call suggestion without a noticeable lag.