How a Clay Assignment Turned Into a Team Brain

So there I was, stuck on a Clay feature I did not get.

I had an assignment at Clay's AlphaForge to learn Audiences. I read the docs. I built a couple. I still could not tell you why I would bother.

They told me I had to do it, so I went and learned it.

Everything below came out of that.

The project I was already working on

At the same time I was building something where the fact that qualifies a prospect only lives on government websites. Hundreds of them. All a little different, plenty behind CAPTCHAs.

Claude Code is Anthropic's coding tool that runs in your terminal. It reads files, writes code, runs the code, then looks at what came back. It wrote every scraper on that project.

The scrapers pushed what they found into Clay over a webhook. Clay is where you put the thing you want to stop thinking about, because it runs on a schedule with nobody in the room.

That worked, and that was the whole of my thinking at the time. Scrape, push, done.

Build one scraper per vendor, not one per website

Hundreds of government websites sounds like hundreds of scrapers. It is not, and I would not have found that on my own.

Those sites are really a few dozen software vendors with a lot of customers each. Two places that bought the same records software end up with roughly the same website.

So you write one scraper per vendor. Claude Code found repeatable ways to tell which vendor a site runs on, then tested that vendor's other customers. One vendor covered 33 sites at once.

Coverage went from 31 sites to 205 in about five weeks. 159 of those verified working.

Somebody grinding the list by hand would have got maybe a dozen.

Then Audiences connected to Salesforce

An Audience in Clay is a saved segment that selects live. Not an export that goes stale the second you download it.

What I missed for weeks is how much it can do with a CRM. We connected Audiences to Salesforce, then put workflows and enrichments on top of that. Their stuff just keeps running.

Two things came out of that, and I am still excited about both.

Contact coverage. Make sure every company has enough contacts on it. You fill in layers. Internet data first, then people data, then a paid data vendor, then AI for the gaps. Cheap before expensive, and you count what you already have before you buy anything.

Job changes. If somebody leaves for a new company, check whether that new company is a potential customer. That person is already warm, and their new employer might be somebody you want to talk to.

So which tool does which job?

Clay keeps the machine running. Once something is solid you leave it in Clay and it keeps working, unattended.

Claude Code helps you build and explore, and lets reps try things nobody has tried yet. It goes past the limits of Clay too, because it can read the open internet, scrape, and write a Python file and run it on your computer. Clay is not going to write you a Python file. Claude Code can stand up a server or an n8n instance if the job needs one.

Salesforce is the system of record. Everything lands back in the tool the reps already live in.

That sounds boring and it is meant to. Nobody learns a new screen.

The real unlock is that a shared repo becomes a team brain

This is the part I would keep if you made me delete the rest.

Point Claude Code at a shared GitHub repo, then teach it to commit as often as people are working. It commits constantly instead of once at the end.

Claude Code keeps the brain up to date. Somebody changes something and everybody gets it.

So as soon as one person figures out a scrape, everyone has it. As soon as one person tries a different approach, everyone has that too. No deploy. No handover meeting.

I did not build an app for this project. I built a repo that the salespeople open in Claude Code. Every capability inside is a plain English skill, so you ask for what you want instead of remembering a command. A hook runs git pull when a session starts, so nobody has to think about being current.

Onboarding is one sentence. Open this repo in Claude Code and say "set up this repo for me."

Two non-technical salespeople became direct committers in about five weeks. 85 of 256 commits are theirs.

I did not expect that. It is the number I would point at if you asked me whether this works.

The rule that makes the brain worth trusting

A shared brain is only useful if what is in it is true.

One rule in the repo. A site can only be marked tested_working if a person ran it and watched real data come back in that same session. It is the strictest of the six values we use for how sure you are.

An audit later found 100% of the tested_working rows had a real file sitting behind them.

Non-technical people can trust the output because the words refuse to lie to them.

What I got wrong: it failed quietly

A duplicate check had a file path hardcoded from one person's laptop. On anybody else's machine, every lookup failed and reported every record as brand new.

It did not crash. It just cheerfully said "all new" forever, and nobody noticed for a while.

The fix was to make it fail loudly. Exit with an error, print the install instructions, refuse to continue.

A loud crash costs you an afternoon. A quiet pass costs you a quarter of bad data you believed.

What I am still not sure about

Whether the shared repo holds up with 10 people instead of 3. Two salespeople committing is great. Ten might just be a merge conflict with extra steps.

Where the line sits between Claude Code and Clay. Right now I draw it at "does this need to run unattended," and I have moved that line twice already.

And I still think Audiences is harder to understand than it should be. I only got there because somebody made me sit with it.

If you have run a shared repo with a sales team like this, I would like to hear how it went.