In an Agentic GTM Era, Sales Plays Will Ship Like Software

Go-to-market has gone through two eras and is entering a third. 

For decades, selling was manual. We’ve spoken to retired sellers who recorded each sale with a fountain pen or mailed weekly reports to their manager. Over the decades that followed, fax machines gave way to email, and we swapped out print directories with databases. Yet, sellers were still doing much of the work by hand, one call (or record) at a time. Nothing in that stretch of time came close to the level of automation that artificial intelligence has ushered in over the last few years.

In the present era, AI agents have taken over much of the daily work of selling. That includes tasks like reading through an account’s hiring and funding news before a call and drafting an email that sounds like the rep who’s sending it. GTM teams now also run a growing share of their work through the terminal, using tools like Claude Code, Codex, and Grok Bot—calls to Clay’s CLI and API jumped to a million a day within two months of its release. Prompted in plain language, agents are increasingly capable, building complex new workflows in Clay from a short sentence or two. But for now, they mostly wait to be told what to do.

Our vision at Clay is to build a self-learning revenue engine. In the coming era of agentic GTM, agents will increasingly predict the next best action you should take to grow your business and help you take it. Based on a deep well of quantitative data and qualitative context about your business, agents will suggest GTM plays and expand revenue for you.

But before teams can trust agents to act on their own, GTM plays have to start shipping like software. Software engineers use CI/CD, short for continuous integration and continuous deployment, to safely change code. They make changes in small increments, test each one before it goes live, and keep a record they can roll back when something breaks. GTM teams couldn’t work that way before because a sales play had no code to version, no test environment, and no logs. Clay and AI have given them all three, and GTM is now learning from software engineering. Our GTM engineers have spent the past six months bringing CI/CD into Clay’s own sales motion. They call it GTM CI/CD. 

What GTM CI/CD looks like inside Clay

Most GTM teams still ship plays the old way. GTM has mostly run in waterfall: a play gets built once, launched to everyone, and revisited a quarter later. A GTM engineer might edit a live workflow, with no review and no detailed record of what was changed. The first sign of a problem might only be noticed by a sales rep weeks later. Adding an agent to that setup only exacerbates the issue; an agent making a bad edit could rapidly repeat it across thousands of prospects before someone pulls the plug on the play.

According to Evan Peters, our Head of Revenue Platform, RevOps needs similar tools to what developers use to run CI/CD pipelines: version control for the GTM brain, staging and production environments, and observability that shows what actually happened. Clay’s workflows now supply all those pieces. Every run is logged down to each step’s inputs and outputs, a snapshot is taken before every edit so any change can be reverted, and an agent can reach it all through the CLI and API.

Ahead of shipping self-improving agentic capabilities into the product, we’re testing them internally. With those logs, snapshots, and CLI access in place, each learning loop we’re experimenting with follows the same steps: 

• An agent proposes a new change based on a previous result
• A real person reviews and approves it
• The agent executes the change
• The system records the results of the change
• The next run starts from better evidence

An outbound loop that learns from seller feedback 

Six months ago, our SDRs spent about seven minutes drafting a message to a prospect. That includes the time spent bouncing between Salesforce, Terra (our internal rep tool), Claude, and a sequencer. The draft was a “B-” grade email, and the process didn’t surface much in terms of learnings.

Four months ago, our GTM Ops team created a message generator to help solve this. This consists of a Clay Workflow that enriches a contact and generates a four-email sequence when a signal lands on an account. It helped. The message generator cut the process down to around five minutes. But SDRs still tweaked and rewrote the emails, and nobody could quite say what was working (and what wasn’t).

So Rana Banankhah and Luca Prando built the following GTM CI/CD workflow:

1. Every AI-generated message is linked in Snowflake to the email the rep actually sent. This way, the team can see the difference between the two (original versus revised) and the reply rate for each version.
2. Reps explain the reason for each edit in a Slack feedback form, which means our SDRs are labeling data every time they give feedback.
3. An AI agent sorts the edits and feedback into different hypotheses. Each week’s evidence adds to the last, so the team’s confidence in a hypothesis builds over time.
4. Two prompts run in the generator: a production prompt (the stable version) and an experiment prompt (a branch testing specific hypotheses), with each contact randomly routed to one.
5. After a week of A/B testing, an agent proposes changes as pull requests, which the growth team reviews in Terra. 
6. When a change is approved and merged, the Clay CLI pushes the edit to the production workflow. Clay stays the source of truth for the workflow, and Terra keeps the full history of every hypothesis, every fix attempted, and whether it held.

The first version of this loop made the emails worse. It ranked edits by how often they occurred rather than by their impact, so a rep’s specific, high-value change to an opener never became a hypothesis because nothing else looked like it. 

Fixing that meant three things: 

1. Writing down what good copy is
2. Giving the loop a memory that carries over from week to week instead of starting from zero
3. Building a review surface where the growth team could exercise judgment quickly

Drafting now takes one minute per prospect, and Terra is the only tool reps have to touch. Every message goes through this self-learning loop, so the generator improves with each send. 

Workflows that find and fix their own failures

Gunner Park, a forward-deployed GTM engineer at Clay, has taken the same GTM CI/CD framework and applied it to any workflow, not just outbound copy. He calls the result “self-healing workflows.” An agent reads what a workflow did, proposes a fix, and a person approves it before anything changes.

This works because Clay logs every workflow run down to each step's inputs and outputs, and takes a snapshot before every edit so any change can be reverted. An agent can reach all of that through the CLI and API.  Add an agent that reads those records, plus a review step, and you have a loop.

Here’s how this one works:

1. A workflow runs in Clay, and its run data goes to an agent audit, either when a rep flags a problem in Slack or when a nightly reviewer reads the day’s runs.
2. The agent proposes a fix as a change to the prompts or rules and cites its evidence. A nightly review of one lead routing workflow found that 47 of 159 leads had been put in a segment that didn't match their company size.
3. A person reviews the fix, with more scrutiny for bigger changes. A fix that affects one account needs a Slack approval, and a fix that affects every run needs a pull request.
4. Merging the pull request deploys the fix. Only the deployment pipeline can write to Clay, and it publishes a new version of the workflow, so nobody edits the live workflow by hand.

Terra, a rep tool that learns from how reps actually work

Terra is our internal rep tool, and this is the least developed of the three experiments. Today it surfaces signals and drafted actions for reps, who edit anything they don’t agree with before it goes anywhere. Terra doesn’t learn from those edits yet.

The plan is to change that with a“bring your own workflow” sequence:

1. Reps work however they want, in the Terra UI or through a coding agent connected to Terra’s MCP.
2. A logging layer records those interactions: which tools reps call, what they ask for beyond what we give them, where they deviate from the sales process, and where they seem frustrated with it.
3. The system correlates deviations with outcomes. If a rep selling into a bank keeps asking for a specific set of signals and it works, that pattern gets promoted into memory for the next rep selling into a bank.
4. Over time, those traces, along with Gong calls, feed a model that proposes where agents could take over work reps do today. 
5. Those agents go back into Terra, and the results feed the next round.

The first data from this experiment is already flowing, and a few reps are piloting it. The plan is for large parts of the loop to be working internally by the end of the quarter.

From experiments to a self-learning GTM system

Over time, the internal experiments that work will move into Clay for every customer. Because Clay is loaded with context about you, your customers, and every play that succeeded or failed, it understands your TAM better than any one individual could. The future of our product will involve self-learning loops that execute the next play to win your next big account, learning from what worked and what didn’t in the past.

That includes three areas: 

• The next-best message. When a new inbound lead comes in, Clay picks which product, use case, and proof point to reference in the reply, based on what’s most likely to turn that lead into pipeline.
• The next-best play. When a signal fires that says an account should be prioritized, there are many ways to respond: a call, an ad campaign, a webinar invite, a gift in the mail. Clay looks at every play you run and assigns each prospect the one most likely to convert them.
• The next-best strategy. Clay looks across every play you’ve run and every deal you’ve closed, then tells you two things: which plays you should be running but aren’t, and how the customers who actually buy differ from the ICP written in your internal docs.

Agentic GTM likely won’t mean asking an agent to “generate $100M in fresh pipeline, make no mistakes” and walking away. People will always be part of this process. The agentic era also doesn’t mean fewer GTMEs. McKinsey suggests new roles like agent managers will emerge as agents take on more of the sales process, and one analysis found that GTM engineering job postings grew 205% year over year last year. We’ve launched a $1 million scholarship to train the next batch of GTMEs who will unlock revenue for companies and grow the economy as a whole. 

But the work is changing for everyone in go-to-market. A GTM engineer still spends a portion of their week inside the build, refining individual prompts and checking a workflow’s output before it goes live. In the near future, more of that time will go toward directing agents that do the building and providing informed iterations on what they propose. A system that learns also still has to be told what counts as a “good” outcome. For now, that judgment comes from the people who have run the plays and sat across from the customer.