A GenAI powered go-to-market stack has three pieces: a data lake, a model layer, and a library of agents. Most of today's attention goes to the first and the last. The model layer is treated as a formality: point a proprietary frontier model at the data and move on.
This paper argues that the formality will not last. As GTM data becomes a genuine competitive differentiator, companies will grow less comfortable running it through models they share with every other customer of the same vendor. The pressure points toward private, dedicated model deployment: a model trained and run inside a company's own walls, on its own data, answerable to nobody else's roadmap.
The shift will not arrive everywhere at once. Large enterprises will move first, because they hold the most sensitive data, have the most to lose competitively, and can afford to build properly. Adoption then moves down market as tooling matures and costs fall. The economics reinforce the trend: per token pricing on a shared model rises with usage indefinitely, while a dedicated model is mostly a fixed cost once it is built.
The practical conclusion for revenue leaders: the model decision is strategic, and the step that keeps every future option open is the same in every scenario. Consolidate your engagement data, joined to the opportunity, inside infrastructure you control.
The three pieces of a GenAI GTM stack
Strip away the vendor categories and a GenAI powered GTM stack reduces to three layers.
- The data lake. One governed copy of the company's engagement data: CRM history, recorded calls, email, internal chat, content engagement and intent signals, matched to the same accounts and opportunities.
- The model layer. The large language model that reads that data, reasons over it and writes the output. Today this is usually a proprietary frontier model reached through an API.
- The agent library. The repeatable workflows that ask specific questions of the data through the model: why deals are lost, which patterns precede a win, where a competitor takes the call.
The data lake and the agents get most of the discussion, and they deserve it. The model layer is where the next real decision sits, and most organizations have not yet recognized it as a decision at all.
How the model layer became a default
The current phase of GenAI in GTM is defined by in-application agents. Every major vendor in the stack has embedded an LLM inside its product. Each one automates workflows on the data that vendor already holds, and each is bounded by that product's data and that product's view of the deal.
Alongside them, general purpose assistants now reach into the same systems through connectors. Ask a question, and the assistant retrieves context from each system one request at a time and writes a cited answer.
Both approaches are useful, and both quietly settle the model question for you. In the first case the vendor chose the model. In the second, the model is whatever your enterprise assistant runs on. Neither choice was made with your GTM data strategy in mind, and neither was framed as a choice.
Right now almost everyone treats the model layer as a formality. That is the habit this paper asks you to question.
Why GTM data is becoming the advantage
Over the past two years the analysis layer of the sales technology stack has been commoditized. Work that once justified a five or six figure annual contract, such as reading a call transcript and producing coaching signals or deal risk flags, can now be done by any frontier model. Categories built on that analysis are being absorbed rather than replaced: the hard problem stops being hard, the category renames itself upward, a general purpose technology eats the new layer, and the incumbent begins importing the commodity it once produced.
When analysis is effectively free, what remains defensible narrows to two things:
- Who owns the aggregated GTM data across every engagement channel, joined at the opportunity level and kept over time.
- Who has built the agents that turn that data into decisions specific to the company's own market, motion and buyers.
That is the core of the argument. If the data is the advantage, then where the data is processed, and by whom, stops being an IT procurement detail. It becomes a question about protecting the one asset that still differentiates.
The shared infrastructure problem
The concern here is not that model providers misuse customer data. Enterprise terms from the major providers generally commit to not training on customer inputs, and there is no reason to assume bad faith.
The concern is structural. An advantage that lives inside shared infrastructure is exposed to forces the company does not control:
- Roadmap dependence. The model's behavior, pricing, retention policies and availability change on the provider's schedule. A workflow tuned to one model version can shift when that version is retired.
- Capability parity. Every competitor reaches the same model with the same general capabilities. The model itself confers no edge; only what you feed it and how you direct it does.
- Concentration of sensitive context. Win and loss reasoning, pricing concessions, competitive objections and internal deal debate are among the most commercially sensitive data a company holds. Sending that context through shared infrastructure is a governance decision that many security and legal teams have not yet examined closely.
As GTM data matures from operational exhaust into a recognized strategic asset, these issues move from footnotes to board level questions. The natural response is to bring the model to the data rather than sending the data to the model.
What private deployment means
Private deployment is a spectrum rather than a single architecture. In practice it covers several patterns, each trading control against effort:
- Dedicated tenancy. A provider's model running on capacity reserved for one customer, inside that customer's cloud account or a contractually isolated environment.
- Clean room style implementation. A controlled environment where GTM data and the insights derived from it are kept away from any model a competitor can reach, with access and outputs governed by the data owner.
- Self-hosted open weight models. A capable open model fine tuned on the company's own engagement history and run entirely on infrastructure the company operates.
What these have in common is the property that matters: the model that learns from your GTM data serves only you, and you decide when it changes.
Phase 1 and Phase 2 compared
| Phase 1: now | Phase 2: next | |
|---|---|---|
| Where the model runs | Inside each vendor's application, or a shared frontier model reached through connectors | Dedicated to one company, inside its own cloud or a clean room style environment |
| What it can see | The data that one application already holds, or whatever a connector returns for one question | Engagement data consolidated across every GTM system and joined to the opportunity |
| Who controls the roadmap | The application vendor or the model provider | The company that owns the data |
| How cost behaves | Per token, rising in line with usage | Mostly fixed once built, falling per unit of work as usage grows |
| Typical adopter | Everyone, by default | Large enterprises first, then down market as tooling matures |
Who moves first
Large enterprises will lead. They hold the largest and most sensitive bodies of engagement data, face the highest competitive stakes, and have the budget and engineering capacity to build and operate a dedicated model properly. Many already run private infrastructure for other regulated or sensitive workloads, so the governance patterns exist.
The mid market follows as the tooling matures. Managed private deployment options, smaller and more efficient models, and falling compute costs will each lower the threshold. The pattern resembles earlier infrastructure shifts: what begins as a bespoke enterprise build becomes a packaged capability within a few years.
For companies further down market, the immediate implication is not to deploy a private model tomorrow. It is to avoid decisions today that make the move harder later.
The economics get stronger over time
The cost argument is often presented as a reason to stay on shared models. In the near term, for light usage, that is correct. Over a longer horizon the curves cross.
- Shared public model: cost rises in line with usage, for as long as the usage continues. Every additional agent run, every additional quarter of history analyzed, adds to the bill.
- Dedicated private model: cost is front loaded in the build, fine tuning and infrastructure. Once running, the marginal cost of additional work is low, so cost per unit of work falls as usage grows.
Where the crossover sits for any one company depends on volume, model size, hardware utilization and the people required to run it. The direction is not in doubt. As agents multiply and analysis runs continuously rather than on demand, GTM workloads move to the right side of that curve.
What to decide now
None of this requires a revenue leader to stand up a model this quarter. It does require treating the model layer as a choice and protecting the options. Five moves hold up in every scenario.
- Name the model decision as strategic. Put it on the same agenda as data governance and vendor selection, with an owner, rather than letting it default through whichever assistant or application gets adopted first.
- Consolidate engagement data inside your own infrastructure. A governed, joined copy of CRM, call, email, chat and intent data, matched to the opportunity and held in your own warehouse, is the prerequisite for every future model option, public or private.
- Keep the agents portable. Build workflows that state their questions, inputs and evidence standards independently of any one model, so they can move when the model does.
- Measure token spend by workflow. Know which agents and analyses consume the most. That is the data that will tell you when your own crossover arrives.
- Write the data terms down. Document where GTM data may be processed, by which providers, with what retention, before more of it starts flowing through shared tools by default.
Questions for your leadership team
- Which models touch our GTM data today, and did anyone choose them deliberately?
- Where does our most sensitive deal reasoning, such as pricing concessions and internal debate, currently get processed?
- Do we hold a joined, governed copy of our engagement data that we control, or does each vendor hold its own slice?
- If our model provider changed its pricing or retired the version we rely on, what would break?
Is your organization treating the model layer as a strategic choice, or as a default?
About Rev-Lens. Rev-Lens is a founder-delivered go-to-market intelligence practice. In a five-week engagement it joins a company's CRM, recorded calls, email, internal chat and intent data at the opportunity level, inside the company's own infrastructure, and returns win-rate findings with a denominator, the evidence behind them and a named owner. The company keeps the joined dataset and the agents.
Related: the definition of win-rate forensics and how Rev-Lens compares to conversation intelligence, forecasting and win-loss research firms.
To discuss whether your data can answer the question your stack cannot, email sales@rev-lens.ai or read the other white paper, Reach Is Not Analysis.