This newsletter is sponsored by Miro - the collaborative workspace where agents and teams converge to think, decide, and build together.
Miro’s MCP has become one of my favorite tools in the AI stack right now. Point Claude, Codex, or whatever agentic tool you’re already using at it, and instead of getting handed copy, you get a built board - ready to review with your team, right inside your workspace.
I use it to turn messy planning conversations and research docs into something that I can actually align on with my team members and clients. A perfect antidote for endless comment threads and AI-generated docs that no human will ever read :) You can check out how I use it in my latest video.
Dear GTM Strategist,
You know this story. Maybe you are living it.
In 2025, you bought an AI SDR platform and then the coaching tool; both tools promised to “transform your GTM”.
Then you invested heavily in enrichment tools and orchestration, trying to bring all the pieces together until you realized in Q1 2026 that you should double down on context engineering and start building your own GTM brain.
Six months later, the pipeline number stayed pretty much the same, and the big boss is 😡: where is the ROI ???
Instead of fingerpointing about which vendor did not deliver on its flashy demo - here is something to REALLY think about: what if all the tools and concepts are just fine, and all we were missing is a layer of control/constrain that would finally bring order in our GTM AI stack chaos.
And before you roll your eyes, “is this another expensive tool?” read this one from Kyle Norton, CRO at Owner.com and host of The Revenue Leadership Podcast.
He calls the missing layer in our stacks the GTM Harness.
And you probably already have a harness - but did you build it on purpose, or is it some combo of prompts guiding the AIs?
In this post, you’ll learn:
What a GTM harness is
Which parts of it to build, and which to buy
How two AI-native GTM teams (Owner and Cursour) built theirs in opposite ways
Who should own the harness inside your GTM org
A six-question audit to run this week
Gitty up 🏇
What Is a GTM Harness?
An LLM on its own knows very little about your business. It has never seen your pricing exceptions, your best rep’s discovery call from March, or the real reason you lost that deal in Q2.
Kai, Kyle’s OpenClaw, put it brilliantly (as quoted in his post):
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 AI explaining what AI needs from you. I enjoyed that more than I should have.)
So the harness is the system around the model. In Kyle’s definition, it is what connects the model to your tools, prompts, files, databases, permissions, workflows, agents and state.
This means you most likely already have components of a harness, whether you intended to or not. Every AI tool you purchased, every Salesforce query you let reps run, every integration you set up. Those are components, and they add up to a system whether or not anyone drew it.
Kyle put it plainly in our chat:
As GTM leaders, what we are doing with our AI investment and now with our RevOps investment, we are building harnesses. We are building sets of tools and permissions and prompts around this superpowered intelligence.
Most teams are assembling those one tool at a time, but this is what raises the stakes. The harness isn’t merely how the model reaches your tools, it’s where your company’s knowledge lives.
Your ICP, your battle cards, your qualification logic, which objections actually matter in your market, which talk tracks sound good and never convert. And this is not something you add later.
Sarah Wooders made the point that memory is not a plugin, and Kyle’s take is that memory is part of the harness itself. Asking to bolt it on afterwards is like asking to bolt driving onto a car.
So the harness holds two things at once: how your AI works, and what your company knows.
Which is why the build vs buy question feels harder than it used to. You are not choosing a tool. You are deciding who gets to keep what your team learns.
Which Parts of Your Harness Should You Own?
Kyle’s take on this is (as voiced on stage at SaaStr): buy your infrastructure, build or own your intelligence.
The old build vs buy conversation was about cost, timeline, customization and whether engineering had the capacity. Those still matter. They stopped being what decides it, for two reasons.
The first is that building got cheap. What used to be a six-figure vendor contract and a two-quarter roadmap can now be a working prototype by Friday.
The second is somewhat more important. Software used to sit still: your dialer dialed, and it never got smarter. Now, with the intelligence layer, it does. The work and the learning arrive bundled.
Kyle’s test for this is one you can run yourself this afternoon. Take Claude: same model underneath, two products.
The consumer chat app is constantly learning about you. Your writing, your preferences, the things you keep coming back to. Ask it something six months in and the answer is shaped by everything it has picked up. It genuinely gets better. Now try to look at what it knows. There is no page that shows you your own memory.
Then go to Claude Code, running in a terminal on your desktop. It writes files directly to your computer. You can open them, read them, reorganize them. You can even sync them to a GitHub repo, so anything you build later can read them.
Same tool. Same intelligence. Opposite ownership.
One learns about you somewhere you cannot open. The other writes it down where you can read it, edit it, and point other tools at it.
Now scale that up to your revenue engine:
If you’re using a tool that is learning about your customer and learning about the messaging that sticks and learning about the optimal sequence to reach out to people, but you can’t look in and understand what those answers are and then take them somewhere else, I in general want to be pretty wary of that as an architecture.
Of course, sometimes renting is the best choice. Let’s say, when the software vendor is genuinely ahead and the alternative would be nine months building something worse.
Just make it a decision somebody made deliberately, rather than one that happened to you because the demo was good.
And one thing that gets misread constantly: own does not mean build from scratch. You can buy a component and still own what it produces, as long as you control the data, understand the logic, can export the memory and can move the learning when you need to. The inverse is also true, and this one stings. You can build something entirely in-house and still fail to own it, if what you built is a fragile one-off that nobody left in the building understands.
Two Teams, Two Very Different Harnesses
Let’s make this more concrete with an example. Take two of the most AI-native GTM teams in the market. Opposite architectures. Both own their intelligence.
Owner.com pre-loads. Their data team built a GitHub repo of skills that teach a model how to query Snowflake properly. Which tables are which, what the fields mean, how to interpret them. Kyle is candid that it is early days, “fairly grassroots” in his words, but the discipline is deliberate: everything goes into GitHub so a human can inspect what exists, and he will not run tools whose output he cannot see.
Cursor does the opposite. George Hou, their Head of Enterprise Growth, built an internal system called ChatGTM for a sales org of roughly 400 people, and explicitly rejected the repo approach. There is no pre-loaded context library. ChatGTM queries Salesforce, Gong, the warehouse and the open web at the moment a rep asks, pulling context on demand rather than maintaining it in advance. Brendan Short covered the full build here, and it is worth your time.
In short, this is when to use which:
→ Pre-load anything that is judgment-heavy but stable, e.g., how you sell, what good looks like, which of your fields lie to you.
→ Fetch live what changes often and already lives in your system of record, e.g., deal state, usage signals, call history, who joined the account last week.
Most teams need both. What you cannot do is copy one company’s architecture and expect the same result. Cursor’s version sat on top of years of context-engineering muscle they happened to have, because building Cursor required exactly that skill. Owner.com’s sits on a data team that had already done the unglamorous work of making Snowflake legible to a model.
The architecture is the visible part. The capability underneath it is what took the time.
Who Should Build Your Harness?
Short answer: not the person you are probably thinking of.
“GTM engineer” has come to mean someone good at Clay tables who builds lists and a few automations. Useful. Not this. Kyle calls his function applied AI on purpose, specifically to draw that line.
What the job actually needs is someone who can hold the whole system in their head:
You need somebody who can be an architecture thinker. They need to be able to understand and zoom out and think through how all of these things connect.
For instance, Owner.com hired a former founder who had previously started a couple of companies in GTM tech, someone who already understood the landscape. Kyle is blunt about the alternative:
Somebody junior and scrappy is probably not going to figure out this broader image. It has to be a real systems thinker.
But the trait that matters most is not technical at all. They have to want to sit with managers and reps, because that is where the requirements actually come from.
The obvious objection is cost. These people are expensive, and most GTM leaders assume they are a Series C problem.
Kyle’s math says otherwise.
Say you have ten BDRs at roughly $100k each. That is a million dollars a year already committed. An applied AI lead runs $250-400k. If that hire makes those ten BDRs 50-80% more effective, you have effectively bought yourself several hundred thousand dollars of BDR capacity without adding headcount. And every BDR you hire afterwards inherits the improvement.
So you have the harness, you have the person to build it, and you have the budget approved. That is when the actual problem shows up.
Building Is Not the Hard Part
Now, let’s get a little bit more practical here.
Kyle has long wanted a system that could tell a rep exactly what to say on a specific call. Not a generic script. The actual opening for this prospect, on this day.
The first version is deliberately simple. It gives the rep the customer closest in geography to the prospect, so they can name-drop someone local. It surfaces a pain tied to what the prospect is already using. It adds one observation from their website. The rep opens with something like: I see you’re using X, and the people I talk to on X usually tell me Y. Is that true for you too?
That system took about a week to build.
It took a few months to get adopted.
It turns out building is not the hard part. The adoption is.
This is where most AI investment quietly dies. The tool works, the demo went well, and six months later the pipeline number has not moved. Kyle’s diagnosis is uncomfortable:
You’re using AI to scale a bunch of stuff that is only mediocre.
Ask him where GTM leaders will waste money over the next year and he does not say the wrong category or the wrong vendor. He says tools that never get used. You are better off with fewer tools and much better adoption.
So how did Owner.com get theirs adopted?
Set the frame before you ship anything. If your team believes AI is coming for their job, they will not lean into it. Kyle’s stance has been the opposite from the start: AI takes away the parts of the job nobody wanted, so reps spend more time with customers and closing. Almost every early investment at Owner.com was aimed at helping reps make more money, not at cutting headcount. That is a culture decision made long before the tool exists.
Pilot with four top reps. Not volunteers, not the strugglers. The reps everybody else is chasing. If those four say this is great, adoption stops being a mandate and becomes something people want.
Sit next to them while they use it. When Owner.com built pre-call research, the applied AI lead flew to Toronto and spent a week beside the reps. Hand them a batch of leads, watch them work it, hear “this is wrong, and here’s why,” go fix it, hand them a fresh batch. The feedback from those sessions is the product.
Give them at-bats before they go live. Owner.com uses Avara so reps can practice a new motion with the AI rather than real buyers. Managers join them during rollout and coach in the moment.
Measure it where it counts. Instead of logins or usage dashboards, keep track of call volume, conversion rates, meetings booked, pipeline. In the pre-call research pilot, those 4 reps made noticeably more calls and converted them at a higher rate, thus earning the rollout.
Which brings us to the part I keep thinking about.
Owner.com gets a lot of attention for the AI they have built. Kyle says that is not what makes it work:
Our secret sauce is our learning and development environment. It is the caliber of first and second-line sales leader that is able to bring these tools to the rep and change their behavior rapidly.
He knows people who have built things just as good as Owner.com’s and got none of the results, because they could not drive the change.
The harness is the easy half. The people holding the reins are the rest of it.
GTM Harness Audit Checklist
Everything above assumes you know what you are working with. Most teams do not, which is not a criticism. The harness got assembled over eighteen months of reasonable decisions made by different people for different reasons, and nobody was ever asked to hold the whole picture.
So before the roadmap, the vendor shortlist, or the hire, spend an hour on these six questions. Run them against what you already own, not just the next thing you are about to sign.
Most teams will not like their answers to three and four. That is fine. Knowing where you actually stand is a better starting position than a roadmap built on assumptions.
Where This Leaves You
The companies that win AI-native GTM will not have the most tools. They will be the companies whose systems get smarter every week because they own the memory that matters.
I’d add one thing. Owning the memory gets you nowhere if nobody touches the system. And a well-adopted tool is a liability if you can’t see what it’s learned about your customers.
You need both. Most teams have one.
So pick the thing you have been avoiding:
→ Nobody can name every tool touching your customer data? Start with the audit.
→ Reps quietly working around something you shipped? Go sit with them for a week.
→ About to sign a platform that will learn how you sell? Ask where that learning lives. Before you sign.
The only thing that helps is action. Pick one, do it this week.
Don’t build everything. But don’t buy your brain either.
Now I want to hear from you. What is the AI tool you bought that nobody uses, and do you know why? Hit reply, I read everything.
Huge thanks to Kyle Norton for the conversation. Go read Don’t Buy Your GTM Brain and subscribe to The Revenue Leadership Podcast. And if you want the full story on what Cursor built, Brendan Short’s piece on ChatGTM is worth your time.
✅ Need ready-to-use GTM assets and AI prompts? Get the 100-Step GTM Checklist with proven website templates, sales decks, landing pages, outbound sequences, LinkedIn post frameworks, email sequences, and 20+ workshops you can immediately run with your team.
📘 New to GTM? Learn fundamentals. Get my best-selling GTM Strategist book that helped 9,500+ companies to go to market with confidence - frameworks and online course included.
📈 My latest course: AI-Powered LinkedIn Growth System teaches the exact system I use to generate 7M+ impressions a year and 70% of my B2B pipeline.
🏅 Are you in charge of GTM and responsible for leading others? Grab the GTM Masterclass (6 hours of training, end-to-end GTM explained on examples, guided workshops) to get your team up and running in no time.
🤝 Want to work together? ⏩ Check out the options and let me know how we can join forces.
Love the harness diagram! For Memory & Context., I wonder if those eventually need to become two separate layers.
In my experience, context helps the agent make the current decision: account state, ICP, pricing, objections, recent calls. Memory preserves what the system learned from prior decisions: why a rule changed, what evidence caused it, and whether the change actually improved the outcome.
Once reps create their own skills and automations, that distinction feels more important. Otherwise the harness can accumulate more information without necessarily getting better at deciding what should persist. Curious how you and Kyle are thinking about that separation.
The "did you build it on purpose, or is it a combo of prompts" line is the whole game. The teams I've watched get real leverage treat the harness as a context asset they curate — the lost-deal reasons, the pricing exceptions, the good discovery calls — and version it deliberately, rather than letting it accrete inside prompt strings no one can audit. Your build-vs-buy split maps cleanly onto that: buy the retrieval plumbing, build the context curation, because that's the part no vendor can know for you. Curious which of your six audit questions best predicts whether a team actually owns its harness versus just having one.