What tech stack do I need to build an AI SDR?

A coding agent, a cloud database, somewhere to run the agents, API or MCP access to your data sources, and a warmup tool. That is the list. Concretely, in September 2026: Claude Code or Codex for building, a cloud database for the store, a VPS or serverless functions to run things, Apollo or Clay over API or MCP for data, and one email warmup tool.

I am Eduard Klein. I advise CEOs, founders and boards on AI Business Strategy, and this is the stack behind the full AI SDR blueprint, published 19 August 2026. Not a reference architecture. The one that runs.

The 2 things on everyone else's list and not on mine

There are 2 of them. You do not need a sequencer, and you do not need an orchestration framework.

No sequencer, because the agent sends its own mail, subject to the same limits any sender respects. A sequencer executes the plan you wrote once. My agents decide what to do next per contact, every time, which is the entire reason I built this rather than buying an AI sales tool. Paying a monthly fee for a component that constrains the thing you built it to do is a strange trade.

No framework, because you do not need technical orchestration any more. I specifically do not recommend n8n. I used it for months and moved off it completely in 2026. It is clunky compared with what Claude Code will build for you in a fraction of the time, and the result is better. Orchestration frameworks were the right answer in 2024, when the models could not reliably write their own plumbing. They can now.

For research you want either local browser automation or a sandboxed research agent, for the prompt injection reasons that decide the architecture of the whole system.

Which LLM or model should power an AI SDR?

Largely a matter of taste. The practical advice is to pick one and stay with it.

I like working with Claude and I have stayed on it for 3 years. The models leapfrog each other constantly, and chasing the leader costs you more than whatever the slightly-behind model cannot do. Switching introduces bugs, and that is the real price nobody puts in the comparison table.

The genuinely smart pattern is multi-model, using each one where its strengths are, rather than serial migration. I ran embeddings on OpenAI for 2 years and moved for cost reasons in 2026. That change was easy, because it was one bounded job with a clean interface. The point is that you can adapt when there is a reason, not that you should keep adapting every time a benchmark moves.

Do we need to fine-tune models, or is prompting enough?

Neither. What you need is memory management.

Fine-tuning is almost never the answer for this job, and prompting on its own plateaus fast. Across 3 years the thing that actually moved quality was having memory exactly where the agent needs it.

I use what I call a distributed agent memory model. Each agent writes what it learns at the touch point where it will later need it, so the system accumulates breadcrumbs rather than one growing blob of shared context.

The counterintuitive part, and the one I got wrong first: more context makes output worse, not better. Distributing it cuts token load and raises quality at the same time. I built the single-blob version in 2025, watched quality drop over 3 months as the context grew, and rebuilt it distributed.

Should I use an off-the-shelf agent framework or write my own orchestration?

Write your own, and let Claude Code write most of it.

This is the build-versus-buy call made at component level rather than product level, which is the useful altitude for it. For each of my 7 components I asked one question: does buying this constrain a decision I will want to change? Where the answer was yes, I built. Where it was no, I bought or used a service.

Email warmup, I use a tool. Database, a cloud service. Hosting, a VPS or serverless functions. Those 3 constrain nothing. The CRM, the qualifier, the research sandbox and the outreach logic are all mine, because each encodes a judgement I want to change on a Tuesday afternoon without asking a vendor.

What data and context does an AI SDR need to perform well?

Firmographics, technographics, intent signals, a clear ICP. All of those matter. What is decisive is having the entire communication history available before every single step.

Email, LinkedIn, whatever else. All of it, every time, before the next move. This is exactly where a sequencer like Outreach or Apollo's own sequencing fails. It does not have the data, so a person reassembles it by hand each time, and that person is the bottleneck the whole system was supposed to remove.

The full requirement is: all account data in one view, plus the complete communication history, plus the ability to research the web safely through a sandbox, plus access to B2B databases when you need funding rounds or the responsible person. Anything less and you are asking the agent to make decisions blind.

Why I built the CRM instead of buying one

The store in the middle is the 1 component of my 7 that I would build again first, and I built it in 2026 after 2 years of trying to live without it.

Every component reads from and writes to the same store. Nothing lives in somebody's inbox, nothing lives in a spreadsheet, nothing lives in an agent's context window and then evaporates when the session ends. Agents that each keep their own state produce a system where nobody, including you, can answer the question "what do we know about this account".

That is why the CRM is not a system the agent integrates with. It is the spine the agent lives on. Salesforce or HubSpot makes you fit its data model, and in a vertical with a field it does not have you are back in Excel converting files. I built mine in 2026 and I have added fields within 1 hour of needing them, more than once.

Integration with an existing CRM, if you keep one, runs over MCP or the vendor's API. Nobody needs Zapier for this in 2026. The agent connects itself given the API documentation, and the only real challenge left is key management.

What this stack costs

The stack is not where the money goes.

A $20 model subscription, maybe $200. A cloud database. A VPS. A warmup tool. Set against an enterprise paying $600,000 a year in Salesforce licence fees, the infrastructure line is a rounding error, which is the point of what an AI SDR actually costs being a question about your own build time rather than about tooling.

The wider question of whether ChatGPT and Google AI Overview can see your company at all when a buyer asks is a different piece: AI strategic visibility.

What I still do not know

I do not know how long the self-hosted answer stays right.

Agent-hosting infrastructure is emerging through 2026 and some of it is good. If a managed runtime arrives that does not constrain the decisions I want to keep, my VPS answer becomes the wrong one and I will say so on this page. I have watched that market for 3 years and I have not seen it yet.

The calls this stack is downstream of: whether someone can hijack your AI SDR from a web page, what maintenance costs after launch and whether to build your own AI SDR or buy one.

About the author

Eduard Klein is an AI Business Strategist for CEOs, founders & boards, and he has sold the stack this article replaces: software sales for SAP, for Microsoft, for Oracle and for the German Stock Exchange, including the CRM and ERP platforms whose per-seat model this piece argues against. Thirty years of building software, years as an SDR up to 3.5 million in revenue and in key account management, and 170+ articles across 100+ publications including Hunter.io and Encharge sit behind the component calls here (the full list).