Building an AI Sales Development Representative with Advanced RAG Knowledge Base

alice · Tech · year n/a · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Sales development automation

11x needed Alice, its AI sales development representative, to write personalized outreach at scale by understanding each seller's products, context, and collateral without forcing sellers to manually maintain a brittle product library.

Constraints:

Alice sends far more email than a human SDR, so context errors scale quickly.
Seller knowledge arrives as documents, images, websites, audio, and video.
Different resource types need different parsing and chunking strategies.
The retrieval system has to support both broad and deep research over seller knowledge.

Architecture

11x replaced seller-pushed context with a knowledge base that ingests resources uploaded in the client, stores originals in S3, creates database records, dispatches vendor parsing jobs by resource type, consumes parsing webhooks, stores parsed artifacts, embeds chunks into Pinecone, and lets Alice query the vector database while writing emails. The team uses markdown/sentence/token waterfall chunking and deep research RAG agents that plan one or many retrieval steps.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  seller[Seller] --> knowledge-base-client[Knowledge Base Client]
  knowledge-base-client --> s3-storage[S3 Storage]
  knowledge-base-client --> backend-jobs[Backend Jobs]
  backend-jobs --> parsing-vendors[Parsing Vendors]
  parsing-vendors --> backend-jobs[Backend Jobs]
  backend-jobs --> parsed-artifact-store[Parsed Artifact Store]
  parsed-artifact-store --> pinecone-vector-db[Pinecone Vector DB]
  pinecone-vector-db --> alice-sdr-agent[Alice SDR Agent]
  alice-sdr-agent --> seller[Seller]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Seller`	Business user whose products and context must inform outreach.	`Knowledge Base Client`
`Knowledge Base Client`	Upload and management surface for seller resources.	`S3 Storage`, `Backend Jobs`
`S3 Storage`	Stores original uploaded resources.	`Knowledge Base Client`
`Backend Jobs`	Creates resource records and dispatches vendor parsing jobs.	`Parsing Vendors`, `Parsed Artifact Store`
`Parsing Vendors`	Convert documents, images, websites, audio, and video to text.	`Backend Jobs`
`Parsed Artifact Store`	Stores parsed resources and clean chunks.	`Pinecone Vector DB`
`Pinecone Vector DB`	Stores embeddings for retrieval by Alice.	`Alice SDR Agent`
`Alice SDR Agent`	Generates personalized sales emails using seller knowledge.	`Pinecone Vector DB`, `Seller`

Data flow

A seller uploads a resource. The client saves it to S3 and the backend creates DB records and parsing jobs. Vendors parse the resource asynchronously, webhook results return to ingest, parsed artifacts are stored and embedded into Pinecone, and Alice queries the knowledge base when generating personalized emails.

“It starts off with the user uploading something any document or resource in the client and then we save it to our S3 bucket”transcript, stated

“eventually our agent can query pine cone, our vector DB for that stored information that we just put in. So now that we have a high level of understanding of how the knowledge base works, let's dig into each individual step in the pipeline. There are five”transcript, stated

Why this architecture

The knowledge base flips context ownership: Alice pulls the most relevant seller context instead of relying on the seller to manually push details into every email. Asynchronous parsing and resource-specific vendors handle messy inputs, while chunking preserves logical units for retrieval.

“we could flip things around so that Alice can proactively uh pull all of the context about the seller into her system”transcript, stated

“um what kind of logical units am I trying to preserve in my data, right? What do I eventually want to extract during my retrieval, right? what strategy will keep them intact and at the same time you're able to successfully embed them and store them in whatever DB you want.”transcript, stated

Models used: embedding model · deep research RAG agents

Scale

Alice sends about 50,000 emails per day.
“Alice sends about 50,000 of these emails to uh in a given day and that's in comparison to a human SDR who would send 20 to 50. Uh and Alice is now running campaigns for about 300 different uh business organizations.”transcript, stated
A human SDR would send about 20 to 50 emails.
“to uh in a given day and that's in comparison to a human SDR who would send 20 to 50. Uh and Alice is now running campaigns for about 300 different uh business organizations.”transcript, stated
Alice runs campaigns for about 300 business organizations.
“20 to 50. Uh and Alice is now running campaigns for about 300 different uh business organizations. So before we go any further, I want to define some terms because since we work at 11X, we have our customers but then our customers also have their customers.”transcript, stated
The system handles at least five resource types.
“had five different resource types and a lot of different file types within each of them. We thought it was going to be too many and we thought it was going to be too much work. We wanted to get to market quickly.”transcript, stated

Alternatives considered (roads not taken)

Manual seller-maintained product library.

Rejected because: It pushed context-entry work onto the seller and did not scale with email volume.

“instead of the seller being responsible for pushing context about the business to Alice, we could flip things around so that Alice can proactively uh pull all of the context about the seller into her system and then use what'sever whatever is most relevant when writing those”transcript, stated

One chunking strategy for every resource.

Rejected because: Documents, PDFs, PowerPoints, and videos preserve useful context differently.

“should I try a different strategy for different resource types we have like we have to deal with PDFs, powerpoints, videos”transcript, stated

Simple one-shot retrieval only.

Rejected because: Deep research agents may need one or many retrieval steps and can decide whether to retrieve more.

“they execute them and the plan may contain one or many steps of retrieval. Right? These deep research agents can go broad or deep depending on the context needs and they can evaluate whether or not they want to do more retrieval. Um”transcript, stated

Patterns

`rag-retrieval` (sales-knowledge)

Alice retrieves seller knowledge from Pinecone while generating outbound emails.

“all of the vectors vectors from our uh pine cone vector database”transcript, stated

`retrieval-ranking` (chunking)

The team tuned chunking to preserve retrievable logical units across resource types.

“we split our markdown headers and then we split on sentences and then eventually we split on tokens”transcript, stated

`tool-use-orchestration` (ingestion)

The ingestion pipeline routes resource types through different parser vendors and jobs.

“kicks off a bunch of jobs depending on the resource type and the vendor selected.”transcript, stated

Tradeoffs

Context ownership

Chose Agent pulls seller context from the knowledge base over Seller manually injects product details into outreach.

Rationale: The agent can use whatever context is most relevant for each email.

“use what'sever whatever is most relevant when writing those emails.”transcript, stated

Chunking strategy

Chose Waterfall chunking by markdown headers, sentences, then tokens over Fixed-size token chunking alone.

Rationale: This preserves clean UI chunks while keeping records within token budgets.

“it has successfully preserved our markdown chunks that we can kind of cleanly show in the UI.”transcript, stated

Gotchas (what bit them)

Super-long chunks dilute meaning.

Root cause: Large chunks combine too many concepts for embedding retrieval.

Resolution: Use a markdown-header, sentence, and token waterfall strategy.

“super long chunks which are, you know, diluting the meaning behind your document”transcript, stated

Different media types need specialized parsing.

Root cause: Documents, websites, audio, and video do not become clean text the same way.

Resolution: Dispatch parsing jobs by resource type and vendor.

“depending on the resource type and the vendor selected.”transcript, stated

Evaluation

11x evaluates through outbound-email volume, campaign count, chunk retrievability, UI chunk quality, hallucination reduction, and deep-research retrieval behavior.

Metrics: Emails per day · Campaign organizations · Chunk token size · Retrieval relevance · Hallucination reduction

“address hallucinations in our emails.”transcript, stated

Outcomes

Alice sends about 50,000 emails per day.
Alice runs campaigns for about 300 organizations.
The knowledge base replaced seller-pushed context with agent-pulled context.

The source reports 50,000 emails per day, 20-50 human-SDR emails, 300 business organizations, five resource types, and Pinecone-backed retrieval.

“And that's effectively what we accomplished with the knowledge base”transcript, stated