The Architecture Behind the Modern AI SDR

Everyone demos an AI SDR that writes a nice email. Almost nobody talks about the plumbing that decides whether it still works in week six. That is the week the CRM layout changes, the inbox fills with replies nobody matched to a send, and the daily send counter lives in three places that disagree. This is a guide to that plumbing.

The four layers of an AI SDR

Strip away the marketing and every working AI SDR is built from the same four layers:

1. Execution: the part that actually does the work. It types the email, clicks Send, logs the note, and updates the stage.
2. Synchronization: how sent emails and inbox activity stay in step between the place that sends and your system of record (usually your CRM).
3. Reply tracking: how an inbound "yes, let's talk" gets matched to the outbound email that earned it.
4. Control: plan limits, send pacing, duplicate checks, and compliance. This is the layer that says no, and says it reliably.

Most automated sales outreach failures are not model failures. They are plumbing failures in layers 2 through 4. The send counter raced and the system sent twice. Reply matching leaned on subject lines and missed real replies. Or the agent kept "working" a CRM whose layout had changed under it. The model writes the email. The architecture decides whether the system can be trusted.

Layer 1: Execution, where the work happens

API-first vs. browser-native

There are two honest ways for software to work a CRM. The first is an API, a service door where two programs trade data directly, no screens involved. The second is browser-native: the agent works the same screens a person does, inside the person's own logged-in session.

The browser-native model has one hard requirement: the agent must learn your CRM's layout rather than assume it. The pattern that works is point-and-click mapping. You show the agent your email button, your fields, and your Send button once, and it saves durable markers for each. When the layout changes, the right behavior is to stop loudly, not guess. An agent that sends zero emails and says so is a support ticket. An agent that guesses is a compliance incident.

The execution guardrails that are not optional

• Dry run: the agent fills everything in but never sends, so a human can watch a full pass before going live.
• Randomized pacing between sends. The delay range the operator sets is treated as law.
• Duplicate protection that survives across devices. "Contacted in the last N days" must be a fact the server holds, not a local cookie.
• Opt-out respect read from the CRM's own fields on every pass, never cached.

Layer 2: Email synchronization for CRM

Email synchronization for CRM is where most homegrown stacks quietly rot. The question is simple: when an email goes out (from a composer, an API, or an agent), how does every other part of the system find out?

The wrong answer: polling

Polling means checking the inbox on a timer, like "look for new messages every 5 minutes." It is easy to build and expensive to trust. It burns through the request allowance the mailbox provider gives you. It adds a lag that changes every time, so you can never answer "did they reply before my second email went out?" Worst of all, its failure is invisible. A dead poller looks exactly like a quiet inbox. (We wrote a whole piece on this: Why polling the inbox is dead.)

The right answer: webhook email tracking

A webhook flips the direction: the mail service pings us the moment something happens, instead of us checking on a timer. With webhook email tracking, the mailbox provider pushes each event (message received, message opened, bounce) to your endpoint the moment it happens. Three properties make webhooks production-grade:

• Signature verification, fail-closed. Every webhook payload carries a signature, a tamper-proof stamp made with a secret only the two servers share, and the receiving server checks that stamp (an HMAC check) before trusting a word. If the secret is not configured, the endpoint rejects everything rather than trusting anything.
• Idempotency by design. Idempotent means running the same thing twice changes nothing. Providers retry deliveries, so your tables must make double-processing impossible. For example, a reply is recorded by writing the inbound message's ID onto the send it answers. The same webhook delivered twice does nothing new.
• First-event-wins timestamps. "Opened" is a single timestamp set once. An email opened five times is still one opened email. The shape of the table enforces that, not careful counting.

Layer 3: Reply tracking infrastructure

Reply rate is the only outreach metric that cannot lie. That makes reply tracking infrastructure the most valuable and least glamorous part of the stack.

How matching actually works

A durable matcher works in descending order of confidence:

1. Thread and Message-ID headers. Every email carries a hidden ID in its headers. When an inbound reply references the ID of a message you sent, the match is certain.
2. Sender plus recency. No header match? Walk the recent unanswered sends to that exact address, newest first, and attach the reply to the most recent open touch.
3. Never subject-line matching alone. "Re: Quick question" matches half the internet.

Attribution has to survive teams

The moment two or three reps share an account, knowing who sent what becomes table design. Every send row should store who sent it: a seat or profile label, written in at send time so a later rename does not rewrite history. Replies should be counted by the mailbox they landed in. Roll-ups by subject, template, person, or send hour then come from one table with no joins. That is what makes them fast enough to put in front of users.

Layer 4: The control plane

The control plane is everything that limits the agent, and it has one rule: the server is authoritative. In plain words, the server holds the real numbers, and the app on your machine cannot overrule them.

• Daily caps live in the database and are worked out from the plan each time they are checked. Clearing browser storage must never grant more sends.
• Seats are enforced server-side. Registering a device beyond the plan's seat count bumps the oldest one, and the bumped client finds out mid-run and pauses within a few records, not hours.
• Entitlements fail safe in both directions. An entitlement is what your plan says you may do. A network blip should not lock out a paying customer, so brief errors fall back to the last answer the server trusted. But an unknown plan tier should never fail up to a paid tier.
• Row-level security on every user-owned table. This means the database itself checks who owns each row, so the public API key inside the client grants nothing beyond the signed-in user's own rows. API integrations for sales tooling should be boring in exactly this way.

The reliability checklist

If you're evaluating (or building) B2B sales automation architecture, these ten questions separate demos from systems:

1. What happens when the CRM layout changes? Stop loudly, or guess?
2. Are webhooks signature-verified, and do they fail closed?
3. Is reply matching header-based with a recency fallback, or subject-string matching?
4. Can a duplicate webhook delivery double-count anything?
5. Where does the daily send counter live, and can a client reset it?
6. Do seats/concurrency limits enforce server-side, mid-run?
7. Is per-person attribution stamped at send time or reconstructed later?
8. Does opt-out status get read fresh on every pass?
9. Is there a dry-run mode a buyer can watch before trusting it?
10. When something's skipped, is the reason logged where an operator can read it?

Related: How to build an AI SDR workflow · Webhooks vs. polling for email tracking · What an AI CRM actually is