The outbound data pipeline we ship in Claude Code

Outbound is a pipeline problem, not a writing problem. Most AI SDR tools framed it as the second and built a single prompt that drafted from a shallow context. That's why most pilots collapsed. The teams that ship pipeline now treat outbound as a five-stage system with a human gate at the end. We build it in Claude Code subagent repos and hand the repo over on day one.

This post covers the five-stage pattern, how each stage gets implemented as a subagent, where the boundaries live, and what the human gate looks like. It's the working blueprint for every outbound build we run.

The five stages

Every outbound build we ship has the same shape.

1. Signal capture. Pull observable events from sources outside the CRM.
2. ICP scoring. Rank accounts against closed-won DNA with rationale.
3. Contact discovery. Find the right human at the scored account.
4. Message drafting. Produce a TVA-grade message with a self-score.
5. Human approval. Rep reviews, edits, sends through their own mailbox.

Each stage is a subagent. Each subagent reads the same root CLAUDE.md. Each one writes structured output to the next stage. The whole pipeline runs nightly and surfaces a small batch of approval-ready drafts every morning. The rep starts their day with a queue, not a blank page.

Stage 1: signal capture

Signal capture watches the public web for events that matter to your ICP. Hiring patterns, funding events, leadership changes, tech stack shifts, regulatory filings, product launches, M&A. We build the signal sources as separate subagents tied to specific sources: Greenhouse boards, SEC filings, BuiltWith deltas, LinkedIn changes, news APIs.

The output of stage one is a normalized signals table. One row per signal, with account name, signal type, signal date, source URL, and a short raw description. The subagent doesn't decide what's important. It captures what's observable and writes it to a shared store the next stage reads.

Signal freshness is the variable that matters most. A signal older than 30 days is mostly dead. A signal older than 90 days is noise. The capture subagent runs nightly and ages out anything older than 60 days unless it's repeated by a fresher event.

Stage 2: ICP scoring

The ICP scoring subagent reads the signals table, joins it against your accounts data, and produces a ranked list with rationale. The rubric lives in CLAUDE.md, derived from closed-won DNA per the ICP discovery process. A score is more than a number. It includes the trigger that earned the score, the value hypothesis that follows from it, and a confidence band.

We documented the working recipe in the ICP scorer recipe post. The short version: the scorer outputs a JSON record per account with score, top three signals, top three reasons, and a kill-or-keep flag. The kill flag prevents low-confidence accounts from feeding the rest of the pipeline.

The output goes to a scored accounts table. Only accounts above a threshold (set per ICP) move to the next stage. Most builds run a threshold that yields 50-150 qualified accounts per week. That number is small on purpose. It is the cap that keeps the human gate functional.

Stage 3: contact discovery

Once an account is scored, the contact discovery subagent finds the right buyer. Title, seniority, function, recent role start, and contact information. We chain Verum and Provyx for clean firmographic and people data, plus a few enrichment vendors for email validation and phone triangulation.

The subagent doesn't just pick the highest title. It picks the buyer the signal points to. If the signal is a VP Sales hire, the buyer is the new VP Sales or the CRO who hired them. If the signal is a Series B funding round, the buyer is the head of GTM or the COO. The trigger informs the buyer, not the org chart.

The output is a contact record with name, title, email, phone (where available), LinkedIn URL, and a short note on why this contact is the right buyer for this trigger. The note is what stage four uses to write the message.

Stage 4: message drafting

Stage four is where most teams overinvest and underdeliver. The drafting subagent reads the signal, the account context, the contact record, and the asset library. It produces a TVA-grade draft with a self-score against the rubric in the TVA framework.

The rubric is three axes, three points each: Specific, Timely, Actionable. The agent self-scores. Below 7 of 9, the draft is regenerated. Three regenerations, the prospect is skipped. The skip behavior is the safety valve that prevents bad drafts from clogging the human queue.

Critically, the drafting subagent doesn't invent the asset. The asset lives in a `/assets/` folder of the repo. A short market benchmark, a one-page tear sheet, a calculator, a curated link to a tool. The agent references the asset that fits the trigger. New assets get added to the folder weekly as the content function ships them.

Output: a draft message with subject line, body, and asset reference. JSON-formatted, ready for the approval queue.

Stage 5: human approval

The human gate is where the pipeline becomes real. Every approved draft posts to a private Slack channel per rep with subject, body, asset, score, and a one-click approve button. The rep reads, edits inline if needed, and approves. Approved drafts get sent through the rep's mailbox via a connected sending tool. Edits the rep makes get logged back into a `/feedback/` folder the team reads weekly to update CLAUDE.md.

Three rules govern the gate.

First, the rep is sending from their own address. Not a shared domain, not a "noreply" mailbox. Personal sender deliverability is meaningfully higher and the relationship trail stays clean if the prospect replies. The rep owns the conversation from message one.

Second, the rep can reject without explanation. A reject button beside the approve button. Rejections are tracked. If a rep rejects more than 20% of drafts for the same reason, the team updates CLAUDE.md and the rejection rate drops. The feedback loop is the whole point.

Third, the queue caps at 30 drafts per rep per day. More than that and the rep can't review properly. The cap forces the upstream stages to be selective, which is what produces forwardable messages. We see a sharp non-linear quality drop above 30 drafts and we hold the cap firmly.

How the stages connect

Each subagent writes JSON to a known location. The next subagent reads it. There's no orchestration framework, no LangChain, no DAG runner. The pipeline is a series of CLI commands chained in a Makefile or shell script.

For most teams we run `claude run signal-capture && claude run icp-score && claude run contact-discovery && claude run draft && claude run gate` on a nightly cron. The whole pipeline takes 20-40 minutes for a 1,000-account database. Output is ready by 6 a.m.

Failure handling is simple. Each subagent writes a status flag at the end of its run. If a stage fails, the pipeline halts and posts to a `#pipeline-status` Slack channel. A human checks the failure. Pipelines that need 99.9% uptime aren't this. Pipelines that need to be readable and fixable by a RevOps lead are.

What the pipeline is not

The pipeline is not a replacement for the human seller. It is the research, qualification, and drafting layer that used to require five BDRs and now requires one senior rep plus a subagent system. We covered that economics in replacing BDR seats with subagents.

The pipeline is also not a turnkey product. It is a working repo with documented subagents, a CLAUDE.md that captures your ICP and voice, an asset library that requires feeding, and a human gate that requires a rep. We ship the build. The team runs it.

What we revisit weekly

The pipeline runs nightly, but the playbook tunes weekly. Every Friday, the team reads three things. The forward-rate report by signal source. The reject reasons from the human gate. The drafts that hit the regeneration cap and got skipped. Each of those three is a learning signal that flows back into CLAUDE.md, the scoring rubric, or the asset library.

The teams that win at this treat the pipeline as a living system. The teams that lose treat it as a deployed product. The build is the easy part. The weekly tuning is the work that produces the forward rate.

For the metric that tells you the pipeline is working, see forward rate. For the CLAUDE.md that gates output, see how to write a CLAUDE.md for your revenue team. For the orchestration patterns that scale beyond one team, see three subagent orchestration patterns. We deploy this pipeline as a fixed-fee engagement and hand off the repo on day one.