How to Build an AI SDR Pipeline with Claude Code and Winnr

What the infrastructure layer of an AI SDR does

An AI SDR (AI sales development representative) researches prospects, writes messages and sends sequences. Underneath that sits the infrastructure that decides whether those messages reach an inbox:

• Domain purchase and DNS (MX, SPF, DKIM, DMARC)
• Mailbox creation and credentials
• Warming: a gradual volume ramp and health monitoring
• Deliverability monitoring: DNS health, warming metrics, placement
• Handing credentials to the sending tool, in that tool's import format

Copywriting, lead sourcing and reply handling are separate layers. They belong to your agent, your data provider and your sequencer.

The two layers run on different clocks. Agent quality depends on the model and your prompts, and it can improve in days. Sending reputation depends on domain age, authentication, warmup history, per-mailbox volume and recipient engagement, and it improves over weeks. When they get out of step the failure is quiet: sends succeed, there is no error, and reply rates sit near zero while everyone debugs the copy. The usual root cause is sending volume that arrived faster than the mailboxes were ready for. Design onboarding so that cannot happen.

The architecture

An AI SDR pipeline has three layers, and each can be replaced without touching the others:

+--------------------------------------------------+
|              CAMPAIGN LAYER                      |
|  Your agent or sequencer (Smartlead, Instantly,  |
|  EmailBison, ...): leads, copy, sends, replies   |
+--------------------------------------------------+
                      |
          SMTP/IMAP credentials (export)
                      |
+--------------------------------------------------+
|            ORCHESTRATION LAYER                   |
|  Claude Code + Winnr skills + MCP server,        |
|  or your own code calling the REST API           |
+--------------------------------------------------+
                      |
                  REST API
                      |
+--------------------------------------------------+
|           INFRASTRUCTURE LAYER                   |
|  Winnr: domains, DNS, mailboxes, warming         |
+--------------------------------------------------+

Infrastructure (Winnr) handles domain registration, DNS records, mailbox provisioning on Winnr's own sending infrastructure, DKIM signing, SPF and DMARC, and warming.

Orchestration is either Claude Code (the MCP server exposes 55 tools; the skills add workflows and defaults on top) or your own service calling the REST API. Both use the same authenticated API.

Campaign is whatever sends: your own agent over SMTP, or a sequencer. Winnr exports credentials in 21 sequencer formats plus a generic CSV, including Smartlead, Instantly, EmailBison, PlusVibe, Snov, Saleshandy, Woodpecker, Reply.io, Salesforge, Mailshake and ReachInbox. Anything that imports SMTP/IMAP accounts by CSV works with the generic format.

Path A: run it from Claude Code

This path suits a team running outbound for itself or for a handful of clients. Active time is a few minutes; wall-clock time is set by warming.

Step 1: Set up the stack

1. Create a Winnr account at app.winnr.app. Creating the account needs no card; buying domains and creating mailboxes need a paid plan (Startup $69/mo or Enterprise $189/mo).
2. Add the hosted MCP server to Claude Code. On first use it sends you to Winnr to sign in, and you choose what it may do: read, write, or purchase (buy domains, buy pre-warmed domains, enable warming).

   claude mcp add --scope user --transport http winnr https://mcp.winnr.app/mcp

   If you prefer a local server, create an API token (it starts with wnr_) under API in the dashboard and run uvx winnr-mcp with it. The MCP server guide covers both.
3. Install the skills pack:

   curl -sL https://raw.githubusercontent.com/winnr-app/winnr-claude-skills/main/install.sh | bash

   This adds eight commands: /winnr setup, /winnr connect, /winnr inbox, /winnr health, /winnr troubleshoot, /winnr scale, /winnr export and /winnr status. See Winnr Claude Code skills for what each one does.

Check the connection by typing /winnr status. It should return your plan, domains and mailboxes.

Step 2: Provision infrastructure

/winnr setup

The skill asks how many mailboxes you need and what your company is called, checks your plan's capacity, then works through the setup:

1. Domain search: suggests names based on your brand and checks availability.
2. Domain purchase: asks you to confirm, then buys them. Domains are a one-time purchase charged to your card on file, priced per extension at checkout (a .com is about $13).
3. DNS: Winnr writes MX, SPF, DKIM and DMARC, and the skill waits until they verify.
4. Mailboxes: creates mailboxes with professional names.
5. Warming: enables warming on every new mailbox ($0.60 per mailbox per month).

You: /winnr setup
     I need 40 mailboxes for cold outreach. My company is Acme.

Claude: Checking plan capacity... room for 40 more mailboxes.
  Suggested 10 domains, all available. Total shown before purchase.

You: Go ahead.

Claude:
  [1/4] 10 domains purchased, DNS setup queued
  [2/4] DNS verified on 10/10 domains
  [3/4] 40 mailboxes created
  [4/4] Warming enabled on 40 mailboxes

  Done. 10 domains, 40 mailboxes, warming active.
  Start cold sending after at least 2 weeks of warming (4 on new domains).

Step 3: Warm for 2 to 4 weeks

Warming is the one step you can't rush. Plan on at least 2 weeks before cold sending, and 4 on brand-new domains. Check progress with:

/winnr health

The skill produces a traffic-light report across DNS health and warming. Winnr's health score is calculated from the share of warmup mail that landed in spam over the last 14 days (health = 100 minus 2 × spam rate), so 80 and above is Good. It measures spam placement inside the warming network, not placement at a specific provider, so run a seed placement test at the providers your prospects use before you start sending.

Step 4: Export to your sequencer

/winnr export smartlead

The skill runs a readiness check first (at least 14 days of warming, health above 75, inbox rate above 85%) and only exports mailboxes that pass, then produces a CSV in that sequencer's import format. Swap the name for instantly, emailbison, plusvibe or any other supported format. Start at 10 to 20 cold emails per mailbox per day and keep total sending, cold plus any warming, at about 50 a day or less per mailbox.

Step 5: Monitor and maintain

• /winnr health: a weekly report across all mailboxes.
• /winnr troubleshoot: DNS and deliverability decision trees when something drops.
• /winnr scale 20: add domains and mailboxes with the same ratios, or remove underperformers.
• /winnr inbox: triage replies across every mailbox and draft responses from the right one.

Using the skills mostly saves time and avoids skipped steps: DMARC is never forgotten, the warming period is never skipped, and every export gets a readiness check.

The capacity math

Whichever path you take, start from the number that matters: emails per day. Two constants turn it into infrastructure.

10 to 20 cold sends per mailbox per day (15 as a default). Providers judge reputation per sending identity, and a young mailbox pushing 50 cold emails a day looks like what it is. Stay near 10 on a fresh fleet. Total sending per mailbox, cold plus warming, should stay at about 50 a day or less.

About 5 mailboxes per domain. Winnr allows up to 10, and the headroom is useful on a mature domain. Plan with 5, because it keeps the blast radius of any single domain incident small.

Mailboxes come with the plan: Startup ($69/mo) includes 50, enough for about 750 cold sends a day at 15 each, and Enterprise ($189/mo) includes 200, about 3,000 a day. Extra mailboxes are $1 each per month on either plan. Domain slots are free to raise. Domains you already own can be connected at no cost. Run your own numbers in the cold email calculator.

Two planning notes. Warmup time doesn't depend on fleet size: 34 domains take about as long to be ready as 2. And size for the peak day, not the average. Sequences are bursty, and a fleet sized for the average pushes individual mailboxes past their daily ceiling on the peak.

The warmup cold start

If you sell an AI SDR, this is the constraint that shapes onboarding most: a customer signs up today and wants to send tomorrow, but new mailboxes need 2 to 4 weeks of warming first. There are three honest ways through it.

The tempting fourth option is to skip warmup and send at low volume anyway. A brand-new domain with no history that starts cold-emailing strangers is a strong spam signal, and the damage attaches to the domain, so slowing down afterwards doesn't undo it. See cold email without warmup for the narrow cases where skipping it is reasonable.

Domain layout: shared pool vs domains per client

Once onboarding works, decide how sending domains map to your customers. This decides whether one customer's behavior can hurt another's delivery.

Many teams run both: a shared pool for entry tiers, separate domains from the first paid tier up. The principle underneath is that sender reputation follows the domain, not the customer record in your database. Two customers you consider separate are not separate if they send from the same domain. Tag each domain with your client ID when you buy it, and let the domain boundary be the client boundary. Domain tags make every later query filterable by client.

Path B: provisioning in code

If your product provisions infrastructure itself, the whole flow is a handful of calls against https://api.winnr.app. Authentication is a bearer token scoped to your account. Full reference: app.winnr.app/docs.

1. Create a token. Store the returned wnr_ value as a secret; it is shown only once.

curl -X POST https://api.winnr.app/v1/auth/tokens \
  -H "Authorization: Bearer YOUR_EXISTING_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "ai-sdr-provisioner", "permissions": ["read", "write"]}'

2. Buy domains. Use async for more than two or three domains so you aren't holding a request open through registration. You get a job back immediately.

curl -X POST https://api.winnr.app/v1/domains/purchase \
  -H "Authorization: Bearer $WINNR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "async": true,
    "domains": [
      {"domain": "acmegrowth.com", "tags": ["client:acme"]},
      {"domain": "acmereachout.com", "tags": ["client:acme"]}
    ]
  }'

Winnr registers each domain, creates the DNS zone and writes MX, SPF, DKIM and DMARC. There is no DNS work on your side.

3. Poll the job. Registration takes a while, and this is the place to drive a progress indicator in your onboarding UI.

curl https://api.winnr.app/v1/jobs/JOB_ID \
  -H "Authorization: Bearer $WINNR_TOKEN"

4. Create mailboxes. Up to 500 per request, all on one domain, so loop per domain. Names that match the customer's real team read better than sales1 to sales5.

curl -X POST https://api.winnr.app/v1/email-users/bulk \
  -H "Authorization: Bearer $WINNR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "domain": "acmegrowth.com",
    "users": [
      {"username": "dana.reyes", "name": "Dana Reyes"},
      {"username": "m.okafor",   "name": "Michael Okafor"},
      {"username": "priya.n",    "name": "Priya Nair"}
    ]
  }'

5. Start warming. The async variant takes up to 500 mailbox IDs per call and doesn't block. Use the slow ramp on a fresh domain. The first month is charged at enable ($0.60 per mailbox).

curl -X POST https://api.winnr.app/v1/warming/enable-async \
  -H "Authorization: Bearer $WINNR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "user_ids": ["eu_abc123", "eu_def456", "eu_ghi789"],
    "settings": {"emails_per_day": 20, "rampup_speed": "slow"}
  }'

6. Hand credentials to the sending layer. GET /v1/email-users returns mailboxes with SMTP and IMAP details, filterable by domain. If your customers use a sequencer instead of your own sender, POST /v1/export returns a CSV in that tool's import format.

curl "https://api.winnr.app/v1/email-users?filter[domain]=acmegrowth.com" \
  -H "Authorization: Bearer $WINNR_TOKEN"

The same six calls cover both layouts. For separate domains, run them once per customer with their own domains and client tag. For a shared pool, run them against your own inventory ahead of demand and assign mailboxes at signup. Rate limits are 300 requests per minute on Startup and 500 on Enterprise, shared across your tokens.

Keeping the fleet healthy

Reputation is judged at several levels at once:

• The domain. The main unit. Blocklists list domains, and a burned domain takes its mailboxes with it. This is the boundary you control, which is why domain layout is the isolation decision that matters.
• The mailbox. Each sending identity builds its own history. Mailboxes on one domain share its fate.
• The sending IP. Most Winnr mailboxes send from shared, managed infrastructure, which is normal for low-volume cold sending, where domain reputation usually carries more weight (see IP reputation vs domain reputation). If a customer needs an IP of their own, dedicated IPs are an optional Enterprise add-on at $20 per IP per month.

The practical rules that follow:

• Never let two customers share a sending domain if their reputations must stay separate.
• Replace badly burned domains rather than nursing them. A replacement costs a domain purchase plus a warmup cycle, which is often less sending time lost than a long recovery. See recovering a burned domain for when recovery is worth it.
• Enforce list hygiene in your application. Infrastructure can't fix a bad list, and an AI SDR that sources its own contacts can generate one.
• Rotate rather than concentrate. Spread a campaign across the fleet instead of using up one mailbox before touching the next.
• Decide on ongoing warming. After the first 2 to 4 weeks, warming is optional. Some teams disable it once campaigns are running; others keep it on at lower volume to give bursty mailboxes a steady baseline. Count it toward the 50 a day total either way.
• Watch placement, not just delivery. Accepted by the receiving server and landed in the inbox are different outcomes, and only the first shows up in SMTP responses. Track reply rate per domain as a leading indicator, and repeat seed tests after big changes.

Build vs buy

You could build this layer. It needs mail servers with correctly configured MTAs, IPs with clean reputation and reverse DNS, automated DNS across registrars, DKIM keys per domain, a warming network of real mailboxes, bounce and complaint handling, blocklist monitoring, and someone who owns all of it when mailbox providers change their sender requirements.

The case for building: if deliverability infrastructure is your actual product rather than a dependency, you should own it, and at very large scale owning the stack can win on unit cost.

The case against: it is months of specialized work unrelated to what your customers buy. They choose an AI SDR because it books meetings, not because its vendor runs mail servers.

Related: vibe-code your own sequencer on top of these mailboxes, and cold email best practices for sending limits, authentication and content.