Don’t Buy Your GTM Brain
The AI build vs buy question is really about who owns your intelligence layer.
Many GTM leaders are going to make the wrong AI build vs buy decision.
They will not make it because they are lazy. They will make it because the category is moving fast, the demos look impressive, and the old software-buying mental model feels safe. Pick the best vendor, negotiate the contract, roll it out to the team, measure adoption. That worked well enough when software mostly helped people complete workflows.
AI changes the stakes because the system is no longer just completing a workflow. It is learning from the workflow and compounding.
That distinction matters.
I talked about this in my SaaStr presentation last week, and I’m going to publish a fuller write-up next week on how I think about AI-native GTM. One of the core ideas is simple: buy infrastructure, build (or at least own) your intelligence.
Buy the dialer. Buy the CRM plumbing. Buy the systems where uptime, reliability, compliance, and scale matter more than uniqueness. There is no prize for vibe coding mediocre commodity infrastructure.
But be very careful when the thing you are buying starts to encode how your company thinks, sells, scores, prioritizes, coaches, researches, forecasts, or wins. That is no longer just software. That is your operating intelligence.
And if a vendor owns that layer, you may be renting your GTM brain.
The AI stack has layers
I’m going to lay out some definitions for AI foundations and if you’re more well versed on the technical basics, feel free to skip this section. I think it’s important to have a mental model to reason through these decisions so understanding how these systems work at a basic level is more important than in previous GTM tech eras. I also see a lot of GTM leaders are using AI language without clear definitions and I think that can be dangerous because fuzzy language leads to fuzzy strategy. So here is the simple version.
The model is the LLM itself. GPT, Claude, Gemini, and the dozens of models that exist today or will emerge over the next few years. The model generates, reasons, summarizes, classifies, and uses tools when the surrounding system gives it the ability to do that.
The harness is the system around the model. It connects the model to your tools, prompts, files, databases, permissions, workflows, and state. Claude Code is a harness. Codex is a harness. OpenClaw is a harness. Agentforce, AI SDR platforms, AI coaching platforms, and many AI workflow products are harnesses in some form.
The best analogy (of many bad ones) I got from Kai (my OpenClaw) was this:
An LLM is like a wild, powerful stallion that’s fast, strong, and highly capable. However, trying to ride it bareback (using a "naked" prompt) results in an uncontrollable, chaotic journey. The harness represents the reins, saddle, and bit. It doesn't provide the muscle, but it gives the rider a predictable, repeatable mechanism to steer that raw power safely to a precise destination.
An agent is what emerges when a model and a harness are wired together to pursue a goal with some degree of autonomy. Instead of waiting for a human to prompt every step, an agent can decide what to do next, call tools, read and write data, and chain multiple actions together to get a job done. A simple agent might research an account and draft an email. A more sophisticated one might run an entire pre-call workflow (pulling signals, scoring fit, prepping the rep, sending an email to the prospect, and updating the CRM) and adjust its approach based on what it learns. The important point for GTM leaders is that the agent is not really the "smart" part. The intelligence comes from the model underneath, the harness around it, and the memory it can draw on. When a vendor sells you "an AI agent," they are really selling you a particular bundle of those three things, and the questions worth asking are about the bundle, not the label. Plus everyone calls basically anything with any amount of AI an “agent” now so the word is losing some of its meaning.
Context and retrieval is how the system finds the right information at the right time. The model does not know your company. It does not know your customers, your deals, your call history, your pricing exceptions, or what your best AE said on a Tuesday in March. Context and retrieval is the layer that goes and gets the relevant pieces and hands them to the model before it tries to do anything useful. In practice this involves embeddings, vector stores, ranking logic, and a bunch of decisions about what counts as relevant. You do not need to understand the plumbing. You do need to understand that the quality of an AI system is mostly a function of what it can see, not how smart the underlying model is. Two agents with the same model and very different retrieval will feel like two completely different products. This is also one of the most quietly proprietary layers in the stack. Whoever decides what your AI sees, decides what your AI knows.
Memory is what the system retains over time, and it is worth being precise here because "memory" actually covers three different things that behave very differently. For GTM teams, it has 3 very different layers:
1. Short-term state: the current conversation, open thread, task context, and whatever the agent is holding right now to get the work done.
2. Structured knowledge: your ICP, battle cards, pricing logic, qualification frameworks, account notes, and the artifacts your team actually maintains.
3. Long-term learned patterns: call patterns, objections, winning messages, lost deal reasons, and the thousand little signals the system picks up across thousands of interactions.
These layers are not equally portable. Short-term state is mostly disposable. Structured knowledge is easiest to own because it usually lives in docs and databases you control. Long-term learned patterns are the hardest and most valuable because they’re created through usage. And too often, they get trapped inside the vendor that generated them. That matters because as agents do more of the work, memory becomes more than a feature.
It becomes part of the company. Eli Mernit made the point that ‘Your company is a filesystem’ a few months ago in an X article that I shared a lot at the time and has stuck with me since. This is also where Harrison Chase’s point about agent harnesses becomes very relevant for GTM leaders. Harnesses are not going away. Even as models get better, they still need systems around them to connect to tools, manage context, retrieve data, decide what matters, and preserve useful memory.
Sarah Wooders made the related point that memory is not a plugin. Memory is part of the harness. I think that is exactly right. Asking to bolt memory onto an agent later is like asking to bolt driving onto a car. The way the system manages context and state is the foundation for what it can remember. That means your platform decision is also a memory decision.
Evaluation (evals) is how you know whether any of this is actually working. Evals are the structured tests, rubrics, labeled outcomes, and human feedback that determine what "good" looks like for your company. Did the AI coach catch the real coaching moment or a surface one? Did the AI SDR write a message your best rep would have sent? Did the forecasting agent flag the deal that actually slipped? Without evals, you are vibing. With evals, you have a feedback loop. And feedback loops are the entire point. This is arguably the most proprietary layer in the whole stack, because your definition of "good" is your company. Two GTM teams looking at the same call will not score it the same way, and they should not. The team that builds a sharp evaluation layer ends up with an AI system that gets better in their specific direction every week. The team that skips it ends up with a tool that is impressive in a demo and mediocre in production.
Why this matters for GTM
In GTM, memory is the accumulated intelligence of your revenue engine. It’s your frameworks, positioning, stack rankings, competitive battle cards, conversion data, enablement materials and more.
Think about an AI coach reviewing sales calls. At first, it might summarize calls, score talk tracks, or flag next steps. Useful, but not especially strategic. Over time, though, the system can start to learn which objections matter in your market, which discovery paths create momentum, which talk tracks sound good but do not convert, and what your best reps do differently from everyone else.
That memory is valuable.
Now think about AI pre-call research. The basic version pulls company facts, recent news, role context, and a few suggested talking points. The better version learns what signals matter for your ICP, which account changes actually correlate with buying intent, which research sources are noisy, and what kind of prep helps reps create better conversations.
That memory is valuable too.
The same is true for lead scoring, forecasting, account planning, outbound messaging, manager coaching, QBR prep, win-loss analysis, and pipeline inspection. Every serious AI workflow in GTM has the potential to create proprietary learning if it is designed correctly.
This is the real strategic question: where does that learning live?
If it lives inside your operating system, your data layer, your prompts, your workflows, your evaluation loops, and your internal knowledge base, it can compound. Every iteration makes the system sharper. Every workflow can teach the next workflow. Every rep interaction can improve the underlying intelligence. The future state the most sophisticated revenue teams are chasing is what I’m calling the Recursively Self-Improving Revenue System (or Level 4 from the Sophistication Ladder in my SaaStr talk).
This future is only possible if you can access and use the combined intelligence of your entire GTM engine. If it lives inside a vendor’s closed platform, you may get speed today and lose ownership tomorrow.
That is not always a bad trade. Sometimes speed is worth it. Sometimes a vendor is so far ahead that buying is clearly right. I am not religious about building everything internally (that’s usually a terrible strategy) and my opinions and our approach shift rapidly with the market.
But leaders need to understand what they are buying.
A tool that automates a workflow is one thing. A tool that absorbs your proprietary GTM intelligence is something else.
The build vs buy question is changing
The old build vs buy conversation usually centered on cost, implementation time, customization, and whether engineering had the capacity. Those still matter, but they are incomplete for AI.
