How to Build an AI GTM Brain using Claude Code

When a team says they want AI for growth, they usually mean a faster send. An agent that fires the same template at a longer list, day and night.

That is the cheap half of the job, and it stopped working a while ago. The hard half is the judgment around the send: which company to contact, why this week, and what to say that proves you noticed them. A bigger list does nothing for that.

A GTM brain is the system that makes that call for you, every day, without you in the loop. It has five parts, and they run as one loop:

• Sense. Watch the market for the accounts that just moved.

• Remember. Keep everything you learn about each one.

• Judge. Decide who is worth a message, and why now.

• Act. Write the opener from the real trigger.

• Learn. Track what comes back, and improve next week.

Get those five right and sending becomes the easy part.

One idea sits under the whole build: people get a UX, software gets an API, an agent gets a command line. You run this one from the command line on a schedule, and the six steps below build it, each with the prompt I paste into Claude Code.

Step 1. The contract

Write the boundary first, before any agent code.

This is the piece that saves you the day you swap tools. Your code should never hardcode the name of your intent vendor or your email tool. It needs two shapes and nothing else: a signal coming in, and a message going out. Open Claude Code in an empty folder and give it this:

What good looks like. Two small files you can read in a minute, and a loop that runs end to end on fake data. You see a signal go in and a draft come out before you pay for a single integration.

Where it breaks. The shortcut that bites you is letting the code call apollo_search or instantly_send directly. Do that and every part is welded to one vendor, so a tool swap means rewriting all five. Keep the two shapes in front and a swap costs one new adapter.

Step 2. Sense the market

Start from movement. Something changed at a company, and that change is the reason to reach out.

Four kinds of movement carry the weight. Ten years on the marketplace taught me to watch these and let the rest go:

• Job. A role opens, gets reposted, or someone lands in a budget-owning seat.

• Social. A company engages a competitor, or posts about the problem you solve.

• Company. A launch, an expansion, a change in the stack.

• Funding. A round or acquisition that drops fresh budget with a mandate.

Most teams watch one of these and ignore the rest. Inside Sortlist the coverage comes from Signals, our own intent tool, but the principle holds whether you buy it or scrape it yourself.

This part is small. Build it in one pass:

What good looks like. A run that prints “sensed 11 signals across 7 accounts,” with the company that has both a funding round and a new role landing as one hot, clustered account.

Where it breaks. Sensing everything and ranking nothing. Dump raw signals downstream and you end up treating a lone like from a tourist the same as a funding round at a perfect-fit account. Cluster at the door instead of pushing the mess onto the judge.

Step 3. Remember every account

This is the piece most tools skip, and it is why they end up as a mail merge with a prompt on top.

Keep one record per company: every signal you saw, every message you sent, every reply, every outcome. A third funding round means something completely different once you know you already emailed them twice and got silence. Without that history, you treat a warm account exactly like a cold one.

This is the part to get right, so spec it fully:

What good looks like. You ask the store for any account and get its whole story back in one call: what moved, what you sent, what came back. It never reaches out twice the same way.

Where it breaks. Most teams skip this and ship without it. Then they judge the system on its cold-start output, decide it is generic, and switch it off in week three, one week before the history would have made it sharp. Build this part first. The other four lean on it.

Step 4. Judge who and why now

This is where Claude does the work, and where the system stops being a script.

The judge reads the new signal, pulls the account’s full history from memory, takes in your definition of a good customer, and decides three things:

• is this account worth a message right now,

• why,

• and which play to run.

This is the part a competitor cannot copy, which is why it is worth building yourself.

The prompt names the model, the temperature, the fallback, and where the system prompt lives:

What good looks like. The hot account scores high with a why_now you could paste straight into the email. The lukewarm ones come back as skip, with a reason. A system that says no to three accounts in four beats one that mails all four.

Where it breaks. Scoring a signal without the memory. On its own, a fresh signal cannot tell an account you have chased twice from one you have never touched, so the model repeats the same opener and you read as a stalker. Without the history, the score is just a guess.

Step 5. Act on the trigger

It writes only after the judge has decided who and why.

The rule for this part is simple: quote the trigger back. “Saw you opened a Head of RevOps role, second ops hire this quarter.” Never “Hi {{firstName}}”. If the message could have gone out unchanged last month, you skipped the trigger.

Build this part the same way, with delivery defaulting to a dry run:

What good looks like. A draft you would forward as is, opening on something true about the account this week. Run it in dry-run and read ten in a row before one ever leaves the building.

Where it breaks. Wiring delivery live before you have read the output. A system that sends on its own will mail one confident, wrong opener to your whole list before a human sees it. Keep dry-run the default; make –live a decision.

Step 6. Learn from what comes back

An agent that never learns is just a faster script. This last part is what keeps it from staying one.

Feed every outcome back into memory and let it grade its own plays. Signals that keep booking meetings get more weight. Copy that keeps failing gets cut. Test, score, keep or kill. This is why it gets better week over week, without you tuning it by hand.

This part is small too:

Then wire the five parts into one command:

Now a single line of cron runs the whole thing daily. If you already run a fleet on an agent runtime, drop it in there as a skill instead.

What good looks like. Month one, it weights the buckets the way you guessed. Month three, it weights them the way your market actually behaves, and the shortlist is shorter, sharper, and ordered by what converts.

Where it breaks. Logging sends but never outcomes. With no result data the weights never move and you have bought an expensive scheduler. Wire the reply and meeting data back in from day one, by hand if you have to.

The two prompts

Every prompt so far builds a part once, then you set it aside. These two are different: the system uses them on every account, every run. The judgment and the voice live here, so these are the ones to keep and tune.

The judge runs on this:

And the drafting step runs on this:

Both ship in the repo as editable files, and they are what you will tune most against your own market.

What you get

With the five wired together, it runs on a schedule and does this on its own:

• sweeps the market,

• scores the accounts that moved and drops the rest,

• drafts the few worth a message,

• posts a ranked shortlist to Slack, a reason next to each name.

Two minutes: approve, edit, or kill. No list to build, no subject lines to guess, no Monday meeting about who to call.

I run a fleet on this shape across Sortlist for about $400 a month in tokens. We had five hires planned this year and cancelled them, because the work runs on the token budget now. The growth brain is the one I would build first. It pays for itself the first time it books a meeting you would have missed.

Start with two

You do not need all five. Build memory first, then the judge on top of it.

Point them at the stub data, run it dry for a week to trust the loop, then wire in one real signal source. You will get a ranked list of accounts worth a message, each with the reason it made the cut, pulled from signals you were already ignoring. That is the part worth paying for.

I packaged a clean version of the whole thing: the five parts, both adapters, the config, the build prompt for every step, the two prompts above, and the cron to run it. A small skeleton you can clone and bend to your own market. Comment BRAIN and I will send it.