Skip to main content
abm.dev
← Notes from the data layer

AI SDR

how to build an AI SDR agent

Stuart McLeod5 min

A great rep once knew every account. Now your agents do.

Here is the working architecture — prospect enrichment, brand voice, a feedback loop, no CRM required. Production-grade from the first commit.

// Minimal AI SDR loop — enrich, score, draft, send
const account = await abm.enrich({ domain: 'acme.com' });
if (account.icp_score >= 0.75) {
  const draft = await llm.draft({ account, voice: brandConfig });
  await sequencer.stage(draft);
}

That is the core. Everything below is how you make it not break at 3 a.m.

What does an AI SDR agent actually do?

Not "automate outreach." That framing hides the real work.

An AI SDR agent runs the top of the outbound funnel without a human driving every step. As GTME Pulse describes it: it pulls a target list, enriches each row, scores against your ICP, drafts a personalized first touch, stages the send through your sequencer, and triages replies. When a reply needs a human, it routes up. Everything else it handles.

The failure mode is not the LLM. The failure mode is bad data moving at machine speed. An agent that acts on a stale job title, a wrong mailing address, or a fabricated phone number does not send one bad email — it sends four hundred.

What is the right architecture?

Skip the monolith. The production pattern is a headless, workflow-orchestrated loop with three distinct stages:

Stage 1 — Signal ingestion. A trigger fires: a funding round hits Crunchbase, a job change lands on LinkedIn, a domain appears in your ICP filter. The agent picks it up.

Stage 2 — Enrichment and scoring. The agent calls a single enrichment endpoint. Behind it: LinkedIn, Hunter, Perplexity, and other providers — aggregated, deduped, reconciled. Every field carries a confidence score and a source citation. The agent scores the account against your ICP definition. Below threshold, it drops the record. Above threshold, it proceeds.

Stage 3 — Personalized first touch. The LLM drafts against a brand voice config — your tone, your proof points, your forbidden phrases. The draft goes to a sequencer. Replies route back into the loop or escalate to a human via Slack.

AgentEnrich's 60-line implementation proves the architecture is not complicated: "Funding signal in, personalized email out." The complexity is not the loop — it is the data layer underneath it.

How do you wire the enrichment layer?

This is where most builds break.

The standard approach: stitch together multiple enrichment vendors, manage multiple API keys, reconcile multiple schemas, absorb multiple per-seat bills, and hope the fields agree. When they do not — and they will not — the agent picks one silently and moves on. No provenance. No audit trail. The agent acts on a fact it cannot defend.

The better approach: one API call that returns eighty-nine canonical fields, sourced from ten providers, with confidence scores and citations attached to every value.

// abm.dev enrichment — one call, cited data
const result = await fetch('https://api.abm.dev/v1/enrich', {
  method: 'POST',
  headers: { 'Authorization': `Bearer ${process.env.ABM_API_KEY}` },
  body: JSON.stringify({
    domain: 'acme.com',
    fields: ['company_name','headcount','tech_stack','hq_address','decision_maker_email']
  })
});

const { fields, citations, confidence } = await result.json();
// Every field: { value, source, confidence_score, verified_at }

No fabricated facts. No silent fallbacks. The agent knows what it knows and why it knows it.

For agents running in autonomous loops, cited data is not a nice-to-have. It is the guardrail that keeps the loop honest.

How do you handle orchestration without a CRM?

Temporal is the right answer for production. It gives you durable execution, retry logic, and a full audit log — without a database schema to maintain.

Each account becomes a workflow instance. The workflow steps through enrichment, scoring, drafting, and send-staging. If enrichment times out, Temporal retries. If the sequencer is down, the workflow waits. Nothing falls through.

Arvexi's production build runs exactly this pattern: "It runs twice daily on Railway, manages a pipeline of 412 ranked accounts, and costs about $12/day." Their agent drafts cold outbound emails, routes them through human review via Slack, learns from every approval and rejection, and logs everything to Salesforce. The key insight from their write-up: "building it required solving problems that most AI agent frameworks quietly ignore" — chiefly, what happens when the agent encounters ambiguous data mid-loop.

The answer is always the same: the data layer has to carry enough context for the agent to make a defensible decision, or escalate cleanly.

What about direct mail?

Inbox noise is real. A thoughtful physical send earns reciprocity that a cold email rarely does.

The agent selects the account, calls the enrichment API to verify the mailing address — with citations, not guesses — and triggers a personalized physical send as a first touch. Not a follow-up. Not a response to a reply. A proactive opening move.

This is not a new idea. It is a very old one, now executable at scale. The verified mailing address field is in the enrichment response. The send can be triggered by the same workflow that stages the email sequence. The agent does both.

How do you build the feedback loop?

An AI SDR that does not learn is a script. The feedback loop is what makes it an agent.

Every reply — positive, negative, out-of-office — feeds back into the workflow. The agent classifies the reply, updates the account record, and adjusts future scoring weights. Approvals and rejections from the human review step do the same.

Isometrik's step-by-step guide frames this as the difference between an AI SDR that books meetings and one that just sends emails: the loop has to close. Lead sourcing, enrichment, personalization, sequencing, reply handling — each stage feeds the next.

Bytemine's 2026 architecture overview makes the same point structurally: they call it "the closed-loop system" and build the entire ICP scoring model around feedback from actual reply and booking rates — not static firmographic rules.

The practical implementation:

// Log outcome back to the workflow
await workflow.signal('reply_received', {
  account_id: account.id,
  reply_sentiment: 'positive',
  booked_meeting: true
});
// Temporal persists this; scoring model reads it next cycle

What does a production-ready build look like?

Four components. No more.

1. Signal source. Crunchbase funding alerts, LinkedIn job-change webhooks, a static ICP domain list — pick one to start.

2. Enrichment API. One endpoint. Cited fields. Confidence scores. The agent never acts on data it cannot trace.

3. Orchestration layer. Temporal workflows. Durable, retryable, auditable. Runs headless on Railway or Fly.io.

4. Brand voice config. A JSON object the LLM reads before drafting. Tone, proof points, forbidden words, signature format. The agent writes like your best rep, not like a template.

That is the whole stack. The enrichment layer is the only part that requires an external dependency you cannot build yourself in a weekend — because the data quality problem is not a code problem. It is a sourcing, reconciliation, and freshness problem that takes years to solve.

Start here

Personalization, at scale.

That is the promise. The architecture above is how you keep it.

Try abm.dev — the account-based marketing API for AI agents. Eighty-nine canonical fields. Ten providers behind one call. Citations and confidence scores on every value. Built for autonomous agent loops, not human dashboard-watching.

The playground is free. Launch credits with the code LAUNCHCODES.

Stuart McLeod · Co-founder, abm.dev