On this page
Programmatic GTM is the practice of running go-to-market motions as named, versioned programs instead of one-off chat prompts. RevSure runs it through a command-line agent that executes a fixed sequence of MCP tool calls against its governed context layer, so the same motion returns the same shape of result on any tenant. Four motions run this way today: lead prioritization, account expansion, signal-to-outreach, and deal win-back.
Ask a revenue team how they use AI for go-to-market and most will describe a chat window. Someone types a request, the model calls a few tools, an answer comes back, and the whole thing evaporates when the tab closes. Run it again next week and the prompt has drifted, the tool calls have drifted, and so has the answer. Nothing accumulates.
Chat-based go-to-market work does not compound
Every chat run starts from zero. The logic lives in one person's message history, reproducible by no one, reviewable by no one. When that person leaves, or simply forgets the exact phrasing that worked last quarter, the motion leaves with them.
For a one-off question that is fine. For a motion a team wants to run every week, on every account, against real pipeline, it is a quiet liability. There is no artifact to improve, no version to roll back to, and nothing to hand a new rep except a link to someone's chat transcript.
It feels efficient because the output arrives fast. That speed hides a harder truth: nothing durable was built underneath it. The work looks automated. It is being re-improvised from scratch every single time.
The unit of work is a Play
Programmatic GTM fixes the unit. The thing you run is a Play: a named, versioned sequence of MCP tool calls with fixed inputs and a defined output. Its logic is written down in one file. Its filters, its stage mappings, and the order of its tool calls all live in that file, where anyone on the team can read them before the motion ever runs.
That single change is what lets a go-to-market motion behave like software.
What a Play is made of
A Play is a .skill file with five parts.
- A trigger description decides when the Play fires and, just as important, when it should route elsewhere.
- Its inputs name the tenant, the entity scope, the date window, and any thresholds.
- Its tool sequence lists the RevSure MCP calls in order, with the dependency between them made explicit.
- A block of hard rules captures the edge cases found in live testing, things like stage-key resolution, filter syntax, deduplication, and how to treat null values.
- Finally, an output contract states what the operator gets back, whether that is a ranked list, a set of drafted messages, or one packaged artifact to hand off.
Because a Play is a file, it can be versioned and reviewed like code, and rolled back when a change makes the output worse. That is the part a chat window can never offer.
How a Play runs, end to end
There are four layers, and the order matters. An operator names a Play from the command line. The Play tells a GTM agent which tools to call and in what sequence. The agent calls them through the RevSure MCP server. The results come back resolved against one identity graph, RevSure's governed context layer, the Full Funnel Data Graph.
Two design rules hold the whole thing together.
The MCP server is the only data path. There are no direct warehouse queries and no side-loaded spreadsheets. Whatever a Play can see, the context layer governs, and that is what lets identity resolve cleanly across Salesforce, HubSpot, 6sense, and Gong before a single record is ranked.
The SKILL.md file is the contract. The mandatory startup sequence resolves there, along with module routing and the tenant configuration, so a Play never has to guess at a stage name, a filter column, or which label a metric goes by. When something breaks during testing against a live tenant, the fix gets written back into SKILL.md as a hard rule rather than left as a workaround inside one Play.
The rule that separates a Play from a prompt
Authoring a Play is a loop. Draft the sequence against a live tenant, run it, find where it breaks, write the correction back into the file as a rule, then run it again. A Play is finished only when it survives a cold run on a tenant it was never written against.
When a run comes back wrong, the fix belongs in the Play file. The next operator inherits the corrected logic instead of rediscovering the same bug in a new chat window. Over a few weeks, the edge cases stop being surprises and start being documented behavior. That is the compounding a conversation cannot give you.
The Plays that run on the CLI today
Four Plays run on the command line today. Together they follow the arc of a go-to-market motion, from first ranking a buyer to re-opening a deal that went quiet, and each one runs against the same governed context layer. Signal-to-outreach is also packaged as a Claude skill, so the same logic runs in chat and on the command line without being rewritten.
Every Play in the catalogue runs end to end against a live tenant, and each one returns a ranked or drafted output an operator can act on the same day.
Who actually runs this
For an internal go-to-market team, the Plays run on their own tenant as live motions. Lead prioritization and account expansion already produce a ranked, drafted, ready-to-review list that a rep acts on the same day, on real pipeline.
For a prospect evaluating RevSure, the CLI answers a question that the phrase 'MCP server' tends to leave hanging: what does an operator actually do with one. A governed context layer is an abstract promise until an operator can run a single command and get back a scored account list with drafted outreach already attached. The CLI is where that abstraction becomes something a buyer can watch execute.
The human stays in the loop where it counts. The CLI drafts and ranks. A person decides what sends. That boundary is deliberate, because the fastest way to burn a prospect list is to automate the send before the judgment is there to catch it.
Why RevSure can run go-to-market as software
There is one reason all of this holds together, and it sits underneath every Play. A Play can be portable, auditable, and safe to hand off only because the data underneath it is governed and identity-resolved before any motion touches it. That is the entire job of RevSure's context layer, the Full Funnel Data Graph. A motion written against one tenant runs against another because both read through the same governed path, resolving the same accounts, opportunities, and people the same way.
This is the operational proof of the context-layer idea: once go-to-market data is governed and identity-resolved, motions become programs, not conversations.
That reframes the question most revenue teams are actually facing. Before automating a motion, the harder task is getting the data underneath it clean enough that automating it would be safe. Programmatic GTM starts in the graph, well before it reaches the command line.
Frequently asked questions
What is programmatic GTM?
Programmatic GTM is the practice of running go-to-market motions as named, versioned programs rather than ad hoc chat prompts. Each motion, called a Play, is a file that defines its inputs, its ordered tool calls, and its output, so it produces the same shape of result every time it runs against the same data.
How is a Play different from a prompt or a saved chat workflow?
A prompt lives in one person's message history and drifts every time it is retyped. A Play is a versioned file with fixed logic and a defined output contract. It can be diffed, reviewed, rolled back, and run by someone who has never seen the underlying data model.
What does RevSure's GTM CLI run today?
Four Plays run on the command line today: lead prioritization, account expansion, signal-to-outreach, and deal win-back. Each executes a fixed sequence of MCP tool calls against the same governed context layer, and a person reviews any drafted outreach before it sends.
Does programmatic GTM replace sales and marketing reps?
No. The CLI ranks accounts and drafts outreach, but a person reviews and approves anything before it sends. What programmatic GTM removes is the re-improvisation from repeatable motions. The judgment about which account matters, and what tone the outreach takes, stays with the rep.
What has to be true in my data for a Play to work?
The tenant configuration has to be clean. A Play resolves identity across sources like Salesforce, HubSpot, 6sense, and Gong through RevSure's context layer, so pipeline stages, filters, and account records need to be mapped correctly. Clean configuration is what lets the same Play run on any tenant and return the same shape of result.
Is a Play the same thing as an AI GTM engineer?
They are close. An AI GTM engineer is the agent that executes the logic; a Play is the logic it executes. Programmatic GTM is what you get when that engineer runs a defined, versioned Play against a governed context layer instead of responding to a fresh instruction each time.