Building an AI SDR Team With Claude Code

Cold outbound used to be a headcount problem. You hired SDRs, trained them for weeks, and hoped they ramped before they got poached or burned out. That math has changed. You can now build the entire SDR function as a system of AI agents, one that researches, builds lists, qualifies, writes, and sends, and run it for roughly the cost of a few API calls. This is the playbook I use to build that system, and the parts that actually decide whether it works.

I have spent the last few years building the pieces that sit underneath this kind of system, lead intelligence, intent scoring, CRM automation, and the LLM pipelines that make any of it reliable. So treat this as a field guide rather than a tutorial: where the leverage really is, where it quietly breaks, and what separates a system that books meetings every week from one that gets your domain blacklisted.

From headcount to system

The traditional SDR model is a people problem dressed up as a growth strategy. You hire, you spend six weeks training, the rep ramps, and then they go on vacation, get poached, or churn out in two months and you start over. Every bit of process lives in someone’s head, and it walks out the door with them.

The shift is simple: you stop hiring the function and start building it. You write the playbook once, as instructions a model can execute, and then the marginal cost of running it trends toward the price of a few API calls. That is not a prompt trick. It is a product decision, and it is the same one I make every day, deciding what to encode into a system versus what to leave to a human. The leverage is real, but only if you treat it like building product, not like running a script.

The pipeline, end to end

Strip away the chat interface and the system is a classic data pipeline. Every stage takes messy input, makes one decision, and hands clean output to the next. Here is the whole thing, with the part that matters at each step.

Where I have built pieces of this for real

I am not theorizing about this stack. I have shipped most of its components in production, and that is what tells me which parts are load bearing.

Knowing who to target before you guess. With VisiLead I built a B2B intelligence platform that identifies the companies visiting your site from a single script, scores buyer intent, and ties each lead back to its marketing channel. It surfaces 25 to 35% of anonymous B2B traffic. The lesson carries straight into outbound: the highest-converting list is rarely a cold database pull, it is the accounts already showing intent. Feed those into the pipeline above and reply rates move.

The qualification and CRM plumbing. At Cafimo I rebuilt the lead engine for a brokerage, a site revamp plus HubSpot automations that wired enrichment, routing, and follow-up together. The outcome was concrete: more leads through the funnel and a cheaper cost per qualified conversation. Step 2 of the pipeline, qualify before you contact, is exactly the discipline that made that work.

The engineering that keeps agents reliable. The hard part of any agent system is not the happy path, it is making it dependable at volume. At Geonimo I run production LLM pipelines and make the trade-offs this stack lives or dies on: which model for which step, how to design prompts and agents that do not drift, and where to spend on accuracy versus latency versus cost. Take one example, doing the enrichment yourself in Claude Code instead of leaning on a tool like Clay is a cost decision, and it only pays off if you have actually reasoned about it.

If you want the fuller picture, the products I have shipped and seven years building in markets are the through-line: take a messy, high-stakes problem and turn it into a system that runs.

The part everyone skips: foundations

The real work is not the live session where you talk to the model. It is the “directives,” the saved instructions that tell the model how to search, how to qualify, how to write. Those are the asset. Build them once and the system compounds. Skip them and you have a very expensive autocomplete.

This is where a product and data background changes how you build it. Three principles I would not ship without:

• Treat the playbook as a spec, not a vibe. The directives are a product requirements doc the model executes. Versioned, testable, improvable. That is what makes the output consistent instead of a slot machine.
• Keep a human in the loop where it is cheap and high-leverage. I still eyeball the list before export, every time. One minute of human judgment on ICP fit saves your domain reputation, which you cannot buy back.
• Instrument it like a funnel. Reply rate, positive reply rate, meetings booked per thousand sent. My instinct from years as a quant is that if you are not measuring each stage, you are not running a system, you are running a hope. Decisions start from the numbers, not the opinion.

The automation glue itself, Apollo, HubSpot, Make, the sender APIs, is the easy part once the thinking is right. It is the same toolkit I reach for when I wire these systems together.

What this means if you are a founder or operator

You do not need a five-person SDR team to start generating pipeline anymore. You need a clear ICP, a sharp offer, and a system designed by someone who has built the pieces and knows where they break. The technology is genuinely a step-change. The failure mode is treating it as a magic button instead of a product you own and improve.

That gap, between a flashy prototype and a system that quietly books meetings every week, is exactly the work I do: taking AI from a clever idea to something dependable in production.