Your coding agent can run your go-to-market.

A coding agent can run your go-to-market, but only if your go-to-market is code. The agent side is solved: Devin, Replicas, Multica, Claude Code and Codex all read a repository, open a pull request, respond to review, and land the change. The missing half is a revenue engine they can reach.

Give an agent a repo and it works. Give it eleven SaaS tools behind eleven logins and it writes you a document about the campaign, which is the least useful artifact in the building.

We have been running Cargo’s own go-to-market this way for thirty days, and agents opened 354 merged pull requests doing it. The numbers are further down. The wiring comes first.

Agents got good at repositories. GTM stayed behind a click. #

Every GTM tool of the last decade assumed a person typing into a form. That assumption is load-bearing: it decides that the interface is the product, that state lives in a database you cannot diff, and that the only way to trigger anything is a button.

An agent should not have to click. Browser agents can drive a UI, and sometimes that is the only door available, but it is the worst interface in the building: no schema, no diff, no dry run, no idempotency, and a silent break the first time someone moves a menu. Every other system an agent touches offers it a CLI and an API. GTM software is the one still handing it a mouse.

So the fix is not a better prompt or a browser-use loop. It is putting the engine somewhere the agent already knows how to work: a repository, a CLI, and a diff. We wrote up the general case in GTM as Code. This is the operational half: what has to exist, and what the day looks like once it does.

The four surfaces an agent needs #

None of them are agent-specific. They are what you would ask of any tool you wanted to run in CI.

A CLI. The agent shells out. cargo-ai runs a play, queries a model, lists connectors, exports a segment. If the only path to an action is a button, the agent is locked out of it.

A declarative layer. State has to be diffable or nothing is reviewable. Connectors, models, plays, agents, segments and workers are declared in TypeScript. cargo-ai cdk plan prints the diff. cargo-ai cdk deploy reconciles it. You review a change to your revenue engine the way you review a Terraform plan, because it is the same operation.

An MCP server. Not every agent has a shell, and not every task wants one. The workspace exposes itself over MCP, so an agent can search actions, execute one, batch it across a segment and poll the run without installing anything.

A skills bundle. This is the surface people skip, and skipping it is why agent output drifts. An agent told how to use your product in every prompt will be told slightly differently every time. npx skills add getcargohq/cargo-skills installs the procedures once: how to build a segment, how to run a batch, how to read a failed run. Your prompt then says what to do, not how.

Together they mean the agent is not integrating with your GTM stack. It is operating it.

The pattern: repo, pull request, merge #

Once the surfaces exist, the operating model is three moves, and all three are ordinary software.

The repository is the workspace. The plan, the ICP, the personas, the proof points, the objection handling, the initiatives, the weekly cadence, and the plays that run in production, all as markdown and TypeScript in one tree. Not a wiki that describes the engine. The engine.

The pull request is the approval gate. An agent never decides on its own that a stranger should hear from your company. It drafts, opens a PR, and a human reads it. Not a safety blanket bolted on afterwards: it is the only review surface that already has diffing, comments, history, and a merge button everyone in the company knows how to press.

The merge is the actuator. This is the move that gets left out, and leaving it out is why most agent fleets look busy and change nothing. Merging to main deploys the plays. Merging a batch of drafted messages sends them: a workflow reads the message files out of the merged directory, delivers each one, and writes an at-most-once ledger so a re-run never double-sends. Approval and action become the same keystroke.

We ran the version without that third move for a week: ten to fourteen pull requests a day, three plays, every one of them disabled, and zero initiative criteria moved. The PRs were good. Nothing happened.

One loop, end to end #

A scheduled run reads the initiative files and finds expansion revenue behind its number with three weeks left on the deadline. It queries the accounts model for customers over their credit allocation whose billing cycle ends inside 30 days, and gets eleven. It writes that filter to a segment definition, drafts a play that enriches the primary contact and scores the expansion trigger, and writes one message per account as a markdown file.

Then it opens a pull request. The diff is the segment, the play in TypeScript, and eleven drafts in plain text.

A human reads the eleven messages, rewrites two, kills one account as a bad fit, and merges. The merge deploys the play and sends the ten remaining messages. Human time: a few minutes.

No chat interface anywhere in that loop, and no browser.

Manifest is that operating model, packaged #

Everything above is an architecture, not a product. Manifest is how we packaged it: the repository layout, the conventions, and the agent instructions that make the loop reproducible instead of something each team reinvents. It is open source and free, and it works with any harness.

git clone https://github.com/getcargohq/cargo-manifest acme-gtm
cd acme-gtm && npm install

Inside are plan/ (where the company is going), context/ (ICP, personas, motions, proof), initiatives/ (bounded efforts with owners and checkable success criteria), cadence/ (the weekly plan, the daily log, the carryover queue), infra/ (the plays, tools and agents that actually run), and outputs/ (the append-only archive of what the fleet produced).

The AGENTS.md at the root is what makes it work unattended: it tells any harness the read order, the layer boundaries, what a pull request has to carry, and what is never allowed to reach a person without a human pressing merge. Point your agent at the repo and tell it to seed itself for your company. It interviews you, fills the layers, and stops for your review.

Manifest is the shape. Cargo is the runtime it deploys into when you want the execution layer live.

Thirty days of running our own #

We run Cargo’s go-to-market in a Manifest repo. First commit 2026-07-29. As of 2026-08-27, day thirty:

Agents opened almost all of those pull requests. Every one passed a human gate: a review and a merge, or for three low-risk classes, a 24 hour veto window nobody used.

The volume is not the interesting part. The governor is. A file called autonomy.yml holds one entry per class of work the fleet produces, each rated on a ladder:

• L3: a human reviews and merges every pull request. The default for everything.
• L4: auto-merge on green checks after a 24 hour veto window. The gate becomes a veto instead of a bottleneck.
• L5: auto-merge immediately, humans audit the log.

Seven classes today. Three sit at L4: the daily log, the Slack scan, the meeting scribe. Anything that can reach a customer sits at L3 and carries a ceiling that keeps it there permanently. Promotion is a pull request to that file, backed by a streak of merges no human had to edit. Demotion is instant: one reverted merge, one caught hallucination, and the class drops back the same day.

Three more bounds, one line each: at most three auto-merges per run, at most twenty-five messages per merged batch, and a file named STOP at the repo root that halts every launcher. Creating it is one commit.

Skipping this part is how a fleet becomes an incident. Earn each level in public, on work whose blast radius you can survive.

Then pick a harness #

The repository does not know which agent is driving, which is why this section is short.

Devin is session-oriented and holds a long task well. Best fit: a large diff with a long arc, like a new motion that touches context/, infra/ and evals/ in one change.

Replicas runs an agent in an isolated VM, triggered by a GitHub mention, a Slack message, or a schedule. Best fit: recurring unattended work. A daily run that ranks the queue and drafts against the top of it wants a cron, not a session.

Multica is open source and puts agents on the board next to people, with issues assigned to an agent the way you would assign to a teammate. Best fit: a team already living in issues that wants agent work tracked where human work is tracked.

The harness is interchangeable. The repository and the execution layer are not. That is the whole test of whether your go-to-market is really code.

Three things we would tell you before you start #

Wire the actuator first. Build the thing that sends before you build the thing that drafts. A fleet producing reviewable work that reaches nobody is the most convincing failure mode there is, because the dashboard looks great.

Never commit a generated file. Our rendered queue and index files were checked in, so every branch conflicted on the same two files and agents burned their runs resolving merge conflicts. Generate them in CI and fail the build if one turns up in a diff.

Give the agent a ranked queue, not a prompt. Ours renders from the success criteria of every open initiative, sorted by dollars at risk per remaining day, with both inputs printed so the order is arguable instead of magic. An agent handed “work on growth” produces something plausible. An agent handed a sorted list works the top of it.

Start #

git clone https://github.com/getcargohq/cargo-manifest acme-gtm
cd acme-gtm && npm install
npx @cargo-ai/cli cdk plan   # from infra/, against a Cargo workspace

Then point your harness at the repo and assign the first issue.

Coding agents already know how to work: read a repository, propose a change, take review, ship. Nothing about go-to-market is harder than the software they already write. The missing piece is on our side of the line, and it is an interface problem: GTM tools have to expose something an agent can operate. The only question left is whether your revenue engine is something they can open.

FAQ #