Building Alice’s Brain: an AI Sales Rep that Learns Like a Human - Sherwood & Satwik, 11x

A sales email needs more than a recipient’s name. It needs a reason that this seller’s offer matters to this particular person. That is the problem behind Alice, 11x’s AI sales development representative, or SDR. Sherwood Callaway, who introduces himself as the engineering lead for Alice, presents the system with Satwik Singh. Alongside Alice, 11x also builds Julian, a voice agent. An SDR sources leads, engages them across channels and books meetings; the outcomes that matter are positive replies and meetings booked. The opening example is an email Alice has written—the everyday output that her knowledge base must support.

Sherwood reports that Alice sends about 50,000 emails per day, compared with 20–50 for a human SDR. At the time of the talk, Alice was running campaigns for about 300 organizations. These are reported operating volumes, not measurements of reply rates or meetings booked; the human comparison’s conditions are not specified.

Two terms separate the parties involved: the seller is the company using Alice to sell something, and the lead is the person receiving the outreach. The seller supplies business context, such as products and case studies, which Alice uses to personalize emails.

Alice needs knowledge on both sides of that relationship:

• Seller context: Products, services, case studies, pain points, value propositions and the ideal customer profile, or ICP.
• Lead context: Role, responsibilities, priorities, previously tried solutions, pain points and employer.

The knowledge-base work here focuses on knowing the seller: making its business information available when Alice needs to write.

Originally, sellers pushed context into Alice through a feature called the library. They entered each product and service, then filled in descriptions of its pain points, solutions and value propositions. These were not merely dashboard labels: the descriptions became context for email generation. During campaign creation, users selected which library offers Alice could access.

That workflow created two connected problems. First, onboarding required substantial manual entry, and users could not run campaigns until they had populated their library. Second, selecting offers forced a poor tradeoff: too few could leave Alice with nothing relevant for a particular lead, while too many filled the context window with material that made the resulting emails worse.

The change was to move context selection from the seller to Alice. Instead of asking users to describe and select every useful offer, the product would let Alice pull seller information into a knowledge base and retrieve the relevant material when writing each email.

The new onboarding model resembles training a human SDR: provide source documents, allow time to learn and check what the person understands. For Alice, the equivalent is a centralized repository of seller information that can be consulted during message generation. Marketing materials, case studies, sales calls and press releases enter through three processing groups: documents and images, websites, and audio and video.

The ingestion architecture separates accepting a resource from making it searchable:

1. Accept the upload. The client uploads a resource, which is saved to S3 and passed to the backend.
2. Record and dispatch it. The backend creates database records and starts jobs according to the resource type and selected parsing vendor.
3. Wait for parsing. Vendors process resources asynchronously, then send completion webhooks to the ingestion path.
4. Persist and index the result. The application stores the parsed artifact in its database and embeds and upserts its content into Pinecone.
5. Expose the knowledge. Database updates refresh the UI, while the agent can query Pinecone for the newly stored information.

The final architecture reveal connects the upload and processing infrastructure to that agent query.

Within this architecture, the team identifies five pipeline stages: parsing, chunking, storage, retrieval and visualization. The last stage is part of the product contract: users need a way to inspect what Alice has learned, not just a background process that finishes successfully.

Parsing converts resources such as PDFs, images and MP4 files into text that the downstream language-model workflow can use. Multimodal models offer another way to consume some of these inputs, but their restrictions did not eliminate the need for parsing in this system. Alice’s common output format is Markdown, which preserves meaningful distinctions such as headings, paragraphs and formatting rather than flattening everything into undifferentiated text.

The team chose not to build parsers from scratch. Supporting five resource types meant supporting many individual file formats, and each format could demand specialist knowledge. Vendors already concentrated their engineering effort on those problems. Outsourcing parsing offered a faster route to market and a more credible outcome than asking the Alice team to become experts in every input format.

Initial vendor selection used three requirements: support the necessary resource types, return Markdown and deliver results through webhooks. Two quality dimensions were deliberately not benchmarked at first:

• Accuracy: Whether the extracted output matches the original resource.
• Comprehensiveness: How much of the resource’s information appears in the output.

The team assumed leading vendors would fall within a reasonable band on both. Cost optimization was also deferred: the system was still pre-production, so they lacked the usage data needed to understand where spending would accumulate.

For documents and images, the team selected LlamaParse, a LlamaIndex product. Among the document parsers they evaluated, it offered the broadest file-format support they found. Support also mattered: the team describes Jerry and the team joining a Slack channel within a couple of hours of the initial evaluation. The demonstration converts an 11x sales-deck PDF into Markdown, turning presentation content into material the rest of the pipeline can process.

For websites, they selected Firecrawl. They already knew it from another project, and the crawl endpoint they needed from the alternative, Tavily, was still in development during selection. That was an availability decision, not a finding that Tavily parsed websites poorly; Tavily now documents a crawl endpoint. The example takes the Brex homepage and produces another Markdown document.

For audio and video, they chose Cloudglue. The decisive capability was extracting information from the video imagery as well as transcribing speech. A transcript alone can miss information presented visually. The talk describes YouTube videos, MP4 files and other video formats becoming Markdown. Input route and API still matter when reproducing that behavior today: Cloudglue’s current Describe documentation demonstrates uploaded-video visual extraction, while its current Extract guide limits direct YouTube entity extraction to speech. The talk does not specify Alice’s historical YouTube processing route.

Once every resource is Markdown, chunking turns long documents into units that can be embedded and retrieved. A title and a paragraph carry different kinds of meaning, so preserving structure matters. Retrieving an entire ten-page document would also make it harder to isolate the part relevant to a particular email.

Possible boundaries include tokens, sentences and Markdown headers; an LLM can also decide how to split a document. The choice starts with the intended retrieval unit: what information should stay together, what will the agent ask for, and will the same approach work for a PDF, a slide deck and a video-derived document? A chunk must preserve enough meaning to be useful while remaining suitable for embedding and storage.

Alice uses a waterfall: split on Markdown headers first, then sentences, then tokens as needed to satisfy a target token count. The target size is not specified in the talk. The following TypeScript expresses that control flow, with the boundary splitters and tokenizer supplied by the implementation:

type Split = (text: string) => string[];

type ChunkingRules = {
  maxTokens: number;
  countTokens: (text: string) => number;
  byMarkdownHeader: Split;
  bySentence: Split;
  byTokenLimit: Split;
};

function chunkMarkdown(text: string, rules: ChunkingRules): string[] {
  const splitters = [
    rules.byMarkdownHeader,
    rules.bySentence,
    rules.byTokenLimit,
  ];

  function split(part: string, level: number): string[] {
    if (rules.countTokens(part) <= rules.maxTokens) return [part];
    if (level === splitters.length) {
      throw new Error("Token splitter exceeded the configured limit");
    }
    return splitters[level](part).flatMap(piece => split(piece, level + 1));
  }

  return rules.byMarkdownHeader(text).flatMap(part => split(part, 1));
}

A section that already fits stays intact. An oversized section falls through to sentence boundaries, and an oversized sentence reaches the token splitter. This makes size enforcement progressively more aggressive instead of discarding structural boundaries immediately.

The team reports that the approach worked across their document types and preserved Markdown chunks they could display cleanly in the UI. It also prevented very long chunks from diluting the meaning of the information being embedded. That connects chunking to two consumers at once: retrieval needs focused units, and users need readable evidence.

Retrieval-augmented generation does not require a vector database. External context can come from a graph database, Elasticsearch, a document or relational database, a key-value store, files or S3. Alice uses vector storage because the operation the team wanted was similarity search.

The team chose Pinecone as an established, cloud-hosted provider with approachable guides and SDKs. Hosting removed another infrastructure responsibility. Its bundled embedding models also removed the need to select a separate embedding provider or host a model themselves: they could use the embedding capability supplied with the database service. Vendor support contributed beyond setup, helping the team examine alternative storage approaches, including graph databases and graph RAG.

With the seller’s information indexed, the next question is how to retrieve it. The talk describes a progression in which retrieval becomes increasingly controlled by the agent:

In the last approach, research can broaden or deepen according to what the task still needs. Retrieval is no longer necessarily a single fixed step before generation.

Alice’s team built its research agent with Letta. The workflow begins with lead information, which conditions the research plan:

1. Form a plan containing one or more context-retrieval steps.
2. Execute the retrieval tool calls.
3. Summarize the results.
4. Return answers in a clean Q&A format.

The demonstration shows a result organized around two questions. The important connection is between lead-specific research and seller knowledge: the repository can contain broad business context, while the agent selects what is useful for the current recipient.

A seller is trusting Alice to represent its business. That creates concrete concerns: will she describe the products correctly, invent a case study or testimonial, or claim to solve a pain point the business does not address? The team’s response was to let users inspect the knowledge behind the output.

The product projects vectors from Pinecone into three dimensions using UMAP, then renders them as interactive nodes. Clicking a node reveals its associated text chunk. Sales and support teams use this view to demonstrate what Alice knows. The useful inspection operation is the connection from a visible node to stored source text; the spatial display itself is not a correctness test.

The ordinary onboarding path begins with an upload modal. Users add URLs, web pages, documents or videos and click Learn; the resources then appear in the knowledge-base UI. A separate Letta-powered agent lets users ask questions about that knowledge.

During campaign creation, knowledge-base content appears as Q&A on the left side of the interface. Expanding a question reveals the retrieved chunks used in the messaging flow. This brings evidence inspection into the task where it matters: a user can examine the context used to produce outreach instead of manually choosing every offer beforehand. The resulting experience returns to the human SDR analogy—provide the source material, then inspect how it is being used.

The difficulty of this project came from the accumulation of small decisions: choosing technologies, supporting heterogeneous resource types and connecting their outputs into one usable workflow. Sherwood describes RAG as substantially harder than the team expected. Their production advice follows from that experience: first ship a system that satisfies the product requirements, then establish benchmarks from real usage and iterate.

Vendors were part of that learning process, not just interchangeable endpoints. The team recommends asking vendors to explain their offerings, compare alternatives and help customers understand why a particular approach fits. Those conversations can reduce the amount of specialist knowledge a small product team must acquire alone.

The remaining work was explicitly a future agenda:

• Email hallucinations: Track and address unsupported claims in generated outreach.
• Parsing quality: Evaluate vendors on accuracy and completeness, the dimensions deferred during initial selection.
• Hybrid retrieval: Experiment with a graph database alongside vector storage.
• Pipeline cost: Reduce spending across the full ingestion and retrieval path.

The implemented knowledge base changed how sellers supplied and inspected context. The next phase was to measure whether the extracted information was faithful and complete, whether Alice used it reliably, and what that reliability cost.