Where Clay Actually Belongs

Hey there,

David here.

Clay comes up on a lot of our calls. Some teams picked it themselves. Others inherited it, with a new hire or a decision made above them.

Either way, the conversation lands on the same point. They have the tool, and they are still working out where it sits.

We had to work that out for ourselves first. We have built 300+ Clay tables for clients. For a long stretch, we had it in the wrong place.

Here is where we landed. It covers where Clay sits in the systems we build today, and how it works alongside Claude.

01When Clay was the centre

We used to run Clay as the centre of everything. Enrichment, scoring, routing and copy generation all lived in tables. Clay could do every one of those jobs, so we let it.

That held up inside a single campaign. The trouble showed up between campaigns.

The centre of a GTM system has to hold context. A table is built to hold rows. Every time a campaign ended, whatever the system had learned ended with it.

We saw it in our own builds. Each client’s list was built in a different table, with different enrichment steps and no shared template. Copy was written in Clay and pushed straight into the sequencer. Later, when we went back to learn from a campaign, the copy was nowhere we could read per lead. We recovered it from the threads that had already gone out.

Clay did each of those jobs well. The gap was that we had asked one layer to be the whole stack.

The test we use now

The test is simple. If a job needs last month’s memory to be done well, it does not belong in a table.

Run each job through that test and the stack sorts itself out.

Clay keeps the work where memory matters least:

• enrichment, filling in what we need to know about each account and contact
• signal layering, stacking the triggers that say an account is worth contacting now
• deep personalisation for high-value accounts, a researched line per lead

The Claude brain sits above Clay and orchestrates. It takes the work that needs memory:

• scoring, which should reason over the ICP as it actually converts
• copy, which should know the copy that worked and the copy that died
• reply handling, where every reply and how it was classified shapes the next one

Supabase sits underneath and holds the record. Leads, replies and blocklists live there. So does every line of copy Claude writes, stored against the lead it went to.

None of it evaporates when a campaign closes. Claude reasons over all of it on the next one, which is how the brain gets better over time.

Enrichment mostly does not need that memory. That is why Clay is still in most of the systems we build.

02How Claude and Clay work together

Here is how the two connect in the systems we build today.

Clay’s own Claude Code plugin is installed alongside our skills. So our GTM engineers work with Clay from the session that already holds the ICP and past campaigns.

Every list build starts with one decision. Claude asks whether to run the enrichment in Claude or hand it to Clay.

If the client’s team already runs a Clay workspace, it goes to Clay. Claude writes the guide for that table. It sets out the enrichments, the AI column that drafts the opening line, and the export into the sequencer.

If they do not, the whole motion stays in Claude and Supabase, from the list to the launch.

Either way, the list starts in Supabase, and the results flow back there once the campaign is live. Clay does its part in the middle.

Clay has a more accurate role in our systems now. Everything around it got better once each layer did the work it is best at.

I am curious where Clay sits in your stack today. Which jobs is it running for you right now?

Hit reply and tell me, and I will say which ones we would keep in Clay.

PS. If you want us to map where Clay should sit in your own GTM system, book a call with us here