Most founders who want a cold email engine take one of three paths.

They hire an agency for $8K-$15K a month and hope the outputs map to their business. They hire an SDR ops person and spend six months training them on the stack. Or they spend 3 months personally duct-taping Instantly, Clay, Apollo, and n8n together, learning deliverability the hard way after a domain burns.

There's a fourth path most people don't see yet: feed Claude Code a blueprint and let it build the engine for you.

The catch is that Claude Code needs the blueprint. It needs to know what good looks like: which tools, in what combinations, with what rules, sequenced how. That's what the Cold Email Architecture cheat sheet is for. It's not a reference doc you read once and file away. It's a spec file. You hand it to Claude, and Claude builds the system.

Here's how that build actually works.

Before Claude can build anything, it needs to understand your business. Not generic cold email theory. The specific positioning, offer, and ICP that make your outbound different from anyone else's.

This lives in CLAUDE.md: a project brain file that loads into context every time Claude works on your outbound engine. Mine holds:

The architecture cheat sheet tells Claude what layers exist in cold email. CLAUDE.md tells Claude what those layers mean for my business specifically. Without both, Claude is guessing. With both, it's building against a spec.

Cold email infrastructure lives across 8-10 tools. Instantly for sending. Apollo for contact data. Trigify for signal monitoring. InboxKit for deliverability. LeadMagic for verification. Attio for CRM. Exa for research. n8n for orchestration. Supabase as the canonical data store.

Most teams run these tools by logging into each one, copying data out manually, pasting it into the next tool, and hoping nothing breaks. That's where cold email operations time gets eaten alive.

The way Claude Code runs them: every tool is connected via CLI or MCP server, so Claude has read/write access to the whole stack from one session.

What that looks like in practice:

When every tool speaks to Claude, you stop being the middleman. You describe what you want in plain English; Claude handles the orchestration across the full stack.

This is the part most people miss. An AI assistant that can only read and write text is a toy. An AI assistant that can execute against your production tools is infrastructure.

The single biggest mistake teams make using AI for cold email is letting the same LLM session handle both the mechanical work (enrichment, cleanup, campaign setup) and the creative work (copy, angles, hooks).

The output is always the same. Mechanical tasks get fine. Copy drifts into AI slop. Reply rates stay flat.

I separate the two using Claude skills.

Mechanical skills handle the plumbing. These pull leads from Apollo, enrich with LeadMagic, score against the ICP model, push to Instantly, tag in Attio. They're long, deterministic, and boring. They run on autopilot.

Creative skills handle the copy layer. Before writing a single email, these load the tone of voice file, the template library (12 templates scored against lead temperature and seniority), the case study bank, the snippet library of proven openers and CTAs, and the current campaign briefing.

Module 05 of the architecture calls for 10-15 angles tested in parallel during message discovery. That's a creative job. I have a skill for it that takes the ICP definition and current offer, then outputs 15 distinct angle candidates with hooks. The tone of voice file constrains every output so nothing reads like a template.

None of the mechanical skills can write copy. None of the creative skills touch the sending layer. Keeping them separate is what lets the engine scale without the copy regressing into generic AI output.

Once the context is loaded, the tools are wired, and the skills are in place, Claude runs the full cold email loop end-to-end. Every layer the architecture defines is Claude's job to own and iterate on.

Campaign strategy. Claude reads a goal ("I want 10 meetings with Series B SaaS founders in April"), pulls the ICP definition from CLAUDE.md, checks the offer structure, and proposes a sequence of campaigns that map to the goal. Output: segmentation, angles to test, expected volume per campaign, and the dependency order.

TAM sizing. Claude queries Apollo with the ICP criteria and returns the true addressable count. If the TAM is too small for the reply rate benchmarks to produce the meeting target, Claude flags the gap before the campaign launches. Better to know a campaign can't hit the number before you build it than after.

Signal generation. Claude queries Trigify for LinkedIn post engagers, runs the JD Intent skill against job postings to score companies for buying intent, pulls SEC filings and funding events where relevant. Output: a ranked list of signal-matched accounts with a reason for each.

Copywriting. Claude triggers the creative skill stack. Selects templates based on lead temperature, generates angle variations, pulls proof points from the case study bank, and writes the sequences. QA gates run before anything ships: word count, banned phrases, locked CTAs, em dash count.

Reply generation. When replies come in, Claude classifies them (positive, objection by type, out of office, hard no), drafts peer-voice responses for the positive and objection buckets, and stages them for human review. I approve or edit. I never write from scratch.

Campaign analysis. Every two weeks, Claude pulls campaign performance from Instantly, checks it against the benchmarks in Module 07 of the architecture (reply rate above 1.5%, positive reply rate above 20%, meeting rate above 0.1%), identifies which variants to kill and which to scale, and proposes the next two weeks of iteration.

Six layers. One Claude context. Everything connected.

Everything above is downstream of one file: the Cold Email Architecture cheat sheet. It defines the 9 modules, the rules within each, the sequencing, and the benchmarks. Without it, Claude Code is a smart chatbot. With it, Claude has a spec to build against.

I use the cheat sheet as the seed input for every new client's outbound engine. We load it into their CLAUDE.md, adapt the specifics (their ICP, their offer, their tools, their stack choices), and Claude builds the engine layer by layer. The build compresses dramatically when the architecture is the spec and Claude is the builder instead of a human ops person figuring it out from scratch.

You can do the same. Take the cheat sheet, load it into your own Claude Code project as the architectural reference, and get Claude to build out your own engine against it. It won't replace the judgment calls (your positioning, your ICP, your offer) but it will handle the orchestration, the tool wiring, the skill separation, and the mechanical layers that kill so many in-house attempts.

The cheat sheet covers: the stack and why each tool is in it, the deliverability rules your domains can't survive without, the ICP clarity process, the market mapping layer, the messaging discovery phase, the A/B testing discipline, the three benchmarks that matter (and the one you should ignore), the biweekly review cadence, and the 90-day launch plan.

All of it is free. Access it here: