Contents
GTM CI/CD is the practice of changing sales and marketing workflows the way software teams change code: in small steps, tested before they go live, reviewed by a person, and logged so any change can be rolled back. Clay set out how its own GTM engineers work this way in a post published on 21 October 2026, after six months of running it inside Clay's sales motion.
The argument is simple. Agents are starting to edit GTM workflows themselves, and an agent making a bad edit to a live play can repeat it across thousands of prospects before anyone notices. Software engineering solved that problem years ago.
What is GTM CI/CD?
CI/CD stands for continuous integration and continuous deployment. In software, it means every change is small, tested and recorded. Clay's post, written by Fadeke Adegbuyi, says GTM teams could not work this way before because "a sales play had no code to version, no test environment, and no logs."
Evan Peters, Clay's Head of Revenue Platform, lists what RevOps needs to change that: version control for the GTM brain, separate staging and production environments, and observability that shows what actually happened.
Each learning loop Clay runs follows the same five steps:
1/ An agent proposes a change based on a previous result.
2/ A person reviews and approves it.
3/ The agent executes the change.
4/ The system records the result.
5/ The next run starts from better evidence.
What did it do for outbound?
Clay gives real numbers. Six months before the post, its SDRs spent about seven minutes drafting each prospect message, moving between Salesforce, an internal rep tool, Claude and a sequencer. A message generator built four months before the post cut that to around five minutes, but reps still rewrote the drafts and nobody could say what was working.
The GTM CI/CD version links every AI draft to the email the rep actually sent, asks reps to give a reason for each edit, groups those edits into hypotheses, and A/B tests a production prompt against an experiment prompt. After a week of testing, an agent proposes changes as pull requests for the growth team to review. Drafting now takes one minute per prospect.
On a rep writing 40 messages a day, that is the difference between 280 minutes of drafting at the start and 40 minutes now. Four hours a day, per rep.
What went wrong first?
This is the most useful part of Clay's post. The first version of the loop made the emails worse. It ranked rep edits by how often they happened, not by their effect, so one rep's specific, high-value change to an opener never became a hypothesis because no other edit looked like it.
Clay says fixing it took three things: writing down what good copy is, giving the loop a memory that carries over week to week, and building a review screen where the growth team could make judgement calls quickly.
The lesson travels well beyond Clay. A loop that learns from frequency will learn the habits of the majority. Someone has to define what good looks like first.
How do self-healing workflows work?
Gunner Park, a forward-deployed GTM engineer at Clay, applies the same framework to any workflow and calls the result "self-healing workflows". An agent reads a workflow's run logs, either nightly or when a rep flags a problem in Slack, then proposes a fix and cites its evidence.
The approval rules scale with risk. A fix affecting one account needs a Slack approval. A fix affecting every run needs a pull request. And only the deployment pipeline can write to the live workflow, so nobody edits it by hand.
The evidence base is real. Clay says one nightly review found 47 of 159 leads, roughly 30%, routed into a segment that did not match their company size.
How can a team apply this without Clay's tooling?
The principles do not depend on any single vendor.
1/ Keep a copy of every workflow before you change it. If you cannot roll back, you cannot experiment safely.
2/ Test on a sample before going live. Run the changed play on a small slice of accounts and compare it with the current version.
3/ Log inputs and outputs for every run. Most GTM failures are found weeks later by a rep. Logs let you find them the same night.
4/ Tie approval to blast radius. Small changes need a quick sign-off. Changes to every run need a proper review.
5/ Write down what good means. Reply rate, meetings booked, correct segment. A loop with no definition of success optimises for the wrong thing.
Does this mean fewer GTM engineers?
Clay argues the opposite. Its post points to an analysis that found GTM engineering job postings grew 205% year on year, and to McKinsey's suggestion that new roles such as agent managers will emerge. It also warns against treating agents as autopilot: agentic GTM, Clay wrote, "likely won't mean asking an agent to 'generate $100M in fresh pipeline, make no mistakes' and walking away."
The work shifts from building every workflow by hand to directing agents and judging what they propose. That judgement still comes from people who have run the plays.
A note on Peach Data
Peach Data builds go-to-market engineering systems for sales and marketing teams: the data foundation, the workflows and the agents behind outbound and inbound. We started as a verified data business, so every build starts with the data layer. peachdata.co.uk
