Can Claude Code send cold emails for me?

Technically an agent can be wired to a sending tool, but I would not do it. Sending is the one step you cannot take back, and it puts your domain reputation and your name on whatever the agent decides. Keep the agent on research, enrichment and drafting, and keep the send button with a person.

Does Claude Code connect to Clay?

Clay's changelog lists Clay in Claude (26 January 2026) and Advanced Search in Clay MCP (7 September 2026), which runs searches over people, company and job data from Claude. It also lists a Clay CLI and a Clay Agent Plugin for coding agents. The changelog does not name Claude Code specifically, so check Clay's docs for the exact setup that applies to you.

What should the agent never be allowed to do?

Send mail, change sequences in your sending tool, delete or overwrite lists, and write into your CRM without review. Deny those in the permission rules rather than relying on a sentence in a prompt, because a rule is enforced and a sentence is a request.

How do I know the setup is working?

Track how many rows the agent proposed against how many you approved at each checkpoint, and how many first lines you rewrote. If you approve nearly everything without reading, the checkpoint has turned into a rubber stamp and needs tightening.

Claude Code for cold outbound, with a human on every send

Yes, Claude Code can do useful work in outbound without ever sending an email. The setup I would use has the agent research and enrich, and a person approving three things: the list, the first lines and the send.

I have not published a benchmark for this, and this post does not claim one. It is a method, with the checkpoints written down.

Why keep the agent away from the send button?

Because sending is the only step you cannot undo. A bad enrichment row takes a few minutes to fix. A bad batch of emails damages domain reputation, which takes weeks to rebuild, and it puts your name in front of real people.

I have sent 5.5M+ emails, and the failures I remember are almost never about writing. They are about the wrong list or the wrong infrastructure going out at speed. An agent that can send makes that failure faster. An agent that can only prepare makes it visible first.

What does the agent do, and what do I do?

Split the work by whether a mistake can be reversed.

Stage	Agent	Human checkpoint
Define the ICP and tiers	Drafts rules from your notes	You approve the rules
Find companies and people	Runs searches, proposes a list	Checkpoint 1: approve the list
Enrich and verify	Fills fields, flags gaps	Spot-check 20 random rows
Score fit and signal	Scores and explains each row	You read the reasons for the top tier
Draft first lines	Writes from table facts only	Checkpoint 2: approve the first lines
Load into the sending tool	Prepares a file	Checkpoint 3: you upload and press send
Handle replies	Sorts and summarises	You answer the interested ones

Three checkpoints, and the agent has no write access to the sending tool at all.

How do I set it up?

Write the rules down once. Put your ICP tiers, banned opening phrases and word limits in a project instruction file (Claude Code reads a CLAUDE.md at the start of a session). My classification approach is in how I classify an ICP, and the first-line rules are in AI first lines that don't sound like AI.
Connect the data source through MCP. Claude Code can connect to tools over the Model Context Protocol. On Clay's side, the changelog lists Clay in Claude (26 January 2026), Advanced Search in Clay MCP (7 September 2026) and Clay Ads in the CLI (5 October 2026), plus a Clay Agent Plugin for coding agents. It does not mention Claude Code by name, so read Clay's docs before assuming a specific install path.
Restrict permissions. Claude Code has permission rules and asks before running commands or editing files by default. Deny anything that touches your sending tool or CRM. Hooks can also run a script before or after an action, which is a good place to log what the agent did.
Give it a working folder, not your accounts. The agent writes CSVs and notes to a folder. Moving a file into the sender is your job.
Run a three-row test first. The same discipline I use in Clay, see how to stop burning Clay credits. Read every output before widening.

What do I check at each checkpoint?

Checkpoint 1, the list. Pull twenty rows at random and read them as a buyer would. Right title, right company type, right size? If more than a handful are wrong, the rules are wrong, not the rows. Check that the count matches what the market can actually supply, as in why your TAM is smaller than your inbox count.

Checkpoint 2, the first lines. Read at least ten, and every line for high-value accounts. Search for banned phrases, raw dates, blank names and any fact that is not in the table. This is the same read-the-outputs routine I use in my own tables, where a raw timestamp once leaked into an opener until I caught it.

Checkpoint 3, the send. Confirm the verified-address filter ran, the daily volume per inbox is within what the infrastructure can take, and the first batch is small. Then you press send.

What should I measure?

Rows proposed against rows approved at checkpoint 1
First lines rewritten by hand, as a share of the batch
Bounce rate on the first batch
Time saved on research, estimated honestly from a before-and-after of one list

If you cannot measure the last one, say so. A claimed time saving with no baseline is just a feeling.

Where this advice stops working

It is slower than letting an agent run end to end, and on a very small list the checkpoints take more attention than the research saved. It also assumes a person who actually reads. If the approvals become automatic, you have the risks of autonomy with an extra step on top.

I have also not tested every agent and model combination, and tool features change quickly. Re-check feature names against the vendor's own docs before you build.

If you are deciding how much of this to hand to an agent in the first place, qualify inbound leads with AI shows the same split on the inbound side, and what is a GTM engineer covers who owns the system. I'm Malik, and the rest of my work is on the about page.