Rebuilding an AI SDR Agent with Multi-Agent Architecture for Enterprise Sales Automation
11x · Tech · 2024 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (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: Enterprise sales automation and AI SDR campaign creation
11x needed to rebuild Alice from a button-heavy outreach workflow into a production AI SDR that could guide campaign creation, source and research leads, personalize outbound messages, and eventually learn from campaigns like a digital worker.
Constraints:
- The rebuild happened during company relocation and fundraising chaos.
- Alice 1 required too much button clicking and manual input to feel like a digital worker.
- The team needed to migrate about 300 customers while go-to-market demand kept growing.
- Campaign creation required many external actions, including lead fetching, database writes, email drafting, and user feedback.
- The architecture had to balance user flexibility with predictable output quality and production observability.
Architecture
11x rebuilt Alice 2 around LangGraph/LangChain with a hierarchical multi-agent campaign-creation graph. A supervisor node interacts with the user and routes work to specialist subagents for research, positioning, LinkedIn messaging, and email writing, while audience creation remains separate. This replaced failed experiments with a single ReAct agent and a rigid 15-node workflow, keeping the flexibility of conversational agents while adding task specialization.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR A["Alice chat interface"] --> B["Supervisor node"] B --> C["Researcher subagent"] B --> D["Positioning report subagent"] B --> E["LinkedIn message writer"] B --> F["Email writer"] C --> G["Lead and web research tools"] D --> G E --> H["Messaging and database tools"] F --> H B --> I["LangGraph runtime"]
Components
| Component | Role | Interacts with |
|---|---|---|
Alice chat interface |
User-facing campaign-creation surface for interacting with Alice like a human team member. | Supervisor node |
Supervisor node |
Routes campaign-creation tasks to specialist agents and handles user interaction. | Alice chat interface, Researcher subagent, Positioning report subagent, LinkedIn message writer, Email writer, LangGraph runtime |
Researcher subagent |
Performs lead research to support campaign personalization. | Supervisor node, Lead and web research tools |
Positioning report subagent |
Builds a positioning report for how to frame the offer to a specific lead. | Supervisor node, Lead and web research tools |
LinkedIn message writer |
Drafts LinkedIn outreach as one specialized campaign-creation task. | Supervisor node, Messaging and database tools |
Email writer |
Drafts personalized email outreach. | Supervisor node, Messaging and database tools |
Lead and web research tools |
External tools for fetching leads, researching people, and accessing information outside model context. | Researcher subagent, Positioning report subagent |
Messaging and database tools |
Tools for inserting entities, drafting messages, and executing campaign actions. | LinkedIn message writer, Email writer |
LangGraph runtime |
Agent framework, cloud hosting, and observability substrate for production Alice 2. | Supervisor node |
Data flow
A user starts campaign creation through chat. The supervisor manages the campaign-creation graph, delegates lead research, positioning, LinkedIn-message writing, and email writing to specialist subagents, then receives their completed work. Those agents use tools and vendor infrastructure to fetch or write outside-world data. LangGraph hosting and observability support production execution, while separate audience creation and future self-learning feed campaign performance back into the product.
3 supporting quotes
Why this architecture
11x chose the multi-agent hierarchy because the ReAct prototype was flexible but weak at tool ordering and output quality, while the workflow prototype was high quality but too rigid and coupled to the UI. Specialized subagents gave campaign subtasks their own prompts and tools without freezing the entire conversation into a fixed user flow.
3 supporting quotes
Models used: Claude models · GPT-4 · Claude 2 · Claude 3 · GPT-4o
Scale
- The rebuild reached production in three months.“We built this enterprisegrade AI STR in just 3 months.”transcript, stated
- The migration covered about 300 existing customers.“we had about 300 customers that needed to be migrated from our original platform to the new one.”transcript, stated
- Alice 2 had sourced close to two million leads by the time of the talk.“she's now sourced close to two million leads. I think these numbers are a little out of date.”transcript, stated
- The system had sent close to three million messages and generated about 21,000 replies.“We've sent uh close to three million messages and generated about 21,000 replies.”transcript, stated
- Recent reply rate was around 2%, on par with a human SDR.“over the last month or so, her reply her reply rate is around 2% which is on par with a a human SDR.”transcript, stated
Alternatives considered (roads not taken)
A single ReAct campaign-creation agent with many tools
Rejected because: It stayed flexible, but struggled with tool choice/order, could loop until recursion-limit errors, and produced mediocre campaign outputs.
A predefined workflow graph for campaign creation
Rejected because: It improved tool discipline and output quality, but coupled product UX to graph structure and blocked jumping around the campaign flow.
3 supporting quotes
Building non-essential infrastructure internally
Rejected because: The team intentionally leaned on vendors and a vanilla stack to move quickly and avoid adding unfamiliar infrastructure risk.
Patterns
multi-agent-orchestration (architecture)
Alice 2 uses one supervisor and multiple specialist subagents for campaign-creation work, separating research, positioning, LinkedIn messaging, and email writing.
tool-use-orchestration (architecture)
The team modeled external actions and information access as tools, including lead fetching, database writes, email drafting, and information retrieval beyond the model context.
observability-tracing (operations)
11x selected LangChain/LangGraph partly because cloud hosting and observability made it possible to understand how Alice performed in production.
human-in-the-loop-gate (interaction)
The workflow prototype used LangGraph node interrupts to collect user input or feedback at specific graph steps, making human feedback an explicit pause point.
Tradeoffs
Campaign-creation architecture
Chose hierarchical multi-agent graph over single ReAct agent or fixed workflow.
Rationale: The hierarchy preserved conversational flexibility while giving each campaign subtask a specialist role and avoiding workflow rigidity.
Implementation strategy during a risky rebuild
Chose vanilla stack and vendor leverage over building unfamiliar or non-essential components internally.
Rationale: The rebuild already carried agent and knowledge-base risk, so the team reduced unrelated infrastructure risk and moved faster.
Handling agent capability
Chose tools for external actions and knowledge access over making the model rely on internal skill alone.
Rationale: The team viewed tools as the preferred way to act in the outside world and reduce context-token burden.
Gotchas (what bit them)
Large tool sets made the ReAct agent unreliable.
Root cause: One general agent had to decide which tool to call and in what order across the whole campaign-creation process.
Resolution: The team moved toward structured nodes and then specialist subagents so each task had clearer responsibility.
The ReAct prototype could spin into recursion-limit failures.
Root cause: The agent repeatedly tried to complete a campaign-creation step without succeeding.
Resolution: The workflow prototype fixed this with a clearly defined execution flow and fixed number of steps.
A rigid workflow improved quality but made product iteration laborious.
Root cause: The campaign-creation front-end flow became coupled to graph structure.
Resolution: The team abandoned the workflow as the final architecture and adopted a multi-agent hierarchy.
Thinking of an agent as a product user flow led to the wrong architecture.
Root cause: The team initially framed Alice as either a user flow or directed graph instead of a team of specialized coworkers.
Resolution: They reframed the system as a team of coworker-like agents and broke big tasks into smaller tasks.
Evaluation
The talk evaluates Alice 2 through production migration and business metrics rather than a formal offline benchmark: migration speed, customers migrated, leads sourced, messages sent, replies generated, and reply rate compared with human SDRs.
Metrics: Three months from first commit to last business-customer migration · About 300 customers migrated · Close to two million leads sourced · Close to three million messages sent · About 21,000 replies generated · Around 2% reply rate, on par with a human SDR
3 supporting quotes
Outcomes
- Alice 2 launched in January.
- The team migrated about 300 customers from the original platform.
- The rebuilt product sourced close to two million leads, sent close to three million messages, and generated about 21,000 replies.
- The recent reply rate was around 2%, comparable to a human SDR.
- 11x planned integration between Alice and Julian plus further self-learning, memory, computer-use, and reinforcement-learning work.
The production system was already handling millions of leads/messages and hundreds of migrated customers, but the source frames self-learning and cross-channel agent integration as still in progress.