GTM as Code: The Complete Guide to Running Your Go-to-Market as Code

To run your go-to-market as code, declare your data models, plays, tools and agents in TypeScript with the Cargo CDK in a git repository, then connect that repository to Cargo: every pull request is planned and previewed as a comment, and every merge deploys. cargo-ai project init scaffolds the repository, and the rest is the pull request workflow your engineers already use.

npm install -g @cargo-ai/cli
cargo-ai login --email you@company.com   # no browser, 100 free credits, no card
cargo-ai project init acme-gtm           # scaffold the repository and its deploy state
cd acme-gtm
cargo-ai project plan                    # the diff a pull request will show
cargo-ai project deploy                  # apply it, or let the merge do it

This page is the map. Each step of the lifecycle below has its own page with the commands, what comes back, and the limits. If you want the argument for working this way first, read your GTM belongs in git and the manifesto.

The lifecycle, one job per page #

1. Declare it #

The engine is TypeScript: one define* call per resource (defineModel, defineSegment, definePlay, defineTool, defineAgent, connectors), and imports are the dependency graph. The scaffold from cargo-ai project init is the open-source Manifest layout: context/ for what the company knows, infra/ for what runs, evals/ for prompt tests and outputs/ for what happened. An existing workspace does not have to be rewritten by hand: cargo-ai project pull generates define* source from it. The Cargo CDK page lists every resource it can declare, and the cargo-project skill teaches a coding agent the same workflow.

2. Review it before it ships #

cargo-ai project plan compiles the repository and diffs it against the deploy state your workspace holds: + create, ~ update, = noop, - delete. Once the repository is connected, Cargo runs that plan on every pull request and adds what the merge will set in motion: the records each play and one-off execution runs on, the emails, LinkedIn actions and messages it can send, and the credits it can spend. Above 100 emails, 100 LinkedIn actions, 100 chat messages, 5,000 audience adds or 2,500 credits, the check fails until a reviewer adds the cargo:approve-impact label (thresholds as defined in Cargo’s code, October 2026).

3. Ship it on merge #

Connect the repository in Settings → States and every push to the production branch runs cargo-ai project deploy --yes on that commit, as a service user with a credential minted for the run. There is no workflow file to write and no Cargo token stored in GitHub. Deploys of one project apply one at a time, in order. If you prefer your own CI, the same two commands, cargo-ai project plan and cargo-ai project deploy, run there.

4. Run one-off jobs from the same repository #

Not everything is a standing play. A pilot enrollment of 50 contacts, a CSV import or a backfill is an execution: defineBatch or defineRun in a file under outputs/. The plan lists it, the next deploy runs it, and a ledger in the deploy state makes sure it never runs twice.

5. Test the agents #

An agent’s system prompt is a string in a defineAgent file, so a pull request can change it. The scaffold ships an evals/ folder with a promptfoo configuration and a case template; run it with npm run eval on every pull request that touches an agent, next to Cargo’s own check. In production, the agent’s evaluator scores each finished turn against a rubric.

6. See it and undo it #

cargo-ai project graph draws every resource and what it points at as a Mermaid flowchart, from the live workspace or offline from the repository, and --plan colours what the next deploy changes. When a change goes wrong, revert the commit: the deploy reconciles the workspace to whatever the code says.

What this is not #

It is not a way around review. Merging is the approval: the deploy runs whatever reached the production branch, so protect that branch the way you protect production, and make the Cargo check required. It is also not a full replacement for the UI. Resources deployed from code stay editable in Cargo, and the project never reads those edits back, so pick one owner per resource. Why GTM teams should migrate their stack to git covers what moves first and what stays in the UI.

FAQ #