Go count the SaaS tools your GTM team pays for. Not the ones in the deck. The ones actually running. The ones someone signed up for eighteen months ago that still bill the credit card even though the champion left. Now count how many of them share data without someone manually exporting a CSV.

That gap between “tools we pay for” and “tools that actually talk to each other” is the most expensive line item nobody tracks.

The Garage Problem

Every GTM team I have worked with over the past 21 years has the same issue. It looks different at every company, but the shape is identical.

It starts with a problem. Pipeline visibility is bad. Someone buys a tool. Content production is slow. Someone buys a tool. Competitive intel is stale. Someone buys a tool. Customer health scores are unreliable. Someone buys a tool.

Each purchase made sense at the time. Each vendor demo was convincing. Each implementation had a champion who cared. And now you have 14 tools across marketing, sales, CS, and RevOps that were never designed to work together, connected by integrations that break quarterly, managed by people who spend half their time maintaining the plumbing instead of doing the work the tools were supposed to make easier.

This is not a technology problem. It is an architecture problem. And the entire GTM industry has been pretending it is normal.

I can say this with confidence because I was one of the people pretending. I signed the contracts. I championed the tools. I sat in the QBRs and told my team the new platform would fix the data problem. Three of those tools are still billing my old company’s credit card right now, and I am not sure anyone knows the login.

The Market Map Illusion

You have seen the market maps. The ones with 150 logos arranged in neat categories. CRM. Marketing Automation. Sales Engagement. Revenue Intelligence. Conversational Intelligence. Customer Success Platform. ABM. Content. SEO. Competitive Intel.

They look organized on a slide. They feel chaotic in practice.

Here is what actually happens when you run a GTM operation across those categories:

Data lives in silos. Your CRM knows about deals. Your marketing automation knows about engagement. Your CS platform knows about health scores. Your content tools know about performance. None of them know about each other. The competitive intelligence your analyst gathered last Tuesday lives in a Google Doc that three people have read.

Integrations are duct tape. Zapier, native connectors, custom API work. They move data from point A to point B, but they do not carry context. A lead score in your MAP tells your CRM a number. It does not tell your sales team why that number is high, what content the prospect engaged with, or what competitive alternative they were evaluating.

Signal loss is the default. Every handoff between tools loses information. Marketing qualified a lead and passed it to sales. What was the qualification signal? It is in the MAP, but the AE is in the CRM. The customer told your CSM something important on a call. It is in the conversational intelligence tool. Your product team will never see it.

Nobody owns the whole picture. Each tool has an admin. Nobody administrates the system. Because there is no system. There is a collection of tools.

What This Actually Costs

The direct costs are obvious. License fees stack. A mid-market GTM team easily spends $200K-$400K annually on SaaS subscriptions across these categories. Enterprise teams spend millions.

But the indirect costs are worse:

Time tax. Your ops team spends 30-50% of their time on integration maintenance, data hygiene, and tool administration. That is your most strategic team doing janitorial work.

Decision latency. When a signal has to travel through three tools and two manual handoffs before it reaches the person who can act on it, you are making decisions on stale information. Every time.

Context collapse. The thing that makes your business distinctive -- your market knowledge, your customer relationships, your competitive position -- gets flattened into whatever fields the tool allows. Your institutional intelligence lives in people’s heads instead of in the system.

Training drag. Every new hire learns 8-12 tools. Every tool update resets muscle memory. Every tool switch requires migration. The switching costs are so high that teams stay on bad tools because moving is worse than suffering.

The Question Nobody Asks

Here is what I kept asking myself across two decades of GTM work: why do we accept this?

Why do we accept that marketing, sales, and CS should operate in different software environments? Why do we accept that “integration” means a fragile API connector instead of shared context? Why do we accept that every department has its own version of the truth?

The answer is that we did not have an alternative. The SaaS model was the best we had. Best-of-breed tools in each category, connected by integrations, managed by ops teams. That was the architecture. It was the only architecture available.

It is not the only architecture available anymore.

What is behind the paywall: The five-step Tech Stack Audit framework I use to diagnose exactly where signal dies in a GTM stack, the thesis that ties this entire series together, and a paid subscriber resource -- a complete Tech Stack Audit Interactive Guide you can run with your ops team this week.

The diagnosis above is free. The prescription is for subscribers.

Read more

“We’re not even using AI that well yet,” he told me. “But the board read the Block announcement and now everyone’s counting heads.”

This is the moment we’re in. And I want to be honest with you about how strange and how consequential it is.

The Block Signal and What It Actually Means

Jack Dorsey didn’t dress it up. When Block cut from 10,000 to fewer than 6,000 employees this month, he said: “This is not driven by financial difficulty, but by the growing capability of AI tools to perform a wider range of tasks.”

Read that again. He’s not saying AI replaced those roles. He’s saying he believes it will.

Oracle followed the same week: 20,000–30,000 cuts to free up $8–10 billion for AI infrastructure investment.

And here’s the data that makes this stranger: 45,000 tech layoffs in March 2026. 20% explicitly attributed to AI — up from less than 8% last year. But at the same time:

• Only 14% of organizations have AI solutions ready to deploy

• Only 11% are actively running AI in production

• 76% are deploying or implementing agentic AI in theory

Companies are restructuring for a capability that hasn’t fully arrived. The expectation of AI performance is driving business decisions faster than AI performance itself.

This has never happened before. In every prior technology wave — cloud, mobile, SaaS — companies restructured after the technology proved itself at scale. This time, the restructuring precedes the proof. The expectation economy has arrived.

And if you run a GTM organization, you have a decision to make before someone makes it for you.

The 65-Point Gap Nobody Is Talking About

Here’s the number that should keep every executive up at night: the gap between intent (76% deploying agentic AI) and reality (11% in production) is 65 points.

Sixty-five percent of organizations are somewhere in between — buying tools, running pilots, writing policies, reorganizing teams, reallocating budgets — but not actually running AI-powered workflows at scale.

They’re paying for the transition without getting the performance. That’s the worst possible position. You have the cost of change without the benefit of capability.

Why does the gap exist? Three reasons, and they’re all fixable with the right architecture:

Data quality. Organizations are committing to agentic AI workflows faster than they’re addressing the data quality those workflows require. An AI agent is only as good as the signals it runs on. If your CRM is 60% accurate, your AI-powered outreach is 60% accurate — and it’ll move 10x faster than a human in the wrong direction.

Integration depth. Demandbase’s new B2B AI GTM Report found that integrating CRM, marketing automation, predictive scoring, and advertising tools into a unified stack boosts conversion rates 53%. Most companies have those tools. Almost none have them fully integrated. You’re not missing software — you’re missing connective tissue.

Governance frameworks. 76% of GTM leaders are deploying agentic AI at a faster rate than they’re establishing the governance frameworks those deployments require. No decision rules. No escalation logic. No human-in-the-loop design. Just agents running in the wild.

The companies that are winning — the ones in that 11% running AI in production — aren’t doing something heroic. They built the infrastructure first. They didn’t skip the connective tissue.

Check out the Claude Cowork and Code Guides for Go-To-Market Below

Click Here

What the AI-Native GTM Org Actually Looks Like

Read more

It’s not transformation. It’s decoration.

And the companies that figure this out—that actually restructure around AI instead of just buying AI-flavored SaaS—are going to have a competitive advantage that’s very hard to close.

The signal is always the same: the early movers don’t wait for the market to package the thing for them. They build the capability themselves, internally, before it becomes table stakes.

Right now, that capability is the Agent Builder.

The Math Changed and Nobody Updated Their Playbook

Buying AI-powered versions of the tools they already have.

New CRM? It has AI baked in. SEO tool? AI-powered. Social listening platform? AI-enhanced. Email sequencer? Copilot included.

The category names are new. The underlying model is identical: pay a vendor, get a tool, add it to your stack.

This made sense when AI was genuinely hard to implement. When you needed a team of engineers and weeks of fine-tuning just to automate a simple workflow. That era lasted maybe 18 months. It’s over.

What changed isn’t just that models got smarter. It’s that agent platforms got accessible enough that a sharp, workflow-minded generalist can build something genuinely useful in a day or two. Not a toy. Not a demo. Something that runs autonomously, handles edge cases, and generates actual output.

The AI agents market is projected to grow from $7.84 billion this year to $52.6 billion by 2030—a 46.3% CAGR. That’s not a trend. That’s a structural shift in how work gets done. And by end of 2026, 80% of B2B sales interactions are expected to be AI-powered.

The companies building this capability internally are going to capture the value. The companies buying it from vendors are going to pay a premium for someone else’s version of what they could have built themselves.

What the Agent Builder Actually Is

The Agent Builder isn’t a developer. They’re not a data scientist. They’re not an ops coordinator who learned to use ChatGPT.

The best Agent Builders live at a very specific intersection: they understand workflows deeply—what humans actually do, step by step, in a given function—and they can translate that into agents that do those same tasks autonomously.

The key word is autonomously. Not “with AI assistance.” Not “AI-augmented.” Autonomously.

Their mandate is simple: find manual workflows and SaaS subscriptions that can be replaced by agents, and build the replacements. Run discovery across teams. Understand inputs and outputs. Build, test, deploy.

But here’s what separates this from a tech project: they’re accountable for the business result. Not “the agent runs.” But “we cancelled that $2,400/month subscription” or “we eliminated 12 hours of manual data work per week from the growth team.”

This is a full-time role. It needs to be. Because the backlog of replaceable workflows and cancellable SaaS subs in your company is enormous—you just haven’t mapped it yet.

The Evidence Is Already In

This isn’t theory. The data is coming in fast and it’s unambiguous.

Owner.com ran a two-week pilot with AI agents in their BDR function. The result: 85% improvement in decision-maker connects. Their reps now operate 3-4x more efficiently than competitors. Two weeks.

Klarna achieved a 152% increase in revenue-per-employee without proportional headcount growth. They didn’t hire their way to efficiency. They built it.

The GTM Engineering talent pool—people who build at this intersection of revenue and automation—expanded 45% in just three months, with 1,570 new profiles entering the market. The role is real and the market is responding.

And here’s something I can speak to directly: I currently manage 93 specialized AI agents across 12 departments with 11 live integrations. One operator. Ninety-three agents. That’s not a future scenario. That’s my Tuesday.

Why GTM Gets Hit Hardest

Go-to-market is where this lands first and lands heaviest. And it’s where most leaders are the most behind.

Think about what your GTM stack actually looks like. Intent data. Social listening. Competitive intelligence. User feedback analysis. Email sequencing. Pipeline analytics. Content production. Prospect research.

How many of those are candidates for agents?

All of them. Every single one.

That doesn’t mean you flip a switch and cancel everything tomorrow. It means you have a strategic opportunity to systematically replace vendor dependencies with internal capabilities that are faster, cheaper, and tailored to your specific business context.

VP RevOps titles have grown 300% in the last 18 months. That’s the market telling you that companies are centralizing operational control. But the smart ones aren’t just hiring RevOps leaders to manage the existing stack—they’re hiring them to replace it.

Anthony Enrico from Leanscale said it plainly: “The Salesforce admin role is gonna die.” Nico Druelle at Revenue Architects went further: “RevOps staying at the surface—dashboards, reporting, CRM admin—AI will do most of that. That whole layer disappears.”

They’re not being dramatic. They’re describing what’s already happening.

The Compound Effect

Here’s what most people miss: it’s not one subscription or one workflow. It compounds.

Every agent you build is a fixed cost that replaces a variable or recurring cost. The agent doesn’t need a seat license. It doesn’t need a renewal negotiation. It doesn’t have a per-user pricing model that punishes you for growth.

And the Agent Builder doesn’t build one agent. They build a system of agents. A coverage map across your company where manual work and SaaS dependencies get methodically replaced.

At the end of a year, a good Agent Builder has replaced 6-12 SaaS subscriptions, automated dozens of manual workflows across multiple functions, and created a compound cost advantage that keeps widening as the company scales.

That’s not a technology project. That’s a structural change to your operating model.

Why This Changes What You Hire For

If you’re a GTM leader, this should change how you think about headcount.

The old question: “Do we need another SDR, another analyst, or another ops person?”

The new question: “Do we need an Agent Builder who can eliminate the need for three tools and two manual processes in their first quarter?”

That’s not hyperbole. That’s the ROI profile I’m seeing from early adopters.

Your SDRs shouldn’t be doing research. Your analysts shouldn’t be pulling reports. Your ops people shouldn’t be manually QA-ing data. Agents can do all of that. Your humans should be doing the things that compound over time—building relationships, making judgment calls, creating strategy, running experiments. That’s where human time has the highest leverage.

The Moat Nobody’s Talking About

Software can be copied. A workflow built on a shared SaaS platform can be replicated by anyone with the same subscription.

An internal agent system? That’s built on your specific data, your specific workflows, your specific context. It gets better the longer it runs. It compounds knowledge. It surfaces insights that a generic tool was never designed to surface.

The company that has an Agent Builder working for 12 months has a capability advantage that a competitor can’t buy off the shelf. They can buy the same agent platform. But they can’t buy your 12 months of workflow knowledge, custom tooling, and proprietary outputs.

That’s the moat. And it’s building right now, whether you’re building it or not.

How to Actually Start

If you’re thinking about this seriously, here’s where I’d begin:

Map your SaaS spend by workflow. Not by category—by the actual thing each tool does. What’s the input? What’s the output? How many hours per week does a human spend operating it?

Find your Agent Builder. They probably already exist on your team. They’re the one automating their own work, annoyed by manual processes, asking “why are we doing this by hand?” more than anyone else.

Start with one thing. Pick one workflow that’s manual, repetitive, and high-frequency. Build an agent. Let it run for 30 days. Measure against what you were doing before.

Then give them a cancellation target. Identify and replace $X in SaaS spend by end of Q3. That creates accountability and forces prioritization.

Most companies will read this, nod, and keep buying tools.

A few will actually do something different.

The question isn’t whether agents can replace manual workflows and SaaS tools. They can. The question is whether you’re building that capability or waiting for a vendor to sell it back to you.

Read more

The demo builders get attention. The infrastructure builders get leverage.

Google just made a significant infrastructure move — and based on what I’m seeing in most GTM and ops conversations, people are treating it like a developer curiosity instead of what it actually is: a signal about where AI agent adoption is heading next.

Let me explain what’s happening and why it matters if you run a team, build products, or are trying to figure out where to actually place your bets with AI.

What Google Actually Launched

Google released a set of managed, remote MCP servers — Model Context Protocol integrations that let AI agents talk directly to Google Cloud services. We’re talking BigQuery, Firestore, Cloud Logging, Google Maps, Vertex AI Search, GKE, and more.

If that sounds overly technical, here’s the version that matters:

Your AI agents can now read from your databases, query your logs, pull from your analytics warehouse, and act on that data — without you building and maintaining the plumbing yourself. Google runs the infrastructure. You configure the connections. The agent does the work.

That’s a different world than what we’ve been operating in.

Most of the AI agent implementations I see today are brittle. Someone builds a workflow that calls an API, wraps it in a custom integration, hosts it somewhere, and prays it doesn’t break. There’s no standardization. There’s no security layer baked in. It works until it doesn’t, and then you’re six layers deep in debugging.

MCP changes that architecture. And Google hosting MCP servers on managed infrastructure — with IAM security, stateless scalability, and official documentation grounding — is the enterprise-grade shift that makes this practical at scale.

Why Most People Will Miss What This Signals

I’ve been in enough technology cycles to know how this plays out.

When something new drops, the people closest to the technology see the capability immediately. The people who actually transform their businesses with it are the ones who see the second-order effect — what this enables that wasn’t possible before.

Here’s the second-order effect nobody’s talking about:

Google didn’t just make it easier to connect AI to Google Cloud services. They built a standardized, secure, enterprise-ready interface between AI agents and live operational data. That’s the gap that’s been stalling real agentic deployment in serious organizations.

Think about the problems I hear from operators constantly:

“We built something with GPT, it worked in demos, but we can’t get it into production because security won’t approve it.”

“Our AI agent workflow is great until the data it needs lives in three different systems with no clean integration.”

“We can’t give AI agents write access to anything important because there’s no audit trail.”

Google’s architecture addresses all three. IAM Service Accounts as the security layer. Managed stateless infrastructure. Official documentation grounding via the Developer Knowledge MCP Server so agents aren’t hallucinating API syntax.

The foundation just got a lot sturdier.

What This Actually Looks Like in Practice

Read more

He mentioned he’d been using Claude Cowork and was getting a lot out of it. Great. Then I asked if he’d tried Claude Code.

“No. That’s for engineers, right?”

I paused. Not because it’s a dumb question — honestly, it’s the reasonable assumption given how Anthropic positioned it. But because it’s the same thing I hear from revenue leaders, ops executives, and founders every single week. And it’s costing them the most powerful AI unlock that exists right now.

So let me just say this directly: Claude Code is not a code editor. It is an AI operating system.

The terminal is just where you type. That’s it.

Think about it like this:

You talk to people via text messages.

You talk to AI via a terminal.

The Misconception Anthropic Created (And Why It Matters)

When Anthropic released these tools, they framed Claude Code as a developer product and Cowork as the accessible business tool. That framing stuck. Hard.

Business leaders saw “Code” and heard “not for me.” They stayed in Cowork, did their one-off projects, and told themselves they were using AI. And they are — just not the most powerful version of it.

Here’s the mental model I use when I explain the difference:

Cowork is a smart contractor you hire for a day. They show up, do the task, leave. Great work. No memory of what they did before. Next time, you re-explain everything.

Code is a full-time operator who sits at your desk every day. They remember everything. They build systems. They get better over time. And when you need something done, they already know the context without you having to catch them up.

Same model underneath. Wildly different relationship.

The Four Things That Change Everything

I’ve put together a full operator’s guide (link below) that breaks down the complete comparison — feature by feature, use case by use case, including a step-by-step setup for your first 15 minutes. But let me walk you through the four capabilities that actually move the needle.

1. CLAUDE.md Is Your Business Operating System

This is the one that blew my mind first.

In Cowork, every session is fresh. You can build a memory workaround — write things to a file, hope it loads — but it’s manual and unreliable. You re-explain your ICP. You re-explain your deal stages. You re-explain your competitive landscape. Every. Single. Time.

In Code, there’s a file called CLAUDE.md that loads automatically at the start of every session. Write your business context there once — ICP, competitors, deal stages, naming conventions, team structure, communication preferences — and every future session starts with full context. No re-explaining. No uploading. No context tax.

It’s the difference between a sticky note on your monitor and an operating manual that’s hardwired into the system.

I now have over 400 lines in mine. First session of the day, Claude already knows everything. The compound effect over months is hard to overstate.

2. Named Agents Are Your AI Team

In Cowork, sub-agents are ephemeral. They exist for one task and disappear. Which is fine for quick work. But it means you’re starting over every time you need a competitive analysis, a piece of content, or a pipeline review.

In Code, you define agent specs. You build a CMO agent — here’s how it thinks about positioning, here are the competitors it tracks, here’s the writing style it uses. You build it once. You refine it over time. It accumulates institutional knowledge.

I’m running over 80 GTM agents now. CMO, CRO, Sales Engineers, Content Writers, Competitive Intel Analysts. When I need a battlecard, I don’t start from scratch. I invoke the Competitive Intel agent that already knows our positioning and our rivals and just ask for the update. The task that used to take an hour takes 7 minutes.

That’s not efficiency. That’s a different category of leverage.

3. Your File System Is Already There

Cowork works in a sandbox. Which means uploading, copy-pasting, and re-uploading your actual files into a contained environment every time you want to work with them.

Code works with what’s already on your machine.

“Read the pipeline export in Downloads and tell me which deals are at risk.”

You type that. It reads it. No prep work. No uploading. No explaining where things are. Your actual pipeline data. Your actual competitive folder. Your actual deal notes. All of it available by just pointing at the path.

This sounds like a minor convenience until you’ve done the upload dance three times in one week. Then it feels like a superpower.

4. Automation That Actually Runs

Cowork’s scheduled tasks are in beta as of right now, and honestly — they’re unreliable. They work sometimes. They silently fail other times. You cannot build a repeatable business process on “sometimes.”

Code supports hooks (event-triggered actions), cron jobs (scheduled tasks), and full automation pipelines. Things I have running in production today:

• Daily competitive monitoring that flags pricing changes

• Automated content pipeline: trend research → draft → review

• Weekly research digests synthesized from multiple sources

• Pipeline health alerts triggered by CRM events

None of those require writing code. They require describing what I want, once, and letting Claude build it.

“But I’m Not Technical” — Let me actually address this

Read more

Let me explain.

The Three Eras (and Why Era 3 Changes Everything)

Era 1: The Service Desk (2015–2021). RevOps was the team that kept the lights on. CRM admin, report building, data hygiene. The career ceiling was “Senior Manager.” Measurement was system uptime and ticket turnaround.

Era 2: The Strategic Partner (2021–2024). The 2022 SaaS correction forced a reckoning. When “growth at all costs” became a punchline, someone had to answer harder questions — What’s our real CAC? Why are we spending $400K on a channel producing $50K in closed-won? RevOps teams that could answer those questions got promoted. Leaders moved from reporting to VP Sales into senior leadership meetings. Directors started commanding $273K total comp.

But even in this elevated state, most RevOps teams remained fundamentally reactive. Better at answering questions. Not designing the system that generates them.

Era 3: The Growth Architect (2025–). This is where we are now. And it’s genuinely disruptive.

RevOps is evolving from a service function to a technical, architectural discipline. The Vasco 2026 RevOps Trends & Predictions Report — built from interviews with fifteen GTM leaders including Jacco van der Kooij, Kyle Norton, Jen Igartua, and Jeff Ignacio — frames it bluntly:

“RevOps is shifting from a service desk to a growth architect and GTM CTO.”

Teams are moving from busywork and reporting to system design, simulation, experimentation, and orchestration.

The Bifurcation No One Is Talking About

Here’s the uncomfortable truth that most RevOps content avoids: RevOps doesn’t have a future. It has two. And they’re diverging fast.

Path 1: Automate and Absorb. The software performs the RevOps function. CRM administration, basic reporting, dashboard maintenance, data cleanup — AI handles all of it. The traditional RevOps team shrinks or disappears. Anthony Enrico of Leanscale is direct: “The Salesforce admin role is gonna die. It’s not gonna exist in an AI-driven world.”

Path 2: Orchestrate and Elevate. RevOps becomes the central node orchestrating all GTM agents — human and artificial. The function owns system architecture, data governance, workflow orchestration, and AI governance.

Guillaume Jacquet of Vasco captures the uncertainty: “Future number one: the software performs the RevOps function and the team disappears. Future number two: RevOps becomes the only function, the central node orchestrating all the GTM agents. I actually don’t know which one wins.”

What’s clear is that the middle is collapsing. RevOps as a support desk that builds dashboards and manages CRM fields — that’s dead. Nico Druelle of The Revenue Architects: “RevOps that stays at the surface — dashboards, basic reporting, CRM admin — AI will do most of that. That whole layer disappears.”

The Rise of the GTM Engineer (and Its Critical Blind Spot)

The most significant new role in the revenue org is the GTM Engineer. Between September and November 2025 alone, the GTM Engineering talent pool expanded by 45%. AI mentions in profiles rose from ~40% to ~60%. Average experience jumped from 27 to 49 months as the role professionalized.

But here’s where I push back on the prevailing narrative.

The GTM Engineer role — as currently practiced — is massively over-indexed toward the top of funnel. Look at where the talent clusters: Clay workflows, outbound sequencing, lead enrichment, prospecting automation, intent signal routing. It’s acquisition-obsessed.

This is the exact mistake that Winning by Design’s bowtie model was designed to correct: treating revenue as something that happens before the signature.

The bowtie isn’t a metaphor. It’s math. In a SaaS business with healthy unit economics, the majority of lifetime value comes from onboarding, adoption, expansion, and advocacy — the right side of the bowtie. NRR is what separates compounding businesses from leaky ones. Yet the overwhelming majority of GTM engineering energy goes into filling a funnel that’s leaking out the bottom.

A true GTM Engineer should be building across the full lifecycle:

• Acquisition systems — but also onboarding automation that cuts time-to-value from weeks to days

• Pipeline orchestration — but also adoption scoring that predicts churn before your CSM sees the signals

• Lead enrichment — but also expansion triggers that surface upsell from product usage data

• Outbound sequencing — but also advocacy loops that turn power users into referral engines

If your GTM Engineer spends 80% on acquire/convert and 20% on onboard/adopt/expand/advocate, your “revenue system” isn’t a system. It’s a funnel with a new job title attached.

The CRM Demotion

The most provocative structural shift: the CRM is no longer the system of record. The data warehouse is.

“More and more operators are pulling truth directly from the warehouse now, because the CRM just can’t describe the real state of the customer anymore.” — Guillaume Jacquet

Kyle Norton takes it further: “We’ll start seeing headless CRMs or chat interfaces built directly on top of the data layer. The UI won’t matter anymore.”

This has massive implications for RevOps talent. If the CRM becomes an interface layer rather than the source of truth, the skills that matter shift from Salesforce administration to data engineering, warehouse architecture, and semantic layer design.

Where We Actually Are on the AI Curve

The Vasco report introduces a useful framework:

• 2025 = Curiosity. Experimentation phase.

• 2026 = Faster. Speed gains at production scale.

• 2027 = Smarter. True intelligence — decision-making, simulation, relevance.

But here’s the honest reality check. Matt Volm of RevOps Co-op: “AI has actually slowed RevOps down this year. On top of our normal work, we’ve added new AI responsibilities, which stretches teams thinner rather than making them faster.”

Stuart Watson invokes the Red Queen Theory: “Finishing something faster doesn’t mean you rest — it just raises the bar. You run faster just to stay in the same place.”

We’re in a skilling phase where the investment hasn’t yet paid off in productivity. But the teams that invested in data foundations before deploying AI are starting to see results. Norton’s team saw 85% improvement in BDR decision-maker connects from a two-week pilot and claims reps are 3-4x more efficient than competitors.

The takeaway: data foundations first, AI deployment second. Always.

The Human Cost No One Talks About

RevOps professionals who built careers on CRM expertise are watching their core competency get automated. The transition to systems architect requires fundamentally different skills — and not everyone will make it.

Nico Druelle says it plainly: “There will be less analyst/admin-only roles. AI will take that over. The reality is: most won’t make the transition.”

Kyle Norton captures the urgency: “If your RevOps team has not already evolved, you’re in serious trouble. We’re over 24 months into the AI era, and if your team is operating the same way it did two years ago, that’s not the right leadership.”

This isn’t just organizational restructuring. It’s a workforce transformation that will leave some people behind.

Five Things Revenue Leaders Should Do Right Now

1. Audit your team against the bifurcation. Which path are your people on? If the majority of time goes to CRM admin, reporting, and manual data work — you’re building on a foundation AI is about to automate.

2. Invest in data foundations before AI deployment. The universal prerequisite. Every single leader I’ve talked to converges on this. If your data is fragmented, AI will amplify the mess.

3. Hire (or develop) GTM Engineers — across the full bowtie. Target RevOps managers and data engineers who can write Python, design APIs, and think in systems. But mandate that at least half their capacity touches post-sale systems.

4. Restructure RevOps as a product team. Stop running it as a service desk with a ticket queue. Organize around product ownership of the revenue system — sprint cycles, user research, dedicated engineering capacity.

5. Manage the human transition deliberately. Acknowledge the anxiety. Invest in upskilling. Create clear career paths from admin to architect. Be honest about which roles are evolving and which are disappearing.

The Bottom Line

RevOps is not dying. But the RevOps most companies have today — reactive, admin-heavy, CRM-centric — is.

What’s emerging is more ambitious, more technical, and more strategically important than anything the function has been before. The Growth Architect doesn’t just support the GTM motion. They design it.

As Jacco van der Kooij puts it: “Once you see growth as a system to be designed rather than a funnel to be staffed, you start to understand why 2026 marks a true inflection.”

The RevOps evolution isn’t about AI replacing people. It’s about AI revealing which people — and which organizational designs — were built for a world that no longer exists.

Go Deeper: The Full Interactive Research Brief

I put together a comprehensive interactive research brief that covers everything in this article and more — including the recommended org chart for the future RevOps team, the four-pillar model, compensation data, the full talent analysis, and the contrarian GTM Engineer argument in detail.

Paid subscribers can dive into the full interactive brief here

Read more

And it still screws up the 10-step process your team uses to qualify enterprise deals.

Not because it’s dumb. Because nobody taught it how your team actually works.

This is the gap that’s quietly killing agentic AI deployments across B2B — and it’s the same gap I kept hitting when I built out 60+ agents across our own GTM operation. The agents were powerful. They had tools. They had models. They had access. And they kept doing things wrong in ways that were expensive to debug and embarrassing to explain.

The fix wasn’t better models. It was a concept most teams haven’t encountered yet: Skills.

The Distinction That Changes Everything

Here’s the cleanest way I can frame it, borrowed from Christopher Penn: agents are like employees in departments — HR, Finance, Sales. They’re vertical. Domain-specific. They own a function.

Skills are like apps those employees use — Excel, Salesforce, your internal wiki. Horizontal. Reusable across departments. Any employee can pick them up.

Another way to think about it: tools let agents act. Skills provide the knowledge of how and when to act — including the company-specific, team-specific, and user-specific context that separates a capable AI from a competent one.

That last sentence is the whole game.

What Agents Actually Are

An agent is a full decision-making entity. It has a system prompt (its identity and instructions), tool access (what it can do), a backing model (Claude, GPT, etc.), and an agentic loop that lets it orchestrate workflows and manage state.

Think of it as an autonomous AI pre-prompted to handle a specific kind of task — debugging code, acting as the voice of the customer, running a competitive analysis, being a virtual CMO. Agents are vertical. They do one specific kind of work within a domain.

In systems like Claude Code (which I use daily), agents even have their own working memory — a little sandbox where they maintain context about what they’re doing and why.

In our system, agents are the parallel workers. Standalone files that execute work concurrently. They invoke skills and workflows as needed. But the agent itself? It’s the who. It owns the decision-making.

What Skills Actually Are

Skills are something different entirely. They’re modular, declarative bundles of expertise — organized procedural knowledge packaged into reusable units that agents load as needed.

Practically? A skill is a folder containing a SKILL.md file (the playbook), optional scripts, templates, and reference docs. It’s a standardized format that packages procedural knowledge and context for agents to load on demand.

The critical word there is “on demand.”

Because here’s where the architecture gets interesting.

Below I will share how to build them, when to use them, and give you a comprehensive step by step guide.

Read more

According to 6sense’s 2025 Buyer Experience Report, 94% of B2B buyers are now using LLMs during their buying process. Not “experimenting with.” Not “curious about.” Using. Actively. Right now. While your reps are still manually updating Salesforce fields and searching for that one case study th…

Read more

The tech press called it “an agent management platform.” Fortune called it OpenAI’s bid to become “the operating system of the enterprise.” Gartner called agent management platforms “the most valuable real estate in AI.”

…

Read more

You still need to find the right customers. Communicate value. Build relationships. Close deals. Deliver outcomes. Expand accounts.

None of that is different.

What’s changing—rapidly—is how we solve for those fundamentals.

For decades, we’ve thrown people and process at every GTM problem. Pipeline weak? Hire…

Read more

The gap between belief and execu…

Read more

Five percent.

Meanwhile, 60% are achieving no material value at all—despite pou…

Read more

None of it mattered.

Netflix won because they understood something Blockbuster couldn’t see: the value wasn’t in physical distribution. It was in knowing what you wanted to watch before you knew it yourself.

That same moment is happening right now in go-to-market.

But instead of physical vs. streami…

Read more