DEV Community: Stuart McLeod

How do I turn a raw domain or email into a full account profile my AI agent can act on?

Stuart McLeod — Wed, 19 Aug 2026 05:30:08 +0000

How do I turn a raw domain or email into a full account profile my AI agent can act on?

Here is the call. One identifier in, a structured account profile out:

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"}'

The response carries eighty-nine canonical fields — each tagged with a source citation and a confidence score. Your agent doesn't guess. It reads.

That's the premise. The rest of this post explains what actually happens between the request and the response, and why the architecture matters when an agent is the consumer.

Why does a raw seed produce bad data without a structured enrichment layer?

A domain is a hint, not a record. Left alone, an AI agent will hallucinate the rest — inferred titles, invented headcounts, plausible-sounding LinkedIn URLs that 404. The model is confident and wrong, and at machine speed that compounds fast.

The pattern is well-documented. Instantly.ai's B2B workflow guide makes the case: using corporate domains as the enrichment seed, you can turn one B2B email into full org charts — but only if you run it through a structured enrichment layer first. Skip that step and you're routing on guesswork.

DataForB2B's guide to enriching signups with Claude frames the gap plainly: a signup form asks for one thing — a work email. Sales wants a name, a title, a company, and a reason to call. That gap stalls most PLG motions before they start. The fix is to work outward from the seed, not to ask the agent to infer what it cannot verify.

The fix isn't more data. It's deterministic data — enrichment where every field carries a source and a confidence score, so the agent can reason about what it knows and act only on what it can verify.

What does the enrichment API actually do with a single domain or email?

The abm.dev Enrichment API runs a seed — a domain, an email address, or a company name — through ten providers simultaneously: LinkedIn, Hunter, Perplexity, Tavily, and others. It aggregates the results, dedupes conflicts, reconciles disagreements by confidence weight, and returns a single structured record.

No per-source bills. No six-tab enrichment dashboard. One call, ten providers behind it.

For a company seed, the canonical output includes firmographics, tech stack signals, funding stage, LinkedIn URL, ICP attributes, and a verified mailing address — each field tagged with a source citation and a confidence score.

For a contact seed, the output adds title, seniority, department, direct email (verified), and LinkedIn profile URL.

Every field ships with two metadata properties: source (which provider returned it) and confidence (a normalized score). An agent can filter on a confidence threshold before acting, log the source for audit, and flag low-confidence fields for human review rather than acting on them silently.

No fabricated facts. No silent fallbacks.

BounceWatch's company enrichment pipeline tutorial describes exactly this pattern: from a single signup email, one API call can automatically surface company name, industry, size, funding stage, tech stack, and live growth signals. The architecture is straightforward — the complexity is in the aggregation and reconciliation layer behind the call, not in the calling code itself.

How does an agent consume this inside a real workflow?

The abm.dev API is built for autonomous agent loops. The REST surface is designed for agent consumption — structured inputs, structured outputs, no UI dependency. An agent running inside Claude via the Claude Connector (MCP) or a custom workflow calls the enrichment endpoint the same way it calls any other tool: with a typed input, expecting a typed response.

Logic.inc's Onboarding Personalizer workflow captures the core use case: research a new user based on their signup email and return a structured profile — who they are, what company they work at, how big that company is, their likely role, and what industry they operate in. Real context, not a blank slate. The same pattern applies to outbound: seed in, structured profile out, agent acts.

A practical agent loop looks like this:

Seed arrives — a domain from a form fill, an email from a LinkedIn scrape, a company name from a news trigger
Enrichment call — POST /v1/enrich/company or POST /v1/enrich/contact with the seed
Confidence filter — the agent checks field-level scores; fields below threshold are flagged, not acted on
Profile assembly — the agent builds a structured account object: firmographics, contacts, GTM signals, ICP score
Action routing — the agent decides the next move: personalized email, LinkedIn sequence, direct mail trigger, or hold for review

Step five is where the enrichment quality pays off. An agent that knows the target's tech stack, funding stage, and the name of the VP of Engineering doesn't send a generic blast. It writes a sentence that could only be written for that account.

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

Why does deterministic output matter more than volume?

Most enrichment tools optimize for coverage — how many fields they can return for how many records. That's the wrong metric when an agent is the consumer.

An agent doesn't browse a dashboard and use judgment to discount a suspicious field. It acts on what it receives. A hallucinated title in a human workflow is a minor embarrassment. A hallucinated title in an autonomous outbound loop is a personalization error sent to many accounts before anyone notices.

Deterministic enrichment means:

Every field has a source. The agent can cite it. The audit log can show it.
Confidence scores are first-class. Not a footnote — a field the agent uses in its decision logic.
No silent fallbacks. If a field can't be verified, it returns null and a reason, not a plausible guess.

This is the difference between enrichment built for human dashboard-watching and enrichment built for autonomous agent loops.

What's the API surface?

The abm.dev API is organized into three domains:

Enrichment — company and contact enrichment, ICP scoring, tech stack signals, mailing address verification
Content Generation — personalized outreach copy generated against the enriched profile, not a generic template
Content Publishing — send triggers for email, LinkedIn, and physical direct mail

The full API reference and resources live at abm.dev/resources.

Start here

Try abm.dev — the enrichment API for AI agents. The playground is free. Use code LAUNCHCODES for launch credits.

One call. Eighty-nine fields. Every one of them sourced, scored, and ready for your agent to act on.

Personalization, at scale.

How do I get company and contact data with citations and confidence scores?

Stuart McLeod — Fri, 14 Aug 2026 05:30:09 +0000

How do I get company and contact data with citations and confidence scores?

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

But only if the data holds up. An agent acting on a fabricated job title or a stale domain at machine speed doesn't just miss — it scales the mistake across your entire target list before anyone notices.

Here's what the request/response cycle actually looks like when enrichment is done right: one seed, structured firmographics back, and every field carrying a confidence score plus a traceable source.

What does a confidence score actually mean in enrichment data?

Most enrichment APIs return a value. The good ones tell you how sure they are.

EnrichForge makes this concrete. A call to /v1/company/by-domain?domain=acme.com returns not just { "name": "React", "confidence": 0.92 } but the evidence behind it — so you know whether 0.92 came from a live crawl, a third-party signal, or an inferred match. That's the difference between data your agent can act on and data your agent has to second-guess.

Confidence scores aren't decoration. They're the decision boundary. Set a threshold and your agent promotes high-confidence fields into the outreach payload automatically. Anything below that threshold triggers a human review queue or a secondary enrichment pass. No silent fallbacks. No fabricated facts.

CUFinder's Company Enrichment API publishes 95% confidence scores across its company profiles — industry, revenue, headcount, tech stack — returned from a single domain, name, or LinkedIn URL. That's the bar worth targeting: not just a filled field, but a field you can audit.

What inputs does the API actually need?

As little as one.

The best enrichment APIs are designed for messy, real-world seeds. TAMI's data enrichment API accepts a website, an email, or a name — "even a messy one" — and matches 96% of companies by name, 100% by website, and 98% by LinkedIn handle. You only pay when it finds a result.

That matters in an agent loop. Your agent may be working from a scraped list, an inbound form submission, or a LinkedIn profile URL. It shouldn't need a clean CRM record to start. It should be able to seed with whatever it has and receive structured intelligence back.

Minimal inputs worth supporting:

Domain — acme.com
Email — founder@acme.com
Company name — Acme Corp (fuzzy match)
LinkedIn URL — linkedin.com/company/acme-corp

One call. The API handles deduplication, normalization, and source reconciliation on the other side.

What does the response actually contain?

Structured firmographics. Per-field confidence scores. Source citations.

Here's a representative response shape — the kind Reverse Contact describes as "confidence-first, with transparent metadata so you know how sure we are":

{
  "company": {
    "name": "Acme Corp",
    "domain": "acme.com",
    "industry_tags": ["SaaS", "DevTools"],
    "employee_range": "50-200",
    "hq_city": "San Francisco",
    "hq_country": "US",
    "linkedin_url": "linkedin.com/company/acme-corp",
    "funding_stage": "Series A",
    "annual_revenue_estimate": "$5M-$10M"
  },
  "tech_stack": [
    { "name": "React", "confidence": 0.92, "source": "crawl:builtwith" },
    { "name": "Stripe", "confidence": 0.87, "source": "crawl:wappalyzer" },
    { "name": "Salesforce", "confidence": 0.74, "source": "inferred:job_postings" }
  ],
  "contacts": [
    {
      "name": "Jane Doe",
      "title": "Head of Growth",
      "linkedin_url": "linkedin.com/in/janedoe",
      "email": "jane@acme.com",
      "email_confidence": 0.91,
      "title_confidence": 0.88,
      "source": "linkedin:profile_crawl"
    }
  ],
  "gtm_attributes": {
    "buying_signals": ["recent_hire:VP_Sales", "job_posting:SDR"],
    "icp_fit_score": 0.83,
    "last_enriched": "2025-07-10T14:22:00Z"
  }
}

Every field carries a source tag. Your agent knows whether the Salesforce entry came from a live crawl or a job-posting inference — and can weight its personalization accordingly. Mention the confirmed tech stack in outreach. Hold back on the inferred one until confidence clears the threshold.

No black-box data. No mystery provenance.

Crustdata's company identification endpoint takes the same approach at the entity-resolution layer: match a company by name, domain, profile URL, or internal ID, and receive results ranked by confidence score before enrichment even begins. Entity resolution first, enrichment second. The confidence layer runs through the entire pipeline.

Why does provenance matter more in an agent loop than in a human workflow?

A human pauses. An agent doesn't.

When a sales rep gets a bad data point, they notice something feels off — wrong industry, title that doesn't match the company size, a phone number that rings nowhere. They skip it or check. That friction is actually useful.

An autonomous agent has no such pause. It reads the field, meets the confidence threshold, and fires the action — personalized email, LinkedIn connection request, direct mail trigger, CRM write. At scale. Before anyone has reviewed a single record.

This is why enrichment built for agent-first consumption looks different from enrichment built for dashboard-watching. Every field in the response needs to be structured for programmatic decision-making: act if confidence ≥ threshold, queue for review if not, log the source for audit if the outreach later gets questioned.

The alternative — stitching together multiple enrichment tools with no unified confidence layer — means your agent is reconciling contradictory signals silently. One provider says the company has two hundred employees. Another says fifty. The agent picks one. You never know which, or why.

One call, ten data sources behind it. Aggregated, deduped, reconciled. That's the architecture worth building on.

How do citations make enrichment auditable?

Citations answer the question every compliance-conscious team eventually asks: where did this come from?

Not just for legal reasons. For operational ones. When a personalized outreach references a specific detail — a recent funding round, a technology the company uses, a hiring signal — and that detail is wrong, you need to trace it back. Which provider surfaced it? When was it last verified? What was the confidence score at send time?

Without citations, that trace doesn't exist. You have a field value and no history.

With citations, your agent can:

Log the source and timestamp at enrichment time
Flag records where the primary source is older than expected
Trigger re-enrichment before a high-value send
Surface the citation in the CRM note so the rep who follows up has context

Deterministic, auditable enrichment isn't a nice-to-have. It's what separates a GTM motion that compounds from one that quietly degrades.

What fields matter most for ABM and personalized outreach?

Not all enrichment fields carry equal weight in a GTM context. The ones that drive personalization at scale:

Company-level

Industry tags and sub-vertical
Employee count and growth rate
Funding stage and most recent round
Tech stack (confirmed, not inferred)
Hiring signals — open roles, recent senior hires
HQ location and subsidiary structure

Contact-level

Verified title and seniority
LinkedIn URL (canonical identity)
Verified work email with confidence score
Tenure at current company
Past companies (for relationship mapping)

GTM attributes

ICP fit score
Buying signals — job postings, funding events, tech additions
Last enrichment timestamp

The ICP fit score and buying signals are where the data layer earns its place in an agent stack. They're not raw data points — they're pre-computed GTM intelligence your agent can route on directly. High ICP fit plus a recent VP Sales hire equals immediate outreach queue. Low fit score equals suppression. The agent decides. No human in the loop for the easy cases.

The build worth shipping

Personalization, at scale.

That's the goal. Not a dashboard full of enriched records nobody acts on. A live agent loop that seeds with a domain, receives structured intelligence with confidence scores and citations, applies a threshold-based decision layer, and triggers personalized outreach — email, LinkedIn, or a physical send that breaks through inbox noise — without waiting for a human to approve each record.

The data infrastructure to do that exists. One API, citations on every field, confidence scores your agent can route on programmatically.

Try abm.dev — the enrichment API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

How should enrichment be priced for agent workloads (no per-field bills)?

Stuart McLeod — Fri, 14 Aug 2026 05:30:08 +0000

How should enrichment be priced for agent workloads (no per-field bills)?

Personalization, at scale.

Here is the number that breaks per-field pricing: a developer running enrichment for an AI agent at scale found that data costs exceeded inference costs — not by a little. The model was cheap. The fields were not. Every retry, every fallback, every partial match: billed. The agent looped. The bill compounded. The budget died before the campaign launched.

That is not a vendor problem. It is a pricing-model problem.

Why does per-field billing punish autonomous agents specifically?

Human operators enrich a list once, review it, and move on. An agent does not work that way. It retries on null returns. It re-queries when confidence is low. It fans out across multiple providers to reconcile conflicting titles or stale LinkedIn URLs. Every one of those operations is a billable event under a per-field model — even when the field comes back empty, even when two providers return the same value, even when the enrichment fails silently and the agent never knew.

Databar's analysis of outcome-based enrichment makes the case plainly: retry-heavy AI workloads broke credit-based pricing. The cost structure was designed for humans clicking buttons, not agents running loops at three in the morning.

The result: teams stitching together multiple enrichment tools and receiving separate bills for data that may or may not agree with itself. No provenance. No confidence scores. No way to know which field came from which source when the agent acts on it.

What does a record-based model actually look like?

Instead of charging per field returned, a record-based model charges per contact or company enriched — one price, one record, regardless of how many providers were queried behind the scenes to fill it.

One call, multiple providers behind it — aggregated, deduped, reconciled. No per-source bills.

The practical difference:

Per-field: enrich a title, pay. Enrich a LinkedIn URL, pay. Retry the title because it came back null, pay again. Reconcile two conflicting company sizes, pay twice.
Per-record: send a name, email, or domain. Receive a structured, verified record. Pay once.

For ABM practitioners building agent-driven go-to-market, this matters at the architecture level. The agent does not know in advance which contacts will match. It cannot pre-screen. It sends the whole list through enrichment, acts on what comes back verified, and discards the rest. Under per-field pricing, the discarded records still cost money. Under record-based pricing, unmatched records cost nothing — you pay for delivered intelligence, not attempted queries.

Databar's agency pricing guide addresses the broader shift: aligning cost with delivered value rather than effort expended on the provider's side. The same logic applies to agent workloads. You should pay for what the agent can use, not for the waterfall mechanics that produced it.

What does bad pricing reveal about the underlying data model?

Pricing is only half the problem. The other half is what gets returned when a record does match.

Consider an enrichment run against twenty-one contacts at a professional services firm with offices in Cambridge, Norwich, and London. Seven contacts based in Cambridge. Three in Norwich. Seven in London. One contact received a correct office address. The rest received nothing — or worse, inherited the company envelope's default: the registered HQ address.

The identity layer was HQ-biased. It knew the company. It did not know the offices.

This is not a data-freshness problem. It is an architecture problem. Standard enrichment APIs resolve a domain to a company record and return the registered address. They do not model the fact that a firm with staff across multiple cities has multiple offices, not one. When an agent tries to send a personalized physical piece to a Cambridge partner, it gets the wrong city. The send is wrong before it leaves the queue.

Verifiable, agent-ready enrichment means the record carries citations — not just a field value, but the source, the confidence score, and the evidence chain that lets the agent audit what it is acting on. A Cambridge contact should return a Cambridge office address, with the source that confirmed it. No silent fallbacks to HQ.

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

What does agent-ready enrichment actually require?

Three things separate enrichment that works in an agent loop from enrichment that merely works in a spreadsheet.

One. Deterministic output. The same seed — name, email, domain — returns the same structured record every time, or flags a confidence change. No silent fallbacks. No fabricated facts. An agent that cannot trust the consistency of its data layer cannot act reliably at machine speed.

Two. Auditable provenance. Every field carries its source. The agent can inspect why a title was returned, which provider confirmed a LinkedIn URL, whether a phone number was verified or inferred. When something goes wrong downstream — a bounce, a wrong address, a misrouted send — the trace is there.

Three. Record-level pricing. The agent enriches the whole list. It pays for matches. It does not pay for retries, fallbacks, or the waterfall mechanics that produced the final record. The cost is predictable. The loop can run.

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

The enrichment layer is what makes that true or false. Eighty-nine canonical fields, ten providers, one API call — that is the infrastructure. The pricing model is what determines whether you can afford to run it at the volume agents actually require.

What should you actually pay per enriched record?

For context, Databar's current pricing runs from ninety-nine dollars per month for five thousand credits on the Build plan. That is a per-credit model — each field or API call consumes credits. At scale, with agent retries factored in, the real cost per enriched contact climbs well above the headline rate.

Record-based pricing inverts this. You know the cost before the agent runs. You can model the campaign budget. You can set a ceiling. The agent operates within it without generating surprise invoices.

For founders and growth engineers building agentic outbound, the pricing model is not a procurement detail. It is a system constraint. Get it wrong and the agent loop is economically unviable before the first reply arrives. Get it right and the marginal cost of personalization at scale approaches zero.

The architecture question and the pricing question are the same question. An enrichment API that charges per field is telling you something about how it was designed — for human workflows, not agent loops. One that charges per record, returns citations, and holds a consistent schema across providers was built for the workload you are actually running.

Try it

abm.dev — the enrichment API for AI agents. Turn a name, email, or domain into verified, structured intelligence: titles, LinkedIn URLs, firmographics, office locations with citations, GTM attributes. One call. Record-based pricing. No per-field bills.

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

Personalization, at scale.

What does good GTM data look like when an agent acts on it at machine speed?

Stuart McLeod — Wed, 12 Aug 2026 05:30:11 +0000

What does good GTM data look like when an agent acts on it at machine speed?

Here is a call that goes wrong at scale. Your agent pulls a company record, confirms the account fits your ICP, writes a personalized sequence, and fires it — three hundred times before anyone notices the funding round it cited closed eighteen months ago. The data looked fine. It was not fine. At human speed, a rep catches that. At machine speed, it ships.

This is the structural problem nobody talks about when they talk about agentic GTM. The question is not whether your agent can act. It can. The question is whether the data it acts on is built for the loop it is running.

Three properties separate GTM data that works at machine speed from GTM data that merely looks right in a dashboard.

What does "actionable" actually mean for an agent?

Actionable is not a synonym for complete. A record with eighty-nine populated fields is not actionable if the agent cannot resolve what to do next from those fields without a human in the loop.

Actionable means: every field maps to a decision. Job title maps to persona tier. Funding stage maps to budget cycle. Tech stack maps to integration fit. When the agent reads the record, it has everything it needs to score, route, personalize, and trigger — without calling a human for clarification.

LangChain's own GTM agent started from exactly this problem. Before the agent, a rep toggled between Salesforce for the account record, Gong for call history, LinkedIn for the contact, and the company website for context — fifteen minutes of research before a single word was written. The agent collapsed that into one structured call. But it only worked because the underlying data was mapped to decisions, not just stored.

The failure mode here is what you might call field bloat. Six enrichment tools stitched together produce a record that is wide but incoherent. Duplicate fields with conflicting values. Employee counts from three different sources, none of them dated. The agent does not know which one to trust, so it picks one — silently. No log entry. No flag. Just a wrong assumption baked into three hundred emails.

Why does freshness matter more than volume?

Most enrichment pipelines are built around a snapshot model. Enrich once, store, query later. That made sense when a human rep reviewed the record before acting. It does not make sense when an agent acts on it the moment a trigger fires.

Explorium's architecture analysis puts it plainly: traditional CRM data stacks were designed for human workflows — batch exports, stale snapshots, and zero API-first design make them structurally incompatible with AI agents that need real-time, deterministic data access.

Stale data at human speed is an embarrassment. Stale data at machine speed is a campaign. The agent does not slow down because the funding date is old. It personalizes around it, at volume, before anyone reviews the output.

Freshness is not just about recency. It is about knowing when a field was last verified. A job title confirmed yesterday is different from a job title scraped two years ago and never touched since. Without that provenance, the agent cannot weight its own confidence — and agents that cannot weight confidence cannot fail gracefully.

Jay Mount's 2026 AI-GTM reference architecture describes the data foundation layer as the thing every other layer depends on. Signals, agents, orchestration, and measurement all feed from it. If the foundation carries stale or unprovenanced data, every layer above it inherits the error — compounded, not corrected.

What breaks when an agent has no failure-tolerance?

This is the property teams discover last, usually after something goes wrong.

Failure-tolerance means the data layer tells the agent what it does not know — not just what it does. A confidence score on the company address. A citation for the mailing address used in a direct mail send. A clear null rather than a silent fallback to a stale value.

Without failure-tolerance, agents hallucinate forward. They have been trained to complete tasks. When a required field is missing, many will infer, interpolate, or silently substitute — and the output looks clean because the agent is fluent, not because the data is correct.

Apollo's analysis of agentic GTM adoption notes that eighty-three percent of AI-using sales teams report revenue growth — but separates autonomous agents from AI features precisely on this point. A feature surfaces a suggestion. An agent executes. That distinction matters enormously when the execution is wrong.

The fix is not more data. It is data with explicit uncertainty. A field that carries its source, a confidence score, and a last-verified date gives the agent something to act on and something to flag. A field that just says "123 Main St" gives it nothing but a false sense of certainty.

Antoine Buteau's GTM observability framework draws the parallel to software engineering directly: logs, metrics, traces, and alerts are not optional once systems become complex. GTM systems have reached that point. Data freshness, error rates, routing accuracy, and agent output quality all need to be observable — not inferred from lagging reports after the campaign already ran.

No citations, no confidence scores, no observable failure states. That is not a data layer. That is a liability at scale.

What does the full picture look like?

Good GTM data, when an agent acts on it at machine speed, has three properties working together:

Actionable. Every field maps to a decision. No ambiguity the agent has to resolve by guessing. No duplicate values from six stitched-together tools with no reconciliation logic.

Fresh. Every field carries a timestamp and a source. The agent knows not just what the value is, but when it was verified and where it came from. Provenance is not a nice-to-have. It is the thing that makes confidence scores meaningful.

Failure-tolerant. Missing data is explicit, not papered over. Confidence scores are attached to fields, not implied by their presence. The agent can decide to skip, flag, or route to a human — rather than fabricating forward into a bad send.

These three properties are not independent. Actionability without freshness produces confident decisions on wrong data. Freshness without failure-tolerance produces a system that acts on ninety-percent-complete records as if they were one hundred percent. Failure-tolerance without actionability produces a system that flags everything and acts on nothing.

The architecture has to hold all three at once. That is what agent-ready data means.

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

The rep who knew every account did not just know the facts. She knew which facts to trust, which ones to verify before the call, and when to say she did not have enough information yet. That judgment was the skill.

Good GTM data gives agents the same judgment — not by making them smarter, but by making the data honest. Actionable fields. Timestamps and citations. Explicit uncertainty. No fabricated facts. No silent fallbacks.

That is the data infrastructure that makes personalization work at scale. Not wider records. Honest ones.

Try abm.dev — the account-based marketing API for AI agents. One call, ten providers behind it. Aggregated, deduped, reconciled, and returned with confidence scores and citations your agent can act on. The playground is free. Launch credits with the code **LAUNCHCODES.

verified mailing addresses b2b

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

verified mailing addresses b2b

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

But an agent that ships a personalized package to a bad address isn't personalized outbound. It's expensive noise. Before any direct mail loop runs — before the agent selects the gift, writes the note, or triggers the send — one gate has to close: is this address real, deliverable, and standardized to postal spec?

That gate is address verification. And for autonomous outbound, it's not optional.

Why does address verification matter more for agents than for humans?

A human rep catches a bad address. She Googles the company, checks LinkedIn, calls the front desk. The error rate stays low because there's a person in the loop absorbing friction.

Agents don't absorb friction. They multiply it.

At machine speed, a bad-address rate that looks small in a large list means a significant number of wasted sends before anyone notices. Worse, most enrichment databases carry addresses that were accurate well over a year ago. Datarade's B2B company database pushes 30-day update cycles precisely because company street addresses change — relocations, subleases, remote pivots, office consolidations. Stale is the default. Verified is the work.

This is the hard dependency: verification isn't a nice-to-have append. It's a prerequisite gate. No verified address, no send.

What does the verification gate actually check?

Not all address checks are equal. A quick regex that confirms a ZIP code exists is not verification. A real verification gate runs at least four checks:

1. Existence — Does this address appear in a postal authority dataset? In the U.S., that means USPS. Smarty's address validation tool defines address validation as confirming an address exists and can receive mail or deliveries, then standardizing formatting to match local postal standards. Existence without deliverability is not enough.

2. Deliverability — Is the address currently active and receiving mail? A building that was demolished last year may still resolve in a stale database. Compliancely's address verification API uses real-time USPS data specifically to reduce delivery failures and returned mail — the two outcomes that make direct mail economics break.

3. Standardization — Is the address formatted to postal spec? Suite vs. Ste., abbreviated directionals, missing ZIP+4 — small inconsistencies cause sort failures at the carrier level. Standardization isn't cosmetic; it's operational.

4. Confidence scoring — Can the system express certainty? An agent acting on a low-confidence address is gambling. A well-structured verification response returns a match grade or confidence score so the agent can route uncertain records to a human review queue rather than sending blind.

Miss any of these four and you have an address that looks verified but isn't.

Why do most enrichment stacks fail this gate?

The typical growth stack stitches together multiple tools: one for firmographics, one for contact data, one for email verification, maybe a direct mail vendor bolted on at the end. Each tool has its own address field, its own update cadence, its own confidence model — or no confidence model at all.

The result is data with no provenance. The agent doesn't know which source supplied the address, when it was last validated, or whether it passed a deliverability check. It acts anyway.

Melissa’s global address verification checks addresses against official in-country postal reference data across 240+ countries — an address only counts as verified when it matches the postal authority’s own records, not because it arrived from a vendor’s list. Verify in real time at the point of use, not a one-time batch scrub from months ago.

PostGrid’s international verification cross-references addresses against Royal Mail, USPS, Canada Post, Australia Post and other national authorities — every country has its own postal format, and a UK address standardised to the wrong country’s rules is still undeliverable. Treat mailing address as a canonical, standardised record, not an afterthought field.

The problem isn't that good address data doesn't exist. The problem is that most agent pipelines never wire up the verification step between data acquired and send triggered.

What does a verified address loop look like in practice?

Here's the minimum viable verification gate for an autonomous direct mail agent:

# Pseudocode — agent verification gate before direct mail send

def should_send(account: dict) -> bool:
    address = account.get("mailing_address")
    if not address:
        return False  # No address, no send. Hard stop.

    result = verify_address(address)  # Call USPS-backed verification API

    if result["deliverable"] is False:
        queue_for_review(account, reason="non-deliverable")
        return False

    if result["confidence"] < 0.85:
        queue_for_review(account, reason="low-confidence")
        return False

    account["mailing_address"] = result["standardized"]  # Always use standardized form
    account["address_verified_at"] = result["timestamp"]  # Provenance matters
    return True

Three outcomes: send, hold for review, or hard stop. No silent fallbacks. No sending on a field that never passed a check.

The address_verified_at timestamp matters as much as the verification itself. An address verified over a year ago is not a verified address. It's a historical record. Agents running continuous outbound loops need to re-verify on a cadence — quarterly at minimum for high-velocity programs.

Why direct mail is a first-touch channel, not a follow-up

The framing that direct mail only works as a response tactic — send physical mail after someone opens an email, use it to re-engage cold accounts — undersells it. A well-researched, personalized physical send is a cold-capable first touch. It breaks through inbox noise precisely because it arrives somewhere the prospect didn't expect contact.

The reciprocity effect is real. A thoughtful physical send — the right object, the right message, the right moment in the account's budget cycle — earns replies that a seventh cold email never will. But it only works if the address is right. A returned package doesn't earn reciprocity. It earns nothing.

This is why address verification is a hard dependency, not a best practice. The channel's entire value proposition depends on delivery. Delivery depends on a verified, standardized, currently-deliverable address. The agent has to close that gate before it does anything else.

What does agent-ready address data actually require?

Four things that most enrichment pipelines don't provide together:

Provenance — which source supplied this address, and when
Verification status — did it pass a USPS-backed deliverability check
Confidence score — how certain is the match, expressed as a number the agent can act on
Standardized form — formatted to postal spec, ready to pass to a print/ship vendor without transformation

Without all four, the agent is guessing. At machine speed, guessing is expensive.

abm.dev is built for exactly this gate. Every enriched mailing address is verified at the full-address level, not just the postcode — through the Google Address Validation API, which works internationally, with a Royal Mail postcode check layered underneath for UK records. You get back a validation granularity (was the building confirmed, or only the street?), a completeness flag, and the canonical, standardised form of the address. When an address cannot be confirmed, “not verified” comes back as a first-class result, never a guess. Confidence and provenance on every field, mailing address included. No fabricated data. No silent fallbacks.

Ready to run a verified direct mail loop?

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

Personalization, at scale.

gifting in abm

Stuart McLeod — Mon, 10 Aug 2026 05:30:06 +0000

Gifting in ABM

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

Sixty percent of prospects who received a gift booked a meeting — without being asked. No meeting requirement. No follow-up sequence. Just a well-timed, well-chosen send. That's the number Influ2 reported from their Oura Ring campaign, where contact-level signals — not a calendar — determined who got what and when.

That result isn't luck. It's what happens when gifting stops being a scheduled gesture and starts being a data-triggered action.

Most ABM gifting programs don't work that way. They work the old way: a fixed send date, a branded item, a list pulled from a spreadsheet. Sendoso's demand generation team puts it plainly: generic sends on a fixed schedule train prospects to ignore you. The teams seeing strong pipeline results are doing something different.

Here's what different looks like when an agent is running the motion.

Why does timing matter more than the gift itself?

The gift is not the variable. The moment is.

A bottle of wine sent on the same day as every other vendor's holiday mailer is noise. The same bottle sent the week an account posts a new VP of Sales hire — that's signal recognition. That's a rep who was paying attention.

The problem is that paying attention, at scale, used to require humans. A human rep could track a handful of accounts. An agent can track thousands.

Demandbase's guidance on direct mail and gifting frames the same principle: the send has to connect to something real in the account's world — a trigger, a milestone, a shift in buying posture. Without that connection, you're not personalizing. You're broadcasting with postage.

The enrichment layer is what makes the connection possible. Verified firmographic data tells you the account. Intent signals tell you the moment. Contact-level data tells you the person. Put those three things together and you have a brief. Give that brief to an agent and it can trigger a send without a human in the loop.

What signals should trigger a gift send?

Not all signals are equal. Some indicate awareness. Some indicate active evaluation. The ones worth triggering a physical send on are the ones that indicate a buying window is open.

Some signals worth watching:

Funding round closed. New budget, new mandate, new urgency. The account just got permission to spend.
Executive hire. A new VP or Head of anything is rebuilding their stack. They're evaluable before incumbents are entrenched.
Job postings. A company hiring engineers for a specific function is signaling a strategic bet. That bet has adjacent spend.
Intent spike. Third-party intent data showing a cluster of research activity on your category — not one page view, a pattern.
Engagement threshold crossed. A contact hit multiple touchpoints without converting. They're interested. Something's blocking them.

Influ2's contact-level signal approach skipped the meeting requirement entirely because the signals already indicated readiness. The gift was confirmation, not cold outreach. That's the distinction that matters.

How does an agent actually execute this?

The motion has four steps. Each one requires data the agent can trust.

1. Account selection.
The agent pulls the target account list — ICP-matched, intent-scored, prioritized by signal recency. No guessing. No stale CRM records. The account data needs provenance: where did this firmographic come from, when was it last verified, what's the confidence score.

2. Contact identification.
Gifts go to people, not companies. The agent identifies the right contact at the account — the economic buyer, the champion, the blocker — using verified contact data. Name, title, mailing address. Mailing address is the hard part. Most enrichment tools don't carry it. The ones that do often don't cite their source.

3. Trigger confirmation.
Before the send is authorized, the agent checks the trigger condition. Is the signal still active? Is the funding round recent or six months old? Is the job posting still live? Stale signals produce sends that arrive at the wrong moment. Agents acting on bad data at machine speed is how you send a congratulations gift to an executive who left the company three weeks ago.

4. Personalized send.
The gift and the note are matched to the account context. Postal's ABM gifting strategy guide makes the point that the accompanying message carries as much weight as the physical item — the note has to reference something specific, something that shows the sender was paying attention. An agent with good account data can write that note. An agent with generic data writes a generic note, and the gift lands like every other gift.

What does the research stack look like?

Elric Legloire's research system for ABM gifting separates account-level research from contact-level research — firmographic context first, then individual signal mapping. The insight is structural: you can't personalize at the contact level until you've understood the account.

For an agent running this autonomously, that structure maps cleanly onto API calls:

# Pseudocode: agent gifting trigger loop

for account in target_account_list:
    # Step 1: verify account context
    firmographic = abm_api.enrich_company(account.domain)
    if firmographic.confidence < threshold:
        skip(account, reason="low_confidence_data")
        continue

    # Step 2: check for active trigger signal
    signals = abm_api.get_signals(account.domain)
    if not signals.has_active_trigger():
        continue

    # Step 3: identify and verify contact
    contact = abm_api.enrich_contact(
        account=account.domain,
        persona="economic_buyer"
    )
    if not contact.mailing_address.verified:
        flag_for_review(contact)
        continue

    # Step 4: compose and authorize send
    note = agent.draft_note(
        account_context=firmographic,
        trigger=signals.top_signal,
        contact=contact
    )
    gifting_platform.send(
        recipient=contact,
        gift=select_gift(signals.top_signal),
        note=note,
        citations=firmographic.sources  # provenance attached
    )

The citations line is not decorative. When an agent acts on data, the data needs a source. No fabricated facts. No silent fallbacks. If the mailing address came from LinkedIn via a verified provider, that's in the record. If it came from a model's best guess, that's how you send a gift to a building that was demolished.

What breaks gifting programs at scale?

Three things, consistently.

Bad address data. Physical sends require physical addresses. Most B2B enrichment tools are built for email. Mailing address coverage is thin, unverified, and rarely cited. An agent that can't confirm a delivery address shouldn't trigger a send.

Stitched-together tooling. Multiple enrichment sources, several intent providers, a spreadsheet in the middle, and a human checking the output before anything goes out. That's not a scalable motion. That's a human-dependent process wearing automation's clothes.

Timing mismatches. A gift that arrives after the deal closes, or after the executive leaves, or after the competitor already sent one — that's not a missed opportunity. That's a negative signal. The account now knows you're not paying attention.

All three failures have the same root: data quality. Specifically, data without provenance, data without freshness, and data that can't be trusted at machine speed.

The send that earns reciprocity

Once upon a time, marketing was a person who knew you — the right call at the right moment, the detail nobody else caught. A handwritten note that referenced the thing you mentioned in passing six weeks ago.

The data is rich enough to do that again. At scale this time.

Gifting in ABM isn't a nurture tactic. It's a proactive first-touch that breaks through inbox noise by arriving in a different channel entirely — physical, considered, timed to a real signal. When the agent selects the account, verifies the address, confirms the trigger, and drafts a note grounded in real account context, the send earns reciprocity. Not because it's expensive. Because it's right.

Personalization, at scale.

Try abm.dev — the account-based marketing API for AI agents. Verified contact and company data, mailing addresses with citations, signal-ready enrichment your agents can act on without a human in the loop. The playground is free. Launch credits with the code LAUNCHCODES.

ABM for startups

Stuart McLeod — Fri, 07 Aug 2026 05:30:09 +0000

ABM for Startups

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

You don't need a $150K platform. You need twenty accounts, verified data, and agents that can act on it without hallucinating the details.

Here's what that actually looks like — and why the API-first path beats the platform path every time.

Why do startups keep buying ABM platforms they can't use?

The most common startup ABM failure isn't a bad strategy. As Stackmatix puts it: it's buying a $150K platform, building a target account list of five hundred companies, and launching campaigns before the sales team has closed twenty deals.

Enterprise ABM was designed for companies with full revenue operations teams, mature ICPs, and the pipeline volume to justify complex attribution models. Startups have none of that. What they do have — and what the big platforms actively waste — is focus.

Avair's analysis makes the point cleanly: a big company sprays across thousands of logos. A scrappy team can know twenty companies cold. That's not a limitation. That's the advantage.

The problem is that most ABM tooling is designed for the spray-and-pray motion it claims to replace. Six enrichment tools stitched together with Zapier. Data with no provenance. Agents acting on bad phone numbers and stale headcounts at machine speed. By the time the bad data compounds, you've burned the accounts that mattered most.

What does a lean, API-first ABM stack actually look like?

Forget the platform. Build the stack in three layers.

Layer one: a tight target account list.

Twenty to fifty accounts. Not five hundred. Abmatic AI's beginner guide is direct about this: startups are actually ideal for ABM because they have speed and agility. A startup can identify twenty target accounts, research each one deeply, and move faster than any enterprise team. The constraint isn't ambition — it's the list.

Define the ICP by the deals you've already closed. Which verticals. Which headcount bands. Which signals — a recent funding round, a new VP of Sales hire, a job post for a role your product eliminates. Keep the list short enough that every account gets real attention.

Layer two: verifiable, agent-ready data.

This is where most stacks break. Your agent needs to know the company's current headcount, the right contact at the right seniority, a verified mailing address, a LinkedIn URL that resolves, a phone number with a source attached. It needs to know why it believes each field — not just the value, but the provenance.

Without citations and confidence scores, agents act on fabricated facts. They personalize the wrong detail. They send to a contact who left six months ago. They reference a funding round that never closed. At human speed, bad data is annoying. At machine speed, it's a reputation problem.

Prospeo's 90-day ABM pilot playbook makes the budget case plainly: you don't need Demandbase. You need enrichment that works, a way to reach the account, and a feedback loop tight enough to iterate inside ninety days. The tooling cost should be a fraction of what the enterprise platforms charge — because the value is in the data and the motion, not the dashboard.

Layer three: agents that act, not humans that watch.

Once you have a tight list and verified data, the motion is simple. An agent selects an account, pulls enriched fields with citations, decides on the right first touch, and executes. No human in the loop for the mechanical parts. Human judgment at the strategic layer — which accounts, which message angles, which signals to weight.

The first touch doesn't have to be email. A thoughtful physical send — a book, a handwritten note, something that took judgment to choose — earns reciprocity in a way that a cold sequence rarely does. The agent selects the account, verifies the mailing address with cited sources, and triggers the send. Cold, proactive direct mail as an opening move. Not a follow-up. Not a nurture play. An interruption that earns a reply.

Why does data provenance matter more than data volume?

Growthspree's seed-to-Series-A playbook notes that the tools have gotten cheaper, the AI has gotten smarter, and the playbook has gotten simpler. That's true. But cheaper and smarter cuts both ways. Agents that can personalize at scale can also fabricate at scale — and they will, if the data layer lets them.

The difference between an agent-ready data layer and a conventional enrichment API is citations. Every field should carry a source and a confidence score. When the agent writes a personalized line about a company's recent Series B, it should be able to cite the source that confirmed it. When it selects a mailing address for a direct send, it should be able to show the source that verified it.

No fabricated facts. No silent fallbacks. No enrichment that returns a value and hopes you don't check.

This matters at startup scale for a specific reason: you have twenty accounts, not two thousand. One burned account is five percent of your list. The margin for bad data is zero.

What does the ninety-day pilot actually look like?

Week one through three: build the list. Twenty accounts. Define the ICP from closed deals. Identify the signals — funding, hiring, tech stack, trigger events. Assign a primary contact per account.

Week four through six: enrich the list. Pull verified fields with citations. Headcount, funding stage, LinkedIn, verified email, mailing address, the right contact at the right seniority. Check confidence scores. Flag anything below threshold for manual review.

Week seven through ten: run the first-touch motion. Agent selects the account, chooses the message angle based on enriched signals, executes the send — physical, email, or both. Log every touch with the data state at time of send, so you can audit what the agent believed when it acted.

Week eleven through thirteen: measure and iterate. Pipeline created per account, not aggregate traffic metrics. Which signals predicted engagement. Which enrichment fields drove the best personalization. Tighten the ICP. Cut the accounts that aren't moving.

Ninety days. Twenty accounts. One API. No platform.

Is ABM for startups really different from enterprise ABM?

The mechanics are the same. The economics are different. And the data requirements are stricter.

An enterprise team can absorb a bad-data rate across a thousand accounts. A startup running twenty accounts cannot. Every agent action needs to be auditable. Every enriched field needs a source. Every first touch needs to be worth the account's attention — because you only get one.

The platform vendors will tell you that you need their workflow tools, their intent data, their multi-channel orchestration suite. You don't. You need a tight list, verified data with citations, and agents that can act on it without asking a human to babysit the loop.

Personalization, at scale.

That's the whole thing.

Build the stack. Skip the platform.

The API-first path is faster to launch, cheaper to run, and — critically — easier to audit when something goes wrong. You know exactly what data the agent had. You know exactly what it sent. You can fix the list, fix the enrichment, fix the signal weighting. You can't do that with a black-box platform that abstracts the data layer away from you.

For a deeper look at what agent-ready enrichment actually returns — citations, confidence scores, canonical fields — see abm.dev's resources.

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

b2b direct mail automation

Stuart McLeod — Thu, 06 Aug 2026 05:30:09 +0000

b2b direct mail automation

Personalization, at scale.

Here is a working trigger in under thirty lines:

// 1. Enrich the account
const account = await abm.enrichment.company({ domain: 'acme.com' });

// 2. Verify the mailing address (with citations)
const address = account.fields.mailing_address; // confidence score + source attribution included

// 3. Fire the send
if (address.confidence >= 0.85) {
  await abm.publishing.directMail({
    recipient: account,
    template: 'cold-prospecting-v3',
    personalization: {
      companyName: account.fields.name,
      trigger: account.signals.hiring_spike,
    },
  });
}

No spreadsheet. No vendor call. No human in the loop. The agent selects the account, verifies the address, and drops a physical piece in the mail — as a first touch, not a follow-up.

That is the pattern. The rest of this post explains how to wire it properly.

Why is direct mail the right cold-prospecting channel right now?

Inboxes are saturated. Cold email response rates have been declining for years as AI-generated volume floods every prospect's Gmail. A thoughtful physical send earns reciprocity in a way a seventh follow-up sequence never will.

The objection you will hear: direct mail is a response tactic — nurture, not cold outreach. That framing is wrong. It is a convention inherited from B2C catalog programs and DTC retargeting. B2B is different. A well-timed, well-researched physical piece sent cold — referencing the account's actual situation, the real blocker, the open role on their engineering team — is an opening move. It says: we did the work before we asked for anything.

Lob’s guide to direct mail in SaaS ABM describes the shift: physical sends triggered programmatically by real-time signals and lifecycle events, not batch-and-blast lists. That is exactly the posture an agent-orchestrated cold send should take — the send fires off a signal, not a calendar.

The physical channel also has a durability advantage. PostPilot notes that traditional direct mail is "super slow and limited" when run manually — but automated, trigger-based programs remove that friction entirely. The slowness was always operational, not structural.

What does the enrichment → signal → send pipeline actually look like?

Three stages. Each one is a discrete API call. None of them should require a human decision.

Stage one: Enrichment.
The agent resolves the account — company name, domain, firmographics, technographics, mailing address — against multiple providers in a single call. One call, ten providers behind it. Aggregated, deduped, reconciled. Every field carries a confidence score and a source citation. If the mailing address comes back below your confidence threshold, the agent skips the send and flags the record. No fabricated facts. No silent fallbacks.

This matters because agents act at machine speed. Bad data does not slow them down — it scales the mistake. PostGrid's direct mail automation platform surfaces address verification as a core requirement precisely because undeliverable mail is not just wasted spend — it is a broken signal loop. Your agent triggered on bad data and got no feedback.

Stage two: Signal detection.
The agent is not mailing every account in the CRM. It is watching for intent: a hiring spike on LinkedIn, a new funding round, a technographic change. When a signal fires above threshold, the account enters the send queue.

Imaginuity's Ai Mail system describes this shift as moving "beyond broad list-based targeting toward genuinely better acquisition decisions" — identifying and prioritizing accounts based on real behavioral signals rather than static list pulls. That is the right model. The agent does not mail because an account exists in the ICP. It mails because something changed.

Stage three: Content generation and send.
The agent renders a personalized template — the account's name, the specific signal that triggered the send, a line about their industry that is true and verifiable, not hallucinated. Then it dispatches the physical piece via the configured mail provider.

PFL's direct mail automation platform frames the goal as eliminating "the hassle of juggling vendors and systems" — end-to-end execution from production to delivery to measurement. The abm.dev architecture takes that further: the juggling happens inside the API, not inside your stack.

What goes wrong when you build this yourself?

Six enrichment tools, none of them talking to each other. A mailing address from one provider, a job title from a second, a company headcount from a third — no reconciliation layer, no provenance, no way to know which field to trust when they disagree.

Then the agent acts on the composite record at machine speed. It sends pieces of mail to addresses that expired when the target company moved offices. Or it personalizes on a job title that belongs to the previous VP, who left months ago.

The problem is not the agent. The problem is the data layer underneath it. Agents are only as reliable as the fields they read.

The three-domain architecture — Enrichment, Content Generation, Content Publishing — exists to fix this at the infrastructure level, not the prompt level. Enrichment returns verifiable fields with citations and confidence scores. Content Generation renders against verified data only. Content Publishing dispatches when confidence thresholds are met. Each domain is a clean API contract.

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

How do you keep the address data fresh in a long-running loop?

Mailing addresses go stale. Companies move. Contacts change roles. A field enriched in January is not guaranteed to be accurate in September.

The pattern is TTL-aware enrichment: every field carries a timestamp and a recommended refresh interval. The agent checks the age of the mailing address before each send cycle. If it is beyond the TTL, it re-enriches before dispatching. If the new confidence score drops below threshold, the send is held and the record is flagged for review.

This is not a nice-to-have. It is the difference between a direct mail program that compounds over time and one that quietly degrades.

What does the implementation checklist look like?

Authenticate — API key scoped to your workspace. One key, all three domains.
Enrich the account — resolve by domain or company name. Specify the fields you need; pay only for what you pull.
Evaluate confidence — gate on mailing_address.confidence >= 0.85 (or your threshold). Check the source citation if you want to inspect provenance.
Detect the signal — subscribe to the signal webhook or poll by company. Filter by signal type: hiring spike, funding round, technographic change.
Generate content — render with the template ID and the verified account fields.
Dispatch the send — pass the rendered content and the verified address. The API handles provider routing, print, and fulfillment.
Close the loop — listen for delivery webhooks. Feed confirmed delivery back into the agent's context so it knows when to follow up.

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

Ready to wire it up?

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

Enrichment, Content Generation, Content Publishing. Three domains. One API. No stitching required.

how to build an AI SDR agent

Stuart McLeod — Wed, 05 Aug 2026 05:30:12 +0000

how to build an AI SDR agent

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.

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.