DEV Community: ABM.dev

b2b enrichment for Claude Code

Stuart McLeod — Tue, 04 Aug 2026 05:30:07 +0000

b2b enrichment for Claude Code

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

Here is the setup that matters. One API call from inside a Claude Code session — company domain in, verified firmographics out, confidence score attached:

curl -X POST https://api.abm.dev/v1/enrich/company \
  -H "Authorization: Bearer $ABM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "stripe.com"}'

Cited sources. Eighty-nine canonical fields. No fabricated facts. No silent fallbacks.

That is the whole pitch. Everything below is the why and the how.

Why does enrichment break inside Claude Code?

Most GTM teams reach for the same stack: Apollo for contact data, Clearbit for firmographics, Hunter for email, ZoomInfo for the enterprise layer, Clay to stitch it together, and a spreadsheet to hold the seams. SyncGTM's 2026 waterfall coverage analysis puts it plainly: lead enrichment is still a five-tool juggling act. Export a CSV from LinkedIn Sales Navigator, paste it somewhere, wait, reconcile conflicts, repeat.

That workflow was designed for humans moving at human speed. Claude Code moves faster. When an autonomous agent hits a missing field, it does not pause and file a Jira ticket. It infers. It guesses. It acts on bad data at machine speed — and the mistake compounds before anyone notices.

Explorium's step-by-step guide for adding B2B enrichment to a Claude Code agent frames the core problem well: fragmented multi-vendor enrichment forces the agent to pre-configure endpoint mappings for every data type. Change one vendor, break the map. The agent has no way to know which source is authoritative when two providers disagree.

The result is data with no provenance. Your agent personalizes an outbound sequence for the wrong company size, the wrong tech stack, the wrong budget cycle. At scale, that is not an edge case. It is the default.

What does agent-ready enrichment actually look like?

The phrase gets used loosely. Here is what it means in practice.

Cited sources. Every field carries a reference to the provider that returned it — LinkedIn, Hunter, Perplexity, and others. The agent can inspect provenance before acting. If the confidence score on a phone number is low, the agent routes to email instead. No human required.

Confidence scores. Not a binary verified/unverified flag. A numeric score the agent can threshold. Set your own rules: skip accounts where headquarters confidence falls below a set floor, escalate to human review above a set ceiling.

Waterfall logic, resolved. One call hits ten providers behind the scenes — aggregated, deduped, reconciled. No per-source bills. No per-source rate limits to manage. The agent asks once and gets the best available answer.

Call it over MCP, don’t rebuild it. Anthropic’s Claude Code MCP documentation describes the Model Context Protocol as an open standard for connecting an agent to external tools and data — so Claude Code can call a verified enrichment API directly, without custom integration code. Agent-ready enrichment also means write-back safety: field-level merge rules, so lower-confidence data never overwrites a trusted CRM record.

How do you wire it into Claude Code?

Two paths. Pick the one that matches your setup.

Path one: direct API calls

The fastest start. Add your API key to Claude Code's environment, then prompt the agent to enrich before it writes any outbound copy.

# .env or Claude Code secrets
ABM_API_KEY=your_key_here

import httpx
import os

def enrich_company(domain: str) -> dict:
    resp = httpx.post(
        "https://api.abm.dev/v1/enrich/company",
        headers={"Authorization": f"Bearer {os.environ['ABM_API_KEY']}"},
        json={"domain": domain},
        timeout=15,
    )
    resp.raise_for_status()
    return resp.json()  # includes fields, confidence scores, source citations

# Claude Code calls this before drafting any personalized outreach
data = enrich_company("acme.com")
headcount = data["fields"]["employee_count"]["value"]
confidence = data["fields"]["employee_count"]["confidence"]

if confidence >= 0.75:
    print(f"Headcount: {headcount} — high confidence, use it")
else:
    print("Headcount uncertain — route to human review")

No dashboard. No browser tab. The agent enriches, checks confidence, and decides — all inside the terminal session.

Path two: MCP server

If you want Claude Code to discover enrichment capabilities dynamically — without pre-configured endpoint mappings — the MCP route is cleaner for autonomous loops. Explorium's data layer architecture guide makes the case directly: a purpose-built enrichment layer separates GTM agents that run from ones that work. Claude Code can orchestrate and call APIs, but it cannot maintain a B2B data universe on its own.

One JSON config block in your Claude Code settings.json:

{
  "mcpServers": {
    "abm": {
      "command": "npx",
      "args": ["-y", "@abm.dev/mcp"],
      "env": {
        "ABM_API_KEY": "your_key_here"
      }
    }
  }
}

The agent now has named tools it can call by name without knowing which providers sit behind them. Swap providers, update waterfall logic, change confidence thresholds: the agent's interface does not change.

What does the agent do with the data?

This is where the pattern pays off.

GTME Pulse's end-to-end Claude Code lead enrichment workflow documents the loop that replaces the Monday-morning CSV paste: trigger, waterfall, validate, write back. Built once, runs unattended. The spreadsheet-to-Clay pattern creates maintenance work and breaks repeatedly. The agent loop does not.

Applied to personalized outbound, the loop looks like this:

Trigger — ICP account enters the pipeline (new funding round, hiring signal, tech stack change).
Enrich — agent calls the enrichment API. Gets firmographics, tech stack, budget signals, decision-maker contacts — all with citations.
Validate — agent checks confidence scores against your thresholds. Low confidence on the direct dial? Route to email. Low confidence on the mailing address? Skip direct mail for this account.
Act — agent drafts personalized copy, selects the right channel, triggers the send. No human in the loop unless confidence falls below the floor.

Personalization, at scale.

What breaks without provenance?

The failure mode is worth naming plainly.

An agent acting on unverified data does not fail loudly. It sends the wrong message to the right person, or the right message to the wrong company size, or a direct mail piece to an address that moved. The damage is invisible until the pipeline numbers come in.

Provenance — knowing which source returned which field at what confidence — is not a nice-to-have for autonomous agents. It is the control layer. Without it, you are not running an AI-powered GTM motion. You are running a faster version of the broken five-tool stack.

The short version

Six enrichment tools stitched together with Zapier is a human workflow. Claude Code is not a human. It needs data that arrives with sources attached, confidence scores it can threshold, and a single endpoint it can call without knowing which providers sit behind it.

That is what abm.dev is built for. Eighty-nine canonical fields. Ten providers behind a single call. No per-source bills. No fabricated facts. No silent fallbacks.

Once upon a time, a great rep knew every account — the right detail, the right moment, the real blocker nobody else caught. The data is rich enough to do that again. At scale this time.

Try abm.dev — the account-based marketing API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

LinkedIn enrichment API

Stuart McLeod — Mon, 03 Aug 2026 05:30:07 +0000

LinkedIn enrichment API

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

Here's the call your agent makes:

curl -X POST https://api.abm.dev/v1/enrich/contact \
  -H "Authorization: Bearer $ABM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"linkedin_url": "https://linkedin.com/in/example"}'

Back comes work history, current title, company headcount, verified email, seniority signal, and the confidence score on every field. One call. No scraper to maintain. No silent fallbacks.

That's the promise. The rest of this post is about what's actually inside it — and why the output format matters as much as the data itself.

What does a LinkedIn enrichment API actually return?

Most coverage comparisons focus on hit rate. That's the wrong question for agents.

An agent acting on bad data at machine speed doesn't pause to sanity-check. It sequences, it personalizes, it triggers sends. If the seniority field is wrong, the personalization is wrong — across every account in the run, before a human notices.

So the real question is: what does the response look like, and can you trust each field independently?

A raw LinkedIn profile endpoint — like the one documented at connectsafely.ai — returns work history, education, skills, certifications, and contact info from a single REST call. That's the foundation. But the response is only as useful as its structure. A flat JSON blob with no provenance is fine for a human analyst who can eyeball anomalies. It's a liability inside an autonomous loop.

Here's what agent-ready enrichment output needs:

Canonical field names — consistent across providers, so your prompt templates don't break when the upstream source changes
Confidence scores per field — not a single match-quality number for the whole record, but a score on current_title, email, company_domain individually
Source citations — which provider returned this value, so you can audit a bad personalization after the fact
Freshness timestamps — when was this field last verified, not when was the record created

Without those four things, you're not enriching for agents. You're enriching for dashboards.

Why does B2B LinkedIn data decay so fast?

Evaboot, which processes LinkedIn and Sales Navigator URLs at scale, puts it plainly: B2B data decays fast — 22.5% of exported leads are outdated by the time they reach a workflow. People change jobs. Titles shift. Companies get acquired. A record that was accurate in Q1 is noise by Q3.

For a human running a quarterly campaign, that's annoying. For an agent running continuous outbound, it's structural — the agent will keep acting on stale data until something in the loop catches it.

This is why freshness isn't a nice-to-have. It's a correctness requirement. An enrichment API that returns a last_verified timestamp on each field lets the agent decide: is this fresh enough to personalize on, or does it need a re-fetch before it writes the message?

The Enrich.so LinkedIn profile endpoint demonstrates what a clean, queryable enrichment call looks like at the API level — a URL in, structured profile data out, ready to pipe into a downstream step. The interface is simple. The discipline is in what you do with the response.

What does stitching multiple enrichment tools actually cost?

Most growth engineers don't use one LinkedIn enrichment API. They use several — because no single provider has complete coverage, and because different providers are stronger on different signal types. LinkedIn profile data from one source, verified email from another, company technographics from a third.

The result: multiple API keys, multiple billing relationships, multiple response schemas to normalize, and multiple places where a field name collision silently corrupts a downstream record. When the agent hallucinates a prospect's title, you spend an afternoon tracing which provider returned the bad value — if you can trace it at all.

Hunter’s Lead Enrichment API illustrates the category: hand it an email or a professional-profile handle and it returns a full contact record with verification built in. Useful capabilities. But each single-purpose tool you add is another schema to reconcile, another failure mode to handle, another bill to justify at the end of the month.

The alternative is a single enrichment layer that aggregates across providers, deduplicates conflicting values, and returns one canonical record with citations showing which source contributed each field. One call. Ten providers behind it. No per-source bills. No schema gymnastics.

That's the architecture abm.dev's Enrichment API is built on — eighty-nine canonical fields, normalized across providers, with confidence scores and source attribution on every value. Built for autonomous agent loops, not human dashboard-watching.

What does agent-ready actually mean in practice?

The phrase gets used loosely. Here's a concrete definition.

An enrichment API is agent-ready when:

The response is deterministic. Same input, same field names, same schema — regardless of which upstream provider answered. The agent's prompt template doesn't need a conditional branch for "what if this field is called job_title vs current_role."
Failures are explicit. If a field can't be verified, the response says so. No fabricated facts. No silent fallbacks. The agent can handle a null; it can't handle a confident wrong answer.
Citations are machine-readable. Every field carries a source reference the agent can include in its reasoning trace. When a personalization goes wrong, you can pull the audit log and see exactly what the agent believed and why.
The API is callable from an agent loop without rate-limit surprises. Predictable throttling behavior, clear retry semantics, and webhook support for async enrichment on large batches.

Most LinkedIn enrichment APIs were designed for humans exporting CSVs. The interface is fine. The output format is the problem. Agent-first design means the response schema is the product, not an afterthought.

Who is this for?

If you're a founder or growth engineer building an AI-agent go-to-market motion, you're probably already enriching contacts somewhere in the loop. The question is whether the enrichment output is structured for the agent or for a human to review.

If you're a Head of Marketing or RevOps lead watching personalization quality degrade as volume scales, the issue is usually data provenance — the agent is personalizing on fields it can't verify, and there's no audit trail when it goes wrong.

Abm.dev's Enrichment API is built for both. The REST interface is simple enough to call from any agent framework. The response schema is strict enough to trust inside an autonomous loop. And the enrichment MCP server gives you a tool-call interface if your agent is running on an MCP-compatible runtime.

Personalization, at scale.

Once upon a time, a great rep knew which accounts were in budget cycle, which titles actually controlled the decision, and which detail in a prospect's LinkedIn history was worth mentioning. That knowledge took years to build and didn't scale past one person's memory.

The data exists now to do it again — at scale, in every account, on every send. The missing piece was always a data layer the agent could call and trust.

That's what abm.dev is.

Try abm.dev — the account-based marketing API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

how to combine direct mail and outbound in abm

Stuart McLeod — Fri, 31 Jul 2026 05:30:08 +0000

how to combine direct mail and outbound in abm

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

Here is a concrete sequence your agent can run today:

# Pseudocode: agent-orchestrated direct mail trigger
account = abm.enrich_company(domain="target.com")
if account.intent_score > 80 and account.mailing_address.confidence > 0.9:
    mail.send(
        recipient=account.champion,
        template="cold_open",
        personalization={
            "pain_point": account.top_pain,
            "use_case": account.product_fit
        }
    )
    outbound.enroll(account.champion, sequence="post_mail_follow_up", delay_days=3)

No spray. No pray. The agent selects the account, verifies the address, and fires a physical send as the opening move — not a consolation prize after email fails.

Why does direct mail belong at the top of the sequence, not the bottom?

Most teams treat direct mail as a rescue tactic. Email bounces, calls go unanswered, and someone suggests sending a gift card. That framing is wrong, and it costs you the channel's real advantage.

A cold, proactive physical send earns reciprocity before digital noise gets a chance to accumulate. A UK analysis of direct mail added to email found the combination lifts overall B2B response by thirty to sixty percent — largely because mail reaches the sixty-odd percent of recipients who never open a given email. The inbox is a warzone. The mailbox is quiet.

When your agent fires a personalized physical send as the first touch — before a single cold email — the follow-up email lands in a warmer context. The recipient has held something. There is a reference point.

Lob's research on direct mail in SaaS ABM frames the underlying problem well: "Your email sequences are easy to ignore. Your ads compete with every other message in the feed. Meanwhile, target accounts may be researching, comparing vendors, and moving closer to a decision without ever replying to outbound." Direct mail is not a supplement to digital. It is the pattern interrupt that makes digital land.

What data does the agent actually need before it sends anything?

This is where most implementations fall apart. The agent has enrichment data from multiple tools, none of which agree on the mailing address, the decision-maker's title, or whether the company is still at that office. It acts on the best guess it has — at machine speed — and you ship a handwritten note to a building your target left eighteen months ago.

Before the agent triggers a send, it needs four things verified with citations:

A confirmed mailing address — not inferred, not cached from a stale record. Confirmed, with a source and a confidence score attached.
The right recipient — title, seniority, and buying authority. A personalized send to an SDR is wasted postage.
A real personalization hook — the budget cycle, the tech stack gap, the recent hire, the product announcement. Something the recipient will recognize as specific to them.
Sequence timing — how many days before the follow-up email fires, and what that email references.

Without provenance on the address and the hook, the agent is guessing. ABM Agency's guide to integrating direct mail into 1-to-1 ABM is direct about this: direct mail "moves beyond junk mail" only when it is tied to a thoughtful, data-driven strategy. Generic sends with bad data are not ABM. They are expensive spam.

How does the outbound sequence actually connect to the mail trigger?

The sequencing layer is the piece most playbooks skip. They tell you to "integrate" direct mail with outbound without specifying what fires what.

Here is the architecture that works:

Step 1 — Account selection. The agent scores accounts by fit and intent. High-fit, high-intent accounts enter the direct mail branch. Mid-tier accounts go into a standard email sequence. The agent is not sending physical mail to everyone — that is a budget problem and a signal problem.

Step 2 — Address verification. Before any send is triggered, the agent calls a verified enrichment source for the mailing address with a confidence threshold. Below the threshold, the account routes to email-only. No guessing.

Step 3 — Physical send as cold open. The agent triggers the send — a handwritten note, a short-run printed piece, a small relevant item — personalized to the account's actual situation. This is the first touch. Cold. Proactive. Not a follow-up to anything.

Step 4 — Email follow-up, timed to delivery. Three to five days after confirmed delivery (or estimated delivery window), the agent enrolls the contact in an email sequence that references the physical send explicitly. "You may have received something from us last week" is not a trick — it is a context bridge.

Step 5 — Signal monitoring. If the contact opens the email, visits a page, or replies, the agent escalates. If nothing happens after two follow-ups, the account recycles into a lower-frequency nurture track.

UserGems' outbound ABM guide identifies the core failure mode this architecture solves: "Your sales team sent 5,000 cold emails last month and booked 12 meetings. Of those 12, only 3 were qualified prospects, and zero closed." Volume without selection is not outbound. It is noise generation. The direct mail trigger forces account selection discipline — you cannot send five thousand physical pieces without noticing the cost.

What does the personalization layer look like in practice?

The physical send is only as good as the data behind it. "Personalized" does not mean the recipient's first name on an envelope. It means the send references something real.

Examples that work:

A founder who just raised a Series B gets a note that references the round and the specific GTM challenge that comes with it — not "congratulations on your recent news."
A Head of Marketing at a company running HubSpot and Outreach gets a piece that speaks to the integration gap between those two tools — not "we help marketing teams."
A RevOps lead at a company that recently posted three SDR job listings gets a note about what those hires will need on day one.

None of these require a human researcher. They require enrichment data with provenance — data the agent can act on because it knows where the fact came from and how fresh it is.

Scribeless's direct mail playbook for B2B SaaS makes the format point worth noting: the physical piece itself — handwritten note versus printed insert versus dimensional mail — should match the account tier and the message. A handwritten note for a ten-person startup. A short printed brief for an enterprise procurement team. Format is a personalization decision, not a production default.

What breaks this motion — and how do you prevent it?

Three failure modes, in order of frequency:

Bad address data. The agent sends to a stale address because the enrichment source had no confidence score and no citation. The send disappears. The follow-up email references a piece that never arrived. The sequence is broken before it starts. Fix: require a confidence threshold and a source citation before any address is used in a send trigger.

Generic personalization. The hook is "we help companies like yours" or a reference so vague the recipient cannot tell it was written for them. Fix: require at least one account-specific field — a recent event, a tech stack detail, a hiring signal — before the send template is populated.

Sequence timing mismatch. The follow-up email fires before the physical piece arrives, or two weeks after. The reference lands cold. Fix: use estimated delivery windows from the mail provider to time the email trigger, not a fixed delay.

All three failures trace back to the same root cause: the agent acted on data it could not verify. Verified enrichment data with citations and confidence scores is not a nice-to-have in an autonomous outbound loop. It is the condition under which the loop is allowed to run.

Personalization, at scale.

Direct mail and outbound are not two separate programs that occasionally reference each other. In an agent-orchestrated ABM motion, they are one loop — account selection, address verification, physical send, timed follow-up, signal escalation. The agent runs the full sequence. You set the thresholds.

The handwritten note that a great rep once sent by hand is now something your agents send to every qualified account in your ICP. At the right moment. With the right hook. Before anyone else in the inbox.

Try abm.dev — the account-based marketing API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

Clay alternative for developers

Stuart McLeod — Thu, 30 Jul 2026 05:30:10 +0000

Clay alternative for developers

Personalization, at scale.

curl -X POST https://api.abm.dev/v1/enrich/contact \
  -H "Authorization: Bearer $ABM_DEV_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "cto@acmecorp.com"}'
# Returns: 89 canonical fields, sourced citations, confidence scores.
# One call. Ten providers behind it. No per-source bills.

That's the whole pitch for developers. One endpoint. Verifiable data. Agent-ready JSON. If you want the longer version — the part about why Clay stops working the moment you try to build an autonomous loop — read on.

Why do developers outgrow Clay in the first place?

Clay is a genuinely capable platform. The waterfall enrichment works. The AI columns are useful. For a growth operator who lives in spreadsheets and wants to build prospecting workflows without writing code, it earns its place.

But here's what happens when a developer sits down to wire it into an agent:

They hit the UI wall.

Clay is built for human dashboard-watching. You trigger enrichment manually, review rows, approve sends. That's the product. It's not a flaw — it's a deliberate design for a specific user. But autonomous agent loops don't watch dashboards. They call APIs at machine speed, act on the response, and move to the next account before you've poured your coffee.

SyncGTM's 2026 comparison puts it plainly: CRM integrations start at $446/month, and credits burn through full-table refreshes you can't control. When an agent is running fan-out prospecting across hundreds of accounts, unpredictable credit burn isn't a billing inconvenience — it's a broken loop.

Deepline’s breakdown of Clay alternatives draws the line developers care about: Clay has no public CLI or programmatic API, so AI coding agents like Claude Code can’t drive its workflows without a browser-automation layer. A data API is a different category entirely — and for developers building agents, that’s the right one.

What does "agent-ready data" actually mean?

This is where the conversation gets concrete.

An agent acting on bad data at machine speed doesn't make one bad call. It makes ten thousand. The failure mode isn't a missed email — it's a personalization engine that confidently references the wrong company size, the wrong funding round, the wrong decision-maker, at scale, before anyone notices.

Cognism's 2026 enrichment roundup lists fourteen Clay alternatives, most of them positioned as lead generation or outreach platforms. What almost none of them surface is data provenance — where a field value came from, how recently it was verified, how confident the system is in it.

For a human reviewing a spreadsheet, that's tolerable. For an agent, it's a critical missing input. The agent needs to know: can I act on this field? Not just what is this field?

Agent-ready data has three properties:

Cited. Every field value traces back to a named source — LinkedIn, Hunter, Perplexity, a public filing. Not a black-box aggregate.
Scored. Confidence is explicit. High confidence: act. Low confidence: flag for review or skip.
Structured for code. JSON with predictable schema. No CSV exports, no manual column mapping, no UI steps between the data and the agent's next action.

Abm.dev returns all three. Eighty-nine canonical fields. Ten providers reconciled behind a single call. Citations attached to every value. Confidence scores the agent can branch on.

No fabricated facts. No silent fallbacks.

What the numbers say about the current state of agent GTM

Here's an honest data point from our own dashboard, because transparency is more useful than polish.

In the last thirty days: one hundred and one visitors, down sixty percent. Organic search delivering roughly six sessions per month. And $mcp_initialize — the handshake call that tells us an AI agent has discovered and connected to the MCP server — equals zero. Not a small number. Zero. No agent has ever found the MCP server in production.

That number tells a story about where autonomous GTM actually is in mid-2026. The tools exist. The frameworks exist. But the data layer — the part that gives agents verified, citable, agent-ready account intelligence — hasn't been wired in yet. Most builders are still stitching together multiple enrichment tools by hand, managing multiple API keys, reconciling multiple schemas, and hoping the outputs agree.

Explorium’s evaluation of 25+ Clay alternatives puts it in agent terms: Clay’s async, table-based architecture and per-provider credit billing don’t fit agents that need sub-two-second sync responses and predictable unit economics. Developers building agent infrastructure don’t want to build prospecting workflows. They want a data primitive they can call from code.

That gap — between what exists and what builders actually need — is exactly what abm.dev is built to close.

What does the switch actually look like in code?

No migration guide. No "step one: export your Clay table." Just what the integration looks like for a developer.

You have an agent. It receives a target account — a domain, a company name, a LinkedIn URL. It needs to enrich that account before deciding whether to trigger outreach, what channel to use, and what to say.

With multiple stitched-together tools, that means multiple API calls, multiple response schemas to normalize, multiple potential failure modes, and multiple invoices at the end of the month. The agent has to handle partial responses, contradictory values, and missing fields — and it has to do that at the speed of a loop, not a human review.

With abm.dev:

import requests

response = requests.post(
    "https://api.abm.dev/v1/enrich/company",
    headers={"Authorization": f"Bearer {ABM_DEV_KEY}"},
    json={"domain": "acmecorp.com"}
)

data = response.json()

# Branch on confidence — no guessing
if data["fields"]["employee_count"]["confidence"] > 0.85:
    agent.set_segment("mid-market")
else:
    agent.flag_for_review(data["account_id"])

One call. Reconciled. Cited. Confidence-scored. The agent branches on real signal, not hope.

For teams exploring the MCP surface — giving agents a verified data layer they can discover and call over the Model Context Protocol — the resources at abm.dev/resources cover the integration pattern in detail.

Who should switch, and who shouldn't?

Abm.dev is not for everyone. Be specific about that.

Switch if:

You're building autonomous agent loops, not human-reviewed workflows
You need data provenance — citations and confidence scores your agent can act on
You're paying for multiple enrichment APIs and reconciling them yourself
You want a single schema, one bill, predictable per-call pricing

Stay on Clay if:

Your team lives in spreadsheets and wants no-code workflow building
You need the visual waterfall builder and manual review steps
You're not building for autonomous agent execution

The two tools are solving different problems for different users. Clay built a great product for GTM operators. Abm.dev is built for the developer who wants to call enrichment from code, trust the result, and let the agent run.

The case for getting the data layer right before scaling

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

But only if the data is right. An agent with bad data isn't a rep who makes the occasional mistake — it's a system that makes the same mistake at the speed of a for-loop, across every account in the ICP, before the first human sees a result.

The enrichment layer isn't infrastructure. It's the foundation of every personalized signal the agent acts on. Get it wrong and you don't get bad outbound — you get confident, fast, personalized bad outbound.

The playground is free. See what eighty-nine cited fields look like in a real API response. Launch credits available with the code LAUNCHCODES.

Try abm.dev →

The account-based marketing API for AI agents.

agentic ABM

Stuart McLeod — Wed, 29 Jul 2026 05:30:09 +0000

Agentic ABM

That's what agentic ABM looks like in production — not a dashboard, not a pilot, not a proof-of-concept deck. Coordinated pipelines running content, SDR, ops, and launch in parallel, acting on verified account data, without waiting for a human to press go.

If you're a founder, growth engineer, or head of marketing stitching together six enrichment tools and hoping the data is good enough to act on — this is what you're building toward. Here's what the architecture actually teaches.

What does "agentic ABM" actually mean?

Not AI-assisted. Not AI-suggested. Agentic.

Wyzard.ai frames the distinction sharply: a target account clicks a LinkedIn ad on Monday, a second person from the same company joins a webinar on Tuesday, a known contact hits the pricing page on Wednesday — and the follow-up still lands late, in the wrong channel, with no shared context across teams. That gap isn't a people problem. It's an architecture problem. Agentic ABM closes it by replacing the handoff with a loop.

Agents don't wait for a rep to notice the signal. They score the buying group, verify the account, select the channel, and fire the action — ads, SDR sequence, direct mail, CS nudge — against a revenue goal, not a vanity metric. The Pedowitz Group describes this as the shift from manually coordinated plays to closed-loop, goal-seeking systems where agents continuously optimize across Marketing, Sales, and Customer Success simultaneously.

The catch: every one of those automated decisions runs on data. Bad data at human speed is embarrassing. Bad data at machine speed is expensive.

Why does the data layer break first?

Companies using traditional ABM report 208% higher marketing ROI compared to broad-based campaigns. That number is why ABM became the enterprise standard. It's also why the stakes are high when agents start acting on stale firmographics, unverified mailing addresses, or job titles that are months out of date.

The failure mode is predictable. You pull a contact list from one enrichment tool, layer in intent data from a second, cross-reference technographics from a third, manually reconcile the conflicts, and hand the result to an agent that has no idea which field came from where. The agent acts. The action is wrong. You don't find out until a rep gets a reply from someone who left the company months ago.

No provenance. No confidence score. No way to know which source to trust.

This is the core problem agentic ABM introduces that traditional ABM never had to solve at speed: agents need data with receipts.

What does the production architecture look like?

Here's the honest version, built from running coordinated pipelines across content, SDR, ops, and launch.

One enrichment call, not six. The agent calls a single endpoint. Behind it: ten providers, aggregated, deduped, reconciled. Eighty-nine canonical fields returned with source attribution and confidence scores on each one. The agent knows where each data point came from and can decide whether to act or hold.

Signal orchestration before account selection. MarketScale's reporting on agentic AI in ABM points to signal orchestration as the layer that separates reactive from proactive. Agents fuse CRM data, intent signals, product usage, and third-party triggers to find surging accounts — before a human would notice the pattern. The agent selects the account. The human set the criteria.

Direct mail as a first-touch, not a follow-up. This is the move most teams get wrong. When an agent identifies a high-fit account and verifies the mailing address with citations, the physical send is the opening move — not a nurture tactic. A thoughtful physical piece breaks through inbox noise in a way a cold email sequence cannot. The agent selects the account, verifies the address, triggers the send. Cold, proactive, and agent-orchestrated from the start.

Loops, not workflows. Each pipeline runs autonomously. Content agents draft and schedule. SDR agents enrich, sequence, and personalize. Ops agents monitor data freshness and flag stale fields before they propagate. Launch agents coordinate across channels without waiting for a weekly sync. No human approval gate between steps — the guardrails are in the data layer, not the org chart.

Build or rent?

Digital Applied draws a useful line here: renting a black-box ABM tool makes sense for speed; building on data you own wins when you need the agent to reason about why it's acting, not just that it's acting. The durable question isn't which vendor has the best dashboard. It's whether your agents can explain their decisions — and correct them when the underlying data changes.

Black-box tools give you lift figures. Owned data gives you provenance. For agentic loops running at machine speed, provenance is the one you can't skip.

The architecture that survives is the one where:

Every enriched field carries a source and a confidence score
Agents can call fresh data mid-loop, not just at list-build time
Failures are loud, not silent — no fallback to a fabricated field
The data layer is callable by any agent, in any pipeline, without re-integration work

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

What this teaches builders

Three things that hold across every agentic GTM stack we've seen or run:

1. Personalization requires provenance. You cannot personalize at scale on data you can't verify. The agent needs to know the budget cycle, the real blocker, and whether the champion's role changed last month — and it needs to know where each of those facts came from before it puts them in a message.

2. Speed amplifies data quality problems. At human speed, a bad data point causes one bad email. At agent speed, it causes many more. The enrichment layer isn't a nice-to-have. It's the load-bearing wall.

3. The architecture is the strategy. Agentic ABM isn't a campaign you run. It's a system you design — with defined inputs, verified data, autonomous loops, and guardrails that catch failures before they compound. Get the architecture right and personalisation at scale is the output, not the aspiration.

Try abm.dev — the account-based marketing API for AI agents. One call, ten providers behind it. Eighty-nine canonical fields, each with source attribution and confidence scores. Built for autonomous agent loops, not human dashboard-watching. No fabricated facts. No silent fallbacks.

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

why AI SDRs fail data quality

Stuart McLeod — Tue, 28 Jul 2026 05:30:07 +0000

why AI SDRs fail data quality

A great rep once knew every account. Now your agents do. But only if the data underneath them is worth trusting.

Here is the uncomfortable number: GTMLens reports that AI SDR vendors raised over $200 million in 2025, and most deployments still produce worse results than a well-run human SDR motion. The model is not the problem. The list is.

This post names the three-layer data decay problem — bad inputs, amplified inference, and no audit trail — and explains what deterministic enrichment fixes at each layer.

Why does the model keep getting blamed when the data is the real culprit?

Every revenue team in 2026 runs roughly the same foundation model. The gap between a campaign that books meetings and one that burns your domain is not GPT-4o versus Claude — it is what those models are working with.

Pristine Data AI puts it plainly: "The easy explanation is that the model is not good enough. The real explanation is almost always the data underneath it."

Your agent did not hallucinate a prospect. It trusted a stale record. Same outcome. Harder to catch.

What is the three-layer data decay problem?

AI SDR failures cluster around three distinct failure modes, each compounding the last.

Layer one: Bad inputs

The list arrives broken. Titles are wrong — "VP of Sales" at a company that restructured eight months ago. Emails bounce. Domains resolve to holding pages. The ICP filter said Series B SaaS, but half the records are agencies and consultancies that slipped through a fuzzy firmographic match.

Cognlay's playbook on list quality is direct: "Fix the list before judging the AI. Verify emails, narrow the ICP, remove bad-fit roles." Most teams skip this step. They hand a contaminated seed list to an agent and wonder why personalization rings false.

The problem is structural. When you stitch together multiple enrichment tools — one for email verification, one for LinkedIn URLs, one for firmographics, one for intent signals — you get multiple provenance chains, multiple billing relationships, and multiple opportunities for silent fallbacks. A field that looks populated may have been filled by a provider that guessed.

Layer two: Amplified inference

This is where AI makes a bad situation worse at machine speed.

A human rep reads a stale title and pauses. The agent does not pause. It infers seniority from the title, selects a persona-specific message variant, references a budget cycle that may not apply, and sends — a hundred times before you notice the pattern.

Lusha's post-mortem on the AI SDR wave documents what this looks like in production: "Burned domains, compliance failures, hallucinated contacts, and polluted CRMs convinced most teams that full autonomy wasn't the answer." The hallucination problem is real, but the quieter killer is confident inference on bad inputs. The model is not lying. It is extrapolating correctly from wrong facts.

Personalization built on a wrong title is not personalization. It is noise with the subject line filled in.

Layer three: No audit trail

This is the layer that makes the first two unfixable at scale.

When a campaign underperforms, you need to know: was the email address invalid? Was the title stale? Did the agent pick the wrong message variant, or was the variant correct but the underlying firmographic wrong? Without field-level provenance — source, confidence score, timestamp — you are debugging a black box.

FirstSales.io's analysis of the three-month churn problem frames it as a process failure: AI pilots break at the data-versus-process seam, not the model layer. Teams optimize for output volume, not outcome quality. The volume death spiral begins when there is no signal to correct against.

No provenance means no feedback loop. No feedback loop means the agent repeats the same mistakes at scale, every cycle.

What does deterministic enrichment fix at each layer?

The answer is not another enrichment tool. It is a different architecture.

At layer one — bad inputs: A single enrichment API that turns a name, email, or domain into verified, structured intelligence. Titles confirmed against LinkedIn. Emails verified, not inferred. Firmographics drawn from multiple providers, aggregated, deduped, and reconciled into one canonical record. One call, ten providers behind it. No per-source bills. No silent fallbacks where a missing field is quietly substituted with a guess.

At layer two — amplified inference: When the agent's inputs are deterministic — a confirmed title, a verified direct, a cited funding round — inference stays in its lane. The agent is not filling gaps. It is personalizing against facts.

At layer three — no audit trail: Every enriched field carries its source, its confidence score, and a citation. When a campaign underperforms, you pull the record and see exactly which fields were high-confidence and which were low. You know whether to fix the list, the message, or the segment. Auditable enrichment is the prerequisite for an agent loop that actually learns.

What does agent-ready data actually look like?

Not a CSV export. Not a dashboard.

Agent-ready data is an API response structured for autonomous consumption — eighty-nine canonical fields, normalized across sources, with confidence scores your agent can branch on. If confidence on the title field is below a threshold, the agent routes to a lower-stakes touch. If the mailing address is verified with a citation, the agent can trigger a physical send as a cold first-touch, not a follow-up.

Built for autonomous agent loops, not human dashboard-watching.

The economics matter too. Every API call covers infrastructure and third-party costs. No enrichment call runs at a loss. That constraint forces an honest architecture — no padding the response with low-confidence fields to look complete, no silent fallbacks that inflate apparent coverage. You pay for what is real.

The fix is not a better model. It is better inputs.

The AI SDR dream did not fail because the models were weak. It failed because teams handed autonomous systems data with no provenance, no verification, and no way to audit what went wrong.

Fix the three layers:

Inputs — verified, structured, sourced from multiple providers through a single API call.
Inference — constrained by confidence scores, not free to extrapolate from stale fields.
Audit trail — every field cited, every record inspectable, every campaign debuggable.

Personalization, at scale. That is the goal. Deterministic enrichment is how you get there without burning your domain on the way.

Try abm.dev — the account-based marketing API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

AI SDR hallucination

Stuart McLeod — Mon, 27 Jul 2026 05:30:08 +0000

AI SDR Hallucination

A great rep once knew every account. Now your agents do. But only if the data underneath them is real.

Three months into a pilot with a mid-market SaaS company, a team watched their AI sales agent draft what looked like a flawless cold email — warm tone, personalized opener, congratulated the prospect on "expanding into the APAC market." The prospect hadn't expanded anywhere. The agent had invented the detail, confidently, at send-ready quality.

That's the hallucination problem in AI SDRs. Not a vague concern about LLM reliability — a specific, operational failure mode that burns sender reputation, poisons CRM records, and scales damage at machine speed before a human ever sees it.

Here are the four distinct ways it happens, and a concrete detection test for each.

What exactly is an AI SDR hallucination?

Large language models don't retrieve facts — they predict plausible text. When an AI SDR drafts outreach, it fills gaps in its context window with statistically reasonable completions. In a B2B context, that means fabricated funding rounds, invented job titles, wrong headquarters cities, and nonexistent product launches — all written with the same confident tone as verified claims.

OpenAI’s research paper on why language models hallucinate frames it cleanly: models hallucinate because standard training and evaluation reward confident guessing over admitting uncertainty. The model isn’t broken. It’s doing exactly what it was trained to do. The problem is using it without grounding.

Failure mode one: wrong company data

What it looks like. The agent references the prospect's industry vertical, headcount band, or tech stack — and gets it wrong. It pulls from training data, not a live enrichment source. A two-hundred-person company is addressed as an enterprise. A bootstrapped SaaS is congratulated on its recent raise.

Why it happens. The agent has no verified firmographic layer. It's pattern-matching from pre-training, not calling a source.

Detection test. Take ten outbound drafts. Pull the company headcount, funding status, and HQ city from each. Cross-reference against LinkedIn and Crunchbase manually. If more than one in ten is wrong, you have a data-layer problem, not a prompt problem.

The fix. Route every account through a structured enrichment call before the agent drafts anything. Eighty-nine canonical fields, sourced and cited, not guessed.

Failure mode two: fabricated contact details

What it looks like. The agent produces a contact record — name, title, email, professional-profile URL — that is partially or entirely synthetic. A 2026 Nature paper on hallucination explains why this class of error is so persistent: one-off facts a model never saw in training — a specific prospect’s title, a recent funding round — are exactly the ones it fills in with a plausible guess. The alternative to catching it is a CRM flooded with contacts that do not exist.

Why it happens. When an agent is asked to "find the Head of Revenue at Acme" and no verified contact exists in its context, it generates one. The name sounds real. The email format looks right. The LinkedIn URL 404s.

Detection test. Run a batch of agent-generated contacts through an email verification tool. A bounce rate above five percent on net-new contacts is a signal. A bounce rate above fifteen percent is a crisis.

The fix. Contact data needs provenance — a source, a confidence score, a timestamp. If the enrichment layer can't cite where it found the email, the agent shouldn't send to it.

Failure mode three: invented intent signals

What it looks like. The agent references a trigger event that didn't happen. A job posting that was never live. A conference appearance the prospect didn't make. A product launch that hasn't been announced. The personalization reads as researched. It isn't.

Why it happens. Intent-signal personalization is high-value when real, so agents are prompted to find it. When no verified signal exists in the context window, the model invents a plausible one rather than leaving the field blank.

Detection test. Audit the "trigger" or "reason for reaching out" line in twenty drafts. Verify each claimed event against a primary source — the company's LinkedIn page, their press room, a job board. Flag any that can't be confirmed in under sixty seconds.

The fix. Intent signals must arrive as structured, cited data — not inferred by the model mid-draft. If the enrichment call returns no confirmed trigger, the agent should know that explicitly and choose a different personalization angle. No fabricated facts. No silent fallbacks.

Failure mode four: stale firmographics

What it looks like. The data was accurate — six months ago. The company has since been acquired. The contact changed roles. The funding round closed and the headcount doubled. The agent is personalizing to a ghost of the account.

Why it happens. Most enrichment pipelines run once at list-build time and never refresh. B2B data has a half-life. Titles turn over. Org structures shift. An autonomous agent loop running on stale records compounds the problem because it operates continuously, not in quarterly batch exports.

Detection test. Pull your last enriched account list. Check the enrichment timestamp. For any record older than ninety days, spot-check five fields against current LinkedIn data. Calculate your drift rate. If more than twenty percent of records have at least one stale field, your loop needs a freshness layer.

The fix. Keeping enriched fields fresh in an autonomous outbound loop requires treating data as a perishable — with TTLs per field type, not a single enrichment event per contact.

Why this compounds at agent speed

A human SDR makes one bad call. An AI SDR makes ten thousand. Ooligo's QA framework for AI SDR drafts scores each outbound draft against four rubrics — claim accuracy, personalization grounding, jurisdictional compliance, and deliverability hygiene — and returns a block/edit/send verdict before the message leaves the queue. The architecture exists because the failure modes are real enough to warrant a dedicated pre-send gate.

The underlying principle is correct. You need a verification layer between the model and the send action. But the more durable fix is upstream: agents that never draft on unverified data in the first place.

Stitching together multiple enrichment tools — one for email, one for firmographics, one for intent, one for technographics, one for direct dials, one for news triggers — creates the gap that hallucinations fill. Each tool has its own schema, its own confidence model, its own staleness problem. The agent sees fragments and invents the rest.

One call, ten providers behind it — aggregated, deduped, reconciled, with source citations attached to every field. That's the data layer an autonomous agent actually needs. Not a dashboard. Not a CSV export. A callable, agent-ready API that returns what it knows, flags what it doesn't, and never silently fills the gap.

The four-mode checklist

Failure mode	Detection signal	Structural fix
Wrong company data	Manual cross-reference vs. LinkedIn/Crunchbase	Verified firmographic enrichment at account selection
Fabricated contact details	Email bounce rate > 5% on net-new contacts	Source-cited contact data with confidence scores
Invented intent signals	Trigger events that can't be confirmed in 60 seconds	Structured intent fields from a live enrichment call
Stale firmographics	Field drift > 20% on records older than 90 days	Per-field TTLs and continuous refresh in the agent loop

Personalization, at scale — but only when the data is real. The model is capable. The question is what you hand it.

Try abm.dev — the account-based marketing API for AI agents. Eighty-nine canonical fields. Source citations on every record. Built for autonomous agent loops, not human dashboard-watching. The playground is free. Launch credits with the code LAUNCHCODES.

b2b data enrichment API comparison

Stuart McLeod — Fri, 24 Jul 2026 05:30:10 +0000

b2b data enrichment API comparison

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

But only if the data holds up.

Here is a quick proof of the problem. Call four enrichment APIs on the same domain. You will get four different employee counts, three different headquarter cities, and at least one confident hallucination about the company's tech stack. Your agent acts on all of it — at machine speed, without blinking.

# Four calls, four answers — same domain, same morning
curl https://api-a.example/enrich?domain=acme.com   # employees: 320
curl https://api-b.example/enrich?domain=acme.com   # employees: 410
curl https://api-c.example/enrich?domain=acme.com   # employees: 289
curl https://api-d.example/enrich?domain=acme.com   # employees: 512

No citations. No confidence scores. No way to know which number to trust. That is the enrichment problem in 2026 — and coverage rate is the wrong lens for solving it.

What does every comparison miss?

Most roundups rank enrichment APIs on coverage, price per record, and email accuracy. Those metrics matter for a human clicking through a dashboard. They are insufficient for an autonomous agent making decisions in a loop.

SyncGTM's 2026 developer-experience ranking of nine production-tested enrichment APIs surfaces a sharper concern: documentation quality and response determinism separate the APIs that work in pipelines from the ones that work in demos. An API that returns a different schema on retry, or silently omits a field when coverage is thin, will corrupt your agent's reasoning in ways that are nearly impossible to debug after the fact.

Coresignal's 2026 guide makes the same point from the buyer side: "Choosing the right enrichment API starts with your workflow and specific needs, not just the vendor's reputation." Define your use case first. Then evaluate.

For builders shipping AI-agent GTM, the use case is determinism and auditability — not just fill rate.

What criteria actually matter for agent-ready enrichment?

Four questions. If an API cannot answer all four, it is not agent-ready.

1. Where did this field come from?
Not "we aggregate multiple sources." The actual source — LinkedIn, Hunter, a public filing, a job board post — cited per field, per record. Without provenance, your agent cannot weigh conflicting signals. It just picks one at random.

2. How confident are you, specifically?
A confidence score on the whole record is noise. A confidence score per field — 0.94 on the email, 0.61 on the direct dial — lets the agent decide whether to act or to ask for verification first.

3. What happens when you don't know?
Silent fallbacks are the quiet killer. An API that returns a stale value rather than a null, or fills a missing field with a plausible-sounding guess, is worse than returning nothing. No fabricated facts. No silent fallbacks.

4. Can I call this from an agent loop without per-seat friction?
Dashboard-first products bolt on an API as an afterthought. The rate limits are aggressive, the auth is session-based, and the schema changes without notice. Agent loops need stable, predictable, programmatic interfaces.

How do the major providers stack up?

Autobound's 2026 test of eight enrichment APIs concludes that People Data Labs leads for raw contact enrichment at scale, Apollo.io suits teams that want enrichment bundled with outreach tooling, and event-based signal feeds are a separate category entirely. Useful framing — but all three are optimized for humans running sequences, not agents running loops.

SyncGTM's companion piece on the seven best enrichment APIs for B2B sales is direct: "Your enrichment API determines your pipeline quality. Bad data means wasted sequences, bounced emails, and reps chasing ghosts." At human speed, a bad record costs one rep an afternoon. At agent speed, it costs you the campaign.

Cleanlist's 2026 benchmark documents a fifteen-provider waterfall cascade. Impressive coverage. But a waterfall that returns a reconciled answer without exposing which provider won — and why — is still a black box. Your agent cannot audit it. It can only trust it.

Trust is not a data strategy.

What does agent-ready actually look like in practice?

The evaluation framework for builders is not complicated. It is just different from the one SaaS reviewers use.

Criterion	Human-dashboard API	Agent-ready API
Provenance	"Multiple sources"	Per-field source citation
Confidence	Record-level or none	Per-field score
Missing data	Silent fallback	Explicit null + reason
Schema stability	Versioned, sometimes	Stable, documented
Auth model	Session / seat-based	API key, stateless
Rate limits	Dashboard-first	Pipeline-first

The abm.dev GTM Intelligence API is built against the right column. One call, ten providers behind it — aggregated, deduped, reconciled. Eighty-nine canonical fields. Every field carries a source citation and a confidence score. When we do not know something, we say so. No guessing. No silent fallbacks.

Built for autonomous agent loops, not human dashboard-watching.

An agent calling abm.dev can reason: "The direct dial has a confidence of 0.58 — route to email first. The mailing address is verified against three sources at 0.96 — trigger the physical send." That is the decision logic a great rep once ran in their head. Now it runs in the loop.

What should you actually do with this comparison?

Stop evaluating enrichment APIs on coverage alone. Coverage is table stakes. Every serious provider in 2026 has coverage. The differentiator is what the API tells you when it is uncertain — and whether it tells you anything at all.

If you are stitching together six enrichment tools to get one reliable record, the problem is not that you have the wrong six tools. The problem is the architecture. One API, one schema, one bill — with provenance and confidence baked in — is the right abstraction for the agent layer.

Personalization, at scale.

Not because the pitch is tidy. Because the alternative — agents acting on bad data at machine speed, with no audit trail — is expensive in ways that compound quietly until they do not.

Ready to build on verified data?

Try abm.dev — the account-based marketing API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

No dashboards to watch. No per-seat fees. No fabricated facts.

Just data your agents can act on.

Introducing abm.dev — account-based marketing for AI agents

Stuart McLeod — Thu, 23 Jul 2026 05:30:15 +0000

Once, marketing was a person who knew you. The handwritten note. The right call at the right moment. The detail nobody else caught.

Then GTM scaled, and lost it. Volume at the expense of relevance. Enrichment that's stale, scattered across ten vendors, built for dashboards nobody opens.

So we built abm.dev: account-based marketing for AI agents.

Hand it a person or a company. Get back verified contact data plus synthesised account research in one call: eighty-nine canonical fields, every one with a citation, research angles you can save, and writeback to your CRM.

What comes back in one call

One call, ten providers behind it. Aggregated, deduped, reconciled. No per-source bills. No glue code.
Built for agents, not dashboards. /llms.txt, /openapi.json, and an MCP server, so your Claude, OpenAI, or LangChain agent discovers and calls it with zero setup.
Grounded, not guessed. Every field carries its source. No fabricated facts. No silent fallbacks. When something can't be verified, "not verified" is the answer, never an invention.

Why it works the way it does

A great rep once knew every account: their context, their goals, the real blocker. Now the data's rich enough to do it again. At scale this time. That's the whole idea. Personalisation, at scale.

Try it

It's open beta. Every new account gets twenty dollars in free credits with code LAUNCHCODES. Bring a LinkedIn URL, or a name and a company, and watch it come back enriched.

→ abm.dev

Stuart McLeod, co-founder, abm.dev

abm direct mail

Stuart McLeod — Thu, 23 Jul 2026 05:30:12 +0000

abm direct mail

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

Here's a claim worth sitting with: response rates for direct mail in B2B campaigns run significantly higher than email, according to USPS research on account-based marketing. Not because physical mail is nostalgic. Because a thoughtful object on someone's desk is harder to ignore than the forty-third cold email in a thread.

Most teams treat direct mail as a follow-up — something you send after three ignored emails, a last-resort nudge to a warm account. That framing is wrong, and it's costing pipeline.

Direct mail is a first-touch channel. A cold-capable, proactive, agent-orchestrated opening move. The agent selects the account, verifies the address, and triggers a personalized physical send before a single email goes out. That sequence earns reciprocity. It earns replies.

Here's how to build it.

Why are teams still treating direct mail as a fallback?

The instinct makes sense historically. Direct mail was slow, expensive, and hard to coordinate with a live sales motion. You sent a batch to a list and hoped something stuck.

ABM changed the unit economics. When you’re targeting fifty accounts, not fifty thousand, the cost-per-send is justifiable. The personalization is achievable. And the channel differentiation is real — a UK study of direct mail and email found most email recipients never open a given send, while a physical piece lands on the desk regardless.

What ABM didn't change was the workflow. Most teams still treat mail as an afterthought bolted onto a digital sequence. The ops burden — verifying addresses, matching accounts to the right send tier, triggering fulfillment at the right moment — kept it manual, slow, and dependent on a human coordinator.

AI agents remove that bottleneck. The coordinator is now the agent.

What does a proactive, agent-orchestrated direct mail sequence actually look like?

Start with account selection. The agent scores the target list against fit criteria — industry, headcount, tech stack, budget signals. It doesn't wait for a hand-raise. It identifies the account as high-priority and opens the sequence.

Next: address verification with citations. Not a best-guess from a stale database. A verified mailing address, sourced and cited, so the agent knows where the send is going and why that address is trusted. Agents acting on bad data at machine speed is the failure mode nobody wants — a thousand packages shipped to wrong addresses because the enrichment layer silently fell back to an outdated record.

Then: send selection. Prospeo's 2026 ABM direct mail playbook outlines a tiered format model — a handwritten note for a tier-one account, a curated package for a strategic target, a dimensional mailer for a high-ACV prospect. The agent applies the tier logic automatically, based on account score and deal size.

Finally: trigger and track. The send goes out. The agent logs it, timestamps it, and queues the follow-up email for forty-eight to seventy-two hours after estimated delivery. The physical piece does the work of breaking through. The email arrives when the account already knows your name.

No manual coordination. No spreadsheet handoffs. No ops team chasing fulfillment confirmations.

What data does the agent actually need to run this?

Four things, all of them verifiable:

A confirmed mailing address. Not the company's general HQ from a year-old record. A current, source-cited address — ideally matched to the specific office where the decision-maker sits.

The right contact. Direct mail sent to "the marketing team" is direct mail that gets recycled. The agent needs a named decision-maker: the Head of Marketing, the RevOps lead, the founder. Oppizi's guide to ABM direct mail is direct on this point — reaching key decision-makers requires precision, not volume.

Account context for personalization. The detail that makes the physical piece land. A reference to their recent product launch. A line that reflects their actual tech stack. The kind of specific that signals the sender did real research, not a mail merge.

A send tier. Budget-appropriate format logic. A tier-one enterprise account gets a different treatment than a mid-market prospect at the top of the funnel.

The problem most teams hit: assembling this data means stitching together multiple enrichment tools, reconciling conflicting outputs, and hoping nothing is stale by the time the agent acts. Lob’s guide to direct mail in ABM and lifecycle campaigns makes the same point: the hard part is connecting the send to clean, current account data, not the printing and posting.

The data layer has to be agent-ready. Cited sources, confidence scores, no silent fallbacks. If the address can't be verified, the agent should know that and hold the send — not ship to a stale record.

How does direct mail fit into the broader ABM sequence?

As the opening move, not the closing one.

The sequence looks like this:

Agent selects account. Fit score clears the threshold.
Agent enriches. Verified address, named contact, account context pulled with citations.
Physical send triggered. Tier-appropriate format. Personalized to the contact and account.
Email follow-up queued. Timed to arrive after the package. References the send explicitly — "I sent you something last week" is a subject line that gets opened.
LinkedIn touch. The agent connects or engages after the email. The account now has three distinct touchpoints, all coherent, all referencing each other.

This is multi-channel orchestration — physical and digital working as a single coordinated motion, not parallel campaigns that happen to target the same account. The International Post Corporation’s cross-country Direct Marketing study ranks addressed direct mail among the top channels for B2B-focused companies, and found that addressing a piece to a named individual measurably lifts open rates — which is exactly why verified contact and address data matters.

The direct mail piece earns the email. The email earns the conversation.

What are the failure modes to avoid?

Stale addresses. An agent that ships to a two-year-old office address wastes the budget and damages the relationship. Address verification needs a source and a timestamp, not just a value.

Generic sends. A package with no personalization is worse than no package. It signals automation without intelligence. The physical piece has to carry a specific detail — something that couldn't have been in a template.

Wrong tier for the account. Sending a dimensional gift box to a prospect two weeks into awareness is a mismatch. Tier logic should be explicit in the agent's instructions, not left to default behavior.

No follow-up timing. The physical send creates a window. If the follow-up email arrives before the package or two weeks after, the window closes. Delivery estimation has to be part of the agent's sequencing logic.

No fabricated facts. No silent fallbacks. No packages to nobody.

The channel that still surprises people

Direct mail shouldn't be surprising. The data has been there for years. The response rates, the reciprocity effect, the differentiation in a crowded inbox — none of it is new.

What's new is the agent layer. The ability to run a proactive, personalized, verified physical send at the start of a cold sequence — without a human coordinator, without a manual ops process, without a multi-tool enrichment stack held together with hope.

Personalization, at scale.

That's what ABM was always supposed to be. Once upon a time it took a great rep who knew every account. Now it takes an agent with the right data layer.

Try abm.dev — the account-based marketing API for AI agents. Verified addresses, cited enrichment, agent-ready data across eighty-nine canonical fields. The playground is free. Launch credits with the code LAUNCHCODES.

best MCP servers for sales prospecting

Stuart McLeod — Wed, 22 Jul 2026 05:30:10 +0000

best MCP servers for sales prospecting

Every major data vendor shipped an MCP server in the last six months. Apollo, ZoomInfo, Lusha, Explorium, Prospeo — all of them now let Claude or GPT-4o pull live contact data without leaving the conversation. As Amplemarket's 2026 comparison puts it: "The moment you need something real — an actual prospect list, a verified email, a contact's history — you leave the conversation. You open another tab, run the search, copy the result back."

That tab-switching is the tax MCP servers are meant to eliminate. But most comparison articles copy feature tables from vendor docs and call it research. This one doesn't.

The question that actually matters for autonomous outbound isn't which server has the most features. It's: does the data come back with provenance, or does your agent act on a guess at machine speed?

Here's a builder's read on the field.

What does a sales prospecting MCP server actually do?

Model Context Protocol gives an LLM a structured way to call external tools mid-conversation and mid-loop. For sales prospecting, that means an agent can resolve a company name to a verified domain, pull firmographics, find a decision-maker's direct email, and pass all of it downstream — without a human touching a dashboard.

The architecture matters because agents don't pause to sanity-check. A hallucinated job title or a stale email address doesn't just waste one rep's time. It fires off a personalized sequence to the wrong person at the wrong company, at the speed of a for-loop. Crustdata's field report on MCP servers for sales teams confirms this is the live problem: teams running real prospecting workflows through Claude every day hit data quality walls that vendor marketing doesn't mention.

So the evaluation criteria here are:

Provenance — does the response tell you where the data came from?
Confidence — does it surface a score, or just a value?
Freshness — is this live, or cached from eighteen months ago?
Agent-readiness — is the schema deterministic enough for an autonomous loop?

Which MCP servers are worth running in an agent loop?

Lusha MCP

Lusha's MCP server streams verified contact and company data into LLM conversations in real time. The pitch is direct: "Give your AI tools access to Lusha's verified contact and company data so your conversations and workflows can find actual prospects, not just generate ideas."

Lusha is strong on email verification and has broad coverage for SMB and mid-market contacts. The MCP integration is clean. What it doesn't expose natively is source attribution at the field level — you get a value, not a citation trail. For human-in-the-loop workflows, that's fine. For a fully autonomous agent loop where you want to audit why a particular contact was selected, you're working without a paper trail.

Good for: Contact lookup, email verification, human-assisted prospecting.

Explorium MCP

Explorium's MCP server is built explicitly for GTM agents. Their positioning — "Create agents that identify prospects with specific traits, uncover nuanced market similarities, and generate targeted prospect lists" — is closer to the autonomous use case than most vendors in this space.

Explorium aggregates signals across company and contact data, which gives it depth on firmographic and technographic attributes. The gap is that aggregation without reconciliation can surface conflicting values across sources. If your agent is choosing between two revenue figures and neither is flagged with a confidence score, it picks one arbitrarily. That's a silent failure mode.

Good for: Signal-rich prospecting, market similarity matching, GTM agent workflows.

Prospeo MCP

Prospeo leads with a significant coverage claim: 300M+ verified contacts. The MCP server lets Claude or ChatGPT take a name, company, or LinkedIn URL and return a full profile with verified email.

The coverage claim is significant if it holds under sampling. Prospeo's tooling is clean, the docs are readable, and the enrichment-from-social-URL flow is genuinely useful for agents that are starting from a LinkedIn signal rather than a known domain.

Good for: Email finding from social profiles, high-volume contact enrichment.

The rest of the field

Apollo, ZoomInfo, HubSpot, and Outreach all have MCP servers now. Crustdata's comparison and Amplemarket's ten-tool breakdown both note the same pattern: the CRM and sequencing vendors built MCP layers on top of existing infrastructure designed for human dashboards. The data shapes are right; the agent ergonomics aren't. You get fields formatted for a UI card, not a structured payload a downstream agent can act on without parsing.

What's the reference implementation for verified, agent-ready data?

This is where the abm.dev Enrich MCP server is built differently.

The core difference isn't the number of providers. It's the data contract. abm.dev's enrichment MCP returns eighty-nine canonical fields — aggregated, deduped, and reconciled across ten providers — with source citations and confidence scores attached to every value. Not a single composite answer. The actual provenance.

No fabricated facts. No silent fallbacks.

When an agent asks for a company's headcount and gets back a value paired with a confidence score and a named source, it can make a downstream decision with that confidence baked in. When it gets back a bare number with no context, it can't. That distinction is the difference between an agent loop you can audit and one you're flying blind.

The architecture is built for autonomous loops, not human dashboard-watching. One call, ten providers behind it. No per-source bills, no stitching together multiple enrichment APIs, no wondering which number to trust when two sources disagree.

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

How do you choose?

If you're running a human-assisted prospecting workflow — a rep using Claude to research before a call — almost any of these servers will do. Lusha and Prospeo are solid choices. The data quality bar is lower because a human is in the loop to catch obvious errors.

If you're building an autonomous outbound agent — one that selects accounts, verifies contacts, personalizes messaging, and triggers sends without a human approving each step — the bar is different. You need:

Cited values, not bare fields. Your agent needs to know why it trusts a data point.
Confidence scores it can use as conditional logic. Skip the contact if confidence falls below threshold. Don't guess.
Deterministic schemas. The same field name, every time, regardless of which underlying provider returned the value.
Freshness signals. Stale data in an autonomous loop isn't a nuisance — it's a liability.

The field is moving fast. Amplemarket's comparison counted ten serious contenders by mid-2026. More will ship before year-end. The vendors building MCP layers on top of human-facing products will keep improving. But the gap between "data for dashboards" and "data for agents" is architectural, not cosmetic. It doesn't close with a UI update.

Build the agent loop that actually works

The enrichment problem isn't finding data. It's trusting it enough to act on it without a human in the room.

Try abm.dev — the account-based marketing API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

Personalization, at scale.

enrichment MCP server

Stuart McLeod — Wed, 22 Jul 2026 05:30:09 +0000

enrichment MCP server

Here is a working config. Drop it into your MCP client and your agent can call verified B2B enrichment immediately.

{
  "mcpServers": {
    "abm": {
      "type": "url",
      "url": "https://mcp.abm.dev/mcp"
    }
  }
}

No SDK swap. No new dependency tree. The agent discovers the tools, reads the schema, and calls them. That is the whole point of MCP.

What is an enrichment MCP server, exactly?

MCP — Model Context Protocol — is the standard that lets an AI agent discover and call external tools at runtime, without you hardcoding every API client into the agent loop. An enrichment MCP server is a server that exposes data-enrichment capabilities through that protocol.

The agent asks: what tools do you have? The server returns a manifest. The agent picks the right tool, passes the right arguments, and gets back structured data — company firmographics, verified contact details, funding rounds, technographics — whatever the server exposes.

Three capabilities, at minimum, define a useful enrichment MCP server:

Company enrichment — takes a domain or company name, returns canonical firmographic data: headcount, industry, revenue band, tech stack, recent funding.
Contact enrichment — takes a name plus domain, returns verified contact details, title, LinkedIn URL, seniority.
Account search — takes an ICP definition, returns a ranked list of matching companies. The prospecting primitive.

Without all three, you have a lookup tool, not an enrichment layer.

Why does the agent need MCP instead of a direct API call?

It does not need MCP. You can hardcode a direct API call in every agent. Plenty of teams do.

The problem is what happens at scale. Six enrichment tools means six auth schemes, six error surfaces, six rate-limit budgets, and six sets of field names that do not agree with each other. employees from one provider, headcount from another, staff_count from a third. The agent has to reconcile all of it before it can act — and if you have not built that reconciliation layer, it acts on whichever number it saw last.

Featureform's EnrichMCP framework names this cleanly: agents need agentic enrichment — type-safe, relationship-aware data models the agent can introspect, not raw API responses it has to guess at. Their Apache-licensed Python framework is built precisely to give agents a navigable data layer rather than a pile of JSON.

MCP solves the discovery and interface problem. A good enrichment MCP server solves the data quality problem underneath it.

How does an agent actually discover and call the tools?

The flow is straightforward.

Agent initializes. It calls tools/list on the MCP server.
Server returns a manifest: tool names, descriptions, input schemas, output schemas.
Agent receives a task — enrich this account list before the sequence fires.
Agent selects the company enrichment tool, passes {"domain": "stripe.com"}.
Server calls its upstream providers — aggregates, dedupes, and returns one canonical object.
Agent receives structured data with field-level confidence scores and source citations.
Agent acts. Writes the personalization. Triggers the sequence. Logs the provenance.

Step six is where most enrichment MCP servers fail. They return data. They do not return provenance. The agent cannot tell whether the CEO name came from a live LinkedIn scrape this morning or a cached record from eighteen months ago. It cannot tell whether the email was validated or guessed. So it acts on bad data at machine speed — which is exactly the failure mode your team is trying to avoid.

This is the problem we wrote about in detail here: why your AI SDR is hallucinating prospect data.

What separates a production enrichment MCP server from a prototype?

Look at what is circulating in the open-source ecosystem. Enrich.so's MCP server exposes a broad set of enrichment tools through a single URL endpoint — emails, contact validation, company search — accessible to Claude, ChatGPT, Cursor, and any other MCP-compatible client. Useful starting point. General-purpose.

MSAdministrator's enrichment-mcp takes a different angle: enrichment for security observables, built in Python, pulling from multiple security data products. A proof-of-concept that shows how narrow the use case can get when you build MCP enrichment for a specific domain.

Both illustrate the same architectural truth: the MCP interface is the easy part. Anyone can wrap an API in an MCP server in an afternoon. The hard part is what runs behind the interface.

For B2B go-to-market, the production requirements are specific:

Multi-provider aggregation. One field, ten providers behind it. The server reconciles; the agent does not have to.
Confidence scores per field. Not a single score for the whole record. Field-level. The agent needs to know whether to trust the mobile number before it dials.
Source citations. Where did this data point come from? When was it last verified? Agents operating in autonomous loops need this to make defensible decisions. See company and contact data with citations and confidence scores for what that looks like in practice.
Freshness signals. Stale data is not neutral. It is actively harmful. A funding round that closed two years ago, presented as current context, sends your agent in the wrong direction.
No silent fallbacks. If a provider returns nothing, the server should say so — not quietly substitute a lower-confidence value and pretend it did not.

No fabricated facts. No silent fallbacks. No per-source bills your team has to reconcile at month-end.

Why abm.dev built MCP as a first-class channel

Most enrichment APIs bolt MCP on as an afterthought. A thin wrapper. A weekend project someone shipped to the docs page.

We built it the other way. The MCP server is a first-class distribution channel because the people building AI-agent go-to-market are not sitting in dashboards. They are writing agent loops in Python and TypeScript. They need data that arrives in the shape an agent can use — eighty-nine canonical fields, reconciled across ten providers, with confidence scores and source citations attached.

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

That is not a metaphor. It is an engineering requirement. The agent has to know the real budget cycle, the actual decision-maker, the technology the account is running today — not last quarter. It has to know what it does not know, so it does not act on a gap.

Personalization, at scale.

That is what an enrichment MCP server is actually for.

Try it

The abm.dev playground is free. Point your MCP client at https://mcp.abm.dev/mcp, run a tools/list call, and see the manifest. Then enrich a domain. Check the confidence scores. Check the citations.

If it looks right — and it will — use code LAUNCHCODES for launch credits.

abm.dev — the account-based marketing API for AI agents.