Blog

Anatomy of an agent-driven outreach pipeline

A step-by-step walkthrough of an outreach pipeline driven by an agent. Scrape, verify, draft, send, learn, with what each step costs in time, money, and judgment.

· By Anton Eliasson

The pitch for an "AI outreach platform" is now ambient. Every vendor has one. What is missing from most of the marketing material is a clear description of what the actual pipeline looks like end to end, and where the agent is doing useful work versus where the agent is the wrong tool for the job.

This post is that description, written from the inside of Coil. It walks through the five stages of an outreach pipeline (scrape, verify, draft, send, learn), shows the actual CLI calls an agent makes at each stage, and is honest about what each stage costs. If you want the longer treatment of why this stack exists at all, the agent-driven lead gen guide is the place to start. If you want the prescriptive workflow, the Coil methodology page covers it. This post is the engineering view.

Why a pipeline at all

Before the steps, the framing.

Most outbound work in 2026 is still done as a sequence of disconnected actions. A list is built in tool A, copied into tool B, enriched in tool C, loaded into sending tool D, and reported on in tool E. The hand-offs are the expensive part. Every transfer loses context, and the founder running the work is the one carrying that context in their head.

A pipeline is the simple act of putting those five stages behind one consistent surface, so the same context (which prospect, which sequence, which reply) travels from end to end without being re-typed. That is what recipes are in Coil: linear pipelines of named steps, defined once, runnable by either a human in the UI or an agent calling the API. The CLI is the thinnest possible surface over that API, which means anything I show below an agent can do verbatim.

Five stages. One pipeline. Same surface for the human and the agent.

Stage 1: Scrape

The first stage is producing a candidate set of prospects from a hypothesis. The hypothesis is judgment work: who, why, when. Translating the hypothesis into a query against a data source is mechanics.

In Coil, the mechanics live behind coil scrapes create. An agent that is given a hypothesis (say, "founders of seed-stage B2B SaaS companies in North America, 5 to 20 employees") translates it into a scrape:

coil scrapes create \
  --type prospect \
  --titles "Founder,Co-Founder,CEO" \
  --locations "United States,Canada" \
  --sizes "11-50" \
  --fetch-count 200 \
  --max-provider-spend-usd 2.00 \
  --confirm-provider-spend

This returns a scrape ID. Behind the scenes, the platform calls the prospect data source, deduplicates against any existing leads in the org, and stores the candidates. The agent can then check the result without scrolling through a UI:

coil scrapes list --json

What this costs: a few minutes of wall-clock time per scrape (depending on --fetch-count). The judgment cost is in the hypothesis, not in the call. The risk at this stage is the same as any list-building tool: a sloppy hypothesis produces a sloppy list, and no enrichment downstream will fix that.

Stage 2: Verify

Before any message goes out, the candidates need to be verified. Email verification is the obvious one. The less obvious verifications are role accuracy (is the person still at the company?), seniority (is the title actually decision-making in this size of company?), and recency of company activity.

In an agent-driven pipeline, this is where the agent earns its keep. A human will typically skip verification, because verification feels like a chore and the list looks pretty good already. An agent will run verification every time because it is a deterministic step.

coil leads list <scrape-id> --json --limit 200

The list comes back as structured data the agent can scan. It can flag leads with missing emails, leads that bounced previously (Coil tracks this across the org), and leads whose roles look off. The corrections happen in place:

coil leads update <id> --fields '{"status":"excluded","exclusion_reason":"role mismatch"}'

This is the stage where a human-only workflow falls apart. Doing two hundred role checks by hand is tedious, so it does not happen. Doing two hundred role checks via an agent loop is automatic. The list that goes into stage three is materially cleaner than what a busy founder would have hand-curated.

What this costs: compute, mostly. Email verification has a per-record price. Role checking can be done with cheap LLM calls on the cached LinkedIn-style profile data. Across two hundred leads the total is small, in the order of a few dollars per cohort. The human cost is roughly zero, which is the entire point.

Stage 3: Draft

The draft stage is the one where the agent is most often misused. The pitch from most "AI SDR" vendors is that the agent writes the email and you press send. In practice this gives you a reply rate roughly equal to whatever everyone else's agent is producing, because the agent's training data is the average email on the internet.

The version that works is the one where the agent drafts and the founder edits.

Coil's recipe system lets you define this as an explicit step in the pipeline. A recipe is a JSON definition with named steps. You define a recipe once and run it on as many scrapes as you want:

coil recipes create --file recipes/first-touch.json
coil recipes publish <recipe-id>

When the recipe runs, the draft step produces a per-lead draft message and stores it on the lead. The draft is grounded in the lead's actual profile and company data, not made up. The founder reviews drafts in the UI (or pulls them through the API), edits them, and approves the batch.

The discipline here is that the founder still controls the strategic email (opener, close, one core argument). The agent fills in the per-recipient bridge sentences. This is the right division of labour because the agent is good at "given this profile, what is a specific connection to the message?" and the founder is good at "what is the message?".

What this costs: a few cents per draft in LLM tokens, and however much founder time goes into editing. The latter is the load-bearing cost. If you skip the edit, you have shipped average copy at scale, and the market is now full of average copy.

Stage 4: Send

Sending is where the agent has the least to add, because deliverability is mostly an infrastructure and behaviour problem. What the agent can do is be disciplined about send windows, throttling, and reporting.

In Coil, sending is delegated to a downstream automation (today, SmartLead). The recipe pushes approved leads into the campaign:

coil recipes run <recipe-id> --scrape <scrape-id>

The agent's job at this stage is observability. After the send, it pulls run results:

coil recipes list --status published --json

And tracks campaign health over the next few days: bounce rates, reply rates, unsubscribes. The agent does not get to "improve" deliverability by being clever. It gets to notice when deliverability drifts and surface it before a human would have.

What this costs: the per-message cost of the sending infrastructure, plus the warmed-inbox infrastructure cost amortised across all sends. For a founder running a few hundred messages a week, this is roughly fifty to one hundred dollars per month all-in, depending on stack.

Stage 5: Learn

This is the stage everyone skips. It is also the stage that compounds.

The output of a send is a stream of replies, which is structured signal hiding in unstructured text. A human reading thirty replies in a row can see the pattern. A founder reading thirty replies across a week of interruptions will miss it.

An agent reads the batch as a batch:

coil leads list <scrape-id> --filter '[{"field":"status","op":"in","value":["replied"]}]' --json

It groups the replies by sentiment, by objection type, and by the part of the message that triggered them. It produces a summary in plain language ("nine of thirty mentioned pricing in the first sentence of their reply, up from two of thirty last batch") and surfaces it back to the founder. The founder decides whether the hypothesis held, whether the message needs to change, and what the next cohort should look like.

This is where the agent-driven methodology closes the loop. Without the learn step, an outbound program is a black box. With it, every batch is an experiment with a recorded result.

What this costs: small. A few minutes of agent time per batch, a few cents in tokens to do the grouping. The expensive part is the founder actually reading the summary and deciding, which is the part that cannot be automated and should not be.

What this is not

Two warnings.

This is not a sales bot. The agent is doing the mechanical work between the steps. The strategic decisions (who, what, when) are still the founder's. If you set up this pipeline and walk away from it, you have not built an outbound machine; you have built a faster way to be average.

This is not a replacement for the discipline of caring about deliverability. Send infrastructure is its own engineering problem. The agent does not solve it. The agent watches it.

How to start

If you want the surface that the pipeline runs on, the recipes page is the product view. The agent API is the same surface exposed to your own agent. The CLI commands shown above are real and current as of writing; running coil --help against an installed CLI will list them.

The shortest path from where you are now to running this pipeline yourself is:

  • Define a hypothesis you can defend in one sentence.
  • Use coil scrapes create to build the first cohort.
  • Use coil leads list to inspect what came back.
  • Define a recipe with a draft step and a send step.
  • Run the recipe.
  • Read the replies the next week as a batch, not one by one.

That is the whole pipeline. The agent does the mechanics. The founder does the judgment. Both pieces are necessary and neither is sufficient.