I’ve been on a real agent kick here over the last couple of months. But then again, so has the entire world.

That ends today.

Yeah, no. I’m going to keep writing about agents.

Today I want to focus on an important shift I believe is happening in the relationship between agents and software1. Ever since agents entered the discourse, the prevailing narrative has had two parts:

1. Agents can build software on demand, permanently shifting the build-vs-buy equilibrium towards build. Buying software will be a thing of the past, making software a bad investment.

2. Software vendors that hope to survive must become “AI native” by embedding agents within their platform.

What if I told you2 there was a third way—one that means great things for both agents and software?

Bring Your Own Agent

Every Friday, I send a weekly update to investors and friends of the company. And each update includes a little blurb I call This Week I Learned (TWIL).

Last Friday this was my TWIL:

When I said “a little early”, I meant about 36 hours early.

On Sunday, Dharmesh Shah, CTO of HubSpot, wrote on LinkedIn that B2B software companies should be creating an “agentic version” of their software—one built around a thoughtful agent user experience (his term: “AUX”).

While I’d like to say “great minds think alike” that seem like too much credit. Let’s just say that between Dharmesh and me, one of us is slightly more influential and accomplished than the other. But hey, together we’re worth just over $1.1B!

Anyway, he ended with this:

Being agentic is not just about agents running *on* our platform, it's about agents *running* our platform (being able to operate it).

And herein lies the 3rd way.

Think about it. Do you really want to pick and choose specialized agents from a bunch of different “AI native” vendors? Do you want to be responsible for coordinating and enabling them across different systems? No, that sounds like a full-time job. Instead, you’ll bring your own agents (BYOA). And they’ll use software for you.

These agents will be customized for your company’s internal processes and context, but they’ll be built on a set of general purpose agentic platforms. These will come from a few providers. Today Anthropic is in the lead with Claude Code and Cowork while OpenAI is playing catch up with Codex. I’m confident Google and Microsoft will spend whatever it takes to be in the mix.3 Maybe OpenClaw is the open source alternative. Hell, maybe Apple will end up owning agents for consumers if they finally get Siri right.4

Right now that landscape is chaotic. There are emerging standards—MCPs and skills—with varying levels of support as vendors jostle for both growth and lock-in. If you’re old enough to remember it, it feels a lot like the browser wars. (More on that in a moment.)

While it’s obvious that BYOA turns the “build embedded agents” narrative inside out, it also changes the “agents make software obsolete” narrative.

Agents will build a lot of software. Creating a v1 has never been easier. That said, the fundamental software R&D story hasn’t changed. Maintaining, debugging, improving, scaling, operating—99% of expenses incurred during the working life of real5 software—still exist. Even if all those things can be reduced to nothing but token costs6, software vendors can still amortize those costs across more customers while getting operating efficiencies from scale. It’ll still usually be better to buy than build.

It follows, then, that in a BYOA world agents will consume more software than they build. If we consider that agents can work 24/7, it stands to reason that they’ll probably consume more software than humans ever could. To me, that sounds like a bull case for both agents and software.

This only works if software companies wake up to Dharmesh’s point (and mine). If you want a shot at the bull case, you’ve got to give up on the idea of owning an agentic workflow inside your software and start thinking about how you make your software available to agents and humans alike.

That means rethinking how we build, deliver and sell software.

The 5th wave of software platforms

I don’t think agents represent the end of software. Instead, I think they’re the next great software platform.

Every generation or so we get a fundamentally new platform for delivering software. Each wave creates new markets, rewards new approaches and (creatively) destroys models that used to work. Consider this progression (dates very approximate):

1. Early Days (1950 - 1970) - The era of mainframes (like the IBM 704 above). Software really only ran on specific hardware. To be a software developer was to be a hardware developer. The only thing that really mattered was making this incredibly expensive hardware do something useful.

2. Operating Systems (1970 - 1990s) - This is the era that birthed the PC and the operating systems we still know (if not love): Windows and Mac7. Building software no longer required building hardware; it meant targeting one of these OSes. Success meant owning distribution (mostly with physical media), making your software work on limited hardware and making it usable by normal people who suddenly found themselves with computers in their house. This wave never really ended. It’s just been largely fixed in place for 25+ years.

3. Browsers (2000 - Now) - Around the turn of the century, a bunch of technologies came together to make browsers a way to deliver software. This is when I started my career. It was a mess. The technology was incredibly limited, browsers were incompatible, the developer tools sucked. However, it was worth it. Suddenly you could deliver software to anyone on the internet, 24/7, always running the latest version, without them having to think about how to install it. Software became a service. And thus SaaS was born.

4. Mobile (2008 - Now) - In many ways this was a reprise of the first OS era, this time powered by new kinds of computers and the internet. You still have to build and maintain separate apps targeted at entirely different operating systems, but distribution got better and those apps could be powered by internet services in the background. Good software became about working with the unique constraints and capabilities of mobile devices.

Each of these shifts started with some new enabling technology. Early companies rush in with different approaches, creating a fragmented market. Eventually you get consolidation and standardization. A few platform winners emerge. Those platforms then enable everyone else to build on their unique capabilities to do useful things for a large market of end users.

You can see this happening today in the competition for agent supremacy. LLMs were the big initial shift. Agent “harnesses” came next. Now standard ways of extending agents are starting to emerge. They’re looking increasingly like platforms.

The big thing that sets agents apart from previous platform shifts is that agents are more than just plumbing to execute software on behalf of users—they are users in their own right. That opens up entirely new ideas about what software can be.

A bull case for software

There’s a strong chance agents follow the common historical arc of disruption, fragmentation, consolidation and standardization we’ve seen from new software platforms over the last 75 years.

If that happens, BYOA becomes a reality and staking your whole strategy on embedded agents will seem as foolish as building your own phone just to ship a few apps.

BYOA does, however, represent an opportunity for a new wave of companies to build software that maximizes what agents can do. It won’t be an easy transition. We’ll see plenty of old guard fade away. UX, GTM and pricing will have to evolve.

I wouldn’t be surprised to see some successful B2B software companies launching with just an MCP, a set of skills and some usage-based pricing. That may seem ludicrous, but it seemed crazy back in 2010 when Instagram launched with a mobile app and no website. They simply went all in on the new platform.

I’m long on agents and software. Bring your own agent and let’s find out if I’m right.

In Part 1, I wrote about the foundations and access layer for the agent architecture we’ve been putting together at Gradient Works.

Here’s a quick recap.

Our goal is to be an agent-first company where agents do the vast majority of the hands-on work. That means humans stop being responsible for doing tasks and focus on being accountable for the quality of the work.

To achieve this, we’re building a unified framework that enables two types of agents: assistants that help people do their jobs and teammates that perform entire roles. One early realization: none of this will be possible if we don’t build security and safety guardrails from the beginning. A system that minimizes the risk of catastrophic mistakes gives us freedom to operate1.

This combo of unification and security informed our gw CLI approach to the access layer. Agents access our business systems (e.g. Salesforce, HubSpot, BI tools, Google Workspace) through a command line interface that offers a single point of control for authentication, authorization and action.

Access, however, isn’t enough. Think about an SDR task like “prospect these 10 companies”. The rep needs secure access to tools (LinkedIn Sales Nav, Salesforce). They also need context (ICP, personas, market knowledge) and skills (the right sequence of steps to fully research a prospect). A rep without all that would fail and so will an agent.

Today, I want to show how we complement our agent access layer with these other pieces. Here’s a simple visual of our overall stack:

The rest of this article focuses on contextual knowledge (pink) and task-specific skills (yellow). I’ll cover the general concepts and provide detail on our specific implementation.

A caveat: our approach is a work in progress. It’s not perfect and it may not be right for you. My hope is that sharing what we learn as we go will contribute to all of us—especially in GTM—figuring out how to wrangle this new reality.

Let’s dig in.

Context

Context is the knowledge an agent needs to act appropriately across a variety of situations, irrespective of a specific task. For our agents, I think about two kinds of contexts:

• Company Knowledge - When you onboard an employee, you give them baseline knowledge to orient them. Think about things like org chart, company history, market positioning, types of customers, core values, etc. You do it because it’s the context an employee needs to inform everything they do as someone who works at your company. You don’t expect someone off the street to have this knowledge, so you teach them.

• Role Knowledge - An engineering employee needs to know different things than a marketing employee. The engineer needs to know coding standards and database schemas. The marketer needs to know personas and attribution criteria. And they won’t know what’s right at your company unless you tell them. Some companies have formal trainings for this stuff; others expect employees to just absorb it on the job.

AI agents don’t have either kind of knowledge. If you don’t tell them, they’ll guess—just like an employee. Unlike employees, they don’t have a good way to just absorb information as they go2. You need to explicitly “ground” them by giving them the context they need when they need it.

Our solution to this problem is a lot like our solution to everything else so far: a CLI + some markdown.

Cortex: a work in progress with a cool name

We’ve built a system for accessing and sharing context across agents called Cortex. There are two parts:

• An organized way to store and distribute knowledge files (in markdown, natch)

• A utility (gw cortex) to help agents find the right knowledge when they need it

Every agent gets a “cortex” folder. Inside that folder are sub-folders, each of which we call a “source”. Inside each source is a set of organized markdown files containing some knowledge. The exact set of folders and markdown files is up to the author.

Here’s an example from my personal agent:

cortex
├── gradient-works
│   ├── Company
│   ├── Customer Success
│   ├── Engineering
│   ├── GTM
│   │   ├── Audience Guide.md
│   │   ├── Brand Guide.md
│   │   ├── Competitive Landscape.md
│   │   ├── Competitors
│   │   ├── Dynamic Books.md
│   │   ├── Gaps.md
│   │   ├── Messaging Guide.md
│   │   ├── Point of View.md
│   │   ├── Pricing and Packaging.md
│   │   ├── Product Marketing
│   │   ├── Proof Points.md
│   │   ├── README.md
│   │   ├── Sources
│   │   └── Voice and Tone.md
│   ├── Product
│   └── README.md
├── opportunities
│   ├── Closed-Won
│   ├── Company 1
│   ├── Company 2
│   ├── README.md
└── uncharted-territory
    ├── posts
    └── README.md

So far, so normal. There’s a wrinkle here, though. The gradient-works folder is actually a git submodule with content from a remote GitHub repository, while the other folders only exist for the specific agent.

This submodule thing means we can update our company-wide knowledge files in one GitHub repository3 and then sync them to all our agents. For example, we recently added a bunch of product marketing content and now we can make that available to everyone’s personal agents as well as our growth marketing, prospecting and outbound agents.

We wrapped some tooling around this in gw CLI, so an agent can get the latest information by running “gw cortex sources pull”.

Now that we’ve got a way to structure knowledge and keep it up to date, we need a way to ensure that the agent can find what it’s looking for. For that, we added search4 to gw CLI. An agent might construct a call like this:

$ gw cortex search "ideal customer profile ICP" \
  --sources gradient-works --limit 2 --output-format json
{
  "results": [
    {
      "source": "gradient-works",
      "path": "gradient-works/GTM/Audience Guide.md",
      "heading": "Audience Guide > The Four Personas",
      "line": 65,
      "snippet": "## The Four Personas"
    },
    {
      "source": "gradient-works",
      "path": "gradient-works/GTM/Audience Guide.md",
      "heading": "Audience Guide > Quick Qualification Checklist",
      "line": 10,
      "snippet": "## Quick Qualification Checklist\n\nA prospect is worth pursuing if they meet **all required** criteria and **most** of the strong signals:"
    }
  ]
}

This helps guide the agent to the exact parts of files that contain particular knowledge, saving both tokens and time.

It’s a good start, but I don’t think we have search fully dialed in. We have topics/keywords associated with particular files which helps boost their search ranking, but I think we’re still too likely to return some lower-quality results. When that happens, it’s not clear that our search tool beats the native file search tools that agents like Claude Code already have. We’ll keep working on it.5

Caveats aside, Cortex seems to work pretty well in its current state. It gives us a (relatively) simple, agent-native knowledge base which we can centrally update and then use across agents to inform the work they do.

And that brings us to skills, the way we teach them exactly how to do that work.

Skills

Skills instruct an agent exactly how to use your tools and your context to do a particular job. Good skills serve the same role as employee trainings. They turn an eager new hire that works hard but makes tons of mistakes into someone you can count on. The difference is that agent skills take effect immediately—it really is an “I know kung fu” situation.

Like almost everything with AI, skills seem more daunting than they actually are. They’re mostly just markdown files containing instructions tucked away in some special locations on your computer. It’s not magic.

In our case, we knew we had to both build good skills and distribute them to our employees as part of our unified approach. Here’s how we’re tackling those challenges.

Building skills or: how I learned to teach kung fu

First, I recommend getting the skill-creator plugin from Anthropic. It’s not required, but it does a great job of writing skills in ways that agents understand. If you’re using Claude Code, you can find it in the “claude-plugins-official” marketplace. You can use “/plugins” or do it in one shot with this command:

$ claude plugin install skill-creator@claude-plugins-official  
Installing plugin "skill-creator@claude-plugins-official"...
✔ Successfully installed plugin: skill-creator@claude-plugins-official (scope: user)

Second, even though skills are just markdown files, I don’t recommend writing them by hand. I’ve found it’s easiest to use “on-the-job” training.

Let’s say you want an email triage skill (assuming your agent can access your email). Walk your Claude Code agent through the process step-by-step. Tell it to auto-archive certain senders, label others, send emails to spam that look a certain way, etc. Once you’ve done the walkthrough, say something like this:

Review everything we just did and turn it into a skill called email-triage
so you can help me do this job more efficiently in the future. Use skill-creator
to ensure the skill follows best practices. You can skip evals.

(That last line ensures the skill-creator skill doesn’t get too fancy and try to do a complex skill quality evaluation—that’s almost always overkill.)

Once you do that, Claude will write a pretty darn high-quality skill for you. (You may need to give it permission to update its own settings before it can complete this.) You can, of course, read the skill yourself and make manual tweaks if you want.

Later as you do email triage with your agent, you may notice it’s not using the skill when you think it should, it’s not handling things quite right, or you just want to add a new capability. When that happens, tell it how you want it to behave and ask it to update the skill accordingly. If you’re not sure what to tweak you can ask it. Say, “You didn’t do X just now. How can we update our skill to ensure you always do X when Y happens?” It’s very similar to managing a human—when you see them go down the wrong path, correct them so they learn for next time.

This process works great for building skills. The end result, though, is a skill that’s stuck on your computer. It’s not something you can easily share with others. Given our goal of a unified framework, we realized we needed a way to distribute reusable skills to multiple people.

Luckily Anthropic had already solved that problem.

Welcome to Dubmart: quality skills at everyday low prices

Plugins offer a way to upgrade Claude Code’s capabilities with MCPs, subagents and—you guessed it—skills. You can distribute them via a “marketplace”.

We built an internal Claude Code plugin marketplace called Dubmart6. So far, most of our plugins provide shared skills centered around particular business systems. They explain how to use gw CLI, describe Gradient Works-specific customizations, outline common access patterns and explain how to find relevant context.

A few examples:

• The “gw-slack” plugin has a skill that describes how to use our gw slack command and also explains our Slack conventions. This includes things like key team channels (e.g. #gtm and #engineering), how to identify shared customer channels and other conventions (e.g. “opp-*” channels for open opportunities).

• The “gw-salesforce” plugin has a skill that knows how to fetch and update Salesforce data. It also knows the specific fields and calculations we use to compute ARR and retention.

• The “gw-fathom” plugin has a skill that knows how to intelligently find sections of Fathom transcripts based on user requests by chaining together different calls to “gw fathom search”. It also includes a specially tuned subagent for summarizing many transcripts at once.

• The “gw-linkedin” plugin includes skills that know how to use the LinkedIn website, building on top of the excellent agent-browser command line tool.7

Now, whenever we build a useful skill we want to share across the company, we can just publish it to Dubmart. If we want to upgrade a skill, we update the plugin and all the agents using that skill automatically get smarter.

The full setup for a private plugin marketplace is a little beyond the scope of this newsletter but it’s pretty straightforward. Mostly you just need a GitHub repository and a few specific files. Like everything else, we use Claude Code help us maintain the repo itself.

Enabling folks to connect to a private GitHub marketplace can be a little tricky since it uses git behind the scenes to fetch the plugins. That’s ok for us because every employee has git and GitHub access. That may be a blocker for your team, so talk to your engineering folks. Once that’s sorted, your users can add the marketplace using the “/plugins” command and start downloading plugins.

Wrapping up

That’s it for the context and skills part of our architecture. Cortex gives us an agent-friendly knowledge base for company and role knowledge. Dubmart gives us a way to share skills. Combine those pieces with the gw CLI access layer and we’ve got a solid framework that’s working well in practice across a number of roles.

The biggest weakness is it’s still pretty “developer-y”. Users will encounter rough edges or have to occasionally interact with developer-centric tools like CLIs and GitHub. Of course we live in a world where C-level folks and sales leaders are on LinkedIn posting screenshots from Claude Code running in their terminal. Maybe this is the new normal—at least for now.

Like I’ve been saying, it’s gonna get more technical before it gets better. Best to roll with it. I hope our approach sparks some ideas for your team.

I got tired of LinkedIn posts and newsletters about agents that don’t include any specifics. I’m going to share our agent-first journey in way too much detail over the next few posts. Hopefully you’ll find it helpful.

Today’s post is about our foundations and approach to systems access. I’ll cover context and skills next time.

Exactly two months ago, I finally had some weekend time to use Claude Code for a specific task. I’d been closely following the evolution of AI in the development space for the past two years, but I hadn’t spent real time with Claude Code.

Within 3 hours, it was obvious everything about our work had to change. We had to become agent-first across our whole team and we had to do it now.

That day triggered an all-out sprint to get as much of that transformation done as we could before my trip to Japan in mid-March. On Feb 1, a couple of our engineers were playing with Claude Code. Today, here’s where things stand across the company:

• Growth - Our growth agent assists the marketing team with optimizing Google Ads1, doing web analytics2 and building landing pages.

• Content - The marketing team’s agents suggest ideas, draft content, edit it and post it.

• Outbound - We have a combination of agents doing prospecting and outbound outreach every single day. One qualifies, identifies contacts and does deep research. The other works through Salesloft tasks.

• Sales - My sales assistant helps with meeting prep and follow up. It’s building a “pipeline brain” with the risks, stakeholders and status of each open opportunity.

• Customer Success - Our CSMs have agents that summarize customer calls, synthesize next steps, and help us draft agendas for meetings.

• Board Materials - We send out a weekly update to board members, investors and other stakeholders. Our agents pull together metrics, milestones and other key topics.

• Engineering - Claude writes the majority of our code while also helping us draft issues, plan features and review pull requests.

So far, all that is no different from what you’ll read on LinkedIn’s infinite stream of engagement bait posts. Let me change that.

That “sales assistant” with a “pipeline brain”? It’s a skill in my personal agent that hits several different data sources (via our CLI—more on that below) and updates some markdown files with the current state of all our deals. It’s not rocket science, but it is genuinely useful.

Not all of these agents are working perfectly. For example, the Growth agent is doing pretty well with Google Ads but it can’t yet deploy landing pages because our HubSpot CLI integration (see below) can’t yet configure all the modules our theme supports. Another example: our Outbound agent still requires some human babysitting and approvals for certain actions.

In short, we’re just now scratching the surface of what’s possible. And we’re nowhere near the “autonomous agents are running our business” stories that people lie about on LinkedIn. That doesn’t mean we haven’t made some meaningful progress that’s worth sharing.

Warning, some of this will be a little technical. But, as I’ve said before, it’s gonna get more technical before it gets better. Below I’ll focus on our foundations and our—somewhat different—approach to tooling.

Let’s dig in.

Foundations

We started with a set of core requirements:

• Everyone is accountable. Everyone in the company should use agents to execute their work. Each person has to move from being responsible for doing all the work to being accountable for the quality of that work.

• Two categories of agents: assistants and teammates. Assistants help an individual human get their work done and are tailored to their individual needs. Teammates take on whole roles, work with others and operate as autonomously as possible.

• One technical foundation. We need a unified architecture that includes the agents themselves, access to systems and data, shared context and skills so that we can continuously improve all our agents across the company.

• Security from the start. We need to make whatever we build as secure as possible. That includes authentication and authorization as well as guardrails against destructive actions (e.g. deleting everything) and data exposure (e.g. sending private data to a 3rd party).

With those requirements set, we had to make some decisions. We decided to build on Claude Code across the company. Nothing in AI is permanent, so this could change. Here’s how we think about the tradeoffs at this moment in time:

• Claude Cowork is less technically daunting than Claude Code but there are still some restrictions that we don’t love. In particular, the virtual machine that runs under the hood—while helping security—makes it harder to integrate with.

• OpenAI Codex is immature compared to Claude (e.g. they just added plugins last week). However, they’re catching up fast. We’ll revisit this decision down the road.

• OpenClaw is robust and extensible. The security situation is getting better. Right now it seems to be more “single player” than Claude and quite a bit more wild west3. That said, it may be the right fit going forward for some things, especially for more autonomous agents.

• Claude Code has the right mix of configurability, security, extensibility and maturity4. Even though it’s probably best as a terminal application for developers, it has a nice UI in Claude Desktop (right alongside Cowork) which makes it reasonably approachable for everyone. Finally, Anthropic has demonstrated a strong focus on enterprise-type work so I trust them to continue down that path.

Ultimately, choosing the agent platform was the easy part. If we’d just told everyone “go use Claude Code”, we might have seen some benefits, but not much. We knew we had to actually enable the agents. As I wrote in Agent Enablement is the New Sales Enablement:

I haven’t seen too much use of the term “agent enablement” so I’ll provide my own definition. It means providing AI agents with appropriate access to business systems, sufficient information about their business context and proper skills for their job. Agents without access, context and skills are just a neat party trick with a penchant for telling convincing lies.

The rest of this post is about the work we’ve done to give our agents secure access to the business systems they need to use to be useful.

Access

The goal of the access layer (which I’ve discussed before) is to give your agents access to the same systems that humans use to do their jobs. MCPs are the most common route for this and they work well. However, they do have have some drawbacks:

• They use lots of tokens to describe their capabilities, taking up precious context.

• They have a lot of surface area for security issues.

• Vendor MCPs tend to support less functionality than their more mature APIs. For example, Salesforce has no official MCP and HubSpot’s MCP server mostly enables querying CRM data. I’m sure this will change over time.

MCPs aren’t the only way to expose data and tools to agents though. They’re equally at home using the command line5. We’ve used that to our advantage.

Inspired by tools like the aws cli, we built a single, extensible, command line interface for all the tools that a Gradient Works agent (or employee) might need. We call it “gw”. It wraps the APIs for our business software with a reasonably consistent set of conventions and a system that securely manages credentials.

The gw CLI

The gw CLI gives us full control over what features and functionality we want to expose to our agents instead of being at the mercy of a vendor-provided MCP.

Let’s use Salesforce as an example. It doesn’t have an MCP, but it does have an expansive API that makes nearly anything in the platform possible. With the gw CLI, you can access Salesforce like this to query for data:

$ gw salesforce query \
  "SELECT Id, Name, Website FROM Account LIMIT 10"

Or like this to create a new record:

$ gw salesforce objects create \
  --object Account \
  --field "Name=Acme" \
  --field "Website=acme.com"

The gw CLI currently integrates with 18 different systems we use to do our work, from Google Calendar to Zeplin. You can see them here:

Token thrift

Since we’ve built our own CLI, we can control the inputs and outputs. This also allows us to customize behaviors that might be useful for agents but aren’t native to specific APIs. For example, our HubSpot CLI allows us to fetch blog posts in HTML from the HubSpot API but convert them to markdown when we output them to the agent:

$ gw hubspot posts get \
  --post-id 330007029495 \
  -o markdown
---
id: '330007029495'
title: Is it the reps or the accounts? A 3-step framework for diagnosing pipeline drops
date: '2026-04-01T17:14:38Z'
author: Manny Ruan
url: https://www.gradient.works/blog/is-it-the-reps-or-the-accounts-a-3-step-framework-for-diagnosing-pipeline-drops
---

You rolled out new territories in January, but outbound pipeline’s down....

If the above blog post was in HTML, it would use about 5x more tokens. The CLI’s conversion improves the signal-to-noise ratio for the agent while making it less likely that you’ll have to fork over money to Anthropic for session overages. With a CLI, you have a lot more control over your token budget.

Security and safety

You might notice the “auth” subcommand. This is where we manage authentication. Each system’s authentication credentials (usernames, passwords, API keys) are managed through a single set of authentication commands.

$ gw auth status serpapi
serpapi:
  SERPAPI_API_KEY    keychain: gw-cli / SERPAPI_API_KEY

Each credential is stored in either the keychain, 1password or a configuration file. They can’t be output via the CLI, only used by the code internally. This makes it much harder for secret credentials to be exposed to the LLM or any other system.

Beyond authentication and authorization, the CLI approach helps keeps our data safe. Since we build only the functionality we want to expose to agents, we can limit what’s even possible. For example, our Salesforce CLI integration doesn’t have the ability to delete an object. Why risk it?

Building your own

This might sound like a lot of work. In reality it’s been relatively low lift. We built the entire CLI using Claude Code itself. For the vast majority of these APIs, you can literally tell Claude Code where to find the API docs, tell it which things you want to enable and have it go from there.

For example, here’s the initial description I gave Claude to build the HubSpot part of our CLI:

Using with agents

We built the gw CLI in python. Since we use the standard project structure, we can use uv (recently acquired by OpenAI) to install it. It looks something like this:

$ uv tool install "git+https://github.com/{your-org-name}/{your-repo}"

In our case, this makes “gw” available to any agent running on the computer.

You’ll also need to add something like this to CLAUDE.md or AGENTS.md:

# Systems Access

When you need to access external systems, you **must** first look for a
relevant skill and invoke it to learn how to access the system.

If you are unable to find a relevant skill, you may attempt to fall back
to the `gw` CLI directly. `gw` is a command that is globally available
to you on your PATH at all times. It provides access to various sytems.

I’ll discuss more about how we pair skills with the CLI in the next article. With all that in place, you can do things like this:

Drawbacks to the CLI approach

There are real tradeoffs and drawbacks to rolling your own CLI. To name a few:

• There is more tooling within the agents themselves for MCPs. This is partly because MCPs are more complex than a CLI, but it does mean that it might be harder for non-technical users to understand what’s going on.

• Our current deployment approach with uv means that all our users have to have access to developer tools like uv, python and git—as well as access to GitHub. At our scale, that’s not a big problem. It might be for you. It’s nothing an afternoon with Claude Code building better packaging couldn’t solve, but that might not be your cup of tea.

• Right now, Claude Cowork and CLI tools don’t play nice. It very much prefers MCPs. That’s one reason we’re not currently trying to push our non-technical users to use Cowork instead of Code.

• While agents are pretty good at using the help output of CLI tools to figure out what to do, you’ll get more efficient usage if you ship skills along with the CLI6. This somewhat negates the token benefit that CLIs have over MCP, but it’s still probably a win.

Last but certainly not least, you need to build and maintain the CLI yourself. That means fixing bugs and adjusting to any vendor API updates. Claude makes that 100x easier than it would have been in the past, but it’s not nothing.

Wrapping up

We haven’t gone 100% CLI for access to everything. For example, we’re using the Google Ads MCP server for ad analytics. That said, it’s fairly limited so we may find ourselves wrapping the Google Ads API in the gw CLI soon.

Despite the (very real) tradeoffs, the gw CLI approach to systems access has served us well. We’re rarely hitting token limits, we don’t have to manage a menagerie of 3rd party MCPs, we can be pretty confident in our security and we’ve been able to easily extend it whenever we need new functionality. Now that we have most of our important systems covered, we can quickly spin up new capabilities. I think this investment will continue to compound.

Next week, we’ll cover how we’re providing context and memory to our agents, as well as our approach to shared skills.

Ok, so the headline is a joke. Sort of.

I published my last post exactly 1 month ago. That’s my longest hiatus since I started Uncharted Territory back in August of 2024. In fact, I don’t think I’ve ever missed consecutive weeks until now.

Life got in the way (in a good way). The first week of March was given over to a team-wide offsite, which we spent outlining exactly how we’re transforming Gradient Works into an agent-first company. (More on that in a later post.)

I spent the last two weeks in Japan with my family. It was—largely—a 10th birthday present for my daughter who’s fascinated with the country.1 Over 10 days, we visited Tokyo, Kyoto and Osaka. Very little of it had anything to do with B2B sales.

Or did it?

History, spirituality and… business?

Sales has, of course, existed since humans first started hanging out in groups and realized that it was often easier to trade stuff than constantly bash each other over the head. It took quite a while for that to get organized into something resembling our modern day ideas of companies producing goods and services for specific markets.

Japan, however, has an incredibly long history of commercial activity that bears a surprising resemblance to our modern day ideas. According to a Bank of Korea study, more than half of the oldest companies in the world are located in Japan, including the five oldest. The oldest, Kongō Gumi, was founded in 578. A little perspective: when Thomas Jefferson was drafting the Declaration of Independence, they had already been building temples and shrines for 1,198 years.

I’d read about this company at some point and it briefly popped into my mind a few days into our trip as we visited the Fushimi Inari shrine in Kyoto—the most important Shinto shrine devoted to the Inari kami2. I don’t think Kongō Gumi had anything to do with this particular shrine, but the first buildings were built in 711.

Today, you arrive there by getting off at the thoroughly modern train station. You immediately pass through a torii (the first of many, more on that in a moment) and head up a gently sloping street filled with vendors serving both the tourists and the faithful as they wind their way up to the shrine itself. You can buy everything from engraved chopsticks to fox trinkets to cheese waffles to barbecued eel. We were there on a random Sunday and it was packed.

The shops continue from the train station all the way up to the grounds surrounding the first shrine. Not knowing what to expect, I was a little taken aback at how freely the commercial and the sacred mixed together. If I’d done my homework, I wouldn’t have been surprised—Inari is the kami of merchants and prosperity.

Fushimi Inari is famous for its 10,000 torii. Several hundred of these gates are set close together, forming a tunnel (the Senbon Torii3) through the forest up the slope of Inariyama. The combination of the setting and the surrounding forest still somehow made it feel hushed and solemn despite the crowds.

This tunnel is yet another example of the mixing of the spiritual, the commercial and the historical that seems somewhat unique to Japan. Each of these torii were donated by a business, a practice that began in the 1600s.

So does this actually have anything to do with B2B sales?

Customer experience is a craft

I’m not suggesting the lesson is we in the US should quite literally enshrine business as a spiritual pursuit. However, I do think this unique combination may contribute to something else I noticed in Japan: a level of care and depth to commercial experiences that we really can learn from.

I’ll offer a quick caveat: my 10 days as a tourist in Japan don’t represent the reality of the people and their culture. Furthermore, nearly everyone I encountered there was in the business of hospitality—explicitly aiming to provide quality experiences. This is not an unbiased sample.

That, however, doesn’t change the fact that so many people we interacted with routinely went above and beyond to make our experiences fantastic. Here are a few highlights:

• After a particularly long day of travel, we tried a local hamburger restaurant4 in Kyoto. As we were leaving, the wait staff literally ran after us to make sure we got stickers.

• The staff at a vintage kimono shop we stumbled across absolutely fawned over my daughter, letting her try on lots of different kimonos to find the perfect one, styled her hair and did a full-blown photoshoot. She was over the moon.

• We randomly stopped into a shop in Kyoto selling wooden crafts (we have a lot of woodworkers in our lives). The elderly shop owner—who didn’t appear to speak a word of English—made a flower out of thinly shaved wooden paper5 for our daughter.

• On our last night in Tokyo, the two amazing front desk staff at our hotel spent all morning finding us a car service to the airport so we could spend our last few hours in Japan wandering the city. When we got back, the car was waiting for us, already loaded with our stuff.

Now, what’s interesting about these experiences is that each involved plenty of GTM technology. We wouldn’t have found the restaurant or the hotel without their excellent SEO. The staff at the kimono shop asked to post some pics on Instagram to help with social exposure. Even the old carpenter managed his inventory on an iPad.

But the aspects that make them more than a simple commercial transaction—that make them literally remarkable—all came from humans who took the care to make the experience meaningful.

Even though I was 14 hours ahead, I’ll admit to checking in on LinkedIn periodically. My entire feed was devoted to AI and how it’s transforming GTM. In the past there were parts of every customer experience that simply couldn’t be turned over to a machine—whether in 578 or 2026. In the future, that will be a choice. It won’t be a matter of can’t, it’ll be a matter of should. We should choose wisely.

A few additional observations

• Japanese has 3 alphabets. Hiragana and Katakana are fairly straightforward to learn mnemonically (thanks Dr. Moku). By the time I left, I could at least sound out a bunch of words and understand the difference between native Japanese and loanwords. Kanji, on the other hand, is intimidating. I basically got as far as recognizing Tokyo (東京).

• The egg salad sandwiches at 7-Eleven are as good as advertised. Let’s just say I had quite a few. I love sushi, wagyu, and enjoy a good katsu, but I don’t love broths and soupy noodles like some people do. Every so often I needed a hit of that perfectly soft white bread and creamy kewpie mayo as an alternative.

• The trains really do run perfectly on time—we took a lot (both bullet and otherwise) and were never even a second late.

• Food was much cheaper than I expected. Inflation got us good here in the US.

• If you saw a large poorly dressed white guy, you could be sure he was American or Australian. You just had to wait for him to talk to figure out which.

• A good futon mattress is astonishingly comfortable.

In 2026, RevOps will change dramatically. The end is the same: provide the platform that enables GTM teams to succeed. The means will need to change thanks to AI agents. (Which are finally real, btw). Counterintuitively, I think it’ll mean RevOps orgs are less focused on tech stack and more focused on enablement.

I’ve been in the trenches (er, the terminal) trying to remake Gradient Works into an agent-first company over the past few weeks. I’m learning what it takes to make agents a reality, even at a relatively small scale. It’s different than I expected. The technology is the easy part. The hard part is the enablement—not of the people using the agents, but of the agents themselves.

I haven’t seen too much use of the term “agent enablement”1 so I’ll provide my own definition. It means providing AI agents with appropriate access to business systems, sufficient information about their business context and proper skills for their job. Agents without access, context and skills are just a neat party trick with a penchant for telling convincing lies.

Think about a task like “prospect these 10 companies”. Whomever is doing that needs secure access to tools (LinkedIn Sales Nav, Salesforce); context (ICP, personas, market knowledge) and skills (the right sequence of steps to fully research a prospect). A rep without all that would fail. So will an agent.

The benefits of AI agents are such that most forward-looking GTM teams will at least attempt an agent-first transformation over the next 12 months. RevOps is well positioned to lead this charge, but it’ll require collapsing the boundaries between the “tech-first” mindset of most ops teams and the “people-first” mindset of most enablement teams.

Go back to the access, context and skills example above. Only the access part is even remotely technical—relating to APIs/MCPs/CLIs, information security and data governance.

Context and skills, on the other hand, are all about synthesizing large amounts of information into digestible documentation. This has historically been the domain of sales training, sales enablement and product marketing.

Now all three factors—access, context and skills—need to be delivered seamlessly together and packaged properly for agents to use them. It’s enough to make one think it’s impractical to keep RevOps and enablement separate.2

Let’s look at how agents are likely to work within human teams and then consider some practical issues for enabling them to be effective.

Two agentic modes

After a couple years of hype, a highly effective agent model that combines a local “agentic loop” with a powerful LLM equipped to use tools and skills has finally emerged.

This model has already transformed software engineering. The rest of knowledge work—including GTM—is next. Claude Code and OpenAI Codex are quickly moving beyond code. OpenClaw, which uses the same basic architecture as coding agents, has positioned itself as a general purpose agent from the beginning3.

So, if your job involves a computer, it’s about to change. Radically. Plenty of others have pontificated about whether this is horribly bad or just “normally” disruptive. I won’t do that, but I will make a prediction.

I believe we’ll will work with agents in two basic modes:

1. Assistant - This agent occupies space on your desktop. It’s integrated with the systems you care about and you chat with it to get tasks done. Think “find time for Bill and me to meet” and “analyze last month’s closed-lost reasons and see how they changed vs the prior month”. It learns how you want to work, uses tools on your behalf and generally makes you better at your job. In short, assistants augment humans.

2. Teammate - These agents run autonomously. They have specialized knowledge, they engage with multiple other people/agents, make plans and execute long-running tasks. They have their own environment, their own identities and their own tools. They require management and direction. In short, these agents replace humans.

Note that these are basically just AI versions of regular jobs. And for that, I owe you an apology. About a year ago I wrote AI Needs its Sewing Machine Era. I argued4 that the best way to build AI systems was by coming up with a wholly new way of looking at the problem, not by copying what humans do.

I was very wrong.5 The agent model that’s working is the one that’s most similar to how a human works: give it a computer, give it some training, give it access to software tools and give it the ability to get guidance as needed from knowledgable humans.

And that “help agents work how humans work” metaphor turns out to be a big unlock.

How to enable agents

Humans rarely do their jobs—GTM or otherwise—by mindlessly and precisely following flow charts. We learn the tools of our trade, we develop domain expertise and we learn to apply techniques that have been proven to work.

This is where a lot of the early “agent” systems failed. Early models weren’t very good at maintaining context and making decisions about what to do next. This limitation meant that most of the effort went towards tight guidance around steps the agents could take and sequences they would follow. Ultimately, they weren’t all that different from building out step-by-step workflows.

Modern agentic models (e.g. Opus 4.6 or GPT 5.2) are good at holding a lot of information at once and making decisions about what to do next based on an understanding of what they’ve done so far and what they’re ultimately trying to achieve. They just need good tools, good information and reasonable guardrails. In short, they’re a lot like a smart and industrious human.

Access

Access principles for agents are the same as for people: give them the most secure, least privileged access to the systems and information they need to do their job. They get what they need but with limited ability to expose sensitive data, damage your systems or otherwise mess stuff up.

Let’s look at a few different access models: APIs, MCPs and CLIs.

Agents are pretty good at interacting directly with APIs. They can take your request and turn it into code they execute to call the API. While it often works, it’s bad for security because you’ll need to hand over sensitive data like API keys directly to the model.

Most teams use MCPs to provide access to their systems. Both Claude Code and OpenAI Codex support MCP out of the box and there are lots of MCP servers out there. Two words of caution:

• MCP can be a “token hog”. It stuffs a bunch of information into the agent’s context widow (sometimes about things you’re not using). This can crowd out your more important task-specific information and cost you more money.

• MCP has its own pretty challenging security issues.

Finally, there are command-line interfaces (CLIs). These are simple text commands that “wrap” various remote functionality. Models are very good at using these. In fact, much of what the coding models do is based on using CLI commands. We’ve primarily gone down this path at Gradient Works, using bespoke CLIs6 to access our systems. They don’t use many tokens, we can customize access to meet our exact needs and we can embed our own security measures.

I’ll add one bonus option: browser use. Some services (cough LinkedIn cough) aren’t friendly to programmatic access. The agents can directly interact with the UI in the browser, but it’s slow and costs a lot of tokens.

The two best routes are MCPs and CLIs. They’ll work for both assistant and “teammate” use cases. Some browser use may be appropriate for assistant agents. For example, sales reps might be able to automate a bunch of Sales Nav clicks.

As with human system access, security is one of the most annoying things about agent access. It’ll be very tempting to just open the gates wide open and figure it out later. Don’t do this. It won’t seem so hot when an agent deletes a bunch of companies out of HubSpot or you suddenly see a user’s API key making weird requests to one of your systems. Just ask Drift.

Context

Think of context as the background information an agent needs to inform how they do their job—before even attempting to execute a specific task.

Imagine you want an agent to asses if a customer is at risk for churn. To do an effective job, it would need to know lots of things such as:

• What is your company and what does it do?

• What products and services do you offer?

• What do customers generally do with your products?

• What constitutes good engagement from a customer?

• What kinds of companies are likely to be good customers?

• What do we know about how that customer’s implemented your product?

• What kinds of issues have they experienced recently?

• Who are the key stakeholders at that customer?

• Has anything changed recently with that customer’s business?

• How do you identify a customer in your systems?

• How do you know what a customer spends or when they renew?

These are contextual questions that range from semi-existential (e.g. “Who do I work for?” and “What do we do here?”) to hyper-specific (“What’s the last update we got from Customer X at the meeting on Thursday?”).

We take it for granted that employees know these things (though maybe we shouldn’t). Of course they know what the company does. They went through onboarding! Of course they know about the latest product offerings. They were in the launch meeting for the last feature! Of course they know the situation with the customer, they get all the support emails!

You’ve got to make all this information accessible to your agents if you want them to be effective. The state of the art for doing this seems to be—I kid you not—writing a bunch of neatly organized text files in Markdown format.

A big part of enabling agents is gathering this data wherever it lives (videos, PowerPoints, etc), extracting it and turning it into clean documentation. Luckily AI is pretty good at helping you bootstrap this. It helps if this data can be easily shared across agents and versioned as it changes7.

This area is where RevOps and sales enablement can make an awesome combination. RevOps can help automate the context gathering (e.g. fetching call transcripts) and sales enablement can help shape it into usable context (e.g. extracting key themes).

Skills

Skills are a special kind of context that gives an agent the specific knowledge it needs to carry out certain tasks. Common examples are reading PDFs or doing data analysis with SQL. So far at Gradient Works, we’ve made skills for things like navigating our Salesforce, building analytics dashboards, researching people on LinkedIn and triaging email.

Like just about every other part of agent knowledge, skills are just Markdown files in a specific format. That means they’re easy to write, manage, share and version. They’re just plain old words that describe how to do something.

You can enlist domain experts to write skills or you can use the agent to help you. This kind of skill “bootstrapping” with the agent is the most effective way I’ve found to make high-quality skills. You can go about it in two ways:

• Jot down some notes, ask the AI to expand on them and then work with it to make adjustments.

• Work with the agent to go through a task, prompting it to do each step and correcting anything it does wrong. One you’re done, ask it to write up a skill that describes what you just did. I did this with my email triage skill and it worked great.

Skills interact with access and context quite a bit. For example, much of our internal Salesforce skill is information about how to properly access Salesforce using our CLI tools.

Just like with humans, task-specific skills should be informed by the larger context. Going back to the example in the previous section, you might end up building a Churn Risk Assessment skill but that will necessarily build on context about your company generally and the customer being assessed specifically.

This is another area ripe for collaboration between RevOps and sales enablement. Every playbook or prospecting training is a potential skill in the making.

Wrapping up

You wouldn’t expect an employee to do great work on day one—no matter how smart they are. Of course they need access to your internal systems. But you don’t just give them a Salesforce login and stop there.

They also need time to get up to speed. They need to go through onboarding and training. They need to shadow more experienced folks. All that effort builds context and skills. It’s enablement.

All of the above is true for agents. People understand the access part. They set up a couple MCP connections and then expect their agents to do good work. They won’t. You’ve (sort of) solved access but not context and skills.

Like people, agents need access to systems, onboarding, training and coaching to do a good job. Unlike people, they want this in a technical wrapper of MCPs and Markdown files.

That’s the opportunity for RevOps to partner with sales enablement and lead this next phase of agentic adoption. They way forward is a unified team of technologists and trainers—one that understands that documentation is the new automation and that agent enablement is the new sales enablement. Your agents and their human teammates will thank you.

For two years now, AI agents have been the next big thing in GTM. AI SDRs were all the rage. Back in 2024, Marc Benioff was talking up Salesforce as the “largest supplier of digital labor […] all powered by these autonomous AI agents”. The reality didn’t come anywhere near to matching the hype.

In the first 6 weeks of 2026, that all changed.

There were glimmers in late 2025, but we weren’t quite there yet. This week, however, I’ve had multiple conversations with other CEOs and sales leaders that all came down to the same thing: the agent reality has caught up to the hype.

In December 2024, I wrote an article titled “Are You Behind in AI?”. True to Betteridge’s Law, the answer was “no”. Fourteen months later, the answer is almost certainly a resounding “yes”.

I can’t over-stress this: there’s a sense of near-panic FOMO. Every minute spent not taking advantage of these agent capabilities feels like a massive wasted opportunity. One CEO told me he’s working 18 hour days to get his agent system off the ground. I’ve certainly felt it myself. Hell, I learned today I have to break down and get glasses because my 45-year-old eyes can’t look at a terminal for 10 hours straight anymore.

In this article, I’ll do my best to share what’s changed and how this new crop of agents work. I’ll try to do it with a minimum of jargon and technical detail. If you’re not yet taking advantage, I hope you take this knowledge and light a fire under your RevOps leaders ASAP.

Now, let’s see how some programs that read and write text files on your computer while looking like a 1980s DOS game are changing the world.

The context

Anthropic last Thursday raised $30B at a $380B valuation. Their announcement included this chart:

Why yes, they did go from a $1B to a $14B run rate in less than 14 months (Jan 2025 - Feb 2026). As Jason Lemkin points out1, Salesforce took 10 years (2009 - 2019) to do roughly the same thing. A big portion of this growth comes from one product: Claude Code. Released in May of 2025, Claude Code itself is at a $2.5B run rate that’s accelerating like crazy. Per Anthropic’s announcement:

Claude Code represents a new era of agentic coding, fundamentally changing how teams build software. Claude Code was made available to the general public in May 2025. Today, Claude Code’s run-rate revenue has grown to over $2.5 billion; this figure has more than doubled since the beginning of 2026. The number of weekly active Claude Code users has also doubled since January 1. A recent analysis estimated that 4% of all GitHub public commits worldwide were being authored by Claude Code—double the percentage from just one month prior.

Business subscriptions to Claude Code have quadrupled since the start of 2026, and enterprise use has grown to represent over half of all Claude Code revenue. The same capabilities that make Claude exceptional for coding are also unlocking other new categories of work: financial and data analysis, sales, cybersecurity, scientific discovery, and beyond.

This growth has coincided with software stocks losing $1T in market value over the past few weeks. The thesis is that Claude Code is so powerful that people won’t buy software anymore—they’ll just build whatever they need.2 So what does a new tool for building software have to do with GTM?

I’ve spent a good part of my life as a software engineer. I care deeply about the craft of writing code—so much so that I named my daughter after the first programmer. After my first hour with Claude Code earlier this year, I realized something: I’ll never personally write code again. After another hour with Claude Code, I realized something else: I’ll never do any work involving a computer the same way again.

The coding is a trojan horse. Claude Code may look like a coding tool, but it’s actually the first truly capable general-purpose AI agent suitable for businesses use.

Anthropic knows this. It’s why they shipped Cowork, which is really just a wrapper around Code for non-developers. OpenAI knows this. It’s why they shipped Codex and paid big bucks to win the bidding war for the OpenClaw guy.

Many of us in GTM got our first impression of AI “agents” from the early attempts at AI SDRs. These were mostly just spam cannons that could generate email at scale that varied somewhere from “halfway decent” to “incredibly embarrassing”. Needless to say they didn’t work.

By the time I wrote my 2025 post about agents, there was a little more nuance. However, that post now looks comically quaint. If your idea of an “agent” in 2026 is a an inept AI SDR, a chatbot that you can talk to, a custom GPT that can summarize a few files or an n8n workflow that uses an LLM for a couple steps, the world has moved on.

After 2+ years of “agents” being an AI buzzword, they’ve finally arrived. They just don’t look quite like most people imagined even a few months ago.

How agents actually work

These breakthrough agents aren’t cloud-based software with drag-and-drop workflow builders. They’re just programs that you install on your computer. They do useful things by thinking about stuff, reading stuff, writing stuff and running other programs—not unlike how you and I get work done. When they need to think about what to do, they send data to an AI model running in the cloud like Claude or an OpenAI GPT.

They differ from the “normal” software you’re used to in 4 key ways:

1. They’re text-based programs3 that run in a terminal. While most of them also have a graphical UI, they’re most powerful in their native form. If you’re old enough, you might remember text-based DOS programs. They’re like that. This gives them their hacker-y feel.

2. They can run other programs. There’s a whole ecosystem of utility programs on our computers that do all kinds of useful stuff that most of us never see—things like searching files, editing files, fetching web pages, interacting with other software, etc. They’re all there as text-based commands available inside the aforementioned terminal.

3. They can write their own custom programs. Want to analyze a complicated spreadsheet? The agent can use the AI model to write specialized code on demand which it can then run just for that purpose.

4. They “know” specific stuff (like how to do a task) and “remember” things by reading and writing to simple text files4. You can give them specialized knowledge just by explaining it in a text file.

The thing that makes this special is gluing it all together with AI and running it over and over again in a loop.

The “agentic loop”

Agents basically are a loop. They start with some context you provide and a task you ask it to do. From there the AI decides what to do next. That might involve reading an email, writing a program, checking LinkedIn, sending a Slack or searching the web for information. It then takes the output of that step and feeds it back into the AI again… and again until it decides it’s done5.

This agentic loop looks like this:

This simple construct is where the magic happens. Anthropic, OpenAI and others have invested mind-boggling resources into building models that are very, very good at handling these kinds of loops. They follow instructions, remember important details, make good decisions, even catch and correct their own mistakes.

It really wasn’t until November of 2025 that models got good enough at running an agentic loop. Now they’re really good. They think through problems, make plans, and (almost always) do what the user asks.

Better models are the primary reason agents have caught up to the hype—but they’re not the only one. All this AI doesn’t add up to an agent if it can’t do actual useful work. There are three other (comparatively simple) pieces that complete the puzzle: tools, skills and memory.

Tools

I mentioned before that agents can run programs (both existing ones and ones they write). They can also read files, write files, search the web, run other agents or talk to other systems. You can think of these actions as “tools” the agent can use.

For example, you could tell an agent to read a list of prospects in Excel and update each row with their city. It might read the list from an Excel file (tool) that contains the list, use Chrome to find each prospect on LinkedIn (tool), read their bio to find the location (tool), and then write the data back to Excel (tool).

The key advancement here is that agents make it easy to plug in new tools that can do different things or access different data. That might be an MCP that accesses HubSpot or the ability to call an enrichment API. This makes a generic agent able to access the capabilities and data necessary to do your specific tasks. Think of it like giving a new employee the logins they need to the various systems they’ll use to do their job.

Just like with a new employee, though, having the login to the CRM isn’t enough. They need to now how to do things your way. That’s where skills come in.

Skills

Tools give agents the ability to take specific actions. They’re pretty good at guessing what actions to take based on the task at hand—not unlike a reasonably eager and intelligent employee. Often, however, they need more guidance and context on how to get an entire job done using their available tools. That’s where skills come in.

Skills are remarkably simple. They’re basically just text files that describe how to do something. For example, Claude’s ability to work with Excel mostly stems from the instructions written up in this file right here. When you ask Claude to do something in Excel, it looks for relevant skills, finds this file, reads the instructions and then gets to work.

Like tools, the power comes when you write your own skills (or download existing ones) for your specific needs. This makes it easy to extend these agents with new capabilities for your specific needs.

Memory

Memory sounds much fancier than it is. Like everything else here, we’re basically talking about text files. These simply give the agent context about the job it’s trying to do. This is somewhat analogous to onboarding and coaching.

For example, an SDR agent would need to know about the company it works for, messaging and positioning, ICP and specific information about the product its selling. This gives it the context to properly create messaging for a prospect. This might live in a text file (or files) that the agent can access and serve as a kind of onboarding document.

Over time, you might correct the agent’s behavior (e.g. “handle objection X with response Y instead of Z”) and ask it to update its memory text files with what it learns. Next time it’ll have that information handy and do things differently.

Wrapping up

The dam has broken. The Rubicon has been crossed. There’s a disturbance in the Force. Something big is is happening.

After years of hype, AI agents are really here. Claude Code was the first to find the right mix of model quality, data access and extensibility. OpenAI followed suit. OpenClaw has as well, in a much more chaotic way. More will follow.

Don’t let the weird terminal UIs and text files intimidate you. These agents can do way more than code—and smart operators are already putting them to use for GTM. There are plenty of times when the hype is fake and the FOMO’s not worth it. This isn’t one of those times. Get to work or fall behind.

Welcome to the 3rd and final post about The Composable GTM Ecosystem. If you’re still with me, I appreciate it. I know these posts have been a little more technical and a little less GTM than most of my other posts. (More on that in just a moment.)

In the event you haven’t read Part 1 and Part 2 I’ll give you a quick summary.

In Part 1, I argued that B2B GTM tech is becoming less monolithic and less CRM-centric. Instead, the smart GTM operators are “composing” solutions from best-of-breed building blocks.

In Part 2, I talked about how these operators are actually composing these parts together using various approaches to building workflows. My prediction is that this emerging orchestration layer will probably look more like the agents powered by Claude Code or OpenAI Codex than the more traditional (though AI-inflected) workflow tools like Clay or n8n.1

In today’s post, I want to wrap up the series by talking about what GTM teams need from software so it can plug into their orchestration layer. As you’ll see, software that works well in a human-first ecosystem built around siloed user interfaces looks very different from software designed to be a building block in a larger system.

We’ll get to that.

But first, a slight digression about being a GTM leader in 2026 and the changing technical skills that requires.

It’s always most technical before the dawn

I’m afraid that GTM is about to get a lot more technical before it gets better. Workflow tools and AI agents are too good to ignore. The problem is they’re also still very technical products.

I’ve seen a lot of folks on LinkedIn who didn’t know what a command line was two weeks ago running autonomous agents with full access to their computers. It hasn’t always gone well.

These kinds of workflow and agent systems sit in this weird netherworld at the intersection of developer tools, consumer products and business software. Historically most developer tools start out as extremely rough proofs of concept and usually only encounter an audience that’s technically prepared to handle it.

Consumers and business users rarely ever encountered these kinds of tools, even after they stabilized and became polished. If they did, they were wrapped in layer-upon-layer of product packaging and user interface. AI? Not so much.

That said, you can’t let this stop you. The tools can do amazing things now and if you’re not figuring out how to harness that, a competitor is. These tools will eventually get easier to use and more approachable for non-technical users. Unfortunately, you can’t wait that long. I’m sorry if you’re “non-technical” but it’s time to get more comfortable with your filesystem, command line tools, APIs, etc.

Now back to the—fairly technical—rest of this post.

Interfaces for users or machines?

Going forward, software should have two primary interfaces: one for users and one for machines. This has been true for a while, but the user interface mattered a lot more than the machine interface.

The composable GTM ecosystem puts these interfaces on equal footing: APIs (Application Programming Interfaces) are just as important as UIs. Without an API, a piece of software simply can’t be composed into a workflow.

In Part 2, I described the CRM as a compromise:

The CRM represents a compromise, one that combines GTM data, workflows and user interface into a single product. Until recently, those things were so intertwined that the only way to do any one of them effectively was to tightly couple all of them together.

That description doesn’t just apply to CRM, but to B2B SaaS products generally (all 40k+ of them)—which includes the vast majority of GTM tech. Every one of these products is really built to automate some kind of specific workflow for some specific set of users who work directly in the product. In the process, it captures data and (hopefully) does something of business value. SaaS is simply packaging up data + workflow + UI and delivering it as a service.

If all goes well (from the SaaS vendor’s perspective) the software becomes a system of record, making it very sticky for customers and producing a nice long-term revenue stream for the vendor. To do that, the software needs data.

Therefore, vendors are most motivated to get data into their systems, not out. The best way to get data in? Have users enter it in. The best way to get users to do that? Focus on the user interface. And wouldn’t you know it, that’s where most product managers spend their time. Sure they may talk about jobs to be done and users wanting holes not drills but the answer is always some form of “make the job possible by clicking around in our product”. The vast majority of products are inherently UI-first.

Composition with workflow tools turns that whole deal on its head. When you use a workflow tool or AI agent to get things done, you don’t want to use the user interface. Humans are pretty good at clicking around on little pictures and words that represent things we want to do. Machines, less so. They can, but it’s pretty inefficient.

You also don’t just want to put data into the software. To compose building blocks together, you need those blocks to do things based on inputs and help you get data out—all so you can send that data along to other tools so they can do their thing.

Luckily we already have some technology for doing all this: APIs. These allow pieces of software to interact directly without a human being involved. I know this isn’t new. I’m sure you’ve encountered APIs before—most GTM software has them—and used them in various ways. If nothing else, you’ve probably used your CRM’s API to connect with other parts of your stack.

Here are two things to know about APIs:

1. APIs are often second-class citizens. Since most SaaS applications are primarily concerned with the UI, the APIs come second. There are things you can do or access in the UI that you can’t do or access with the API. Or the API changes more slowly than the UI. Sometimes this is intentional—prioritizing stability for existing integrations—and sometimes it’s just that the PMs don’t care as much about the API.

2. APIs are a bit like websites—no two are alike. They have standards for how you access them and some basic building blocks for sharing information2, but each individual one is different. Just like each website has different layouts and buttons, each API has different ways of manipulating data. Knowing how one API works does not mean you know how another API works3. And, unlike websites, APIs don’t give you helpful labeled buttons to discover what’s possible. The system using the API needs to know exactly what it can do and how to do it.

The first point means that just because a piece of software offers a capability and an API, there’s no guarantee you can effectively use it within your orchestration layer.

The second point means that APIs are fine if you’re building a tight integration between two systems that’s not meant to change much—engineers can read the documentation and code up everything to work just so. This is often exactly what you want! Marketo better reliably send leads to Salesforce and Clay should always sync data to HubSpot without random errors.

This also works pretty well for more traditional workflow tools like Zapier, n8n and Clay. With the user’s help (and some pre-built integrations), they can plug into lots of different APIs to connect various systems together. Of course, those workflow vendors have to maintain all those integrations, but that’s their problem, not yours.

Agents can easily talk to these APIs if they know what to say. However, the uniqueness of each API makes it harder for AI agents to quickly discover capabilities on the fly and use them. Advanced agents are good at reading online API documentation to figure out what’s possible, but that’s slow and expensive.

There are some attempts to solve that last problem which, predictably, involves another acronym: MCP (model context protocol). MCP is a sort of hybrid between a text-based UI and an API built specifically for helping AI agents learn what they can do and then enabling them do it. Today, most MCPs are just slightly-more-agent-friendly wrappers around APIs. MCPs may not be the long-term solution4, but something similar will probably emerge5 and that too will most likely rely on APIs.

In short, a building block in your workflow is only as good as the API it offers. GTM tech vendors will need to compete on the quality of their API as much (or more) as they compete on the quality of their user experience6.

How to evaluate an API

So, what does good look like for an API? I’ve used a lot of APIs in my life as a software engineer and as a GTM operator. Below are some practical questions you can use to evaluate a product’s API to determine whether it might fit into your composable GTM workflows:

• Can you get data out as well as in? Ensure the API allows you to get access to all the important data contained within the product.

• Can you do everything in the API you can do in the UI? Sometimes certain features and capabilities from the UI aren’t available via the API. For example, if the UI lets you search, the API should let you search as well.

• What limits are there? Many APIs have “rate limits” that prevent you from accessing things more than a certain number of times over a period. This can sometimes be a big restriction, as anyone who’s dealt with running out of Salesforce API calls can attest to.

• Is it well documented? - If the online docs are complete and well organized, it’ll be relatively easy for you to configure workflows that use the API. It’ll also be relatively easy for agents to read the docs and figure out how to talk to the API.

• Do they offer an SDK or programming language libraries? These tools make it easier to access the API, handling some of the details for you. It’s not required, but agents can build on these if they’re available.

• Does it take security seriously? - You should expect the API to use standard authentication mechanisms like OAuth and/or HTTP header-based API keys. Can those keys be tied to specific users and revoked? Is there a robust permissions model for authorization that can, for example, make it so certain users can read data but not change it?

• Can you test it out? Just because a capability is documented doesn’t mean it works as advertised. Make sure you can actually test the API in something resembling your real workflow before making a big commitment.

• How is the data licensed? This is mostly related to a specific kind of GTM API—data enrichment. Make sure you know what you’re allowed to do with any data during your contract and after termination.

If a product’s API scores well across all these criteria, it likely means it’s composable and will plug nicely into your orchestration layer. If not, you need to make sure it has enough value on its own and that you can dedicate enough resources to use it solely through the user interface.

Wrapping up

It’s a brave new world out there for those of us building GTM tech stacks. The era of CRM-centrism is waning. The new model that’s replacing it—composing best-of-breed services using AI—is more complex and more technical, but far more powerful. It’s worth the tradeoff.

Last week, in Part 1, I wrote that the CRM-centric model of the GTM technology ecosystem is under threat. The CRM represents a compromise, one that combines GTM data, workflows and user interface into a single product. Until recently, those things were so intertwined that the only way to do any one of them effectively was to tightly couple all of them together.

That compromise may no longer be necessary. If technology (AI or otherwise) increasingly does jobs performed by humans today, it removes the final thing holding CRM-centrism together: the requirement to always have a human in the loop.

This creates an opening to compose a solution from best-of-breed components. We’ve already seen this happen in GTM-adjacent markets like e-commerce and content management.

But how are teams actually composing these solutions? That’s the job of the orchestration layer.

The emerging orchestration layer

If you live in certain corners of LinkedIn, you’ve likely seen comment-bait workflow screenshot posts or “20 tools I used to generate a gazillion dollars in pipeline” posts. While the posts are clickbait, the concept is real.

Smart technically-inclined GTM folks really are composing increasingly powerful systems by orchestrating data and process flows that combine specialized services. To do this, they’re tapping into the rapidly evolving GTM orchestration layer: the part of the tech stack that connects all the individual vendor tools into holistic workflows that do something valuable.

Coincidentally, this layer is where most of the value in the GTM technology ecosystem is currently accruing. Clay, the most well-known player in this space, just allowed employees to sell stock at a $5B valuation. Another contender, n8n, just quietly raised at $2.5B. Needless to say, it’s an interesting1 time to be an orchestrator.

The rest of this piece lays out the 3 major orchestration layer models and speculates (wildly) on how this might all evolve for those of us trying to build GTM systems. Here are the 3 models:

• Low-Code - drag-and-drop workflow builders that allow users to craft processes using building blocks for logic and integrations

• Aggregated - a special case of low-code workflow builder and data marketplace largely represented by one player: Clay

• Agentic - AI that, given a directive, can connect with systems and achieve goals on a user’s behalf

Let’s look at each.

Subscribe now

Low-code workflows

Low-code (or no-code) workflow tools provide a graphical user interface that makes it easy to connect systems together. Zapier, founded in 2011, was an early example. Make is another. Lately, n8n has emerged as the darling of more technically inclined users.

The idea is you can drag-and-drop integrated connectors and logic together to do things like update a CRM record when a form is submitted on your website—without having to know how to write code to connect those tools together via APIs.

These tools typically offer massive libraries of pre-built integrations—most of which serve use cases that have nothing specifically to do with GTM. Zapier boasts more than 10,000 while n8n has more than 1,000. They also allow for extending integrated capabilities by providing lower-level building blocks that can access any available API.

While their foundations are in traditional drag-and-drop style workflows, these tools have recast themselves as systems for building AI agents. It’s a pretty natural fit because they make it relatively easy to access the data and systems that agents need to do interesting things.

What they don’t typically do is act as a marketplace for the tools they integrate with. You don’t pay Zapier or n8n for access to the tools and data their workflows integrate with—it’s up to you to sign up directly with those vendors and then “bring your own key” to enable workflow access. The workflow platforms themselves make money with a usage-based model that charges per step or per execution.

One player in the low-code workflow space, however, takes a different approach.

Aggregated workflows

Ben Thompson, tech industry analyst and publisher of the popular Stratechery newsletter, has written extensively about what he calls Aggregation Theory which describes how platforms work in the internet era.

He starts by defining traditional modes of competition that apply to any market:

The value chain for any given consumer market is divided into three parts: suppliers, distributors, and consumers/users. The best way to make outsize profits in any of these markets is to either gain a horizontal monopoly in one of the three parts or to integrate two of the parts such that you have a competitive advantage in delivering a vertical solution.

Aggregation Theory posits that it used to make the most competitive sense to integrate scarce supply with distribution (e.g. newspapers integrated editorial content—with ads—and physical delivery networks). But, in the internet era, it’s more profitable to integrate user experience with distribution so you control demand for an otherwise abundant supply (e.g. Google gets an infinite supply of individual pages from the whole web which they serve up—with ads—to their users).

Historically a lot of GTM tech—especially in the data enrichment space—worked like the newspapers. ZoomInfo built a massive business and contact database (supply) which they integrated with a sales engine (distribution). They bragged about the billions of data points that they’d mined, cleaned and structured. Other data providers did the same. Everyone competed on the size and quality of their proprietary supply of data, not the user experience of using that data.

Clay came along and flipped it all around. They built the distribution mechanism and competed on user experience while selling easy access to myriad data suppliers—both via direct integrations and “bring your own key” API calls. If the user chooses the convenience of direct integration, they pay Clay some “credits” for each piece of data they retrieve. That revenue then gets split with the integrated partner.

That model let Clay tout access to all kinds of data without being responsible for the data itself. They recognized that the data was a commodity with many willing suppliers. They could compete on the integrated experience, control demand to get favorable terms from suppliers and disrupt the supply-integrated companies like ZoomInfo.

In fact, if one supplier gives bad data, the best practice is to try another one, paying Clay more credits in the process. Not only do they not get blamed for bad data, they actually make more money! That’s a neat trick.

From this foundation, Clay has rapidly expanded into a unique kind of workflow platform that combines a Stratechery-style Aggregator with the other features found in the low-code workflow tools. They also caught the AI wave early with their “Claygent” feature to scrape data from the web.

So is Clay the future of GTM orchestration? Maybe not.

Agentic workflows

Now we get to what may well be the final boss of workflow technology: agents.

Agents use AI to do the work for you. You tell them what you want done and they go figure out how to make it happen—making decisions, accessing data and using various tools along the way. This differs from the workflow tools we’ve described so far which require step-by-step instructions spelled out for each specific task.

It all sounds great, but we’re about 2 years into agent hype without a whole lot of working agents to show for it. There’s reason to be believe, however, that agents might finally be coming into their own.

Over the past couple months Claude Code has broken containment from a developer tool to something that non-coders are exploring. I can personally attest to Claude Code’s capabilities—it’s very good. That said, it’s still a command line application that runs in the terminal, which is not everyone’s idea of a good time. Seeing this, Anthropic in January released a friendlier version called Claude Cowork.

Not to be outdone, OpenAI just shipped the latest version of Codex, their Claude Code competitor. Meanwhile in the gnarlier corners of the AI internet, adventurous agent users have been testing out OpenClaw (f/k/a Moltbot, f/k/a Clawdbot).2

These agents have all more or less settled into a general design:

• They use a powerful LLM (e.g. Opus 4.5, GPT 5.2) which has been trained to follow instructions and reason about next steps while also having a reasonably large memory to keep track of things during long-running tasks

• They can write code and access things on your computer (more or less securely)

• They can use a web browser (more or less securely)

• They know how to connect to external systems using APIs or MCP

• They can be told how to do specific tasks in specific ways via Skills

Slowly but surely, these capabilities have added up to something resembling an actual colleague that can get real work done. It seems likely that the future of GTM orchestration will look like a lot of other knowledge work: done by agents with some (for now) human guidance.

If that AI vision comes to fruition, there’s very little reason for the low-code workflow tools to continue to exist except in niche cases where entirely deterministic processes are necessary. Even then, it’s unclear that those workflows couldn’t just be vibe coded—replaced by deterministic code written, deployed and monitored by agents.

Wrapping up

If I had to bet on a winner in the GTM workflow layer, I’d bet on the AI agents. They can produce code for the fully deterministic tasks (e.g. update this field if that thing is true) and also learn to properly handle the many semi-deterministic tasks that happen in GTM.

For example, there’s some skill in determining the next step in a sales process based on the totality of information that’s known about the prospect’s situation and the conversations so far. It’s semi-deterministic—there are good choices and bad choices but there’s still a wide range of action that can be taken within the set of good choices. AI agents can do this. Other orchestration models can’t.

So far in this series we’ve looked at the emergence of a composable GTM tech stack as a threat (or perhaps a response) to CRM-centrism and the orchestration layer that might actually enable the composition. In the next piece, we’ll look at the role of the rest of the GTM tech stack and how GTM tech vendors need evolve to participate in—and benefit from—this composable ecosystem.

Something’s happening to the GTM tech stack. Yes, it’s AI, but it’s not just AI. We may be on the cusp of a different kind of architecture for GTM tech—one built less on monolithic platforms and instead composed of best-of-breed components. This is the first of two posts investigating that shift.

The state of the stack

For the last 16 years, Scott Brinker has published a graphic of what he calls “the marketing technology landscape”. Scott brands this the MartechMap, but it really includes just about anything related to GTM, making it the best proxy we have for the overall GTM technology ecosystem.

The map started life in 2011 as a slide with 150 product logos. This seemed like a lot at the time. By 2025, it looked like this:

Those tiny colored pixels are actually product logos representing 15,384 tech products. (Go here to zoom in.) If you’re keeping score at home, the number of market participants has grown at a 39.2% CAGR since 2011. I’ve said before that the supply of software products is likely outpacing demand. I’d say this data point supports that thesis.1

No company uses all these products at once, so they pick and choose different products to form their tech “stack”. That makes sense. A “stack” sounds like an orderly arrangement, pieces fitting neatly together, lower layers supporting higher layers, everything in its right place.

Anyone who’s actually supported the unholy amalgamation of tech that represent the modern “GTM tech stack” knows this orderly analogy is… generous. It’s less a stack than a pile of overlapping functionality, spotty integrations and data silos aplenty.

There is some structure, though. A few pieces of tech sit at the center, while others roam the periphery. In B2B, one piece of technology tends to be the center of it all: the CRM.

Threats to CRM-centrism

On June 22nd, 1633 Galileo was found guilty of heresy by the Roman Inquisition2 because he argued for heliocentrism—that the Earth orbited the Sun. The Catholic Church, unfortunately, felt pretty confident God wanted Earth at the center of the universe (geocentrism). As punishment for thinking otherwise, they made Galileo live in his (quite lovely) villa under house arrest for the last 9 years of his life.3

It would be almost 200 years before the church fully came around to heliocentrism. For a long time, nobody got fired for choosing geocentrism even if it wasn’t actually correct. It was a very gradual diffusion from “crazy idea” to “matches observations” to “we know why this works” to “generally accepted”.

These shifts in worldview are sometimes only obvious in hindsight. That said, it’s possible we’re seeing the beginnings of something similar in the GTM world. For the last 20+ years, B2B GTM tech has been CRM-centric. That may be changing.

At first glance, nothing about this data seems to threaten CRM-centrism. In fact, slightly more respondents said the CRM was at the center of their stack in 2025 than in 2024. But, something kind of weird is happening. The “Other” category grew 5x. It’s possible a different approach is brewing.

The markets provide some other evidence of uncertainty about CRM dominance.

It’s been a rough 12 months to be a CRM vendor. Salesforce’s stock is down 37% and HubSpot is down 60% over that time. Meanwhile, the S&P 500 is up 15%. Something’s got investors spooked.

I’ve seen some folks predict the death of CRM because people will just “vibe code their own CRM”. I believe that’s nothing more than a clickbait argument that needs to be put on the shelf alongside the perennial LinkedIn “death of outbound” posts. If we do see a real shift away from CRM-centrism, I think the reasons will be due to a larger shift in how GTM—and technology generally—work.

From CRM-centrism to composability

CRMs have historically competed across three dimensions:

• Data - CRMs aim to be the system of record. Once they become the source of truth for all your customer data, they’re nearly impossible to rip out.

• Workflows - CRMs aim to be the system of action. Since they have all your data, they might as well also host the business processes that use and manipulate that data.

• User Interface - CRMs aim to be the “pane of glass” where the humans on the GTM team do their work.

Different CRMs emphasize different elements. Salesforce competes on depth of data and workflows. Sophisticated users get ample sharp tools with which to build custom solutions, while risking some bodily harm in the process. As for the UI, it can best be described as “designed by a team whose first and last experience with a computer was in 2005”.

HubSpot, on the other hand, emphasizes user experience. I’d say it’s…fine in that department—plenty of big friendly explanations sprinkled among the upsell CTAs. Its data and workflow capabilities have improved, but still frequently feel a bit like performing surgery while wearing mittens. Sure, your hands aren’t cold in that freezing operating room, but your patient might not wake up in the state you’re hoping for.

Regardless of the emphasis, the big question is whether this bundle of capabilities is actually best delivered as one product. In a world where the majority of GTM is human-centric, this makes sense. Business processes need data combined with a human in the loop. Workflows need to be close to the data. Humans need interfaces to that data and those workflows. It all make sense as One Thing.

But today the grand compromise that created the CRM is breaking down.

There have been major changes at the level of basic technology infrastructure since the emergence of the CRM category. Tools and techniques for managing data, connecting systems and building workflows are cheap and commonplace. When Salesforce began, every one of those things was capital intensive and difficult.

All of those technical changes happened before the emergence of AI. AI makes it possible to remove the final thing holding CRM-centrism together: the requirement to always have a human in the loop.

As these shifts play out, there’s less imperative to bundle data, workflow and UI into a single product. Instead, it becomes possible to compose a solution from best-of-breed parts. This isn’t just “vibe code a CRM from scratch”. Instead we can start to see an industry-wide shift towards well-defined components that can be combined together to build a GTM solution.

This has long been the case in developer-heavy ecosystems (e.g. DevOps and data analytics), but it’s also common in parts of GTM-adjacent tech ecosystems like e-commerce and content management.4 It’s now standard procedure to compose best-of-breed components together to build solutions in those industries.

The same may be true of GTM. While I’m skeptical of the long-term viability of the GTM Engineer role, most of what GTMEs do today involves putting composability into practice. They use tools like Clay and n8n to orchestrate workflows using API-enabled services that do things like retrieve firmographic data, enrich contacts, scrape websites, send emails, etc.

In this world, the locus of competition in GTM tech shifts from closed platforms that present a single “pane of glass” for human users (e.g. CRMs) to a distributed set of relatively open components that can easily interoperate with each other via APIs. This shift creates promise and peril for both GTM teams and GTM tech vendors. How that world might evolve will be the subject of Part 2.

In 1964, the Supreme Court issued a ruling in a case called Jacobellis v. Ohio. The issue before the court was whether or not the state of Ohio could ban a film1 for being obscene. Ultimately, the court ruled against Ohio.

Justice Potter Stewart issued a concurring opinion in which he noted only the most hard-core pornography could be considered out of bounds according to the First Amendment. He wrote:

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description [“hard-core pornography”], and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that.

That bolded line became so famous and controversial that “I know it when I see it” has its own Wikipedia page. It’s controversial because, well, how could it not be? Everyone’s line at which speech/film/anything goes from “I don’t like it” to “it’s obscene” is different and is most definitely not an objective standard.2

“Sir,” you might be saying, “this is a B2B newsletter.” (Assuming the first couple paragraphs even got past your work’s email filters.) “Please stop talking about obscenity and get to the point.”

Fine. “I know it when I see it” (which I’ll abbreviate to IKIWISI) is a good way of thinking about the subjective test your sales reps use to decide if a prospect is worth pursuing. IKIWISI stands in opposition to the effort teams put into coming up with objective account scores.

One reason Justice Potter felt confident enough to put IKIWISI in his concurrence, is that he could expect people from the same society would have mostly similar standards. Societies tend to enforce rules and influence preferences that way. For sales, those rules are your ICP, so rep IKIWISI judgments ought to mostly conform to your company’s ICP. In short, there ought not be much daylight between rep preferences and your a scoring model based on that ICP. Right? Right…

Yeah, it doesn’t usually happen that way. Every sales rep interprets your ICP in their own way based on many factors: how well they’ve been enabled, their past experience, their skillset, hopes, dreams, current quota attainment, etc.

Here’s how it usually plays out:

1. RevOps builds a scoring model based on account firmographics and their statistical relationships to historical performance. Leadership buys in.

2. RevOps uses that model to rank accounts and assign territories to the reps.

3. Reps look at the top few accounts in the territory, do a cursory glance at LinkedIn, scroll a bit on the company website and then start disqualifying accounts that “don’t look good”.

4. RevOps and front-line managers get Slack messages ranging from “hey could you look at a couple of these accounts” to “my territory is a barren wasteland and my family will surely starve”.

And, for another year, all the work on objective account ranking butts up against the cold, hard reality of rep IKIWISI.

Welcome to the Wild Wild West

That reality is enough to make some teams try to avoid the pain of building and enforcing a ranking model altogether in the name of letting reps have more “ownership”. They implement a process where reps choose the accounts they work. I’ll affectionately refer to this model as “wild wild west” because it generally bombs.

But it doesn’t bomb for everyone. The reason the wild wild west is so appealing is that IKIWISI works—but only for the reps that have the ability to see the right things that are actually correlated with outcomes.3 The best reps have both a knack and a process for consistently identifying prospects that are similar to past successful deals and repeating those patterns to close new customers.

It’s great for star performers, but terrible for those at the top of the bell curve. And completely unhelpful for helping new reps get better. As you scale, you need a system that enables all your reps to be as productive as possible, not just those who are especially good at IKIWISI.

So, the answer is to just enforce a top-down scoring model and force the reps to comply. It’s not quite so simple. IKIWISI is valuable; ignore it at your peril.

There’s another way of describing IKIWISI: tacit knowledge.4 This is information that’s not documented but instead lives in the heads of particular—often successful—individuals, subject to their willingness to share and their own subjective interpretations. In that respect, it’s incredibly valuable. The only problem is, it’s seemingly impossible to codify and scale.

A truly good account scoring model should fit with the intuition of successful reps. Blindly correlating firmographics with outcomes often misses important subjective signals that IKIWISI captures.

So we’re at an impasse! A good scoring model should be scalable, objective, explainable, correlated with outcomes, and match up with subjective IKIWISI evaluations. Seems impossible. Maybe. Let’s explore some ways to systematize IKIWISI and unlock it for all reps.

Make IKIWISI work for you

The challenge of IKIWISI knowledge is that it’s—by definition—hard to describe. People look at the totality of an account (or film) and make a judgement call. In order to co-opt it into your scoring system, you need to work with your reps to turn their tacit knowledge into something you can use.

The best way I’ve found to do this is to sit down with your best reps while they do account research. Give them a list of new accounts and then watch how they go about deciding whether they should work them. It’s probably easiest to do this on Zoom so you can record their screen.

If they’re anything like reps I’ve worked with in the past, you’ll probably see them visit the company website and click around a bit. Then they’ll head to LinkedIn to look at the company page along with some contacts. They might also visit ZoomInfo, Apollo, etc.

As they go through this process, ask them questions. The conversation might go something like this:

Q: I saw you visited the careers page, what were you looking for?

A: I wanted to see if they have any sales rep openings.

Q: What does that tell you?

A: Well I’ve noticed that if the sales job descriptions mention travel/driving, they’re likely to need a corporate card for each of their reps.

Q: Cool, and what are you looking for in Sales Navigator?

A: I like to look at how many sales reps they seem to have overall with similar job titles to the descriptions I found.

Q: How do you use that information?

A: When I call them up I reference the number of sales reps and ask how they’re managing expenses for the ones on the road. That worked really well on my last couple deals. They’ll have other people that travel—like maintenance workers—but the sales reps tend to have the biggest expenses so they’re usually higher priority.

There’s nuance in here you might miss if you didn’t follow along with the rep. If you just asked the rep what factors they look for, they might not give you the whole story. Maybe they say “sales headcount” but the reality is they’re looking for sellers who are also road warriors. This may or may not align with your ICP definition.

The above Q&A is paraphrasing a real conversation I’ve had. This one was easy because those are pretty concrete things. Admittedly, it’s sometimes a little more nebulous. I’ve heard things like “if they have a really professional website, I know they’re investing in marketing”. With some questioning, you can usually get a better idea of what the rep actually looks at to determine “professional”.

Now, repeat this process for a selection of top, middle and low performers. Find the common things the top performers look for that they others don’t. Those things become the foundation for turning IKIWISI from something indescribable to something a bit more tangible.

From here, you can use AI research tools to crawl the web and enrich accounts with some of these data points.

Sometimes it’s hard to boil some IKIWISI knowledge down to a clean list of “enrichable” data points. You may want to augment those factors with a “bottoms-up” analysis that uses AI to review a prospect’s online presence and compare it to your successful customers. You can do this for a small set of accounts with the LLM of your choice. If you want to do it at scale, I would humbly suggest Market Map for this kind of scoring.

However you do it, once you’ve codified IKIWISI knowledge in a systemic way, you can then incorporate that into account scores alongside more traditional firmographics.

Wrapping up

Like it or not, your sales reps will rely on “I know it when I see it” knowledge to evaluate the accounts you’re asking them to pursue. No matter how much effort goes into an account’s score, if it violates the IKIWISI test, you’ll end up with nothing but annoying Slacks.

The answer isn’t to give into IKIWISI and go wild wild west, but neither is it to ignore IKIWISI entirely. Instead, take the time to work with the reps, get all that valuable tacit knowledge out of their heads and into your ranking systems.

It may not settle a Supreme Court case, but it’ll definitely help you grow.

A few weeks back I wrote a post about what to do when you take over a sales team. I talked a lot about quantitative analysis but only a little about the qualitative side of things, especially talking to customers. That’s an incredibly important topic that really needed its own post. Well, dear reader, this is that post.

I want to share what’s been working for me to learn from our customers. Hopefully it’ll help you too—whether you’re starting a new role or just hoping to refine your team’s messaging and positioning.

First, a little history. In a past life, I co-founded a social media analytics company called Union Metrics. I was a first-time founder and I made a stupid (but classic!) first-time founder mistake1: I didn’t talk to our customers enough.

We had several thousand customers, many of whom were SMBs. I believed we were more sophisticated than they were about social analytics and—instead of listening to them—it was our job to show them what they needed. It was an immature, egotistical Henry Ford “faster horse”2 perspective that held us back.

Gradient Works is very different. We have fewer, larger customers and I know how much their feedback matters. I talk to many of our customers frequently, but I’ve never felt like I’ve built a system for gathering customer feedback that both improves our GTM and makes our product better.

As we’ve started to expand our platform (and packaging) with Carve, I’ve begun to focus on that more. I’ve learned a few things that have helped me make sure customer interviews a) happen consistently and b) end up providing useful feedback.

I’m indebted to Paul Stansik who introduced me to Forget the Funnel3 by Gia Laudi and Claire Suellentrop. I’ve borrowed liberally both from Paul’s writing in this area as well as the book itself. I highly recommend you read both.

That said, I do feel like there’s a gap in the discourse. Most of the content out there about customer interviews is written from either a marketing or product perspective. I’ve tried to approach this from a sales leader perspective. I’ve also tried to keep it tactical because talking to your customers doesn’t work if you don’t actually, you know, get the meetings to get their input.

Getting the meeting

Interviewing customers ought to be easy. Booking a customer meeting is certainly easier than booking a call from cold outbound. It’s not, however, easy.

You know what is easy, though? Talking about talking to customers without ever actually talking to customers. In fact, most GTM orgs excel at it for several reasons.

Your customers are busy with their actual work and have multiple vendors vying for their attention. They’ve been burned by meetings with friendly CS reps who want to “align priorities so we can better serve your needs” that devolve into a pitch for some new AI add-on. Even if they really like you, they may not be jumping at the chance to chat with you—emails go unanswered, scheduled meetings gets pushed at the last minute. Before you know it, it’s taken 6 weeks to have a simple conversation.

Another thing that gets in the way is making “customer research” into a big production. You might find yourself stuck in some political morass about who “owns the initiative” and “owns the customer relationship”, etc. A process that started with “let’s learn some things from our customers” suddenly becomes a 25-slide PMM powerpoint with schedules, milestones and RACI matrices.

If that’s your lot in life, I’m sorry. This process will be a little harder. However, remember you can just do things. And if you’re a senior GTM leader, talking to customers is not only something you can do, it’s something you must do.

Luckily I’m not currently at a big company so I don’t have worry to about the politics of it all, but I think the approach I outline below can help regardless of your situation.

Just like with setting an outbound meeting, setting a customer interview works better if you strike while the iron’s hot. In outbound, that might mean some kind of in-market signal. With your customers, you probably already have the signal you need, you’re just not looking at it.

Here’s what I do. Every morning I check our product analytics to see who’s been doing what.4 I pick 1-3 overall heavy users who have some recent activity from the last couple days and I send them an email.

It goes something like this:

Hi [person],

I’m CEO of Gradient Works. Saw you were using [X feature] recently. We’re trying to understand more about how folks are using [X] so we can improve it.

Would you have 15 minutes to provide some quick feedback? If so, feel free to grab some time at the link below or I can send over a few suggestions if you prefer.

[calendar link]

Let me know!

Hayes

Three things to note here:

1. I’m trying to make a thing they’re actively using better, not upsell them. Hopefully this defuses any “Oh god what AI thing are they selling now?” defenses.

2. I’m only asking for 15 minutes, so it’s low-commitment.

3. I’ve given them a calendar link to book something immediately without back-and-forth while also offering to handle scheduling if they want (some people still get a bit squirrely about the etiquette around calendar links).

The conversion rate on this email is very good—I almost always get the meeting. I’m sure it helps that I’m the CEO, but I’d wager that any other reasonably senior leader could get similar results.

There’s one drawback to this approach, especially for enterprise software: your day-to-day product users may not be your buyer. In that case, the research you do with these users is necessary, but not sufficient, for informing GTM.

That said, the gap between buyer and user keeps shrinking. People like Jason Lemkin are telling senior leaders to deploy agents themselves and Kyle Norton is making it clear that RevOps leaders need to become technical. If your product matters, chances are some of your hands-on-keyboard users will also be buyers. You can always cross reference your product user data with LinkedIn to verify.

So, you’ve got 15 minutes on the calendar. What do you do during the call?

Running the meeting

Treat this meeting like a discovery call.

Unless you’ve just arrived from 2010 (in which case… my god are you in for some surprises), you wouldn’t run a discovery call without using something that captures video and transcripts. You’ll want that information for later. I personally use Zoom + Fathom.

Also like a discovery call, the interview will be incredibly valuable if you ask good questions and a huge waste of everyone’s time if you don’t.

This is where Forget the Funnel comes in. If you haven’t read it, it’s a quick ~150 pages. In Chapter 3, they give you a set of open-ended questions that really work to help you understand your customer’s situation. I blend their questions with a couple of my own:

1. How are you using [product]? What’s your goal?

2. How were you doing [thing] before [product]?

3. Why did you start looking for a different way to do [thing]?

4. Why did you choose us over other options?

5. What’s the number one thing you’re able to do now with [product] that you weren’t able to do before?

6. What do you wish [product] did that it doesn’t do today?

7. How would you describe the value you get from [product] to a peer?

Question 2-5 are nearly verbatim from Forget the Funnel, while 1 and 7 are my own additions. I feel like asking them in this order provides a solid (albeit tight) agenda and flow to the call. That said, they’re not all created equal. If I find myself pressed for time, I make sure to ask 2, 5 and 7.

Here’s why I think those three are so important:

• How were you doing [thing] before [product]?
  The answer helps you understand the struggle5 your customer was going through to solve their problem before they found you. You can turn these answers into mind-reading—articulated pains that resonate with your prospects.

• What’s the number one thing you’re able to do now with [product] that you weren’t able to do before?

  The answer will help you figure out your most important value proposition. This is the thing that your users actually care about among all the things your product does. This may be very different than you think. Your “comprehensive AI platform for X” is probably—to most users—defined by one key capability.

• How would you describe the value you get from [product] to a peer?
  There’s money in this answer. Not only can this give you a great soundbite, but it helps write your marketing copy for you. It can also highlight issues. If the answer isn’t short, sweet and similar across customers you need to dial in your value prop.

Once you’ve asked your questions, be sure to wrap up the meeting by confirming any next steps. Pay special attention to any complaints or product gaps and make sure you get that to the right CS or product folks for follow up. If the customer is happy, now’s a great time to ask for a referral and/or permission to use something they’ve shared publicly.

You’ve asked your questions and you’ve got a recording along with AI transcript. What now?

Learning and operationalizing

Once you’ve captured a few of these transcripts, you should pull out useful themes with the AI process Paul Stansik describes here:

Hello Operator

How To Figure Out What Customers Care About

Here are two ways to figure out what your customers actually care about…

Read more

6 months ago · 18 likes · 2 comments · Paul Stansik

Paul’s process is really all you need to start getting value from these transcripts.

You can go deeper, though, and align customer feedback around the “jobs to be done” (JTBD) framework as described in Forget the Funnel Chapter 5.

I won’t go into everything about JTBD, but the idea is that customers “hire” a product to help them do a job. A customer’s job to be done can be summed up in a statement like:

When I (struggle), help me (motivation), so I can (desired outcome).

The goal is to extract common themes from your interviews that align to struggle, motivation and desired outcome for different customer job statements. You can do this manually or with AI. The output might look like the table below from Forget the Funnel.

Stack rank these jobs based on the ones that appear most frequently and are most correlated with urgency and willingness to pay. Pick the top one and use that as input for enablement materials, outbound messaging and talk tracks.

Finally—and you’ll want to partner with marketing on this one—make some clips from the videos. If you have customer permission, share them publicly even if they’re not polished. Authenticity beats high production values in 2026.

If you can’t share clips publicly, share them internally with reps so they can learn to speak in language that sounds like their prospects.

Wrapping up

Remember, if you’re a GTM leader, it’s your job to talk to customers. Don’t let institutional inertia get in the way.

Make it easier on yourself by setting quick calls with recently active customers. Ask consistent, open-ended interview questions and record it all. Synthesize multiple calls with AI and share real clips as much as possible.

Rinse and repeat for the secret to growth.

I’m feeling a little rusty today as I come off a two week hiatus. Since I send these on Thursday morning and the last two Thursdays were Christmas and New Years Day, respectively, I figured I wouldn’t interrupt your (or my) holiday cheer with a newsletter.

I’m back now and ready for 2026. I think this is gonna be a bumpy year for B2B sales, so we might as well focus on things we can control. What better way to do that than to make resolutions? Those always work!

Jokes aside, I genuinely do think these are critical. Do these things well and much of 2026 falls into place. Here’s hoping they stick better than that gym membership.

Let’s dig in.

Resolution 1: Start every quarter with enough pipeline

I’m a big fan of Dave Kellogg. One of my favorite things from Dave is his simplification of sales down to two questions:

1. Are we giving ourselves the chance to hit the number?

2. Are we hitting the number?

Question 1 is most important. If the answer’s “no” to #1, the answer to #2 is—barring a miracle1—definitely no. The metric, of course, that lets you know if you have a chance is pipeline coverage.

Here’s a quick refresher on pipeline coverage: it’s the pipeline you have when you start a period (quarter, month, etc) divided by your target for that period, expressed as a multiple (e.g. 3x).

Let’s say at the start of Q1, your total pipeline with a Q1 close date is $3,250,000 and your target is $1,000,000. There you go, 3.25x pipeline coverage:

It’s also important to note that pipeline coverage isn’t simply the inverse of win rate (e.g. 20% win rate = 5x coverage) because your starting pipeline consists of a blend of opportunity stages—which have different win rates.

So far so good. But our resolution is about “enough” pipeline. So what constitutes “enough”?

The received wisdom is to aim for 3x pipeline coverage, but your mileage will vary. The best way to answer this question for your team is with historical pipeline snapshot data. If you don’t have that, you can use the equation on the right side of this slide from Jeremey Donovan at Insight Partners:

If you’d like to take a deeper dive on this topic with recommendations on how to calculate this for yourself, check out How Much Pipeline Coverage Do You Need.

Now we know how to measure whether we have “enough” pipeline with pipeline coverage. There’s one problem. Pipeline coverage is a forward-looking metric for revenue generated in a given quarter, but it’s a backwards-looking metric for our resolution. The question then shifts to: “What can we do this quarter to ensure we start next quarter with the right pipeline coverage?”

For most sales teams, a big chunk of the answer comes in the form of inbound. Since that’s owned by marketing it’s rarely under the sales team’s direct control.

One thing that is under sales’ control is outbound. The problem is they don’t control it very well. Most outbound teams focus on activity, operating on the principle that more activity = more pipeline2.

Reps typically get a patch, get told they’re “the CEO of their territory” and get sent off to make their fortunes. Any problems? Just do more activity! How many times have you heard (or said) some variation of, “It takes 100 dials to set a meeting. Every no gets you closer to that yes!”

In 2026, sales teams should resolve to get more sophisticated about outbound so they can control their pipeline destiny. That means moving beyond brute force activity towards a more sophisticated picture of how activity translates into pipeline creation. That means paying attention to some different metrics:

• Account Coverage - to see whether the team is working the right accounts

• Opportunity Creation Rate - to see the percentage of engaged accounts that turn into opportunities

• Incubation Period - to see how long it takes an account to go from outbound touch to opportunity

That also means changing how they work accounts, which we’ll see in the second resolution.

Further reading:

• The Power of Pipeline Coverage

• How Much Pipeline Coverage Do You Need?

• 3 Outbound Metrics CROs Need

Resolution 2: Focus on fit first, signals second

Approximately nobody enjoys doing cold outbound. Ideally reps would have a reason to reach out—even better if it’s something that indicates a buyer might be interested right now.

In 2025, everyone obsessed over signals. My LinkedIn feed was alive with GTM Engineers pushing the idea of AI continuously scraping the internet for signs of a prospect with a pulse and then routing them to a rep (or better yet, an AI agent) ready to pounce.

Meanwhile, my Gmail inbox was alive with… this:

There’s nothing inherently wrong with signals. In fact, you’d be stupid not to use them. However, too many sales teams forget that fit comes first. There’s no point in chasing signals for accounts that aren’t in your ICP. I’ve always viewed this through the lens of the Fit-Timing (FT) Quadrant:

Ideally, every bit of outbound energy should be focused on the top-right quadrant where great fit buyers are ready to buy. If you relax the fit criteria and rely too much on signals, you’ll end up creating a lot of ephemeral pipeline from folks in the bottom right. This is the land of slow-nos and happy ears.

In 2026, every revenue team should re-dedicate themselves to being fit-first before chasing down any signals.

Take the first few weeks of the year and really dig into your ICP. Enrich your data and use the scoring methods that Grant Hefler from SBI discusses in our Secrets of Segmentation chat. If you don’t have a bunch of historical data, use a rules-based approach that gives a basic, explainable, starting point.

Don’t worry about perfection. As a reminder, here’s my Uncharted Territory Law of Account Scoring:

The best account score is the one reps actually use so long as it’s better than choosing accounts at random.

Once you’ve got that score, operationalize it. You can’t just assume your reps will go after the highest scoring accounts on their own—they absolutely will not. The best approach is to build focus into your account coverage model. Use territory design to drive rep behavior and coaching to hold them accountable.

Further reading:

• The Tao of the TAL

• Psychology and the Signals Slot Machine

• Traditional Territories Hurt Commercial Sales Teams

Resolution 3: Move from AI experiments to real efficiency

ChatGPT launched on November 30th, 2022. We’re already in year 4 of the LLM era. Time flies when you’re setting money on fire.

The problems with early LLM models—hallucinations, poor instruction following, limited context—still exist. However, the most recent models are lightyears better in all these areas.

I believe we’ve recently3 reached a tipping point in model capabilities. They’re not perfect. But guess who else makes mistakes, doesn’t always follow instructions and gets a little lost when they have to remember a bunch of stuff? People. These models are on par with all but the most experienced employees in many domains.

We’ve seen this evolution ourselves building the Carve territory agent. GPT 5.2 can do very sophisticated analysis and code generation. With the right context, tools and engineering around it, it’s as good as any RevOps analyst for this task.

There just aren’t any more excuses for slow-rolling AI usage. 2026 is the year you should be seeing real efficiency gains from AI in production.

This was the theme of my talk with Kristina McMillan at Scale Venture Partners. Based on Scale’s survey of 300 GTM leaders, it’s clear teams are beginning to use AI to radically augment rep performance, not just improve things at the margins:

We’re not going to hit 10x Rep levels in 2026, but it’s time to make material steps in that direction. The potential CAC improvements will be massive because large sales teams are historically expensive.

I’d love to give you sage advice from experience but I can’t do that for this one. Besides our own tools, we don’t deploy a ton of AI in our GTM at Gradient Works. I plan to follow this resolution and change that. We’ll need to solve two big problems:

1. Focus - Avoid the temptation to sprinkle a little AI here and there. My goal will be to identify a single process and implement it end-to-end. Go deep or go home.

2. Context - Even for a small team like ours, it’s hard to gather all the information we need for an end-to-end AI use case all into one place that’s accessible to AI. We’re making progress on a data warehouse as we speak. That should help.

I suspect these will be problems for other teams as well. I’ll report back on our experience.

Further reading:

• RevOps at the Crossroads

• AI Needs Its Sewing Machine Era

• Build or Buy?

Wrapping Up

There you have it. Start each quarter with enough pipeline. Get that pipeline by being ruthless about prospect fit. Drive efficiency with AI (which is really and truly finally ready). I’m confident if we all keep to those resolutions for the whole year, it’ll be a good one.

The last 12 months have been a wild ride for B2B GTM. AI’s inescapable. The economy, while definitely better than the prior two years, is weird and unpredictable. Nobody knows what to make of it all. Most GTM leaders I talk to seem to vacillate between anxiety and cautious optimism.

So, I figured why not build on that complete lack of certainty to make confident assertions about what’s going to happen next year?

That’s right, I’ve decided to go full pundit and give you my six 2026 predictions. I’ve tried to provide some rationale each one, but I’m sure some of these will look ridiculous in hindsight.

With that in mind, I give you my word that I’ll come back to these in 12 months and thoroughly roast myself for whatever I get wrong. I believe in both accountability and baking in some content for my future self.

Without further ado, here are my 2026 GTM predictions:

1. AI comes for RevOps

2. Clay’s wheel will spin slower

3. The US will have a (shallow) recession

4. At least one “AI native” fades away

5. We stop talking about * engineers

6. We’ll have a startup mass extinction event

As a bonus, I asked several knowledgeable GTM folks for their predictions. I’ve added thoughts from the likes of Sam Jacobs, CEO of Pavilion, and Kyle Norton, CRO of Owner.com, at the end.

Let’s do this.

1. AI comes for RevOps

Most of the conversation about GTM and AI has focused on replacing sellers (or at least the sellers doing low-complexity tasks). RevOps mostly seems like the beneficiary of an AI shift. After all, AI represents a new layer for GTM that shifts the balance of power from managing teams of human reps to orchestrating technical systems—a role RevOps was born to play.

The actual story is murkier. Earlier this summer, I wrote that there was a troubling lag in AI adoption by RevOps teams and that they might not have fully internalized how much of their existence involves being a natural language interface for the CRO.

Since then, AI has only gotten better at the things that CROs rely on RevOps for. Things like data management, analysis, reporting, documentation and system maintenance. All the major models are now mostly phenomenal at this stuff.

In 2026, we’ll see RevOps hiring slow as more of these tasks get turned over to AI.

2. Clay’s wheel will spin slower

Clay had an incredible 2025, hitting a $3.1B valuation and projecting $100M in revenue. Just about every GTM org I talk to is using Clay in some capacity, but there’s trouble brewing.

Former Netscape CEO Jim Barksdale famously said there are only two ways to make money: bundling and unbundling.

Traditionally, data enrichment has been about bundling—collect as much data as you can in one place, sell it at the highest margin possible and grab more share of wallet by creating a platform out of add-ons. ZoomInfo is the poster child for this kind of bundling in the GTM data space. It worked. They make $1.2B per year. People buy ZoomInfo, but nobody loves ZoomInfo. And each bad phone number erodes any sliver of goodwill that might exist.

Clay’s stroke of genius was two-fold: unbundle the whole thing and then empower people to piece it back together again.

Instead of paying ZoomInfo for access to all that data, you could make your own ZoomInfo by enriching just the data you needed from a host of different providers. You could even combine that with raw data scraped from the web and transformed with AI. Put it together however you like, and only pay for what you use.

The catch? All that unbundled capability had to be repackaged into something useful. So Clay championed the people willing to do that. They supported agencies and creators who could turn Clay’s complexity into services engagements. Eventually, the GTM Engineer was born.

It’s proven to be a powerful combination. The upshot, though, is that Clay has a high total cost of ownership. Not only do GTM teams foot the bill for credits, they also need specialized roles (either in-house or on retainer) to manage it.

Now, Clay is trying to build their own bundle. As Adam Schoenfeld put it, “the friendly people from Brooklyn now look hyper aggressive.” They’re not only competing with ZoomInfo, but nearly every other part of the GTM stack. And, the more they try to simplify their core product to expand their market, the more they risk alienating the GTM Engineer role they’ve built themselves around.

Don’t get me wrong, these are good problems to have. They’re still going to grow, but in 2026 that growth will slow down markedly.

3. The US will have a (shallow) recession

There’s reasonable evidence that the US economy wouldn’t be doing so hot if it weren’t being propped up by the AI boom. We’ve got tariffs, combined with sticky inflation and a cloudy unemployment picture.

I’ll make a sub-prediction here: the AI bubble won’t burst and take us all with it, but it will deflate a bit. There are some weak links that are using a lot of debt to do things like fund data centers based on demand that may not emerge right on schedule. Some of those won’t make it through 2026.

Ultimately, there will be enough AI turmoil to spook investors and dampen the hype, which will eliminate the post that’s currently propping up the economy.

4. At least one of the “AI natives” fades.

One or more of the $100M-ARR-in-the-blink-of-an-eye AI natives will hit a churn wall and sees their growth suddenly hit an asymptote. Cassie Young termed this the Gross Retention Apocalypse and I’m 100% on board.

We won’t see a spectacular bust because churn kills slowly (unlike debt). We’ll see some early sales—followed by fire sales—when this starts to happen.

5. We stop talking about * engineers.

In 2025, everyone wanted to be an engineer. In particular, we had the rise of GTM Engineers and Forward Deployed Engineers. I believe these aren’t durable roles and the hype will die down in 2026.

When new technology shows up, nobody knows how it’s supposed to work. It’s complicated and finicky so you need specialists to go figure it out. AI has produced myriad new, complicated and finicky things. Therefore, we need specialists. Often those specialists are kinda making it up as they go along (after all no one actually knows what they’re doing when something’s brand new) so they need a patina of credibility. “Engineer” sounds cool, credible and technical, so here we are.

As technology matures, things get simpler and the need for specialists goes away. Way back in the year 2000, I did a summer internship at a dot com after my freshman year in college1. We had big teams of people with computer science degrees building…. e-commerce websites. The sites we built were vastly inferior to the one your crafty cousin sets up in an evening on Shopify when she finally decides to sell her artisanal soaps. But in 2000, selling some stuff on the internet required bespoke expertise, cost $1M+ and took a year (if it could even be done at all).

Every technology has a maturity curve. AI’s should be faster than any other technology—part of the promise of AI is that the AI itself can do most of the hard technical work for you—but it still very much exists.

Before all the GTM Engineers descend on this newsletter with pitchforks and Clay tables, let me just say: more parts of GTM are now able to be orchestrated with technology than ever before2. There’s meaningful work there, but it’s inevitably going to get simpler, less technical and more accessible to more people.

In short, all these engineers titles are a symptom of things being too damn complicated right now. That will start to abate in 2026, taking the engineer titles with it.

6. We’ll have a startup mass extinction event

I recently finished Otherlands, a book that genuinely has nothing to do with B2B sales3. Instead, it’s a reverse-chronology tour of extinct life on Earth that opens with Alaskan horses 20,000 years ago and ends with the emergence of multi-cellular life 550 million years ago.

Naturally, it includes well-known events like the meteorite that killed the dinosaurs and the Cambrian explosion4. One thing I hadn’t heard about, though, is an extinction event called “The Great Dying”5 that happened ~250M years ago in which 95% of all species on earth went extinct thanks to a massive volcano in Siberia.

I think 2026 will see a mass extinction event for startups—not 95%, but a large number. There are a lot of startups that are barely hanging on from rounds raised during the Cambrian explosion of funding that ended in 2022. Just take a look at this Carta data:

And these are the ones that have gotten to a next round. There are still quite a lot of startups (at all rounds) that have stretched about as far as they can stretch. Carta also reports that bridge round funding ticked up again in 2025. At some point, there really is an end to the runway and we’ve got to be approaching it.

So there you have it. Those are my six predictions. We’ll check back in a year. Meanwhile, let’s see what some other folks had to say.

Crowdsourced Predictions

Most of these came from responses to a LinkedIn post. They’ve been lightly edited for clarity.

Let’s start with a spicy one:

OpenAI will go through a restructuring and Sam Altman will not be the CEO in 12 months.

Sam Jacobs - Founder & CEO, Pavilion

We’re already seeing this quietly but I think 2026 will be the Great GTM Bifurcation where companies that were early and aggressive adopters of AI in GTM will start breaking away. The leverage of AI is so great and I think many companies will start hitting a maturity level where the compound returns become pretty massive.

We’re already feeling this in our business and yet I feel like we’re just scratching the surface. We’ve gone from 0 dedicated GTM AI headcount 6 months to 2 today and more soon, which is greatly accelerating our progress. Our first productive AI use case went live in 2022 (I can’t believe that’s 3 years ago 😅) and yet I only feel like we hit our stride in the last few quarters.

Kyle Norton - CRO at Owner.com and host of The Revenue Leadership Podcast

Employee morale will likely take a hit across U.S. businesses as AI continues to replace roles. The companies that succeed won’t just adopt AI, but they’ll use it to empower and enhance their people. Those that position AI as a tool for growth rather than a threat will see a boost in morale. By the end of 2026, employee engagement will be a bigger priority than it’s been since the lockdown. I guess there is a GTM angle: keep this in mind when crafting your messaging or pitching—how you frame AI’s role in enabling people, not replacing them, will resonate deeply with prospects and customers.

Ryan Simmons - VP, Global SaaS Sales at Terryberry

Marketers will feel more pressure from CEOs and CROs to “show up” in LLM responses as LLM adoption moves into the mainstream with consumers.

1) Lack of visibility in LLM responses means lack of “frame-making” influence at the time people are learning about things.
2) Lack of visibility in LLM responses will undermine confidence in a solution/service/product/idea.

David Kirkdorffer - Consultant

It’s very early, but enterprise GTM will increasingly be abstracted by agents. Business arrangements between two ISVs with agentic transactions will require new models. These transactions will happen at the machine level, requiring machine level SLAs, hallucination risk absorption, and revenue share.

[Ed note: I asked Dustin about the possibility of “hallucination insurance”]

I guess it’s almost inevitable. Transferring risk for a fee is as old as The Dutch East India Company, and here, it’s a real risk that costs money.

Dustin R. Thompson - Head of US Partnerships at Promon

Many firms will cut back on customer success & support headcount in favor of AI solutions right as a massive wave of churn hits. There will be a scramble for qualified CS candidates by the end of the year as 2027 annual plans are baked with hope for improving GRR.

Ryan Burke - VP of Sales at Zilla Security

And finally:

This AI thing seems like it’s gonna be big. Like and subscribe for more game-changing insights.

Paul Stansik - Partner at ParkerGale Capital and author of Hello Operator (which you actually should subscribe to)

You know, I think Paul’s probably right about this one.

But I think we’ve got all those beat—both for strategic importance and for nerdiness—with today’s account segmentation conversation with Grant Hefler. Grant is an Executive Consultant at SBI, one of the premiere GTM consulting firms. They help PE-backed and publicly traded B2B SaaS companies grow faster through GTM strategy consulting, training and operational execution.

Grant walks us through the whole segmentation process step-by-step. We got deep on tricky analysis topics that impact ICP scoring and account potential, covering things like cohort selection, sample sizes, factor weighting, frontier analysis and P x Q approaches. It wasn’t all nerding out on analysis, though. We also talked about running the process, managing stakeholders, plugging into the larger annual planning exercise and how to put segmentation results to work.

I loved this conversation because there’s no fluff. It’s just a ton of really practical and useful stuff for anyone looking to do segmentation.1 Seriously, keep this one for reference.

Highlights below in bullet point form.

(1:47) What is segmentation anyway?

• The purpose of account segmentation is to drive strategy, prioritization, and resource allocation.

• It’s an account-level exercise that’s distinct from broad market segmentation. This isn’t a TAM calculation which is best done top-down.

• At the core, it produces two key metrics:

  • ICP score – a fit score that determines how well an account aligns with your ICP. This is not the same as propensity to buy.

  • Account potential – how much an account could spend based on bottoms-up financial and firmographic data.

• Once you’ve got an ICP score and an account potential, you can use them to inform all your downstream processes like capacity modeling, comp plan design, coverage models and territory.

(5:44) Getting started

• Gather as much clean, reliable customer data as you can. The most important thing is a structured customer “cube”2 with accurate accounts, spend, and hierarchy information, since this drives how segmentation and coverage will operate.

• Get a reasonably complete list of targetable accounts so segmentation reflects the true SAM.

• Start with a basic ICP hypothesis. At minimum, this means a working understanding of who you believe you should be targeting. You can use the segmentation work to help refine this.

• Prepare firmographic and technographic data. You’ll want to refresh your data from a 3rd party data provider to make sure it’s as up-to-date as possible (even though it’ll never be perfect).

• Come with as much strategic clarity as you can. This can include high-level ideas around coverage model, team structure, and major priorities.

(11:47) ICP scoring

• ICP is a framework defining the best-fit accounts based on firmographic and technographic factors—not personas and not propensity-to-buy.

• ICP development requires art and science. You should base it on your existing data but it depends on business strategy. For example, your company may be moving upmarket which means yesterday’s customer metrics aren’t a good fit for tomorrow’s desired state.

• ICP is meant to be a relatively stable, long-term fit model that should be considered separately from short-term behavioral or intent signals.3

Calculating an ICP score

• Select 4–6 measurable factors that correlate with historical success (e.g., employee count, revenue, industry, cloud maturity, tech stack, budget metrics).

• Assign each factor a weight within an overall score which usually sums to 100 (e.g. 5 factors might each be weighted 20 points).

• Break each factor into cohorts (e.g., employee count bands; industry sub-segments) to allow comparison of account performance across groups.

• Figuring out cohort boundaries is easier said than done, but they often become clear when you look at ARR distribution and other deal metrics through the lens of business strategy (e.g. more granular employee bands for mid-market companies if that’s a focus area).

• Always make sure cohorts have an adequate number of accounts. What counts as “adequate” varies but you’ll probably want ~10 deals in each cohort to have reasonable confidence.

• Categorical factors (e.g., industry) may require further decomposition or combination with another categorical factor (e.g., industry × country) to capture meaningful variation. But again, don’t slice too thin.

• Within each factor, give each cohort a sub-weight (up to that factor’s total weight) based on how it performs on deal metrics such as win rate, deal size, cycle time, and ARR contribution.

• Rank cohorts within each factor based on these metrics, and assign sub-weights proportionally based on the ranking.

• The final ICP score for an account is the sum of its sub-weights across all factors.

(26:45) Account potential

• Account potential estimates how much each customer or prospect could spend on your solution. You can measure this at the account level overall or at the product/line of business level.

• There are two primary methods for calculating account potential: frontier analysis and P x Q.

  • Frontier analysis

    • Use customer spend as a percentage of a financial metric (e.g., revenue, IT budget, ARR per employee).

    • Group accounts into cohorts using a categorical and size metric (commonly industry × company size). Just like with ICP, make sure you’ve got enough samples in each cohort (Grant recommends at least 10) and watch out for outliers.

    • Within each cohort, compute the 80th percentile of spend ratio to establish a benchmark (“frontier”).

    • You can then scale the “frontier” to each account’s size (e.g., 80th percentile ARR/employee × actual employee count) to calculate potential.

    2. P × Q model

    • This approach works best for per-user pricing models.

    • Q = estimated number of potential users (e.g., employees who could adopt the product).

    • P = price per user or per seat.

    • Total potential for each account = P × Q. You can also do this at the product level if products have different prices and user bases within an account.

• Remember, potential is directional, not literal. Nobody should treat this as a precise forecast. Potential simply identifies where the most value exists if everything else goes according to plan.

(35:10) Operationalizing it all

• Use ICP score + account potential to build prioritization models for customers and prospects.

• ROAD model for existing customers

  • Plot customers on a scatter plot where the X axis is current spend and the Y axis is account potential.

  • ROAD stands for Retain, Opportunistic, Acquire and Develop. Each of these represents a quadrant in your scatter plot. For example, Acquire accounts would be in the top left with relatively low existing spend but high potential and Develop accounts would be in the top right with high spend and headroom to spend even more.

  • Use the ROAD placement of the customer to determine their service model (e.g. white glove account management for Develop customers and put hunters on Acquire customers).

• Plot prospects similarly to the ROAD model but use ICP score for the X axis. The top right quadrant (high fit + high potential) becomes the foundation of your new logo assignments.

• Build balanced territories by distributing ICP quality and white-space potential evenly across reps, ensuring equitable opportunity.

• Feed segmentation into quota, comp, and capacity planning by testing whether territories provide enough potential for target attainment and determining required headcount.

• Direct marketing spend and other GTM investment towards high fit, high-potential segments.

This time last year, I wrote that you’re not behind in AI (which also used some Scale data). What a difference a year makes. Scale’s 2025 report makes it clear that the gains from AI adoption are real and they’re happening now. If you’re not taking advantage, you really are falling behind. The good news is the current wins are mostly based on individual productivity. There are much bigger gains ahead and you can still (probably) catch up.

Go grab the report for yourself and follow along with the conversation!

For those of you who prefer words, below are some of the key topics and takeaways from the conversation.

Everyone’s actually doing it, and it’s working

Kristina started our conversation by laying out the takeaways from the Scale report.

We’re about 3 years into the AI era (ChatGPT was released in late 2022) and we’re now reaching the end of Phase 1 of GTM AI adoption. This phase has largely been about increasing individual productivity with relatively simple use cases like drafting content and doing account research.

The team at Scale found that regular use of AI is ubiquitous in GTM (even if it’s a bit “lumpy” across teams). If your reps aren’t using AI to impact their individual performance today, you are most definitely behind.

The most important takeaway here is that all this adoption really is having an impact, especially when it comes to quantity metrics (e.g. activity levels) and time savings. Kristina shared an example where Vanta has reduced the time reps spend on non-sales activities by 10 hours per rep per week.

The next phase will focus on quality1. Kristina predicts that emerging AI use cases like rep coaching will have a much more direct impact on metrics beyond simple productivity gains—she expects to see material gains in areas like sales cycle length and rep attainment.

You need to build and buy

I wrote about build vs buy not too long ago and Kristina had a lot to add to that discussion. AI has certainly scrambled the traditional “build vs buy” calculus.

Kristina shared a simple framework for thinking about the decision based on task complexity. You can see the visual from the Scale report here:

If your task is very low complexity (e.g. individualized account research) and can be accomplished directly in AI tools like Gemini or ChatGPT, don’t bother buying anything specialized. By the same token, if your task is very complex and highly specific, you’ll probably need to build your own.

For middle-of-the-road use cases, you should probably buy. As Kristina notes, you’ll benefit from the best practices that vendors are able to codify by working with lots of customers at once.

A word of caution, though: buying AI tools is hard. There are tons of point products and it’s unclear how durable they’ll be. Pricing is evolving and it’s hard to model costs. That said, the same challenges around long-term durability and costs can be applied to internal builds as well.

Kristina summed it up pretty nicely: “Right now we’re in a period where things don’t make sense.” Start small and see how far you can get with basic LLM tools. Scale has a nifty “game board” to help you on this journey.

Keys to adoption and measurement

As a former RevOps leader, I was gratified to hear Kristina share that RevOps involvement improved AI initiative impact by 20%. However, that impact can only be felt if you have a baseline to measure against.

Kristina said the need to establish the baseline emerged in the qualitative part of their data collection. She saw teams doing time studies to figure out bottlenecks as well as running some controlled experiments to see incremental improvements before going all-in.

Speaking of all-in, she highlighted the initial AI SDR craze as cautionary tale about AI adoption. Some folks fired their whole SDR teams only to discover the tech wasn’t ready. Those orgs ended up with pipeline gaps and had to scramble to rebuild their teams.

Ultimately, Kristina sees AI adoption as a process of stacking gains on top of gains. Each individual gain might not be obvious, but the aggregate effect can be large. Scale is recommending two metrics to measure this holistic impact: GTM Efficiency and GTM Productivity. You can see those defined below:

These bear some similarity to the SaaS magic number and ARR / FTE, respectively, but centered more tightly on new revenue growth and GTM. Regardless, these org-level metrics should show material improvement over time if the combination of your AI efforts are driving efficiency.

How org design needs to change

Nobody actually knows how GTM orgs will evolve due to AI, but Kristina did have a few takeaways about the current state of evolution.

AI adoption can’t be something people do in their spare time. There’s just too much technical know-how required and too much change to keep up with. Someone (or someones) has to be focused on it. She’s seen orgs have success forming “tiger teams” devoted to AI adoption.

While you do need someone driving AI adoption, you should also be harnessing energy and excitement from more junior employees who may be more AI native. Kristina cited front-line managers building out AI enablement tools for reps and technically-inclined early career folks stepping up as GTM Engineers.

Speaking of GTM Engineers, they are “definitely a thing”. The role isn’t terribly widespread yet, but Kristina believes it’s going to grow in importance.

We actually ended the conversation talking about AI agents. Kristina sees most folks in GTM use the term “agent” as largely a shorthand for any AI capability that’s more complex than just a simple chat.2

Most of today’s “agents” don’t rise to the level of replacing an employee on the org chart. Kristina’s advice is not to over-engineer agents to try to do too much just yet—a partially automated task requiring tons of human intervention is probably worse than one without the automation. That said, agents will continue to get more sophisticated over time and someone will need to “manage” them by being familiar with their capabilities and knowing how to deploy them effectively.

We may not know what our orgs will look in 2035, but there’s a good chance they’ll change a lot more in the next 10 years than they did in the last 10.

On Tuesday nights, I take my 9-year-old daughter to gymnastics. That gives me approximately 45 minutes surrounded by gymnastics trophies and a faint haze of chalk dust to ponder what the hell I’m going to write about in this newsletter.

This week I used the time to read the State of GTM AI in 2025 report from Scale Venture Partners. One thing I appreciated was that they asked respondents about specific use cases for specific roles, not just about nebulous “AI adoption”.

When I got to slide 8, I saw that 90% of sales dev teams and 85% of sales teams use AI regularly to draft their outreach. You can see the slide below:

Earlier this year, when I wrote about my conversion to the idea of the 10x sales rep, I mentioned that, for AI to be effective at scaling outbound activity, it would need to use multiple channels like phone, LinkedIn and email. Since cold calling with AI is generally illegal, all this AI message drafting has to be applied to LinkedIn or email.

That means we’re rapidly reaching a point where nearly all the text-based outbound buyers receive is AI-generated. That doesn’t automatically mean there’s no human in the loop—Scale’s data says 52% of SDR teams don’t (yet) routinely “engage prospects” using AI—but it sure looks inevitable that AI will both write and send the outreach for the vast majority of outbound.

Most of this outbound outreach will be email. Unlike LinkedIn, email is totally ubiquitous and easy to scale. That leads to the fundamental problem I wrote about in the 10x Sales Rep:

Because of the limits on other kinds of outreach, AI SDRs usually use mass email which is both legally suspect and has horrible conversion rates. Even assuming you somehow managed a 1% opportunity creation rate via that kind of email, you’d need your AI to work 100,000 accounts to get to the number of opportunities needed to produce pipeline to support a $10M quota. Your whole TAM may not be that large.

Those problems clearly haven’t stopped folks from trying. Spend enough time in the wrong corners of LinkedIn and you’ll learn all the tips and tricks about how to load up your AI-driven spam cannons. Soon you’ll find yourself in the gray area of disposable domains and inbox warming. Or you’ll realize that for the low price of 5 Clay tables, 18 SaaS products, API access to 3 LLMs, and 7 n8n workflows you too can book 200 meetings per month without an SDR team. (All you have to do is comment AGENT on this post and be ok with a 75% no-show rate!)

On the other side of the equation, you have some folks like Will Allred at Lavender who genuinely seem to be trying to use AI to help actual humans write really awesome emails to other humans.

In the end, no amount of AI-driven emailing is going to matter if email as a channel is already totally trashed. It sure feels trashed. I doubt I’m atypical and here’s what I’ve received just today:

These are all bad. But even if a good one snuck in, there’s so much bad here it would be really hard for it to get any attention. Suffice it to say none of these got a reply.

This is why the overall narrative (which I bought into in my 10x Sales Rep post) is that cold email used to work back in the halcyon pre-COVID days but now it doesn’t. There’s just too much noise now to drive meaningful response rates. Therefore, one of the most heavily adopted AI use cases—writing and sending email—isn’t actually helping us sell anything.

Is it actually harder to write email in 2025?

All of the above was going through my head as I was driving my daughter home from gymnastics. On the way, I told her that I still wasn’t sure what to write for my newsletter. Knowing this is an email newsletter, she replied (sarcastically), “Why don’t you write about how hard it is to write an email?”

Well the joke’s on her (and, it seems, me) because I decided to do just that. I realized I didn’t have solid data on whether the “decline of email” narrative was actually true. So, like I did in my post about outbound sequence benchmarks, I set out to scour the internet—this time with the goal of finding data points on reply rates1 for cold B2B email.

I identified 16 sources with statistics going back to 2018. Of those, I deemed 11 to be at least medium-to-high quality. High quality sources contained original research2 across a large corpus of emails. Medium quality sources were at least from reputable vendors.

Without further ado, here’s what I learned:

First, all those numbers are higher than I expected. They’re also higher than my personal experience. Let’s set that aside and look at the trend.

If we focus on just high quality sources, there’s a downward trend in reply rates, from 8.25% in 2018 to 6.3% in 2025. That 1.95 point drop represents a 23% drop in reply rates. If you use the 2024 data point of 5.8%, it’s a 30% drop.

So is it harder to write an email in 2025? Seems that way. It’s reasonable to say that it’s about 25% harder to write an email that gets a reply now than it was 7 years ago.

Email bulls and bears

Let’s review. About 90% of our SDR and sales teams are using AI in a way that depends on email for success. However, reply rates are 25% lower now than they were pre-COVID and they’re trending down.

Where do we go from here?

The bear case is an email death spiral. Declining reply rates combine with the declining marginal cost of writing email to spur teams to send even more email. That further clogs inboxes, causing reply rates to decline further and teams to send more email… You get the idea. No amount of AI makes any difference because nobody even bothers to read their email.

The bull case is that AI actually leads to better emails, not just more emails. It’s not crazy. I love SDRs, but the average SDR rarely has the training, time and inclination to compose truly relevant emails. At best they do some variable replacement and tweak a sentence in a stock template. (If you don’t believe me, just look at that screenshot from my inbox again.)

AI, on the other hand, could pull together all the context necessary to create carefully crafted messages on a per-recipient basis. With the right data, guidance and thoughtful messaging frameworks, AI might be able to write more truly great emails than most SDRs.

Which case are you buying?

The first week of November is a special time in B2B SaaS. Since so many of these companies have fiscal years that end on January 31st, it marks the beginning of Q4.

The beginning of Q4 usually heralds one of two things for sales leaders: buckling down to hit the Q4 number or starting a new job entirely. Sure enough, last week I saw a big spike in those “starting a new position” LinkedIn posts. Anecdotally it feels like more folks than usual have decided to make the leap this year.

I certainly get the appeal of starting a new job in Q4. You get to influence planning for the next fiscal without getting blamed for this year’s results. That’s the good news.

The bad news is you need that extra quarter. Sales leader tenures are crazy short and 70% of these runs end involuntarily. You’re most likely replacing someone who was fired. It’s safe to say they weren’t fired because things were going too well. The board, the CEO and the rest of the team have brought you in with the expectation that you’re going to fix everything. And fix it fast.

With all that pressure, figuring out where to focus can be daunting, especially if you look at it as one big, thorny problem. You’ve got to break it down or you’ll find yourself stuck in analysis paralysis. The goal is to quickly find the bottleneck—the thing that’s holding back the entire system—and eliminate it.

Here’s my recommended process:

1. Model the funnel (or bowtie) to find your bottleneck

2. Diagnose the bottleneck

   1. Quantitative diagnosis

   2. Qualitative diagnosis

3. Make changes to address the bottleneck

4. Repeat

Let’s dig in.

Model the funnel

Start with high-level volume, conversion, and time metrics by working backward through the funnel (or the whole “bowtie” if you’re responsible for retention and expansion as well). If you’re not sure exactly what to measure, Winning By Design has a framework (see Chapter 5) that’s as good as any.

When you’re doing this, resist the urge to immediately diagnose and, whatever you do, don’t cherry-pick data. That will quickly lead you to the wrong conclusions.

For example, if you’re looking at lead-to-opportunity conversion rates, resist the urge to immediately dive in if the rate is low and don’t listen (yet) to someone who says “oh we don’t count those leads for reason X”. This is one reason why you might be wary of existing historical conversion rate data. It often comes with baked-in assumptions that mask problems.1

Make sure you know precisely what’s being counted for volume metrics and what’s going into the numerator and denominator for conversion rate metrics. For time-based metrics (e.g. sales cycle), make sure you know when the clock starts (e.g, opp creation? SQO? stage 4?). Generally speaking, use this effort to get at your “raw” metrics before you start adjusting for anything else.

There’s a roughly 0% chance you’ll have access to all the metrics you actually want at this stage. Some things won’t be tracked at all, some things won’t have the right timestamps, etc. That means there’s a roughly 100% chance this will be frustrating. The key is how you respond.

You can’t change the past, but you can impact the future. Work with your ops team2 to track the metrics you need going forward. The best time to solve this would have been a long time ago; the next best time is right now.

That said, remember that improving your data is an incremental process. Don’t succumb to the bad data binary and declare you can’t make progress until every problem is fixed. That’s a recipe for, well, making no progress at all. Move quickly, but deliberately: fix the easy things fast and fix the hard things thoughtfully.

Quantitative diagnosis

Once you’ve got your bowtie metrics, find your bottleneck. For example, if you have a 30% win rate but only convert 5% of leads to opportunities, increasing your win rate is unlikely to help. By the same token, increasing the volume of MQLs with more ads will just waste money.

Once you’ve found the bottleneck, now it’s time to dive deeper. This is when you should listen to how metrics been measured previously—just make sure to trust but verify. You should focus on trying to break down the bottleneck into root causes.

As an example, let’s say you find a low outbound contribution to pipeline. There are two likely culprits here: the accounts are bad or something about the way reps work the accounts isn’t right. At this point, it would be helpful to try to break down the accounts according to your ICP or segments (if you have that defined) AND also look at performance by rep. You’re likely to find that some segments convert better or some reps convert better.

Looking across those dimensions, consider key diagnostic metrics like incubation period, opportunity creation rate and account coverage.

Then, break the problem down conceptually into a “diagnostic pyramid”. Think of outbound as a set of layers, each building on the next: activities at the top, that’s made effective by messaging, which is made effective by persona/contact and—at the base—are the accounts you’re working. The top 3 layers (activity, messaging, contacts) are fairly easy to change but they’re heavily dependent on the bottom layer (accounts). Don’t just assume more activity will get you where you need to go.

Finally, put the two together. If you find that you have a high opportunity creation rate, the problem may really be that you’re not covering enough accounts. If you find you have high account coverage, but are still struggling to create opportunities from outbound, the problem is likely lower down the pyramid.

This is just an example, but the pattern is the same no matter what:

1. Find the bottleneck in your bowtie

2. Investigate diagnostic metrics

3. Form a hypothesis about the root cause3

Quantitative analysis will uncover likely issues, but don’t start changing things just yet. Now it’s time to dig deep on the qualitative side.

Qualitative diagnosis

This is where you shut up, listen, observe and avoid the temptation to blindly start applying your playbook without adapting to your new context.

Talk to your colleagues on the leadership team. Ask why things have been done a certain way in the past. Ask them what they think needs to change.

Talk to your reps. Ask them what they think is working and not working—just don’t take it as gospel. Break out call recordings and go listen to real conversations. Listen to calls across reps, across customers and at different stages in the sales cycle. While I firmly believe you should actually listen with your own two ears, this is also a great place to apply AI. Paul Stansik has a handy framework for using AI to review calls.

Talk to your customers. If you’re primarily focused on new business, focus on understanding the happy customers since they’re the ones you want to replicate. For your happy customers, here are a few simple questions you can ask4:

• What happened to make you feel certain buying our product was the right choice?

• Now that you have our product, what’s the number one thing you’re able to do that you were’t able to do before?

• Before you had our product, what were you using instead?

Listen to the good and the bad in all these conversations. If you’re taking over an existing team, something probably hasn’t been going well. But don’t let that make you assume your predecessor was an idiot. Assume positive intent all around and try to make sure you understand why a competent person would have made certain choices.

Use your judgment (that’s why you’re here!) but keep an open mind.

Make some change

Once you’ve done all of the above, then you’re ready to start making changes. Chances are good you’ll want to make quite a few changes, but recognize that forcing through 20 changes at once is likely to result in nothing changing.

Focus on 2-3 things that will have the most impact on your bottleneck and reinforce the hell out of them (especially with your front line managers). Once those are in place, move on to the next bottleneck and do it all over again.

Congrats on the new job! No pressure.

Today I want to do three quick hits on topics I’m thinking and reading about as we barrel through the final days of 2025.

• Every senior seller started as a junior seller. What happens if AI eliminates all the entry-level jobs?

• There’s a software “middle class” and it employs a lot of GTM folks. What if it disappears?

• I’m not an economist, but I have lived through a couple massive bubbles. And AI sure is looking frothy these days.

Let’s jump in.

Where will new sellers come from?

I saw a LinkedIn post earlier this week that featured the chart above. I instantly recognized The Economist house style1 and tracked down the original article with a reverse image search.

It caught my eye because the inflection point at the end of 2022 is wild. Junior roles are disappearing, while seniors aren’t impacted at all (yet).

While the chart itself isn’t specifically about sales, it touches on something I’ve talked about with several sales leaders: if we eliminate all the junior roles (SDRs, etc) that are the typical entry point into a sales career, where do we get the next generation of sellers?

We’ve all heard the anecdotes about smaller sales teams and replacing SDRs with AI, but there’s not much quantitative data (that I can find) which isolates the impact on entry-level sellers. There is however, some data that supports the idea that AI adoption is reducing sales team size overall. And it seems unlikely that this reduction is coming at the expense of productive, senior headcount.

For example, the ICONIQ State of GTM report points to a significant reduction in GTM FTEs for high AI adopters at earlier-stage companies:

These companies are more agile and less able to support high CAC, so of course they’ll press any cost advantage they can find. Could this phenomenon just be because they haven’t yet built the people-heavy teams required for enterprise? After all, a lot of the “no sales team” success stories change their tune later on.2 It could be, but the “High AI” vs “Low AI” differences are pretty stark.

So why does this matter? Sales—in B2B tech especially—is a rare form of white collar(ish) job. It’s historically been a path for someone with plenty of grit but few credentials to break into tech and make a great living. It’s as close as we can get to a role that’s built on meritocracy.

Also, since nobody learns sales in school, it’s also one of the few areas of tech where an apprenticeship model is alive and well. People learn sales on the job from other sales people while they do the crappy work (e.g. cold calling) that more senior people have earned the right not to do.

If we use AI to replace most of those entry-level folks, we’ll lose a meaningful path for economic upward mobility and the “apprenticeship” pipeline that builds tomorrow’s sellers.

I could be wrong about all this. Maybe the idea of employing entry-level SDRs dialing for dollars will seem as quaint in 40 years as the idea of employing 1,000,000 typists.

One key difference: becoming a human word processor3 in 1980 wasn’t a ticket to potential upward mobility and there were plenty of ways to learn to type without an apprenticeship.4

I think we’ll probably regret losing skilled sellers more.

The death of the software middle class

This week Jason Lemkin5 published an article on SaaStr titled Who Will Buy the SaaS Companies?. The gist is that—once upon a time—if you built a SaaS company to $20M+ ARR with decent metrics, you had something someone would want to buy. Now the mechanisms that fueled this are all breaking down.

I think of the companies Jason describes as the “middle class” of software. They’re more than an indie software developer selling something on an app store, but they’re never going to IPO. They tend to employ quite a few GTM folks.

Unfortunately, that middle class may not be long for this world. All the VC dollars are going to AI while PE is souring on SaaS as the business model starts to look less predictable.

VC Brett Queener wrote a much more substantial treatment of a similar topic earlier this month. He called out the logical implication of the shift:

Except for the absolutely crazy breakout companies, this implies that if you don’t have a ton of committed ARR and a lot of upfront cash payments, you’ll need to fund some of your growth the old-fashioned way — from the balance sheet. […]

I believe it may be more of a winner-take-all approach at some point in each market, as those companies with the most funding are likely able to invest the most GTM opex ahead of growth.

Two things:

• Acquisition is the hardest problem in startups and it’s not even close.

• It’s very hard to self-fund acquisition without lucking into either a market wave or some kind of PLG viral loop. I bootstrapped my last startup, so I know about funding acquisition from the balance sheet. It’s a rough math problem in the best of times and only gets harder if you’re using month-to-month contracts to lower the barrier to entry.

If you extrapolate from both Jason and Brett’s posts, you can see today’s software industry become an even more extreme winner-take-all environment where 0.1% of companies can raise enough to pay for acquisition and everyone else dies. Take it one step further and it leads to an arms race of VCs picking winners earlier and earlier—basically finding the smartest-looking baby in the maternity ward and handing it a scholarship to Stanford.

It’s hard to see how this wouldn’t lead to fewer surviving software companies. Software would be like legacy industries—capital intensive and difficult to break into. Two guys in a garage just won’t cut it anymore.

Putting this all together, we may see the software middle class disappear. It just won’t be possible to generate a meaningful outcome there. We’ll be left with the capital-heavy winners and the extremely capital light indies.

Something to think about as you look for your next CRO gig.

Come on guys, it’s definitely a bubble

On Tuesday, OpenAI completed its restructuring as a for-profit company. To celebrate, Sam Altman held a livestream which included this little nugget (per The Information):

Altman said OpenAI has $1.4 trillion worth of “financial obligation” from commitments it has made to use or develop 30 gigawatts of data center capacity. However, there’s a large gap between OpenAI’s revenue, which is projected to reach $13 billion this year, and its planned spending on servers to develop its technology and stay ahead of rivals such as Google and xAI.

Now look, I can do math. OpenAI is growing at an insane clip. Today’s $13B in revenue will be a lot more tomorrow. They can IPO now that they’re a “real” company. There are plenty of ways for them to come up with cash. However, the words “large gap” are doing a lot of work up there.

Also, let’s not forget that this restructuring helps unlock a $100B investment from Nvidia (who just hit $5 trillion in market cap yesterday). Gee I wonder who sells the GPUs that $100B will get spent on?

So… that’s great. But I’m sure it gets more sane:

Microsoft said it secured a commitment from OpenAI to spend $250 billion renting Microsoft servers over an unspecified period, mirroring a similar commitment OpenAI recently made to rent servers from Oracle.

Oh.

Microsoft, by the way, now owns 27% of OpenAI’s new public benefit corporation, a stake that’s worth about $135B. That $250B commitment from OpenAI represents 3.3x Microsoft’s entire 2025 Azure revenue.

I see.

There sure is a lot of money flowing around in a circle here. At least nobody’s loading up on any kind of risky debt to finance all this. Oh, wait. I’m sure it’s fine.

At least we’re doing our part at Gradient Works.

I wrote about the territory planning process a couple weeks ago but I’m told that not everyone likes to consume their information in the most words.1 Lucky you! This week, I’ve got an interview about territory planning and design with Joe Ort.

Joe’s been doing this a long time. He’s currently the CEO of RevOps Inflection. Before that, he’s done territory design at companies like SiriusDecisions, Brainshark and Collibra as well as supporting the process across a PE portfolio. He’s got plenty of tips and tricks.

We had a great chat. Watch the video to learn how territories are like icebergs, why sales reps would make good lawyers and how to structure a planning process that (mostly) won’t drive everyone insane.

For those of you who do actually like words, below are some of the key takeaways from the conversation.

On the data foundation (2:42)

The first phase of territory design is about getting your account data as good as possible—without losing sight of the fact that your data will never be perfect. You can do all the careful segmentation and territory balancing you want, but if the underlying data’s complete garbage you won’t be successful.

One area that we returned to a couple of times in the conversation is hierarchies. These tend to cause a lot of trouble in most territory designs—especially enterprise and strategic. Joe recommends spending extra effort on getting hierarchies right and suggests D&B as the best data source.

Once you’ve got this data, then it’s all about narrowing down the segmentation and getting specific about ICP.

On order of operations (8:00)

Once you’ve invested in getting the data right up front, Joe recommends that the RevOps team do a first pass on segmentation and account potential calculations before presenting anything to the sales leadership.

These calculations should take into account a host of metrics that span the entire funnel: lead volumes, sales cycle length, ASP and renewal rates. If you’re just focused on ASP, you’ll make bad decisions, especially in SaaS where CAC payback often requires at least one annual renewal before you start making money.

From there, he recommends taking that first pass to sales leadership and iterating. After that, start working your way to the front line managers and sales reps to get account-by-account intelligence as necessary.

On managing subjectivity (14:26)

Every territory plan is a combination of objectivity and subjectivity. There’s plenty of math but also plenty of opinions. Expect lots of stakeholders to weigh in with different perspectives about the best approach.

This subjectivity (and a dose of politics) also manifests itself in things like holdover requests and feedback processes. Not only are these sometimes sources of conflict, the mechanics of the process can be really hard to scale.

Joe calls out that you’ve got to rely on a single decision maker who’s empowered to make the final call on anything that’s in dispute. That’s usually the CRO.

On exploring scenarios (36:02)

My theory is most teams end up with suboptimal territories because they simply run out of gas before exploring all the options. Building any particular territory scenario takes so much manual effort that they rarely fully build out more than one.

That’s why I love Joe’s quote above. You’ve got to at least give yourself two options or you’re not giving yourself an actual choice. Make sure you build in time to try more than one scenario.

On focus (38:56)

We wrapped the conversation with a discussion of the territory taxonomy and how best to use territories to drive focus.

Joe mentioned that the first time he cut territories, reps ended up with 3,000-4,000 accounts and it was terrible. Now he tries to make sure reps only have to focus on those accounts that are great fits and are likely to buy in the next 6-18 months2.

He quotes the late Jim Ninivaggi from his time at SiriusDecisions, “We don’t need 3x pipeline if we’re only working accounts that are going to buy. We only need 1x.”

I’m in the midst of a week-long northern swing to visit customers, prospects and smart GTM folks. First up, Boston. In typical Boston fashion1 it gave me a rude welcome with an umbrella-maiming nor’easter. Luckily the conversations were better than the weather.

One of the most interesting conversations was with a VP who runs a large (300+ person) sales org. They’re building their own in-house AI agent capabilities to research accounts and deliver talking points to reps. It’s working so well he believes they’ll be buying a lot less 3rd party software in the future. That led us to discussion of the age-old question of build vs buy.

That question feels especially pressing in GTM because AI is rapidly changing our conception of the technology platform our teams need. The old tools don’t seem quite right anymore but it’s impossible to sift through all the new tools and their claims. And that’s before asking if we even need separate tools. Can AI just do it all somehow?

I’ve dealt with this from both sides of the table in my career: as a RevOps leader (with a reasonable-sized dev team at my disposal) and as a vendor.2 I’ve also personally built quite a bit of software, so I know what it means to create, maintain, improve and otherwise support an application over the long term.

That’s led me to some pretty strong feelings on the build-vs-buy question. The answer is there is no single answer—context matters. So instead of providing a definitive answer, I’ll share my thoughts on how to arrive at the right answer for your particular situation.

Your revenue platform is a product and RevOps is the PM

First, I’m well aware that RevOps does many things—forecasting, comp, process design, sometimes even enablement—that are only tangentially related to the tech stack. But in modern sales, the tech stack sits at the core of how GTM teams operate. That means many RevOps teams own a sprawling set of interconnected GTM systems.

Their job (from a tech stack perspective) is to provide a product to the company as a whole: a platform the GTM org can use to sell. Viewed through that lens, a core RevOps competency is product management of the revenue platform.

They must understand user needs, prioritize those needs, work with stakeholders to build a roadmap, resource that roadmap, deliver the roadmap, and repeat.

Sometimes a big customer (e.g. the CRO) demands something that requires shaking up the roadmap and deprioritizing things that other people (e.g. the SMB reps in Cleveland) need. Sometimes there’s a set of random, (seemingly) unrelated complaints that collectively point to a feature they realize needs to exist but that no one quite knows how to ask for3.

In short, product management.

It doesn’t always seem like product management. RevOps is usually seen as a systems integrator. After all, the GTM tech stack probably starts with a CRM that has a bunch of other off-the-shelf tools plugged into it. In reality this isn’t all that different from other software products—nobody builds their own database from scratch to make their SaaS product—it’s just more obvious because Salesforce has a UI meant for non-technical people.

Some things are definitely not systems integration. There is plenty of functionality that’s so specific and so custom that we build and maintain it in-house. That’s always been the case. But now the build option has become especially prominent. It’s also become closely intertwined with the emerging GTM Engineer role.

That leads us to the question: When do we build something ourselves vs when do we buy something off the shelf?

The meaning of build vs buy

Build vs buy is presented as a binary choice but that’s inaccurate. Building something doesn’t necessarily mean you don’t buy anything—it’s a spectrum. Here’s how I would define the ends of the spectrum:

• Build - use internal resources to combine “lower-level” building blocks into a full solution to a problem.

• Buy - purchase a solution from a 3rd party that attempts to fully solve the problem directly.

For example, let’s say your problem is that your reps don’t have tailored talking points on calls and that’s hurting your win rates. You could do one of the following:

1. Set up web scraping infrastructure on AWS, combine scrapers with AI (sourced from the OpenAI API) to direct their behavior while shaping their output, manage the process of running those scrapers, set up tooling to get those outputs into CRM and build out a way for reps to see the talking points.

2. Buy a product which provides a simple way to define regular scrapes using AI prompts that also integrates with CRM. Provide it with AI prompts, feed it account lists regularly, and sync that data back to CRM.

3. Get a copilot vendor that monitors assigned accounts and delivers updated talking points in a rep-friendly UI.

Option 1 is obviously the most pure “build” of the three options. Option 2 is still more on the “build” end of the spectrum even though it involves buying a product. That product, however, is a collection of low-level capabilities that require orchestration to solve any particular problem. Option 3, on the other hand, is firmly on the “buy” end of the spectrum as it involves forking over cash for an end-to-end solution.

The more you’re building, the more you’re ultimately responsible for saying how to do something to produce a useful output. The more you’re buying, the more you’re stating what you need done without worrying about how it happens.4

So how do you decide whether to “own how it works” vs “state what you need”?

Interdependence vs modularity

The late, great Harvard Business School professor Clayton Christensen is known for his research on “disruptive innovation” which looks at how companies deal with new technologies and changing customer needs. He influenced a generation of business leaders with several books, most notably The Innovator’s Dilemma and The Innovator’s Solution.

There’s a lot to unpack in both books—they’re not your typical quick business reads. I’m going to focus on a couple of chapters in the Innovator’s Solution where he talks about product architecture and how it impacts business performance.

Every product has an architecture. The revenue platform is no different. Here’s how Christensen defines it:

A product’s architecture determines its constituent components and subsystems and defines how they must interact—fit and work together—in order to achieve the targeted functionality. The place where any two components fit together is called an interface.

These aren’t graphical user interfaces, these are where two parts of a product come together. Think, for example, about a USB-C plug. That’s an “interface” for data and power transfer.

USB-C is what Christensen would call a “modular” interface. There’s a well defined standard and it does everything you want. It gives you data, it gives you power, it’s thin, it’s light, there’s no wrong way to plug it in. If you pick up a USB-C cable, it’s 99.9% likely to do the job because device manufacturers and cable providers and everyone in between have worked out the kinks and standardized on what a USB-C interface should do.

Now, think back a few years to older Apple devices. Remember these guys:

The two on the left weren’t standardized like USB-C. Apple designed them especially for Apple products. Despite what you may think, they didn’t just do that to be annoying and make more money. The state of the art for data and power transfer back 2012—much less 2003—was pretty crappy. Connectors at the time were fragile, slow, fat and had to be plugged in a certain way. They under-served people’s needs. Apple wanted to do better, so they made their own.

Those old Apple connectors are what Christensen would call an “interdependent” interface. If you want to give people a higher-performance, higher-quality experience when the state of the art is pretty crappy, you’ve got to build both sides.

He wraps this whole theory up into a diagram that puts all these ideas together. It’s very HBS professor-y, but it’s worth some study. Here it is:

That diagonal dashed line represents what’s “good enough” performance for customers of a particular product.

When products are immature and aren’t quite yet delivering what customers value, it makes sense to build interdependent product architectures so you can squeeze out every ounce of innovation to get closer to what customers actually want.

As products mature and start becoming more than “good enough”, it’s usually a better business to standardize into modules that get assembled together—it’s cheaper and more efficient that way.

In short, modular stuff will always perform a little worse than interdependent stuff. That matters a lot before most products in a category are “good enough” but basically stops mattering once they are.

There’s one last wrinkle though: what constitutes “good enough” is constantly changing. It might undergo major shifts as customer preferences change or new technologies emerge. When that happens, it starts the whole cycle all over again.

So what does all this have to do with build vs buy?

Let’s apply this to something a little more GTM-specific: sales engagement platforms. Circa early 2022, the innovation of running outbound sequences had evolved to be “good enough” for revenue platform customers (aka the GTM team). SEPs were basically “modules” in the revenue platform. It was a clear buy scenario. You need one of them. Don’t like Outreach? Plug in Salesloft. Or Apollo, doesn’t really matter. Not as standard as USB-C, but not far off. It’s no coincidence this is when Outreach started to stagnate and Salesloft sold to Vista.

Later that year, ChatGPT launched and the idea of “good enough” for sales engagement started to shift quite a bit. Three years later, we’re still not exactly sure what we want, but we know it’s got to be better than a human running sequences with a few variable replacements. So if you’re the PM for the revenue platform, you can’t just plug in a “module”, you probably need something more interdependent. That probably means build, at least for now.

The above logic, I think, largely explains my VP friend’s assertion that they’re better off building these agents in-house. Until you know what “good enough” is, better to own the how.

But, owning the how comes with a big catch.

Building is way more expensive than it looks

Building the first version of a piece of software is the easy part. That’s always been true, but AI—especially vibe coding—makes this particularly seductive. You can get to an initial working version in hours or days instead of weeks. Why not just build it yourself?

The problem is, it’s a trap. If you make the commitment to build instead of buy, somewhere between 60 and 85%5 of the investment that happens over the lifetime of the software will go toward support, maintenance and enhancement.

Are your internal resources equipped to answer questions, track bug reports, fix those bugs, deliver enhancements, test new capabilities? Are they ready to do that for the entire useful lifetime of the software while also managing the rest of their responsibilities? Are they ready to adequately transfer knowledge to another person when they leave to make sure everything keeps running smoothly?

There’s a cost to all that, but it’s often hidden. It’s locked away in other projects that don’t get done, bugs that don’t get fixed and features that don’t get implemented.

External vendors do this full-time all day every day. They’re fixing bugs and constantly incorporating things they learn from others. In most cases, that means the software gets better without you having to a lift a finger. These costs, however, show up on the invoice.

Before you make the decision to build, just make sure you’ve done a thorough accounting of the total cost involved.

Wrapping up

AI has thrown many parts of our tech stacks and revenue platforms into a new world. This technology shift has changed what constitutes “good enough” for our GTM teams, moving us from a cycle of modularity to one of interdependence in the revenue platform architecture.

That’s temporarily shifted the build vs buy equation, pushing more RevOps teams into build territory as they figure out what this new world looks like. That may be the right call for your context. Don’t make those decisions lightly, though. They cost a lot more than you think.