A week ago I posted that Sam Altman is showing GPT-6 to Washington before he shows it to the rest of us, and I listed the six things we already seem to know about it. It made an original scientific discovery. It solved an eighty year old maths problem on its own. It runs for hours with nobody watching. The line in that post that pulled the most replies was the last honest one. We built our whole core system on Claude this year, and I would still bet that GPT-6 ends it for Anthropic. The post took 279 reactions and 116 comments, and almost every reply circled the same worry. If the best model keeps changing, how do you build anything on top of it. This article is that answer, written for anyone building a go to market engine.
I run Growth Cab, a GTM advisory. We put AI inside outbound, research and reporting for B2B teams selling contracts above fifty thousand dollars. So the question of which model to trust is not academic for me. It decides whether the system we shipped in March still works in September. Here is how I think about it now, after getting it wrong for most of a year.
in
“We built our whole core system on Claude this year. And I would still bet that GPT-6 ends it for Anthropic.”
How to Build an AI GTM Stack That Outlasts One Model
The mistake I made for months was treating the model as the foundation. We picked Claude, we built on Claude, and every prompt, every workflow, every integration quietly assumed Claude. It felt like commitment. It was actually a single point of failure. The day a better model arrives, or the one you chose gets quietly worse, the whole thing is exposed. If you want to know how to build an ai gtm stack that lasts longer than one release cycle, the first rule is uncomfortable. The model is the most replaceable part of the system, so you build it to be replaced.
Think of the model the way a good engineer thinks about a cloud region. You would never write code that only runs in one data center and can never move. You keep the thing that does the work separate from the vendor that happens to host it this quarter. The same logic applies here. The value your stack creates should live in the layers around the model, so that swapping the model is a small job instead of a rebuild.
The Three Layers, and the One You Should Never Hardwire
Every AI GTM stack I have built or repaired comes apart into three layers. Get the boundaries between them right and the model risk from that GPT-6 post mostly goes away.
The data layer is your accounts, your signals, your CRM, your enrichment. It is the slowest to build and the most valuable, and it has nothing to do with which model you run. Own it completely. If your data only exists inside a vendor's tool, you do not have a data layer. You have a rental you can be evicted from.
The logic layer is your actual plays. The way you score an account, the brief you hand a research task, the rule for who gets an email and who gets a call. This is your company written down, and it should live as readable prose and structured rules that any capable model can execute. When it sits in a document you control instead of inside one model's memory, you can hand it to a new model in an afternoon.
The model layer is the part everyone obsesses over and the part that matters least to your defensibility. It is a swappable engine. Today it is Claude, tomorrow it might be GPT-6, next year something with no name yet. If your data and your logic are clean and portable, the model becomes a setting you change instead of a foundation you pour.
What Building It This Way Looks Like on a Revenue Team
On a normal morning our stack runs four jobs. One agent researches a fresh account list. One drafts first touch emails off that research. One reads yesterday's reply data. One writes the pipeline note. None of those jobs is welded to a particular model. The brief for each one is written in plain language and stored where we control it. When we tested a different model last month, moving one of those jobs across took under an hour, because the job was defined by our logic rather than by the tool.
Contrast that with the version of us from a year ago. Back then the research prompt had model specific phrasing baked into it, the reply parser assumed one output format, and nobody had written down why the account scoring actually worked. Moving anything meant rebuilding it from memory. That is the real cost of hardwiring a model. The real cost is not the license fee. It is the rebuild you pay for in lost weeks.
There is a quieter benefit too. When your logic lives outside the model, it accumulates. Every good brief we write gets reused and sharpened, and it keeps working no matter which engine runs it. A stack that is welded to one vendor cannot compound like that, because half of what it knows is trapped in a place you do not own.
Where Building an AI GTM Stack This Way Breaks Down
I am not going to pretend this is free or that portability solves everything. Three places it gets genuinely hard.
The first is that models are not actually interchangeable at the edges. Two of them will follow the same brief and still hand back different tones, different formats, different failure modes. Portable does not mean identical. Every time we move a job we re read the output for a week before we trust it, because a silent quality drop is worse than an outright break. That GPT-6 post also mentioned Fable 5 getting quietly nerfed, and that is exactly the kind of change you only catch by watching the work, never by reading a changelog.
The second is that keeping the model at arm's length costs a little performance. A prompt tuned obsessively to one model will usually beat a neutral one on that model. We give up a few percent of polish for the freedom to move. On most GTM work that trade is obviously worth it. If you are doing something where the last five percent is the whole game, it might not be, and you should know that going in.
The third is discipline. It is genuinely easier to paste vendor specific tricks into your prompts and let your logic live inside one tool's memory. Portability is a habit you have to keep choosing, and the first afternoon you are in a hurry you will be tempted to weld something in. We still catch ourselves doing it. The stack stays portable only because we treat that as a hard rule rather than a preference.
So the honest answer to the worry under that GPT-6 post is that you do not build on a model at all. You build on your data and your logic, and you let the model be the easy part to replace. Altman may well be right that the next thing is a real jump rather than another small step up from ChatGPT. If he is, the teams that win will be the ones who can pick it up in a day, because they never bet the company on the last one.
I write up the systems we actually run at Growth Cab in The Revenue AI Brief, one play a day. The original post, with the full list of what GPT-6 can reportedly do, is on my LinkedIn.
