“I think that IP and software was effectively rendered worthless two days ago.”

That’s a direct quote from Chamath Palihapitiya on the All In podcast recently.

He goes on to say:

“If you think about it, when everything is headless, so when Elon makes his services headless, Benioff made Salesforce headless a few months earlier, when all of these things are headless and you can wrap them in agent tools and you can connect them via MCP to other experiences, the value of IP no longer exists in software. It doesn’t exist.”

This is one of the most well connected, ‘sees the future’ VCs and entrepreneurs on the West Coast.

It’s worth paying attention to, because I already see the writing on the wall for traditional GTM tooling, and it’s not just the VCs saying it.

Gartner put a number on it in July, reckoning up to $234bn of enterprise application spend is exposed between now and 2030 as agents complete tasks across multiple systems and people stop needing to open each app’s interface. Their MD, George Brocklehurst, said this “breaks the link between user growth and revenue growth” for a lot of software vendors, which, if you’ve ever sold a product priced per seat, is a fairly big deal.

Salesforce’s own Headless 360 launch in April made every capability it’s built over 25 years available via API, MCP or CLI, which is about as clear a signal as you’ll get from the biggest system of record in GTM.

The move towards a ‘headless future’ feels almost inevitable at this point; and it’s one of the reasons so many teams are doing build versus buy, because they don’t want to be tied into yet another proprietary UI and UX from the vendor.

What is ‘Headless’ software?

Headless means two things here. I’m predominantly arguing that the UI layer becomes irrelevant, but also that the data and logic should be decoupled from any single vendor’s interface, so that the core IP you develop from taking actions within your GTM playbook and system is bespoke to you, and not entirely tied to one particular system of record or one system of execution.

Why teams are building instead of buying

IP is a side point in this. Teams are building because they’re frustrated with clunky UX, with price, but most importantly, with poor adoption from their teams.

It takes so much effort to train teams on new ways of working, on navigating new and alien UX. Often it’s not very intuitive. Some of the team might get it, and of course there are always one or two champions who love it. But most are going to be on their guard, and they don’t want to change the way they’re already working in the systems they’re already working in.

Then the UX is almost never flexible enough to adapt to all the different ways of working, styles of working and preferences across a diverse team. But when it tries to become that complex, to accommodate all the different needs and wants and ways of working, it becomes way too complicated for anyone really to operate. That ends up being this terrible, clunky, “enterprise” type of experience that tries to accommodate too many things and ultimately ends up being a nightmare for anyone.

And then you end up having to hire full-time staff or agencies to manage that interface, which is a kind of crazy legacy redundancy of resource that I think will also start to go away.

It’s why, despite how much time, energy and effort has gone into building each wave of go-to-market systems of record and execution, whether that’s Salesforce or HubSpot or Outreach or SalesLoft etc, so many reps ultimately go back to manual processes and/or something completely adaptable to them, like Google Sheets or Excel, where it’s a blank page for them to use how they want and need, without having to figure out a UX that doesn’t suit them or meet their needs.

Salesforce’s own data more or less says the same thing. Their State of Sales report this year found reps still only spend around 40% of the week actually selling, 42% feel overwhelmed by too many tools, and 51% of sales leaders already using AI say tech silos are delaying or limiting it, which is a slightly awkward finding when you’re one of the companies selling those tools.

One agentic infrastructure, wherever your reps already work

The obvious objection is that going headless and building your own just trades a vendor’s clunky UX for a bespoke system only its builder understands, another Frankenstein of stitched-together tools.

Not if the sales team can interact where they’re already comfortable. That’s one of the major benefits of the move towards headless go-to-market: the skills layer, or the layer of action, can be pushed and pulled on in any other tool that individuals across the GTM team use regularly.

That may be Slack or Teams. It could be WhatsApp, could even be phone calls, could be in Gmail or Outlook, could be Google Sheets again. Wherever they’re most comfortable and spend most of their time is where you want to make it easy for them to access the GTM agents that run under the hood.

That’s the point about decoupling the logic and the data from the UI.

Very importantly, there does need to be a company context layer and an individual context layer that feeds into the execution layers, so it always has the correct context and guardrails in which to operate, which somewhat gets harder without the hard parameters set by a UI. But so long as it’s set up correctly, it’s very achievable.

This way, you’re not building a Frankenstein, stitching together lots of different tools per se. You’re actually building one set of agentic infrastructure that works headlessly wherever the end user needs it.

Gartner landed in pretty much the same place in July. They’re predicting agents will outnumber sellers 10 to 1 by 2028, yet fewer than 40% of sellers will say the agents improved their productivity, and their advice to CSOs is to build a centralised context layer that connects enterprise data, systems and seller judgement so the agents produce something relevant to the business.

My guess is a lot of that productivity gap comes down to agents being bolted onto an existing stack without that layer underneath.

But of course, someone has to architect and govern that context layer, or the guardrails don’t get set and the whole thing fragments.

And most companies aren’t there yet: a Gartner survey of over 2,000 CIOs this year found 71% expect to deploy agentic AI in the next 12 months, but only 21% have agentic AI governance in place.

This is where you need a great RevOps resource, or ideally a GTM Engineer, who can architect that for you, with the team interacting through whatever surface they’re already in.

What a GTM Engineer actually builds

First, the context layer: ICP, messaging, positioning, battlecards, tone of voice and so on.

It’s more than that, though. It’s also the continuous updating of that context layer by capturing what’s happening throughout the organisation. As the CRM is updated, as Notion is updated, as team meetings happen and decisions are made, as revenue data, win data, loss data and competitive data stream in, it’s really important that all of it gets captured, codified, normalised and presented back to the leadership team, so they can make final decisions about whether it goes into the canonical version of the context layer.

That normalising bit matters more than people think. Validity’s research this year found 62% of organisations are losing revenue directly because of poor CRM data quality, and that problem doesn’t disappear just because there’s an agent on the other end of it, if anything it gets amplified.

There’s an awful lot of complex work in capturing the myriad decisions and actions taking place across the organisation that lead to further decisions, planning and strategy.

Then it’s about making sure all the right agentic intelligence is in place, so that the various actions you’d want AEs, BDRs, marketers and CS to tap into are capable, well trained and well configured: they know what they’re doing, what they shouldn’t be doing, and how to do it. They should have a standard operating procedure that’s well codified into their ways of working.

In many respects, it’s like onboarding and continuously training and coaching a set of employees.

It’s also important that the agents have access to the additional point solutions and systems they need to go and execute their work. Which often means lots of integrations: checking data and field maps correctly, making sure they can’t go outside the confines and boundaries they’re set, and can’t bring in external data or sources that may produce worse outcomes rather than better ones. So you’re making sure you’ve got the right operational guardrails and coding in place.

And then, from a cost perspective, it’s making sure the agents are drawing on the right models when they run their tasks. Essentially, making sure they’re not using something like Opus 5.5 for absolutely everything they’re doing, when they may need a smaller model like Sonnet for simpler reasoning. Or, where there are quite set boundaries around what they’re trying to achieve, it can be done deterministically using something extremely cheap, or possibly even more simply, just hard-coded into the operating system.

Those are the types of things a good GTM Engineer will be owning and working on.

What changes when you’ve got one

This isn’t theoretical.

I recently looked back at 250 calls across dozens of orgs to create a report on ‘What actually stops AI in go‑to‑market‘.

3 of the companies in the report had an AI GTM engineer embedded inside the revenue team, and the difference was pretty stark. 78% of their AI work was team-wide or custom-built, against 52% everywhere else, custom workflows made up 22% of it compared with 7% elsewhere, and only 23% was stuck at autocomplete-level use, where everyone else was at 48%.

In plain terms, those are the teams that stopped using AI to draft emails a bit faster and started building their own GTM system around their own process, which is exactly what a headless setup is meant to give you.

Where does your team sit?

If you’ve read this far and recognised your own stack somewhere in it, there are 2 things worth doing.

The first takes a few minutes. Score your team against the 15 frictions from the report, and it’ll tell you whether you’re ready to start building headlessly or whether the layer underneath needs fixing first, because any new tool, headless or not, will inherit every one of those problems.

The second is a 30 minute call with me. We’ll work out which tier your team is at today, which frictions are keeping it there, and what a headless GTM setup would look like for you.

If it makes sense to embed an AI GTM engineer to do the build, we can talk about that too, but you’ll leave with a clearer idea on how to build towards the future either way.