Your GTM already runs on hundreds of rules. You probably can’t say why most of them exist.
Your scoring model wants a minimum headcount. Routing sends one segment to one team and everything else to another. Your ICP excludes a vertical. A funding signal counts for six months, a new hire for three. And there is an exception for the four accounts the CEO knows personally.
Someone decided every one of these. Now pick one and ask, six months later:
- Why is this threshold 30% and not 20%?
- Who decided it, and on what evidence?
- What was the rule before?
- What else depends on it?
- What happens if it changes, and can we undo it?
In most revenue teams, nobody can answer all of them. The rules exist. Their history doesn’t.
That is the real weakness of GTM today. Not missing rules: rules with no rationale, no history and no decision tree anyone can inspect.
The first two pieces in this series argued that building GTM is starting to look like building software and compared the code-first and UI-first ways to build it. This one is about what the shift actually buys you. Not governance for its own sake. Compounding.
Rebuilding is asking an agent to solve the same problem again. Improving is making the solution part of the system.
Agents made rebuilding cheap #
A coding agent can build a scoring model, an enrichment flow or a research pipeline in an afternoon. It feels like the problem is solved.
Then look at where the result lives. The context sits in a session that ends tonight. The logic sits in a folder on someone’s laptop. Half the rules sit in CRM settings the agent edited directly. There is no version anyone can point to and say: this is the system, as of today.
So the next session starts from fragments, and it rebuilds.
Cole D’Ambra, head of growth at Plain, lived exactly this. He described his 2025 setup as four Claude Code sessions playing bumper cars in messy folders on his laptop while making permanent changes to the CRM. The first scoring model and the research briefs it produced were genuinely good. Then he asked for one more signal. The agent rewrote everything, and the briefs got worse. He couldn’t see what had changed, so he couldn’t undo it.
By his own estimate, starting over cost him about two months of the past year. It took five rebuilds before he saw the pattern, and his diagnosis is the one this whole piece rests on: nothing was wrong with the logic. It had “no memory and no rules for change.”
Faster rebuilding is still rebuilding.
Rebuilding: a new prompt or session reconstructs the context from fragments, rebuilds the logic and runs, and whatever was learned stays in that session, so the next pass starts from fragments again. Improving: the current version of the system runs, the run produces evidence, a proposed change is evaluated and reviewed, and once merged it becomes the next version, which is where the next pass starts.
A system needs memory before it can improve #
Cole’s fix wasn’t a better prompt. He moved the system into a repository.
Same logic, different home. Scoring became a single TypeScript file, backed by more than 500 automated checks in GitHub Actions. The Cargo workspace came along as code next to it. From then on, every edit arrived as a pull request, whether a person or an agent made it. The move took him less than 24 hours.
Two things changed at once. The GTM logic stopped living only in his head. And every new agent session started building in seconds from the current version, instead of making him fill in the gaps again.
That second effect is the one to notice. An agent is only as durable as the system state it can return to. If that state is a repository, every session starts from the best version so far. If it is a pile of fragments, every session starts from zero, however good the model is.
Software compounds because yesterday’s solution becomes today’s starting point. Most GTM systems don’t, because there is no single current version to start from.
The mechanics of the move are in why GTM teams need to migrate their stack to Git. The point here is narrower: durable state comes first. Nothing improves without it.
Then the system started proposing its own improvements #
This is the part Cole says he didn’t see coming. Durability was what he had planned to talk about. What happened next was that the agents started proposing changes.
Plain runs a weekly job over its pipeline and intent data. It asks two questions. Are we missing high-value accounts, in new pipeline or among high-intent companies the scoring model marked out of market? And did we miss a signal we should have caught before the first call or the first email?
One run flagged a large security company. It was all over Plain’s website: an intent score of 217, 17 sessions, and still a card that read cold. It sat outside the addressable market because of a fit rule from 2025: a company only counted if engineers made up 30% or more of its headcount.
The job didn’t stop at the one account. A model judged whether the classification still made sense. It didn’t. The job then checked whether the rule was hiding other accounts too. It was. So it opened a pull request: for companies above 500 people, lower the engineering-density threshold from 30% to 20%.
Before anyone approved it, the new rule was run against every one of the 55,000 accounts in Plain’s CRM. About 200 would cross from outside the target market into tier 3. Another 86 would move up to tier 2, and 23 up to tier 1.
Then the pull request sat until Cole read the preview and merged it. Overnight, a few hundred accounts recalculated their tier, the security company flipped from cold to hot, and its AE and SDR got the alert.
Don’t read this as “a number changed.” Read the sequence. Running the system produced evidence. The evidence exposed a weak rule. An agent proposed the fix, priced it against every account in the CRM, and a person approved it. The system shipped a new version of itself.
The output of operating the GTM system became an input to changing it. That is the line between a system that automates and a system that improves. The job itself, step by step, is in let an agent propose changes to your scoring model.
Improvement is not faster change. It is change with evidence. #
There is a lazy version of this story: the agent spots something and edits production. That isn’t improvement. It’s a quicker way to make a mistake that nobody will trace back.
The version that works puts every change on the same path:
Every change walks the same path: evidence from operating the system exposes a weak rule; an agent proposes the smallest change that fixes it; the change is evaluated to tell a pattern from a one-off; its impact is previewed account by account before anything ships; the person who owns the rule approves it; it is merged with an author, a date, a reason and a way back; and it becomes the next version every later run uses.
Each step removes a way to be wrong. Evidence means the reason exists before the change does. Evaluation keeps one strange account from rewriting a rule that works for ten thousand others. The preview replaces a debate about the threshold with the list of accounts it moves. The approval puts a name on it. The merge keeps the previous version one revert away.
Self-improving doesn’t mean uncontrolled. The pattern that holds today is simple: the agent proposes, a human approves, the system deploys. As a workflow builds a clean track record, approval can move to exceptions only. That trust is earned one workflow at a time. Nobody’s whole GTM flips to autonomous on a Tuesday.
Rippling runs the same pattern at a very different scale #
Plain’s system was built by its head of growth. Rippling sits at the other end of the scale. John Kutay leads growth GTM engineering there, and described Growth OS at 2,000 internal users a month, roughly a million AI prompts a month and more than a billion rows processed daily.
Two parts of his talk matter here.
Shared memory at the center. Growth OS starts from a shared GTM memory: accounts, contacts, plays and outcomes. The operating context lives in Git, versioned, so coding agents can loop over it and run long tasks against it. Same principle as Plain: the agent doesn’t wake up and reconstruct the company.
Validation before production. A raw signal, a job change or a funding round, doesn’t go straight to sellers. Rippling’s coding agents do what an analyst would: pull the data, compare results, check Salesforce, and resolve the event to the right account and contact. The team runs evals on that work. Only a validated signal ships as a pipeline in Growth OS.
Our reading of that pattern: explore with agents, validate, codify, then run it on repeat. The expensive reasoning happens once. What it proves becomes part of the system, and every later run uses it without solving it again.
The mistake is using agents to solve the same problem over and over. The opportunity is using them to improve the system that solves it from then on.
One boundary keeps this honest. Git is where the definition of the system lives: context, policy, scoring logic, workflows, evals. The operational state, from millions of records to events and run history, lives in CRMs, warehouses and the runtime that executes the workflows. John’s test for when something crosses over is concurrency: keep the GTM brain in files as long as you can, and move it to a database when the number of people writing at once makes review the bottleneck.
From automation to compounding #
Automation runs the same system more times. Self-improvement lets each run change the system the next run uses.
| Automation | Self-improvement | |
|---|---|---|
| What it does | Repeats the workflow | Changes the workflow |
| The current rules | Executes them | Questions them |
| Each run produces | Outputs | Outputs, and evidence |
| Patterns surface | When a human finds the time | Every time the agent reads the evidence |
| Change happens | By hand, once a quarter | Proposed continuously, approved by a person |
| The previous version | Overwritten | Kept, with the reason it changed |
| The next run | Same system | The accepted better version |
Memory isn’t learning, either. A repository full of outputs gives a system a history. It only improves when evidence becomes a proposed change, the change is evaluated and accepted, and the next run uses it.
Automation compounds execution. Self-improvement compounds judgment. Every accepted change is a judgment call the system keeps, so nobody has to make it twice.
What it looks like as one architecture #
Plain and Rippling built this on different stacks, at different scales, and landed on the same split. The repository defines the system. A runtime runs it. Agents operate it. Humans govern it.
That is the split we built Cargo around. Your repository holds the context, the rules and the workflows. Cargo runs them in production, with the connectors, the data and the record of every run. The loop on top has four steps:
- Sense: every signal, reply, run and outcome is recorded.
- Decide: agents read the current version of the system and its context, and choose the next move.
- Act: the production runtime enriches, scores, routes and sends.
- Steer: outcomes become evidence for the next change. Humans govern what matters.
Every accepted change starts the next pass.
The next advantage is how fast your system improves #
Take two companies with the same scoring model today. One revisits it once a quarter, in a meeting. The other finds weak rules every week, proposes fixes, prices them, and ships the ones a person accepts.
A year from now, the gap between them isn’t the model they started with. It’s how many better versions each one shipped.
That rate deserves a name: System Improvement Velocity, how quickly outcomes become better GTM. Once everyone has agents, it is what separates the teams that pull ahead from the ones that stay where they started.
Start with one rule #
Don’t re-architect your GTM this quarter. Pick one consequential rule: an ICP threshold, a scoring weight, a routing policy, a qualification step, an exclusion, a territory. Then ask:
- Is it written down somewhere explicit?
- Do we know why it exists?
- Can we see its history?
- Can an agent read it?
- Can we test an alternative against real accounts?
- Can we preview the impact before it ships?
- Does someone own the approval?
- Can we roll it back?
Every “no” is a place where your system forgets.
The goal isn’t to put your GTM in Git. The goal is a GTM system that gets better without forgetting why it is the way it is.
Stop rebuilding. Start improving.
FAQ #
Because the logic behind them is split across tool settings, documents, local files, agent sessions and people’s memory. With no single current version to start from, every new project or agent session reconstructs the system from fragments, and whatever the previous attempt learned is lost.
Automation runs the current rules again and again. Self-improvement treats each run as evidence about those rules: when results show a rule is wrong, an agent proposes a change, its impact is checked, a person accepts or rejects it, and accepted changes become the version every later run uses.
Not for consequential changes, today. An agent proposes the change with its evidence and an impact preview, and a person approves it before it deploys. Approval moves to exceptions only for workflows that have built a clean track record, one workflow at a time.