How We Built Our AI SDR (and What Broke First)
A build log: what the first version got wrong, why enrichment came before writing, and the guardrail that keeps an autonomous SDR from burning your domain.
Published 2026-03-06
Version one was wrong
The first AI SDR we built wrote excellent emails. It was useless.
The mistake was building it around the writing step, because that is the step that demos well. In practice writing is the easy part and the smallest part. What determines whether outbound works is whether the list is right and whether the follow-ups happen — and neither of those is a writing problem.
So we rebuilt it in the order the work actually happens.
The pipeline
1. Qualify before enriching. Enrichment costs money per contact, so filtering first is not an optimisation, it is the difference between a sane bill and a stupid one. The ICP is written as explicit rules including exclusions, and anything ambiguous is dropped rather than guessed.
2. Enrich, then verify. A contact with an unverified address is worse than no contact — it damages the sending domain that every later campaign depends on. Bounce risk is checked before anything is written.
3. Write from the record, not from a template. Personalisation that reads as personalisation is worse than none. The employee writes from what it actually found, and if it found nothing specific, it sends the short generic version instead of inventing a compliment about a funding round.
4. Sequence with a stop condition. Four touches, then the contact moves to a dormant list. The stop condition matters more than the cadence: an autonomous system with no stop is a machine for annoying people at scale.
5. Log everything at the time of action. Every touch written to the CRM as it happens. This is the step humans skip and the one that makes the whole channel measurable.
What broke
Enrichment cost. The first run enriched everything before filtering. Fixed by reordering, which is the entire lesson.
Over-personalisation. Early drafts opened with a specific detail from the prospect's site every time. It read like surveillance. Now specificity is used when it is genuinely relevant and skipped when it is decoration.
Silent failures. A connector expiring mid-run looked identical to "no leads today." Now a failed step is an alert, not an empty report — a dashboard showing zero should always distinguish between "nothing to do" and "nothing worked."
No send cap. The obvious one, learned the boring way. There is now a hard daily ceiling that the employee cannot raise on its own.
The guardrail that matters most
Approval on the first week's sends.
Every message queues for a human yes or no before going out. It is tedious for five days and it is what makes the following month unattended, because each rejection teaches something no instruction file would have captured — that a phrase you use internally reads badly outside, that a claim you are comfortable with makes you sound like everyone else.
After that week, approval switches off for routine sends and stays on for anything involving a named customer or a number. That, plus the audit log, is the whole safety story for an autonomous sender.
What it does now
Qualifies inbound and outbound against written ICP rules. Enriches and verifies. Writes from the record. Runs a four-touch sequence with a stop condition. Books directly on the calendar when a reply is warm. Logs every action.
It does not take the call. That was never the goal — the split between what an SDR should and should not automate is the buying guide version of this post.
If you are building your own
Build in pipeline order, not demo order. Put the stop condition in before the cadence. Make failures loud. Approve the first week by hand.
And write the ICP exclusions down. Almost every outbound problem we have debugged since has turned out to be a list problem wearing a copy problem's clothes.
Get access if you would rather not build it.
All OpenLabor blog posts