Outbound run from Claude Code

Built from the system Tim Scheuer, co-founder at Oxygen, described on GTM Vault SMYS 6 (https://pro.gtmvault.co/episodes/smys-06). Published free by GTM Vault. Numbers below are the operator's own, from the episode; your results will differ.

When to use this

Use this when campaign setup, not sending capacity, is what limits how many outbound tests you run. It fits a team that already has a sequencer and inboxes, works in Claude Code or a similar agent, and wants each campaign to be a cheap hypothesis rather than a multi-hour build. It is strongest against a dense, over-targeted prospect pool where coverage and personalization decide who gets a reply.

The system on the record

Oxygen sells a CLI and MCP for go-to-market so that Claude Code can orchestrate the whole GTM stack and create a campaign from natural language (SMYS 6, 0:00). Tim demoed a campaign aimed at Y Combinator founders, a pool he describes as valuable and hard to stand out in (SMYS 6, 1:03). The build ran as a sequence of prompts:

1. Scrape. He told Claude Code to scrape the YC directory. It returned over 1,900 SaaS founders from recent batches, with batch, name and LinkedIn profile (SMYS 6, 1:03).
2. Enrich. He asked Claude Code to enrich emails with waterfall enrichment, and the agent built the waterfall table itself: multiple data vendors called in turn, so a contact one vendor misses can be found by the next. Email verification ran on top (SMYS 6, 2:07). He named Apollo, LeadMagic, Prospeo and BetterContact among the vendors in the waterfall (SMYS 6, 4:55).
3. Personalize. He created an AI variable that researches each prospect and writes a line referencing that prospect's ideal client profile, for use inside the email (SMYS 6, 2:07).
4. Launch. Claude Code pushed the leads into Instantly, the sequencer (SMYS 6, 3:10).
5. Split test the copy. Two angles ran from the start. The winning shape referenced the YC batch, asked whether the ICP line was right (in the demo, whether the prospect was targeting space manufacturers), asked whether they use Claude Code, and offered a Claude Code repo with pre-built integrations and skills in exchange for a thumbs-up reply (SMYS 6, 3:10 and 4:13).

Behind this small campaign sits a larger sending layer: over 220 inboxes from Zapmail, split 50% Google and 50% Microsoft, which gives around 100,000 cold emails a month of capacity used to run many split tests in parallel (SMYS 6, 5:56). Tim ties the test volume directly to build speed: because Claude Code streamlines campaign creation, the team can run a lot of split tests (SMYS 6, 4:55). His view of the next 12 to 18 months is that "the people who will stand out will test much more" (SMYS 6, 10:20).

The result

1. Campaign setup went from three to five hours in Clay, in his earlier GTM engineering service company, to three to four prompt exchanges costing around 40 minutes per end-to-end campaign (SMYS 6, 6:38).
2. Over 180 emails sent to the YC list at the time of recording, with eight positive sales opportunities generated (SMYS 6, 3:10).
3. Average reply rates across campaigns between 1% and 5% (SMYS 6, 7:40).
4. Over 220 inboxes and around 100,000 cold emails a month of sending capacity (SMYS 6, 5:56).

Run it on your company

1. Ask once, in one message, for: the product and the one-line value proposition; the target pool and where it lives (a directory, a marketplace, a list URL, a CSV); the trait that makes that pool relevant (in Tim's case, heavy Claude Code use); the low-friction offer you can give away for a one-word reply; the enrichment vendors and API keys available; the sequencer; current inbox count and daily send limit per inbox; and how many campaigns the team ships per week today.
2. Write the scrape prompt. Produce a Claude Code prompt that names the source, the filters (segment, batch or cohort, recency) and the output columns: company, first name, last name, LinkedIn URL, website, cohort field, one-line company description. Output: a fenced prompt block plus the target CSV schema.
3. Write the waterfall spec. Order the user's vendors cheapest or highest-hit-rate first, specify that each vendor only runs on rows the previous one left empty, add a verification step, and add a provenance column recording which vendor found each email. Output: a table with columns Order, Vendor, Input fields, Runs when, Output column, plus the Claude Code prompt that builds it.
4. Write the AI variable. Draft the research instruction that reads each prospect's site and returns one short, checkable claim about who they sell to, phrased so it can be posed as a question. Include a fallback value when confidence is low, and a 10-row spot check the user reviews before launch. Output: the variable prompt and the spot-check table.
5. Write two angles. Angle A follows Tim's shape: cohort reference, ICP question built from the variable, relevance question, thumbs-up offer. Angle B changes exactly one element (the offer, the relevance question, or the opener) so the test answers one question. Output: both emails with merge fields marked, and a one-line hypothesis per angle.
6. Write the launch prompt. Produce the Claude Code prompt that pushes verified, personalized rows into the sequencer, splits them evenly across the two angles, and excludes rows with no verified email or a fallback variable. Output: a fenced prompt block.
7. Build the test log. Size each test to the user's inbox capacity, and set a review date and a kill or scale rule before sending. Output: a table with columns Campaign, Hypothesis, Angle, Sent, Replies, Positive opportunities, Decision, Next test.
8. Close with the capacity math: campaigns per week at the current build time versus at roughly 40 minutes, and whether inboxes or ideas become the new limit.

Tools on the record

1. Claude Code: executes scrape, enrich, personalise and launch from prompts.
2. Apollo: first vendor in the email waterfall.
3. Lead Magic: second vendor in the email waterfall.
4. Prospeo: third vendor in the email waterfall.
5. BetterContact: final vendor in the email waterfall.
6. Instantly: email sending and sequencing.
7. Zapmail: inbox provisioning and email infrastructure.
8. Clay: campaign build layer, later replaced by CLI orchestration.

Any tool doing the same job works; the method is the point. Full stack by layer: https://pro.gtmvault.co/stack/operator/tim-scheuer

Where it breaks

1. Saturation. Tim expects the barrier to launching campaigns to keep falling, which means more saturation and a harder time standing out (SMYS 6, 9:33). A faster build does not fix a weak angle.
2. Sending capacity. The method assumes enough healthy inboxes to run several tests at once; Oxygen runs over 220 for that reason (SMYS 6, 5:56). With a handful of inboxes, test count stays low no matter how fast the build is.
3. A shared raw list. Everyone targeting a public directory has the same scrape. The edge comes from coverage and the personalization variable, so skipping the waterfall or the spot check removes the advantage.
4. No hypothesis discipline. Tim describes the new job as forming hypotheses and orchestrating agents, not stitching tools (SMYS 6, 10:20). Angles that change several things at once produce results nobody can act on.
5. Replies are not the goal. Tim separates reply rate from positive replies and whether they convert into deals (SMYS 6, 7:40). Log positive opportunities, not raw replies.