GTM as Code: Run Your Go-to-Market as Software

GTM as Code is the practice of running your go-to-market as software: your data models, enrichment logic, scoring, routing, plays, and AI agents defined in version-controlled code, reviewed as diffs, and deployed with one command. The same shift that took infrastructure from hand-configured servers to Terraform, applied to revenue.

If you can describe your revenue engine in files an engineer can read, an agent can run it, a teammate can review it, and your company owns it. That is the whole idea.

The black box you run revenue on #

Every company has revenue logic. It decides which accounts matter, which contacts to target, what signals mean buying intent, how leads are scored, who owns each opportunity, and which action happens next.

In most companies, this logic is scattered everywhere. Some lives in CRM filters. Some in automation tools. Some in documents. A significant part lives only in the head of the RevOps person who configured the system six months ago. The engine makes thousands of decisions every day, and the company cannot clearly see how.

Why was this account classified as Tier 1? Why was this lead assigned to Sarah? Which version of the scoring model is running right now? What changed last Tuesday? Most GTM teams cannot answer these questions without opening five tools, asking three people, and reconstructing the logic by hand.

There is a name for this way of working: ClickOps. Someone opens a workflow, changes a filter, presses save and hopes every dependent system still behaves correctly. The problem is not that the change happened through an interface. The problem is that the resulting logic is difficult to review, reproduce, test or reconcile with the rest of the engine. That is not a revenue engine. It is accumulated operational debt.

GTM as Code replaces it with a definition layer:

• Your account and contact models, your segments, your plays, and your agents are declared in code, not clicked into existence.
• Every change ships as a diff you review before it touches production, the way engineers review infrastructure changes.
• The whole engine lives in a git repository your company owns, so knowledge survives the person who built it.
• Because the engine is text, AI agents can read it, reason about it, and operate it without a human in the loop for every step.

Engineering teams made this exact move twice already: infrastructure as code (Terraform, AWS CDK, Pulumi) and analytics as code (dbt). GTM is the next system of record to follow.

Why now #

Two things changed in the last two years.

First, AI agents became competent operators. An agent can source 500 accounts, enrich them through a waterfall, score them against your ICP, and draft the first line of outreach. But it can only do this against a system it can read and write. A CRM assumes a human is typing into forms. An agent working through a UI is a screen-scraper with a fancy name. Agents need programmable primitives: typed models, callable tools, declarative plays. GTM as Code is the interface agents actually need.

For a decade, the visual interface was where GTM systems were built, because clicking was the only practical way in for an operator who does not code. AI coding agents removed that constraint. The authoring model shifts from a human clicking every box to a human defining intent, an agent writing the change, and a human reviewing it before it ships. AI makes the interface cheaper. It makes the underlying system more valuable.

Second, the GTM engineer became a real job. There is now a person on the revenue team who thinks in schemas and pipelines, not in tabs and filters. Handing that person a no-code UI is like handing a backend engineer a website builder. They want the primitives, a CLI, and a repo.

The four primitives #

Cargo’s version of GTM as Code rests on four primitives. Everything else composes from them.

1. Data Models. Unified account and contact tables, cleaned and deduplicated across your CRM, product data, and providers. The outcome that used to require a dbt project or a CDP, delivered as a primitive. Every downstream decision reads from one clean layer.
2. Tools. Typed, callable actions: enrich this domain, verify this email, write this field to Salesforce, post this Slack message. Tools are what agents and plays invoke; each one has a schema, so calls are checkable, not vibes.
3. Plays. Declarative workflows that run continuously: waterfall enrichment on new signups, scoring on segment entry, routing on score change, signal-triggered outreach. A play is code, so it diffs, deploys, and rolls back like code.
4. Agents. AI operators with access to your tools and your context graph (ICP, personas, objections, proof points). An agent grounded in that context sounds like your best rep, and its instructions are versioned files you can test and review.

Data models give agents ground truth. Tools give them hands. Plays give them standing orders. The primitives are the point: you compose your engine instead of buying fifteen finished tools that almost fit.

What it looks like, concretely #

The engine is TypeScript files using the CDK’s define* primitives (@cargo-ai/cdk):

import { defineModel, defineAgent } from "@cargo-ai/cdk";

import { anthropic } from "../connectors/anthropic";
import { enrich } from "../tools/enrich";

// A workspace-owned contacts table with the standard schema.
export const contacts = defineModel("contacts", {
  kind: "native",
  extractSlug: "defineContact",
});

// The qualifier. Everything it can call or read is one `uses` array:
// models, tools, sub-agents, connector actions. The reconciler deploys
// dependencies first and injects their uuids.
export const qualifier = defineAgent("trial-qualifier", {
  connector: anthropic,
  languageModel: "claude-sonnet-5",
  systemPrompt: [
    "You qualify trial signups.",
    "Ground every judgment in the workspace context: ICP, personas, disqualifiers.",
    "Score fit and recommend a route (AE, nurture, decline) with a one-paragraph rationale.",
  ].join("\n"),
  uses: [contacts, enrich],
});

Segments, tools, plays, and connectors follow the same pattern: one define* call per resource, imports as the dependency graph. Shipping it is two commands:

npx @cargo-ai/cli cdk plan     # preview every change as a diff against production
npx @cargo-ai/cli cdk deploy   # ship it

Here is what that buys you in practice. Say your company changes its definition of a Tier 1 account: employee count from 50 to 100, ICP score from 70 to 80, and a new requirement of at least two RevOps people on the team.

Under ClickOps, someone edits a few filters. The change takes five minutes. The consequences last for months: six weeks later nobody remembers the previous thresholds, the documentation still describes the old definition, another workflow quietly keeps using the old cutoff, and the CRM report and the routing system now disagree about who is Tier 1.

Under GTM as Code, the same change is a proposal before it becomes a fact. The diff shows the thresholds moving. The deployment preview shows the impact: 184 accounts leave Tier 1, Sarah’s territory loses 31 accounts, 2 automated plays stop targeting the removed accounts. The team reviews the business impact, then ships. If the new model performs badly in production, you restore the previous version in one step.

Every revenue decision needs a receipt #

“Auditable” sounds like compliance language. The business meaning is simpler: every decision the engine makes can be traced back to the rule and the version that produced it.

Finance would never accept a P&L made of numbers nobody can trace. GTM teams accept the opposite every day: their systems decide prioritization, ownership, and expansion, and the reasoning is invisible. Run your own stack against the Receipt Test. Five questions:

1. What happened?
2. Which data was used?
3. Which rule produced the outcome?
4. Which version of that rule was running?
5. Who changed it, and can we restore the previous version?

If your revenue engine can answer all five, you have receipts. If not, you have a black box with a pipeline attached. Most GTM failures are not dramatic enough to trigger an incident: a high-intent account routed to the wrong territory, a customer with expansion signals excluded because one field is missing. Each looks small. Across millions of decisions it becomes silent revenue leakage. With receipts, the investigation starts from the actual decision path instead of symptoms across five tools.

The repo around the code #

The repository structure is open source: Manifest, the template extracted from Cargo’s own GTM.

acme-gtm/
├── plan/          # the number you are chasing and the moves to get there
├── context/       # icp/, persona/, objection/, proof/, signal/: one claim per file
├── cadence/       # weekly plan, daily log, carryover
├── initiatives/   # bounded efforts with owners and success criteria
├── infra/         # connectors, models, segments, tools, agents, plays (deploys to Cargo)
├── evals/         # tests that catch a prompt change making agents worse
└── outputs/       # dated receipts: every list built, every campaign shipped

Knowledge in context/, execution in infra/, receipts in outputs/. An agent opening this repo knows what your company knows, what is running, and what happened last week. No re-explaining your business from zero in every chat session.

Who this is for #

GTM as Code is for the technical GTM builder: the GTM engineer, the technical founder doing founder-sales, the RevOps lead with engineering DNA who wants to build, not configure. The mindset test is simple. If you say “give me the primitives and I will build it,” this is for you. If you want a finished workflow out of the box, a point tool will serve you better, and honestly, faster.

The rest of the org does not need to write code, and the interface does not disappear: it becomes the place where people observe execution, investigate a decision, approve a change, and resolve the cases that genuinely need human judgment. Humans do not leave the loop. They move up in it. Agents write the implementation; humans still define the policy. “Prioritize good accounts” is not a policy. “Prioritize companies with an ICP score above 80, two or more RevOps employees, recent funding, and no active opportunity” is one. AI lowers the technical barrier. It does not remove the need for rigorous GTM thinking. It exposes vague thinking faster.

GTM as Code vs UI-first tools #

Clay and its peers are spreadsheet-shaped: powerful, visual, built for a human assembling enrichment flows in a browser. That is a legitimate way to work, and for one-off list-building it is often the right one. The differences are structural, not cosmetic:

	UI-first tools (Clay et al.)	GTM as Code (Cargo)
Source of truth	Tables and flows inside the vendor’s UI	A git repo your company owns
Change management	Edit live, hope for the best	Diff, review, deploy, roll back
Agent operability	Agent drives a UI built for humans	Agent calls typed primitives directly
Scope	Point workflows	The whole engine: models, plays, agents
When the builder leaves	The logic leaves with them	The repo stays, documented and testable

The honest framing: UI tools are applications. GTM as Code is infrastructure, the layer beneath them.

Proof this is not a thought experiment #

• Cargo runs millions of play and agent executions every month in production, and we run Cargo’s own pipeline this way: changes to our engine ship like product releases, previewed, reviewed, reversible.
• About 115 companies run their revenue engine on Cargo, including Weights & Biases, WorkOS, Descript, Monte Carlo, Dust, Augment Code, and Braintrust, which runs its GTM out of a git repository: revenue logic in code, versioned, and theirs to keep.
• About 50 percent of Cargo users operate the platform through the CLI or Claude Code rather than the UI. Half the user base already treats GTM as a programming target. That number is the clearest evidence the shift is real.
• The demand side is already there: prospects ask about version history before we introduce the idea. They are not asking for a developer feature. They want to know whether a critical revenue change can be traced and reversed.

Getting started #

Ten minutes to a working repo:

git clone https://github.com/getcargohq/cargo-manifest acme-gtm
cd acme-gtm && npm install
claude .   # or Cursor, or any agent that reads AGENTS.md

Tell your agent to seed the repo for your company. It interviews you, fills the layers, and stops for your review. When you want the execution layer live, run npx @cargo-ai/cli cdk plan from infra/ against a Cargo workspace. The GTM skills that carry CDK definitions (tam-building, account-scoring) scaffold straight into infra/ so you rarely start from a blank file.

Codification is not the destination. It is what makes the next step possible: once revenue logic is explicit, versioned and testable, agents can reason about it, simulate changes, and propose improvements. The future revenue engine will not be built by clicking through an ever-growing maze of workflows. Humans will define its intent. Agents will write and test its logic. The repository will preserve its memory.

FAQ #