Building a Software Factory for Go-to-Market

A software factory for go-to-market is a revenue engine built the way software is built: the logic written as code, reviewed as diffs, versioned, shipped by a pipeline, and operated by agents instead of by people clicking through tools. The output of the factory is not campaigns. It is capabilities that keep running after the person who built them moves on.

Two things have to be true for the model to work. The engine has to be reproducible, which is an engineering property. And the company has to be legible to the agents operating it, which is a knowledge property. Teams usually get the first and skip the second, then conclude the agents are not good enough.

The software factory approach to GTM #

The test for a factory is reproducibility: could someone rebuild this engine from what is written down, and would it behave the same way. Most revenue stacks fail it. The logic is spread across CRM filters, a workflow tool, three spreadsheets and the memory of whoever configured it, and no artifact describes the whole.

The factory model replaces that with four properties, each of which an engineering team would recognise:

• Declared, not clicked. The account model, the enrichment waterfall, the fit score, the assignment rules, the recurring workflows and the agents are all files on disk. GTM as Code is the full version of this argument.
• Reviewed before it runs. A change to revenue logic is a diff somebody approves, not an edit that takes effect on save.
• Deployed by a pipeline. A plan step shows what would change, an apply step ships it, and the previous version is one command away.
• Tested. Evals on the agent prompts, the way a test suite guards a refactor. LLM evals for revenue agents covers what to measure.

What this buys is not speed on day one. Clicking a workflow together is faster on day one. It buys the second year: a change you can reason about, a rollback that exists, and an engine an agent can operate, because text is the medium an agent is fluent in.

That last property is the one people underrate. An agent working through a browser is a screen-scraper with a good vocabulary. An agent working against declared primitives can read the current state, propose a change as a diff, and deploy it. The same engine is callable from the UI for the people who prefer one, from a CLI, from the API and from an MCP server for the agents, which is what makes a self-service agentic workspace a real thing rather than a slide.

The cost of not having a factory is measurable in hours. Writing up eight months of running more than twenty agents across go-to-market, SaaStr’s Jason Lemkin reports that he and a colleague each spend 15 to 20 hours a week managing them, stitched across six or seven tools with automation glue in between. That is what agent operations look like without infrastructure underneath: the agents work, and two senior people are the runtime.

Providing context to AI agents #

The second requirement is the one that decides output quality, and it is not the model. Lemkin’s summary of the same eight months is blunt about it: the more context the agent has, the better the output. Every team that has shipped an agent into a revenue motion arrives at the same finding from a different direction.

The reason is structural. A model knows how to write. It does not know that your ICP excludes companies under 50 employees unless they are Series A, that “enterprise” means something specific in your pricing, that one competitor wins on deployment speed and you concede it, or that a named account is in a legal review nobody should email into. That is tribal knowledge, and in most companies it lives in Slack threads, a deck, two Notion pages and the head of the person who has been there longest.

Making a company legible to its agents means moving that knowledge somewhere a machine reads at decision time:

In Cargo this is a primitive rather than a prompt. Context is a git-backed knowledge base of markdown that syncs into the workspace with one declaration:

import { defineContext } from "@cargo-ai/cdk";

export const context = defineContext({ path: "context" });

Everything under that folder is synced on deploy, a new file is picked up automatically, and the sync is additive, so what a non-technical teammate writes in the UI is not overwritten by the next deploy. Cargo derives a knowledge graph from it and serves that to every agent, play and tool at runtime, which is the property that matters: update the ICP once, and the research agent, the qualifier and the outbound draft all change with it. There is no second copy to keep in step.

Three rules make the difference between context and a document dump.

One claim per file, with a confidence level. A file that says a competitor loses on deployment speed should say how that is known: two customers said so on calls, or one prospect said it once. An agent that cites an anecdote as a fact will do it at scale.

Write the boundaries, not just the pitch. What you cannot do, who you decline, which segments are out of scope. Agents reproduce the shape of what they are given, so an unbounded context produces unbounded claims.

Keep it beside the code that uses it. Context in a wiki drifts from the engine within a quarter. Context in the repo moves in the same pull request as the play that reads it, and a reviewer sees both.

The result is an engine where the knowledge and the execution ship together, and where the honest answer to “why did the agent say that” is a file with a history rather than a guess about the prompt. That is the whole of the software factory idea applied to revenue: not more automation, but an engine somebody can read.

Frequently asked questions #