Why your GTM belongs in Git

Ask someone on your team a simple question: what happens, step by step, when a high-intent US enterprise account fills in the demo form?

Then watch where they go to answer it.

The ICP is in a Notion page. The fit score is a formula in Salesforce. Enrichment runs in a Clay table. Routing lives in a routing tool, except for named accounts, which live in a spreadsheet. The rule that partner accounts never go to an AE was agreed in a Slack thread in March. The prompt that drafts the first email is on someone’s laptop.

Six tabs and one thread later, you have most of the answer. Not all of it.

Here’s the actual problem, and it isn’t a missing system. Your GTM already has source code: the logic that decides who is ICP, what makes an account Tier 1, which signals count and for how long, who owns which territory, and which contacts are never emailed. Someone wrote all of it. It’s just written in six places, in six formats, and partly in people’s heads.

There is a system. Nobody can read the whole thing.

Putting your GTM in Git means giving the definition of your go-to-market system one explicit, versioned home: the context, policies, logic, workflows and agent instructions that decide how it behaves, in a repository that humans and agents both read, where every change can be reviewed, tested and reversed. It doesn’t mean storing your customer data in Git. And it doesn’t mean your GTM team starts writing code.

The reason isn’t engineering taste. Agents are becoming operators of the revenue system, and an agent can only operate your GTM reliably if your GTM is something it can read.

Earlier pieces in this series covered why building GTM looks like building software, the code-first vs. UI-first choice, and how a versioned system improves instead of being rebuilt. This one takes your GTM belongs in Git literally: what goes in the repository, what stays out, and why agents make it matter now.

What does it mean to keep your GTM in Git? #

Start with a distinction most stacks blur. A GTM system holds two kinds of truth:

• What the system knows about the world: accounts, contacts, website visits, product usage, emails sent, meetings booked, runs executed.
• How the system should behave: who counts as ICP, how an account is scored, which signal triggers what, who owns which accounts, what an agent may and may not do.

The first changes every second. The second changes when someone makes a decision.

The repository owns the second kind, plus the durable business knowledge needed to interpret the first: personas, objections, proof, competitors. It is the source of truth for how your GTM works, not for everything your GTM touches.

A working GTM repository answers five questions. Here is how Manifest, the open-source template extracted from the repository Cargo’s own GTM team runs on, lays them out:

• Direction: where are we going, and what matters now? plan/ holds the goal, the strategy and the outcomes that must become true. initiatives/ holds the bounded efforts in flight. cadence/ holds this week’s plan and the daily log.
• Knowledge: what does the business know? context/ holds the ICP, personas, objections, proof, competitors, signals and motions, one claim per file.
• Execution: what actually runs? infra/ declares the connectors, data models, segments, tools, plays and agents in production. Skills hold the procedures agents follow.
• Guardrails: how do we know a change is acceptable? evals/ holds the test cases that catch a prompt change making an agent worse, next to the checks that run on every pull request.
• Evidence: what happened? outputs/ holds dated, append-only receipts of every list built and campaign shipped, with its result.

At the root, AGENTS.md tells any agent that opens the repository what to read before it acts.

Two rules in that template carry more weight than the folder names.

Nothing depends on outputs. Evidence is memory, not knowledge. A campaign result in outputs/ changes nothing until its conclusion moves into context/ or infra/ through a reviewed change. Recording what happened isn’t learning. Learning is evidence changing the next version.

Claims carry a confidence level. A proof point or a signal starts as a hypothesis and earns “validated” on its second independent occurrence. Outreach may only cite validated knowledge, and a linter fails the pull request otherwise. That is a business rule, don’t claim what you can’t back, turned into something a machine enforces.

What belongs in Git, and what doesn’t? #

The test is simple. If something describes how the system should behave, changes when someone decides, and benefits from review, it belongs in Git. If it describes the world, changes every time something happens, and has many writers, it belongs in a data system.

Git defines the system. Databases, warehouses, CRMs and runtimes hold its operational state.

John Kutay, who runs growth GTM engineering at Rippling, drew the same line at our GTM Belongs in Git event. His rule is to start in files and stay there as long as you can, because “everything’s in files. It’s easy to read. It’s consumable by agents.” The move to a database or warehouse comes with concurrency: when so many people write at once that pull requests become the bottleneck. That’s from a team whose Growth OS processes more than a billion rows a day. What lives in Git is the operating context. The rows live where rows belong.

Why is code a better operating surface for agents? #

Natural language is a great interface for humans. Code is a better operating surface for agents.

That doesn’t mean GTM people become programmers. The human states the intent:

Route high-intent US enterprise accounts to the right AE, unless they’re already in an active opportunity.

Through a UI, the agent goes Settings → Routing → Advanced rules → Conditions → Exceptions → Save. Agents can do that. But an agent that operates only through product UIs inherits their boundaries: it can take the actions the screens expose, and it can’t see what they hide.

Against a repository, the same agent works on the policy itself. It reads the routing rules and the territory map they depend on. It finds that “high intent” is already defined in the scoring logic and reuses it instead of inventing a second definition. It writes the smallest change, runs the tests, replays last month’s inbound to show which accounts would land with a different owner, and opens a pull request for a person to approve. If the change misbehaves later, reverting it is one command.

  // routing/policy.ts (simplified)
  export function route(account: Account): Owner {
+   // Accounts in an active opportunity stay with the opportunity owner.
+   if (account.openOpportunity) return account.openOpportunity.owner;
    if (isUsEnterprise(account) && isHighIntent(account)) {
      return territories.aeFor(account);
    }
    return queues.inbound;
  }

A UI exposes the paths the vendor anticipated. Code exposes the system itself.

If agents become operators, they need an operating surface designed for machines, not only an interface designed for people. For the definition of a GTM system, versioned files and code are far less constrained than any product’s settings screens. John’s version on stage was shorter: “coding agents are the best agents.”

Agents also raise the stakes on documentation. Humans survive an undocumented system: they ask a colleague, search Slack, remember the exception. An agent starts every task cold, and before it acts it needs answers:

• What are we trying to achieve, and what matters this week?
• Who is our ICP, and what do we already know about this account?
• Which rules apply here, and which policies constrain this action?
• What is already built, and what happened the last time we ran this?
• What can I change, what needs review, and how do I test it?

In a repository, each of those questions has a file. In a fragmented stack, each one is a Slack message the agent can’t send.

Repo-first is not an engineering aesthetic. It is an agent architecture. The point of putting GTM in Git isn’t to make GTM people write code. It’s to give agents a system they can read, reason about and safely change.

Agents judge. Code controls. #

“GTM in code” doesn’t mean putting the whole company inside one giant prompt. A system that holds up separates two kinds of work.

Agentic judgment is for questions that need interpretation:

• Is this company really ICP, despite incomplete data?
• What changed at this account since last month?
• Which objection is this prospect actually raising?
• What is the best next action, given everything we know?

Deterministic logic is for what must hold every time:

• A contact who opted out is never emailed.
• A score above the threshold always gets the same tier.
• An account never has two owners.
• A failed API call is retried by policy, within the rate limit.
• An accepted outcome always reaches the right downstream system.

In practice, the two sit next to each other:

// Judgment: an agent reads the evidence and decides. (simplified)
const fit = await assessFit(account, context.icp);

// Control: code enforces what must always be true.
if (contact.optedOut) return skip("opted out");
if (account.owner) return keep(account.owner);
return assignTier(fit.score, policy.tierThresholds);

A prompt that says “never email someone who opted out” is a request. A line of code that skips them is a guarantee.

Use agents where judgment creates value. Use code where predictability matters. Agents reason inside the system. Code draws its edges. The repository is where both are written down, side by side, so a reviewer can see which is which.

What does a repository remember that your tools forget? #

In most GTM stacks, change history disappears. Someone opens a workflow, edits a condition, clicks Save. The system now behaves differently, and the previous version of your operating model is gone.

In a repository, every change leaves history behind without anyone deciding to write it. You can ask of any rule:

• Why does it exist, who introduced it, and when?
• What did it replace, and what changed with it?
• Which tests must it pass, and can we revert it?
• Which version was running when a given outcome happened?

The history of your GTM becomes part of the GTM.

That matters more with agents than without them. Picture an agent tidying up the routing policy. It finds partner accounts going to one person instead of the territory owner, and to a model hunting for inconsistencies, that looks like a bug. In a settings screen, the agent has no way to know otherwise. In a repository, the commit that added the rule says why: partner relationships stay with the partner team. The agent reads that before it proposes anything. History is context too.

And when every outcome can be tied to the version of the rules that produced it, “the new scoring isn’t working” stops being an opinion and becomes a question with an answer. GTM as Code covers tracing a decision back to its rule.

How does a GTM change become a production change? #

Today, most GTM changes take one path: edit → save → production.

A repository gives them a different one: propose → diff → evaluate → review → merge → deploy → observe.

Plain shows what that looks like. An agent proposed loosening an engineering-density rule in Plain’s scoring policy. The new rule was scored against roughly 55,000 accounts first, and the preview listed which ones would change tier. Only then did a person approve it. The full job is in let an agent propose changes to your scoring model.

The interesting part isn’t the threshold. A GTM decision became a production change with provenance: a proposal, a measured impact, an approver and a way back.

Is the repository the runtime? #

No. This is where “GTM in Git” gets oversold.

A repository doesn’t run schedules, host agents, hold millions of records, store credentials, rate-limit APIs, retry failures, manage queues, deliver email, run integrations, monitor production or alert anyone when something breaks. It defines the system. Something still has to run it.

That’s the job we built Cargo for. Your repository declares the context, policies, workflows and agents. Cargo connects them to your CRM and data providers, holds the data models, runs the workflows and agents in production with credentials, retries and rate limits handled, sends from managed mailboxes, and traces every run, with alerts when something fails.

The repo defines it. Cargo runs it. Agents operate it. Humans govern it.

Once a system is explicit, versioned, testable and observable, the operating loop becomes possible: Sense → Decide → Act → Steer. Git is one of the structural reasons an accepted improvement becomes the next version of the system, instead of a good answer that disappears with the chat session.

Where to start: one rule, written down completely #

You don’t need a migration plan to start. Pick one consequential rule: account scoring, routing, ICP, territory ownership or qualification. Then write five things down in one place:

1. The rule, as it runs today, not as the deck describes it.
2. Why it exists, and who decided it.
3. The logic that executes it, wherever it lives now.
4. The test that proves it works: a handful of real accounts and the outcome each one should get.
5. Its history: what it was before, and when it changed.

Then make the next change to that rule through a diff instead of a settings screen. The step-by-step move is in why GTM teams need to migrate their stack to Git, and Manifest gives you the folders.

Your GTM doesn’t belong in Git because GTM teams should become software engineers. It belongs in Git because humans and agents need one place to understand how the system works, why it works that way, and how it changed.

If agents are going to operate your GTM, give them a system they can actually read.

FAQ #