Your coding agent fixes your revenue engine before you notice it broke.

Somewhere in your GTM stack, a workflow is failing right now. Not loudly, nothing pages anyone: an enrichment step drifted out of its schema weeks ago, and every run since has died quietly, in a few milliseconds, filling a queue nobody reads. You will find out the way GTM teams always find out: weeks later, through the bad data it left behind.

We watched exactly this on a production Cargo workspace this week: 13,616 spans, a failure queue repeating the same line, Missing required field: id. Now hand that failure to a coding agent working on an engine that is code. It reads the failing span, finds the play passing a column that no longer exists, patches the TypeScript, prints the diff with cdk plan, and opens a pull request with the trace linked. You review it with your coffee. The merge deploys the fix. That error class never fires again.

A coding agent can run your go-to-market, but only if your go-to-market is code. The agent half is solved. Devin, Replicas, Multica, Claude Code and Codex all do the same four things: read a repository, propose a change, take review, land it. They are good at it. They are not good at your GTM stack, and that is not their fault: there is nothing in it for them to open.

We have spent thirty days running Cargo’s own go-to-market this way, and agents opened 354 merged pull requests doing it. Most were useful. One drafted a message to a customer that should never have gone out, and a human caught it by reading the diff.

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 someone presses.

An agent should not have to press it.

Browser agents can drive a UI, and sometimes that is the only door available. It is still the worst interface in the building: no schema, no diff, no dry run, no idempotency, and a silent break the first time a vendor moves a menu. Every other system an agent touches offers it a CLI and an API. Most GTM software instead hands it a mouse.

So the fix is not a better prompt, and it is not a browser-use loop with more retries. 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.

Four surfaces, none of them agent-specific #

They are what you would ask of any tool you wanted to run in CI. Agents just make the absence expensive.

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, and so is your CI, and so is anyone who wanted to script it at 2am.

A declarative layer. State has to be diffable or nothing is reviewable. Connectors, models, plays, agents, segments and workers are declared in TypeScript:

npx @cargo-ai/cli cdk plan     # the diff against production
npx @cargo-ai/cli cdk deploy   # reconcile 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 deserves 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 inside every prompt gets told slightly differently every time, by a different person, in a different hurry. Install the procedures once instead:

npx skills add getcargohq/cargo-skills

Now how to build a segment, how to run a batch and how to read a failed run live in one place, and your prompt only has to say what you want.

Together, these four mean the agent is not integrating with your GTM stack. It is operating it.

Repo, pull request, merge #

Once the surfaces exist, the operating model is 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 of it markdown and TypeScript in one tree. Not a wiki that describes the engine. The engine.

The pull request is the approval gate. Not because a human must read everything forever, but because review should be priced by blast radius, and a pull request is where the price gets set. A play patched against a failing trace is cheap to approve. A change to the scoring model deserves real scrutiny, because every play downstream inherits it. A routine touch to a low-tier account may eventually need no human at all: that is what the autonomy ladder further down is for. What the PR gives you is the decision itself, written down and versioned, on the only review surface that already has diffing, comments, history, and a merge button everyone in the company knows how to press. Today humans hold most of the gates. The direction is fewer: reviewer agents take the routine classes first, and humans keep whatever changes the engine itself.

The merge is the actuator. For software this is ordinary: merging deploys, and every engineering team has run this way for fifteen years. Go-to-market never has. Approval in GTM means a thumbs-up in a Slack thread, and then a person still logs into five tools to make the thing true. Wiring the engine to the repository closes that gap: merging the play deploys the play, merging the fix ships the fix, and if the diff carries drafted messages, merging is what sends them, each exactly once, with a record of what went out. The approval and the action stop being two separate jobs.

One convention holds it together: every pull request ends with one sentence answering the only question a reviewer really has. What happens in the real world if I press merge? Most of the time the answer is “nothing is sent and nothing is deployed.” When a pull request does contain messages, that sentence has to name exactly who will receive what, and the build fails if it does not. The agents follow this on every single PR, because it is installed once as a skill instead of asked for in prompts, and the result is something few human teams have: every change arrives with its consequence spelled out in plain language, cleaner than most people would take the time to write.

One loop, and the one it got wrong #

A scheduled run reads the initiative files and finds expansion revenue sitting 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. 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 segment, the play in TypeScript, and the drafts in plain text.

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

Our expansion play drafted check-ins to two customers whose credit consumption had jumped about 65 percent in four weeks. Same opening line, same close, both factually accurate, both ready to send.

The accounts were not in the same position. One was on pace to burn through its annual allocation about five months before it renewed. The other was going to finish its cycle with room to spare. The play could not tell them apart, because the only usage field it was handed was a four-week rate of change, and a rate of change cannot tell you how much is left.

A human spotted it in the diff.

• The email was withdrawn before it was ever queued. Nothing was sent by anyone.
• The account with margin got nothing at all, because “your usage is up and you are within plan” is not worth a customer’s attention.
• The account running dry got a short Slack message from me, in the channel we already share, opening on how much of that burn was our own failed runs inflating their bill. We had precedent: on another account, roughly half of a 54,000-credit overage turned out to be failures.
• The missing fields went in as a bug, so the next run sees runway and cycle length, not just a delta.

The idea to keep from this story: an agent’s mistakes do not look like mistakes. They look like finished work. Both emails were well written and factually accurate. One was wrong, and nothing in the message itself could tell you which one.

A smarter model would not have caught it. The gap was not intelligence, it was a missing field, and a data gap survives every model upgrade. It is also why the review happens on a diff and not in an inbox: alone, each message looked fine. Side by side, next to the play that produced them, the difference between the two accounts had somewhere to show up.

And it is why it matters that the engine is code. In a SaaS tool, that email goes out and you apologize. Here, the near-miss turned into a bug fix the same afternoon: the missing fields went in, the next run sees runway instead of a delta, and this exact mistake is no longer possible. The gate is not ceremony. Every failure it catches makes the engine one bug harder to fool.

Manifest is that operating model, packaged #

None of that requires buying anything. Manifest is how we packaged it: the repository layout, the conventions, and the agent instructions that make the loop reproducible instead of something every team reinvents from scratch. It is open source, free, and works with any harness.

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

Inside: 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 everything 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 #

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 has used yet.

And it is not only us. The Revenue Architects, the GTM engineering studio behind Descript, WorkOS and Linear’s infrastructure, run their client work the same way: workflows in a GitHub repository, built through CLI agents, and when something breaks, “an agent can troubleshoot what’s failing and quickly ship a PR.” They stopped building in the UI months ago, and builds that used to take a day or two now take a few hours. The write-up on their setup is worth the read.

The volume is not the interesting number. 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 for now: lifting that ceiling honestly takes a reviewer trusted as much as a human, and the candid answer is that the reviewer will be another agent before it is nobody. 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.

The rest of the governor is four lines:

kill_switch: STOP

limits:
  max_automerges_per_run: 3
  veto_hours: 24
  max_messages_per_send: 25

Skipping the governance 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.

Devin is session-oriented and holds a long task well. Good for a large diff with a long arc, like a new motion touching 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. Good for 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 one to a teammate. Good for a team already living in issues.

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 I 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 fantastic the entire time.

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 cheerfully burned their runs resolving merge conflicts instead of doing the work. 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 it 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 was never on their side of the line. It is an interface problem, and it is ours: GTM tools have to expose something an agent can operate.

So the only question left is whether your revenue engine is something they can open.

FAQ #