GTM teams need to migrate their stack to git because the people changing it are no longer only people. Coding agents now propose changes to scoring, routing, segments and outreach faster than anyone can check them by opening five tools. A stack configured by clicking has no diff to review, no preview of what a change moves, and no version to go back to. Git has all three, and every agent already knows how to use it.
This is not a rewrite project. The teams that have done it moved one layer at a time, starting with the logic that breaks most often, and the first move usually takes less than a day. What follows is the case for doing it now, the order that works, and what should stay exactly where it is.
If you want the definition of the practice first, read GTM as Code. This piece is about the move.
The volume of change went up. The review did not. #
For ten years, the rate of change in a GTM stack was limited by the person configuring it. One RevOps lead, a few edits a week, each one made live in a tool’s settings. Nobody reviewed them because there was nothing to review: the change and the deploy were the same click.
That ceiling is gone. We run Cargo’s own go-to-market from a repository, and in the two months since 2026-07-30 it took 675 merged pull requests. 538 of them were opened by agents. Plays, segments, scoring rules, drafted messages, weekly plans: all of it proposed by a machine and approved by a human reading a diff.
Now imagine the same 538 changes landing in a stack with no diff. Each one is a filter someone edited, a threshold someone moved, a prompt someone pasted into a text box. Nothing records what the previous value was. Nothing says which accounts it touched. The first sign that one of them was wrong would be a rep asking why their pipeline dried up, a month after the edit.
Karl Rafidimanana put it well at our GTM Belongs in Git event: a broken payment system fails loudly, and a broken go-to-market workflow keeps running. An agent with a bad scoring rule does not make one mistake. It makes the same one every day. The faster changes arrive, the more a review is worth, and a review needs something to read.
Three costs of staying where you are #
Teams rarely decide to keep a clicked-together stack. They just never schedule the move. Here is what that decision costs, in the order it usually shows up.
You rebuild instead of improving. Cole D’Ambra, who runs growth at Plain, built the company’s account scoring model from scratch five separate times. Its logic was split between files on a laptop and fields in the CRM, so no earlier version existed to compare against or return to. Adding a signal meant starting over, and each restart produced worse results than the one before. A system you cannot diff is a system you can only replace.
You pay for tools that cannot explain themselves. Karl, a GTM engineer at TRA, described a client that cancelled a prioritization product billed at roughly $50,000 a year. The scores were not the problem. The product kept no history of its rules and gave reps no explanation for any account’s rank. When a rep asks “why is this Tier 1?”, “the vendor decided” is not an answer anyone keeps paying for.
Your agents work around your stack instead of in it. Coding agents are fluent in files, branches and pull requests. Point one at a stack that only exists behind a login and it is left clicking through screens built for a person, with nothing to validate against, no way to preview a change, and a workflow that stops working whenever the vendor redesigns a page. The agent is not the bottleneck. The stack is.
What actually moves into the repository #
“Migrate your stack to git” sounds like it means moving everything. It does not. It means moving the parts that make decisions, so every decision has a source you can read.
| Layer | What it is | Why it moves |
|---|---|---|
| Knowledge | ICP, personas, objections, proof points, signals | Agents read it before every action. Plain text, versioned, one claim per file. |
| Decision logic | Scoring, tiering, routing, qualification rules | It breaks most often and costs the most when it does. |
| Plays | The workflows that run on a trigger or a schedule | A play is a standing order. It should deploy and roll back like code. |
| Agents | Prompts, tools, models, and the evals behind them | A prompt change is a behavior change. It deserves a test, not a paste. |
| Receipts | The lists, sends and results each run produced | The memory that lets the next run start from what happened last time. |
What stays out matters just as much.
The CRM stays the process layer. Opportunities, stages, forecasts, and the records reps work from all stay in the system reps already use. TRA runs exactly this split: signals and hosting in Cargo, the ICP and scoring in GitHub, the CRM for process.
The UI stays, and changes job. An interface is still the right place to watch a run, investigate a decision, and approve a change. It stops being the place where logic is authored.
Data stays in a database once files stop scaling. Even at Rippling’s volume, John Kutay keeps the GTM brain in files first, since files come with history and agents read them natively. The time to move data into a warehouse is when so many writers touch it at once that reviewing pull requests slows everyone down. That limit is real, and almost nobody hits it on day one.
The order that works #
Nobody migrates a whole stack in one pull request, and nobody should try. This is the order we have seen hold up, each step small enough to ship in an afternoon.
1. Write down what you know
Start with the knowledge layer: who you sell to, who buys, what they object to, what proves you right. It is markdown. It needs no deploy, no connector, and no engineer. It is also what every later step reads, which is why an agent writing outreach without it sounds like a generic bot.
The fastest start is a template that already has the folders:
npx @cargo-ai/cli@latest project init my-gtm
Open the folder in Claude Code, Cursor or Codex and have the agent fill it in. It asks you questions about the business, writes the answers into the right folders, and waits for you to read them before anything is committed.
2. Move the rule that broke last
Pick the one piece of decision logic that caused the most recent incident. Usually it is scoring or routing. Write it as code, with the thresholds as named values instead of numbers typed into a filter.
This is the step that changes how the team works. Plain’s move took less than a day. The scoring model ended up as a single TypeScript file, guarded by more than 500 tests that run in CI on every change. Nothing about the logic changed, only where it lived. Then something better happened: a weekly job started opening pull requests on its own when a high-intent account was being suppressed, and each one showed its effect across all 55,000 accounts before review: about 200 would move up to tier 3, 86 to tier 2, and 23 to tier 1. Someone on the team still had to approve it.
That preview is the thing a clicked-together stack can never give you. You see the blast radius before the change, not after.
3. Adopt what is already running
You do not have to tear down your live workflows to put them under version control. If they run on Cargo, declare each one in code and bind the declaration to the resource that is already running, so nothing gets recreated:
npx @cargo-ai/cli project import agent:sdr <uuid> # bind a live resource to its code
npx @cargo-ai/cli project plan # preview what would change
npx @cargo-ai/cli project deploy # reconcile it
npx @cargo-ai/cli project rollback # restore the pre-deploy snapshot
From here, a change to a play is a pull request with a plan attached, reviewed the way an infrastructure team reviews theirs. The Cargo CDK page covers the full surface.
4. Make the merge the approval
The last step is the one that makes the migration pay for itself. Wire the repository so that merging a change is what makes it true: merging the play deploys it, merging the fix ships it, and merging a batch of drafted messages is what puts them in front of the people they were written for, with the send logged against the pull request that approved it.
Without it, a yes in a comment is only the start: somebody still has to go and make the change by hand, in whichever tool holds it. After it, the approval and the action are the same button. We describe the full operating model, including the time it caught a message that should never have gone out, in running GTM with coding agents.
Signs your team is ready #
You do not need an engineering team to start. Cole’s own line about the move was that you do not need an engineer to do it. You need one person comfortable letting an agent handle a repository, and a few honest answers to these questions:
- Has a scoring or routing change broken something in the last quarter, and did it take more than a day to find out?
- Could anyone on the team tell you what your Tier 1 definition was three months ago?
- Is part of your revenue logic known only to the person who built it?
- Are agents, yours or a vendor’s, already changing your stack?
- When a rep asks why an account was routed to them, does someone have to go and look?
Two yes answers is enough to justify step one. It costs an afternoon and changes nothing in production.
What the person who owns it needs to learn #
The syntax is the part agents already write. What the owner of a GTM repository needs is a grounding in data design: tables that last, keys that identify one record and only one, and a clear picture of how each system hands off to the next. Both hosts gave that same answer at the event when asked what a non-engineer should learn first.
The discipline also moves up. “Prioritize good accounts” is not a rule a repository can hold. “Route any account above 500 employees that visited pricing twice this week to its named AE within an hour” is. Moving to git does not remove the need for sharp GTM thinking. It shows vague thinking faster, which is the point.
The engine that wins the next few years will not be the one with the most tools. It will be the one where humans define intent, agents write and test the logic, and the repository keeps the memory. That is what your GTM belongs in git means, and the migration is how you get there.
FAQ #
Because changes to the stack now arrive faster than a person can check them by hand, and many of them come from AI agents. Git gives every change a diff to review, a preview of what it affects, a history of who changed what, and a way back. A stack configured through tool settings has none of those.
No. Move one layer at a time: the knowledge files first, then the decision logic that broke most recently, then the plays already running, then wire merges to deploys. Each step is small enough to ship on its own, and the first one changes nothing in production.
No. The CRM stays the process layer: opportunities, stages, forecasts and the records reps work from. What moves into git is the logic that decides which accounts matter, who owns them and what happens next.
Not a team of them. One person comfortable with a repository, or willing to let a coding agent handle it, is enough to start. Knowledge files are plain text, and agents write most of the code. What that person should learn is data architecture, not syntax.
The first step takes an afternoon. Plain moved its account scoring model into a repository in less than a day, with more than 500 tests running on every change. Live workflows on Cargo can be declared in code and bound to the running resource with one import, so they come under version control without being torn down.
When many writers change the same data at once and pull requests become the bottleneck. That is the point to move data into a warehouse or database, while the rules and plays that act on it stay in the repository.
AurelienSept 30, 2026