The agent is the easy part. A research agent that pulls context, reasons over it, and drafts a brief is maybe two weeks of work if the context is available.
The context is never available. That is the project, and it is roughly three months.
Teams that invert this order build an impressive demo on curated data in week two, then spend six months discovering that production data does not resolve, does not chunk usefully, and does not have access controls the assistant can respect. Here is the build order that works.
Layer 1: Ingestion
Connectors for CRM, email, calendar, call recordings, support, product telemetry, and billing.
Design choices that matter more than they look:
- Incremental sync with a replayable event log. You will change your chunking strategy. You will change your embedding model. Both mean reprocessing everything, and you do not want to re-pull from every source API to do it. Land raw payloads first, transform downstream.
- Preserve raw payloads. Whatever you discard now is what you need in month four. Storage is cheaper than a re-integration.
- Rate limits are the schedule. CRM APIs will not let you backfill three years of activity quickly. Plan the backfill as a multi-day job with checkpointing, not a script someone runs on a Friday.
- Diarised transcripts, not merged text. A transcript that does not distinguish the rep from the buyer is close to useless for the questions you actually want to ask. Speaker attribution is not a nice-to-have.
Layer 2: Entity resolution
This is where the schedule goes wrong, and it goes wrong for everyone.
The same account is Acme Corp in the CRM, acme.com in product telemetry, Acme Corporation Ltd in billing, and ACME in the support system. The same person is a user ID, an email hash, a phone number, and a LinkedIn URL.
Retrieval quality is bounded by this mapping. A brief that misses half an account's history because two records never joined is worse than no brief, because the rep trusts it.
What actually helps:
- Deterministic matching first — exact domain, verified email, external ID. Cheap, high precision, and it handles most of the volume.
- Probabilistic matching for the remainder, with a review queue rather than an auto-merge. Silent bad merges are the worst failure mode here, because they surface as one customer seeing another customer's information.
- Watch transitive merges. A resolves to B, B resolves to C, and the A-to-C link is wrong. Cap chain depth and require higher confidence for transitive links.
- Persist the resolution as a graph, not as a one-off join. You will need it for privacy work too — rights requests need exactly this mapping.
Layer 3: Chunking and indexing
Generic chunking strategies perform poorly on sales data, because the semantically meaningful unit is not a fixed token window.
For call transcripts, chunk by topic segment, not by turn or by token count. An objection spans several exchanges — the buyer raises it, the rep responds, the buyer clarifies. Split that across a boundary and retrieval returns half an objection, which reads as agreement.
For email threads, the thread is the unit. A single message out of context is frequently misleading, especially short ones.
For CRM records, generate a natural-language summary at write time and embed that alongside structured filters. Embedding a raw record dump wastes most of the context window on field names.
Hybrid retrieval — semantic plus keyword — outperforms pure vector search noticeably here, because sales queries contain exact tokens that must match: competitor names, product SKUs, contract terms. Semantic similarity will happily return a passage about a different competitor.
Layer 4: Access control at query time
Non-negotiable, and much easier to build now than to add later.
A rep's assistant must not surface a deal they are not entitled to see. Enterprise customers will ask about this in security review, and "the UI filters it" is not an answer, because the UI is not where the retrieval happened.
Filter at the retrieval layer, before results enter the context window. Once a passage is in the prompt, it is in the answer, and no amount of instruction reliably prevents the model from using it. Post-hoc filtering of generated output is not a control.
Practically: encode ACLs as metadata on every chunk and apply them as a pre-filter in the vector query, not as a post-processing step.
The validation gate
Before building anything user-facing, ask the system this:
What were the three most common objections in lost deals last quarter, in the buyer's own language?
If it cannot answer, do not proceed to the agent. The answer requires working transcript ingestion, correct entity resolution across CRM and calls, chunking that keeps objections intact, and retrieval that can filter by outcome and date.
It is a single query that exercises every layer. Teams that pass it ship agents that work. Teams that skip it ship agents that hallucinate confidently, which is worse than shipping nothing.
Then, and only then, the agent
Once retrieval works, the patterns come quickly: pre-call research briefs with citations, constrained outreach drafting against an approved evidence library, questionnaire response generation, deal-risk signals.
Two things to carry into all of them. Every factual claim about the buyer needs a citation the rep can check in two seconds — an unsourced claim that turns out wrong costs more trust than ten correct ones earn. And log every prompt, retrieval set, and completion, because after your first model upgrade you will need to explain why quality changed.
The full engineering treatment — the five production patterns, guardrails, measurement, cost ranges, and a ninety-day rollout — is here: Generative AI for Sales: The Engineering Guide for 2026.
We build these as LLM integration and agentic workflow engagements.
Frequently Asked Questions
Why build retrieval before the agent?
Because the agent is roughly two weeks of work and the retrieval layer is three months. Building the agent first produces a demo on curated data, followed by months of discovering that production data does not resolve, chunk, or filter the way the demo assumed.
What makes entity resolution hard in sales data?
The same account and person appear under different identifiers in every system — CRM, billing, telemetry, support. Retrieval quality is bounded by that mapping, and a silent bad merge surfaces as one customer's data appearing in another customer's context, which is a confidentiality incident rather than a quality bug.
How should call transcripts be chunked for retrieval?
By topic segment rather than by turn or fixed token count. An objection spans several exchanges — raised, answered, clarified — and splitting it across a chunk boundary returns half an objection, which frequently reads as agreement.
Is vector search alone enough for sales retrieval?
No. Hybrid retrieval combining semantic and keyword search performs noticeably better, because sales queries contain exact tokens that must match — competitor names, SKUs, contract terms. Pure semantic similarity will return a passage about a different competitor.
How do you enforce access control in a RAG system?
Filter at the retrieval layer, before results enter the context window, using ACL metadata as a pre-filter on the vector query. Once a passage is in the prompt it is available to the answer, and instruction-based restrictions are not a reliable control.
What is a good readiness test for a sales retrieval layer?
Ask it for the three most common objections in lost deals last quarter, in the buyer's own words. Answering requires working transcript ingestion, correct entity resolution, objection-preserving chunking, and outcome filtering — one query that exercises every layer.
Top comments (0)