Agentic GTM

Why is Claude Code so cracked for GTM? Do you still need Clay?

It comes down to two things: code + context.

I’ll start with a claim that might sound extreme: you can do almost any knowledge work better with code. Including marketing tasks.

Even creative stuff like writing emails?

Yes. Let me explain why.

Great emails are pipelines

What actually makes a great email from an SDR?

I say this as someone whose job for the last ten years has largely been to write great cold emails for sales orgs — it is far more formulaic than you think.

It’s not actually about writing. There are three steps that have to be done well:

1. Find something specific about the prospect or their company (a signal)
2. Connect the signal to a problem your product solves (a bridge)
3. Express that connection naturally — no tough pitch (voice)

Most AI-written emails suck because they can’t get good signals to start with, so they default to something like “Hey! I saw you are the VP of Engineering at Company X.” or “Hey! I saw you also went to U of T!” Then rant about their product. Then get immediately blocked and say cold email doesn’t work.

With Claude Code, you can run step 1 much more effectively (custom enrichment). You can run step 2 more clearly because you’ve built a powerful context repo over time. You can run step 3 because you have all your best-performing copy and outbound results saved. This is a pipeline — and pipelines are what code was literally invented to build.

Most GTM work is information manipulation

This extends way beyond writing emails.

So much of the work your sales team does is information manipulation — filtering leads, enriching accounts, scoring them, routing, updating the CRM, drafting sequences.

Code is the most powerful way to manipulate information. You don’t want a human toggling between LinkedIn, a company website, a Google search, and a CRM entry anymore — like I did back when I was an SDR — when a script can do this in seconds for thousands of records.

Two years ago, having an army of engineers building custom data pipelines for your GTM team would have been inaccessible for most. This was reserved for VC-backed orgs with massive budgets and an early understanding of growth engineering. Now, a single GTM engineer with Claude Code can direct that same work in plain English.

Code alone isn’t the unlock. Context is.

What if every time you built something, the system remembered your reasoning, your feedback, your ICP, your methodology — and got better? The same way a real hire would?

This is what you can do now. Claude Code works in a local folder on your machine, and that folder becomes a knowledge base that grows with the project. You drop in your closed-won transcripts, your ICP doc, your sales methodology, your campaign history. Claude reads it, structures it, and references it in every future session.

On your first campaign, you have to explain everything to Claude Code — ICP, value prop, signals.

On your second campaign, it knows all of that already.

On your fifth campaign, Claude Code is making suggestions you didn’t think of, because it’s cross-referencing patterns across all your previous work.

This is what compound engineering (shoutout to Kieran Klaassen) looks like in GTM.

This is also what puts Claude Code in a completely different league than ChatGPT. With chat, you do work in a browser, and once you’re done, you’re done. No repeatability for all of your hard work. You shut down your laptop, come back tomorrow, and start from a clean slate again.

Yes, chat has memory, but it is a flat memory system. Imagine having an unlimited filing cabinet organized by project (Claude Code) versus a single sheet of paper that tries to contain every single fact about you.

From workflows to agents

The shift from workflows to agents is the paradigm change.

We love workflows in GTM. We are addicted to tables and databases. Apollo gives you contact information in a table you can export. Clay lets you access any API via a table. Scrapers return CSVs.

We build fancy diagrams about our workflows that incorporate multiple databases, tools, and scrapers together. And then build it all again from scratch when we want to adjust something.

Workflows are pretty. But they don’t know you. They don’t know what you’re trying to accomplish. They execute a fixed sequence regardless of what the data tells them.

Agents, on the other hand, look at an account and decide which enrichment steps to run based on what they already know.

A practical example: you built a Clay workflow targeting AI GTM products. A workflow runs the same eight enrichment steps on every account, whether it’s a 10-person startup or a 10,000-employee enterprise.

An agent recognizes the difference. For the enterprise account, it pulls the 10-K filing, reads the earnings call transcript, and identifies which business unit is most relevant to your product. For the startup, it skips all of that and instead checks their job postings and recent product launches — because that’s where the buying signals actually live.

We also have to be clear about what an agent actually is. Your n8n workflow with an API call is a workflow, not an agent, despite what the lead-gen magnets on LinkedIn will have you believe.

Does this make humans obsolete in GTM?

No. But it does mean that a single GTM engineer has insanely powerful leverage.

GTM orgs are built around tools that force manual work. Most teams are extremely slow once they get big enough — they decide on a campaign idea and take weeks to build their enrichment and launch. Then a few more weeks before iterating on anything.

Today, a single GTM engineer can do work that would have required a team of engineers two years ago. They can build custom data pipelines in days. Tweak their enrichment logic and relaunch that same afternoon.

Lenny’s Podcast had a great episode with Vercel’s COO about what this can look like at an org level.

For anyone with sales and marketing chops who is technical enough to get their hands dirty, this is the most fun GTM has ever been.