Claude Code Lead Enrichment Workflow
The end-to-end pattern. Trigger, waterfall, validate, write back. Built once, runs unattended.
What This Workflow Replaces
Most GTM teams enrich leads with one of three patterns. A spreadsheet pasted into Clay by an SDR each Monday. A Zapier zap that triggers on form submit and calls Apollo. Or a Make scenario with eight steps that breaks every six weeks and nobody knows why. All three work. All three create maintenance work and none of them handle the parts of enrichment that need judgment.
A Claude Code lead enrichment workflow replaces the orchestration and the judgment, not the enrichment itself. Clay still runs the waterfall across vendors. Apollo still returns the contact data. What changes is everything around them: the trigger, the validation, the conditional routing, the CRM write, and the failure handling. You write that once as a Claude Code prompt and the agent runs it every time a new lead arrives.
The honest caveat. If your enrichment workflow is one form, one vendor, one CRM field, build it in Zapier. The complexity overhead of an agent runtime isn't worth it. This pattern earns its keep when you have multiple enrichment sources, validation rules that need interpretation, and downstream decisions that depend on what came back.
The Architecture
Six components, each one boring on its own.
1. Trigger. The thing that wakes the workflow up. A form submit webhook, a CRM list refresh, a scheduled cron at 6 AM. Claude Code doesn't watch for events on its own. You hand it a list to process and it processes the list.
2. Input loader. The agent reads the new leads from your source of truth. Usually a Clay table, a CRM segment, or a CSV dropped into a folder. The MCP server is the wire.
3. Enrichment waterfall. Clay or your direct vendor stack fires the enrichment. Clay's strength is that it already handles the three-vendor fallback (Clearbit fails, try Apollo, Apollo fails, try Cognism) without you writing that logic. See the waterfall architecture guide for the design pattern.
4. Validation layer. The piece most teams skip. Does the email pass syntax and a deliverability check? Does the company domain resolve? Is the title a real title or a parsing artifact ("VP of People & Operations & Sales & HR")? Bad enrichment looks right until it bounces three weeks in.
5. Decision router. Based on the enriched data, the agent decides what happens. ICP fit and verified email goes to the active outbound sequence. ICP fit with no email goes to LinkedIn-only outreach. Out of ICP gets archived. Unverifiable contact gets queued for manual review.
6. CRM write-back. The final step. The enriched and validated row writes back to your CRM with provenance: which vendor returned the email, what date, what confidence score. Without provenance, nobody can debug a bad enrichment two months later.
Step 1: Wire the MCP Servers
Three servers cover most lead enrichment workflows. Clay (or your direct enrichment vendor). Your CRM. Your alerts channel.
For Clay:
claude mcp add --transport http clay https://api.clay.com/mcp --header "Authorization: Bearer YOUR_CLAY_TOKEN"
For HubSpot:
claude mcp add --transport http hubspot https://mcp.hubspot.com/anthropic
For Slack alerts (use the official Slack MCP server):
claude mcp add --transport http slack https://mcp.slack.com/anthropic
If you're going direct to Apollo or another vendor without Clay in the middle, wrap their REST API in a small stdio MCP server. The Anthropic SDK includes a template that takes about 40 lines of Python for a basic wrapper. The benefit of the wrapper: the agent calls every vendor through the same interface, which simplifies the prompt and isolates breakage when one vendor changes its API.
Store the shared servers in a project-scoped .mcp.json so the wiring travels with the repo. Keep tokens in environment variables, never in tracked files.
Step 2: Define the Validation Rules
Validation is what separates a workflow that ships data your team trusts from one that quietly pollutes the CRM. Spell out the rules in the CLAUDE.md, not the prompt, so every run uses the same checks.
A working ruleset for B2B lead enrichment:
Email. Syntactically valid (passes RFC 5322 check). Domain resolves with valid MX records. Not on a known blocklist. Optionally, runs through ZeroBounce or MillionVerifier and comes back as "valid" or "catch-all" (catch-all gets flagged for human review, not auto-routed to outbound). See the deliverability guide for the threshold settings.
Title. Between 3 and 80 characters. Not all caps. Not a date or a number. Contains at least one keyword from a sanity list ("Director", "Manager", "Engineer", "Head", "VP", "C-level", "Founder"). The list is rough, but it catches 95% of parsing artifacts.
Company. Domain resolves. Has a homepage that returns HTTP 200. Employee count falls inside your ICP band.
Phone. Optional. Passes E.164 format. Country code matches the country in the enriched data.
Anything that fails goes to a "needs review" queue, not the active outbound segment. The agent never silently drops a lead. It always writes the row somewhere with a reason for the routing decision.
Step 3: Write the Enrichment Loop Prompt
The prompt structure that holds up across thousands of runs:
Goal. "Enrich and validate the new leads in the Clay table called inbound_queue. Write each enriched row back to the table and route to the correct CRM segment based on the rules in CLAUDE.md."
Steps. Numbered, explicit. Read the new rows. For each row, call the Clay enrichment. Validate the output against the rules. If valid and in ICP, write to the HubSpot active segment. If valid but out of ICP, write to the archive. If invalid, write to the review queue with the reason. Log the decision to a Slack channel.
Stopping conditions. Stop after 200 rows. Stop on any error that affects more than 10% of a batch. Stop if the Clay enrichment endpoint returns rate-limit errors more than five times in a row.
Save the prompt as a project file so every run uses the same instruction. For automation, the headless command is claude -p "process today's inbound queue". While you're still tuning, run it interactively and watch every decision.
Step 4: Add the Guardrails
Three guardrails matter for enrichment workflows.
Batch caps. Cap the run at 200 rows. A bug in the loop that retries forever costs you Clay credits and CRM write quota. Set the cap in the prompt and in a PreToolUse hook so the cap holds even if the model talks itself out of it.
Provenance on every write. Every CRM write includes which vendor returned the data, what timestamp, and what confidence score. Without it, three months from now you can't tell why a contact has the wrong title. The CRM hygiene playbook covers the provenance schema in detail.
Quarantine for ambiguous validation. Catch-all emails, partially-matching domains, and titles that pass the keyword check but look weird go to a review queue, not the active outbound. The cost of routing a junk contact to a real sequence is a complaint and a deliverability hit. The cost of quarantining for human review is 30 seconds of someone's time.
Step 5: Test on 20 Leads, Then Schedule
Same rule as every other agent build. Run the workflow on 20 leads. Open each enriched row by hand. Verify the title is real on LinkedIn. Verify the email actually exists. Verify the company matches. Verify the routing decision matches your written rules.
Plausible-but-wrong is the failure mode that costs you. An email that's syntactically valid but actually belongs to someone else. A title that sounds reasonable but doesn't match the prospect's actual role. A score that came out plausible but the model improvised the weights. Catch those on the first 20, fix the prompt or the validation, rerun. Don't scale until a 20-row sample is clean.
Once the headless command produces clean output on the test batch, schedule it. A cron job on a small VM running every six hours, every hour, or on whatever cadence matches your lead volume. The first week, watch the logs. The second week, just watch the CRM segment sizes. By week three, you should be looking at outcomes (reply rate, meeting rate) rather than the workflow itself.
What Breaks in Production
Three things break repeatedly. Vendor schema drift. Clay changes a column name, the agent doesn't see it, the run completes "successfully" but every row has missing data. Validate the schema at the start of every run.
Rate-limit cascades. One vendor's rate limit triggers retries that pile up and trip the next vendor's rate limit. Add exponential backoff and a hard ceiling on retries per row. The enrichment waterfall guide covers the retry patterns.
CRM duplicate writes. A lead gets enriched twice in the same week, the workflow writes both, the CRM ends up with conflicting records. Use an idempotency key (email plus company domain is usually enough) and either update or skip, never duplicate.
For the broader Claude Code build pattern, see the Claude Code sales agent guide. For the same workflow on OpenAI's stack, see the Codex sales agent walkthrough. For the underlying Clay setup, the Clay enrichment workflow guide covers the table structure.
Authoritative References
For MCP server setup and transports, see Anthropic's Claude Code MCP documentation. For Clay's API and enrichment endpoints, see the Clay documentation.
Frequently Asked Questions
Why use Claude Code for lead enrichment instead of just Clay?
Clay handles the enrichment itself well. Claude Code handles everything around it: the trigger, the validation, the routing, the CRM write, the slack alert, and the error handling. Clay is the engine. Claude Code is the driver. If your enrichment never needs validation, routing, or conditional handoffs, you can stay in Clay alone. The moment the workflow needs judgment between steps, an agent runtime saves you from chaining together five Zapier zaps and a Make scenario you can't debug.
Do I need Clay to build a Claude Code lead enrichment workflow?
No, but you'll usually want it. Clay already runs waterfall enrichment across Clearbit, Apollo, Cognism, FullEnrich, and others with fallback logic. If you skip Clay, you're wiring each vendor MCP server separately and rebuilding the waterfall yourself, which is real work for marginal gain. The teams that build straight on Apollo or FullEnrich without Clay usually have one ICP, one vendor, and want every dollar going to that single source. Most teams keep Clay as the enrichment layer and use Claude Code for what sits around it.
How long does it take to ship a Claude Code enrichment workflow?
An end-to-end build for one ICP, with three vendors, validation, and CRM write-back, takes a GTM Engineer two to four working days. Day one is the MCP wiring and the CLAUDE.md. Day two is the loop and the validation. Day three is the CRM integration and the hooks. Day four is testing on 20 rows and fixing what breaks. Teams that try to ship it in an afternoon ship something brittle that breaks in week two.
What's the cost difference between manual enrichment and a Claude Code workflow at 1,000 leads per month?
Manual enrichment at 1,000 leads per month runs roughly 25 hours of GTM Engineer or SDR time, which is $1,500 to $2,500 in fully-loaded labor. The Claude Code workflow runs about $40 to $80 in Claude API spend per month plus your existing enrichment vendor cost (Clay, Apollo, FullEnrich) which you'd pay either way. So the savings is the labor minus the model spend, generally $1,400 to $2,400 per month at that volume. Higher volumes widen the gap.
Can I run the enrichment workflow on a schedule without sitting at my terminal?
Yes, that's the whole point of shipping it. Once the headless command is stable, schedule a cron job on a small always-on box. The job runs claude -p with your enrichment prompt, processes the new leads since the last run, writes to the CRM, and exits. Pipe the run log to a file for audit. Pipe failures to Slack. You should be looking at the results dashboard, not babysitting the run.
Source: State of GTM Engineering Report 2026 (n=228). Salary data combines survey responses from 228 GTM Engineers across 32 countries with analysis of 3,342 job postings.