I’ve been a real downer lately when it comes to RevOps in the age of AI. First, I said that RevOps teams would shrink and then I shared analysis that showed that junior RevOps roles are in trouble.

Am I being too pessimistic? Maybe. Either way, RevOps is clearly going to change. So, what’s a practitioner to do? I’ll try to answer that. But first, let’s take a quick jaunt through some history and economics.

A (very) brief history of automation and jobs

There’s a long history of doomerism about new technology.1 It sounds quaint now, but Time ran an article in 1961 titled The Automation Jobless fretting about how machines replacing labor might lead to rampant unemployment.2 That article doesn’t even mention computers, but it does say this:

Many of the losses in factory jobs have been countered by an increase in the service industries or in office jobs. But automation is beginning to move in and eliminate office jobs too. In the U.S. Census Bureau, 50 people last year did the census tabulations that required 4,100 statisticians in 1950. California’s Bank of America and other banks are introducing sophisticated machines to process all checks and paperwork. While no one is being laid off, the banks expect to expand their business vastly without increasing their staffs. The Bell System’s volume of calls has jumped 50% in the past ten years; yet its phone company jobs increased only 10%.

Like I said, quaint. Clearly we didn’t eliminate office jobs in the 1960s. Speaking of “sophisticated machines to process all checks and paperwork”, that Time article predated the introduction of ATMs. ATMs are often held up as an example of how technology doesn’t replace labor because the number of bank tellers increased after the introduction of ATMs in the 60s and 70s.

The ATM story goes something like this: ATMs didn’t replace bank tellers. Instead they made bank branches more efficient so banks opened more branches. There were fewer tellers per branch, but that was offset by more branches. Net result: more tellers overall.

It’s a good story! There’s just one problem: it’s only kinda true. David Oks explains that the proliferation of branches had more to do with 80s bank deregulation. Also, the growth in tellers ended abruptly in 2010 and has roughly halved since then. The reason: smartphones. As banking moved completely online, the bell tolled for tellers.

So, the story of productivity gains from technology isn’t one of reactionary Luddites standing in the way of progress. Some technologies complement people (ATMs, sorta) while some technologies substitute for people (mobile banking).

With AI, folks looking to soften the potential rough edges talk about it as pure complement while ignoring the substitution effects. Think the “AI won’t take your job, someone using AI will take your job” sub-genre of LinkedIn post.

A more galaxy-brained version of this sentiment invokes the Jevons paradox. William Stanley Jevons was an English economist who observed in the mid-1800s that as coal use got more efficient, people just used more coal—thereby increasing the total demand for coal. By that logic, if AI makes something more efficient, we’ll just use more of it. Aaron Levie, CEO of Box, offers a good example of this argument applied to knowledge work:

Jevons paradox is coming to knowledge work. By making it far cheaper to take on any type of task that we can possibly imagine, we’re ultimately going to be doing far more.

Like the ATM story, it’s not so simple. The Jevons paradox only holds in certain conditions. Namely, demand for a good needs to be elastic in the economic sense—the market can and will consume more of that good if the price goes down. This applies neatly to things like coal and AI tokens but doesn’t automatically apply to related jobs.

For the Jevons paradox to imply that there will be more jobs in a given AI-impacted role, it’s not enough to just have demand elasticity for the role’s outputs, AI must also be a complement—not a substitute—for the tasks that role does.

Let’s look at how those two criteria apply to RevOps.

AI: RevOps substitute or complement?

My last two posts offer some support for both positions.

On the substitution side, it’s clear that some of the most common RevOps jobs-to-be-done (JTBD) are very likely to be straight-up replaced by AI:

RevOps is first-and-foremost viewed as a reporting function. The kind of reporting varies by seniority, but ultimately it’s all about data in, data out. AI is extremely good at this kind of work. It stands to reason that there won’t be much reason to have humans do this in the future. Other prominent RevOps JTBD categories like data management, lead management and systems admin are also very AI-shaped.

On the complement side, RevOps—especially leaders—plays a critical organizational role: building a shared reality across stakeholders, setting strategy, and acting as referee. AI can help with those things, but can’t (yet) replace them.

It’s also likely that RevOps will own meaningful aspects of AI strategy, agent enablement and agent orchestration. So, the very existence of AI creates some complementary jobs-to-be-done. The emergence of the GTM Engineer as a RevOps-adjacent-but-distinct role is an example of this complementarity already surfacing.

The real question for the future of RevOps is whether the complements beat out the substitutes. The economists Daron Acemoglu and Pascual Restrepo give us a straightforward framework to think about the effects of a technology change on jobs. They break it down into 3 “effects”:

• Displacement effect - automation performs tasks previously done by labor

• Productivity effect - cost savings from automation reduce prices and expand output, raising demand

• Reinstatement effect - the opposite of the displacement effect, i.e. new tasks get created where labor has an advantage

Putting it together, you can think of the impact on jobs from these effects as:

It sure seems to me that the displacement effect is likely to be larger than the reinstatement effect for the more junior roles in RevOps—those roles are just too filled with rote data analysis to see net positive demand. Senior roles, on the other hand, should see a smaller displacement effect. Those that embrace AI should see a stronger reinstatement effect.

That leaves the productivity effect. I have no doubt that AI will increase RevOps productivity. However, to fully consider the effect, we need to decide whether more RevOps productivity will be met with increasing demand.

Is RevOps too lumpy to be elastic?

Here’s a slightly different framing: if RevOps gets wildly more productive and each “unit” of RevOps output gets cheaper to produce, will companies want more RevOps?

Anecdotally, I’ve never met a sales organization that indicated their data was immaculate, their systems humming, and their reporting perfected. I’ve also never met anyone in RevOps who complained about having too little to do. All those are clear signs that if we could deliver “more RevOps outputs at a better price”, the market would want that.

What I have met are a lot of companies with understaffed or non-existent RevOps teams. This is especially true outside of B2B tech—those companies tend to have minimal ops support for their GTM teams. They’re not immune from the problems RevOps is built to solve, yet they’re not investing in it. That implies there’s some kind of barrier.

I think that barrier is that RevOps is a “lumpy” investment. RevOps is actually a collection of many sub-specialties bundled together. To get one month of territory planning or a good comp plan, you typically need to “buy” those capabilities in the form of a whole full-time employee. If you want systems administration or lead routing or data enrichment, you need to “buy” that in the form of another FTE or two. Oh and don’t forget that you’ll probably also need to equip those people with some specialized software.

So, while demand for the capabilities exists, fulfilling that demand often requires an investment that exceeds the actual need—kind of like buying a beach house to use twice a year. And just like vacation rentals exist to solve that challenge, fractional RevOps agencies exist to solve the RevOps challenge. However, agency unit economics still come down to people allocation and, as such, require retainers or commitments that minimize any true “on demand” capability.

In short, demand for RevOps outcomes is probably elastic if AI can unbundle them. That’s ultimately a strike against RevOps roles winning out in the Jevons paradox calculation. So long as the fundamental unit of RevOps input is a person—and that person only brings some RevOps JTBD to the table—you’ve got a bundling problem.

So what’s an operator to do?

Become a one-person RevOps org

Operators have two options to respond:

• Figure out how to “unbundle” themselves so companies can buy only what they need

• Make their “bundle” of capabilities so valuable that companies want the whole thing

Not surprisingly, both of the options involve mastering AI agents, because you’ve gotta fight fire with fire.3

Operators can ensure that AI complements them by building their own set of agents capable of doing a wide array of RevOps jobs-to-be-done. These agents should extend your capabilities and they should be your IP—not tied to any particular job. You build them up over time as you gain experience, and they become part of your value proposition in your next role.

That may sound a little odd until you realize that RevOps practitioners have always been hired for their experience, their skills and—often—their network. These agents are the logical extension of that for the AI era.

Armed with this agent army4, operators can then choose:

• Unbundle yourself and pursue a fractional approach, providing specific capabilities to multiple companies with specific needs at a scale that was previously impossible for a single individual.

• Bundle the total package together and offer your services as an FTE. The employer gets the capabilities of multiple specialists with a single hire and you command an outsized salary.

Combine the above with some people skills and baby, you’ve got a stew going.

I recognize this is a tall order. Not everyone can take this kind of approach to their role. Those who do, though, will have an AI-proof opportunity to benefit from their own personal slice of the Jevons paradox in action.

I recently made the case that AI would massively shrink RevOps teams.

My argument was pretty simple. Most of the jobs done by RevOps have a high AI “automation ceiling”. That, combined with continued improvements in AI capabilities and financial pressure for more efficiencies, means that RevOps teams are destined to shrink. It’s a reasonable take (if I do say so myself), but it lacked data—and I don’t much like to make arguments without data.

So, I decided to bring some data to the table. I analyzed a sample of 237 RevOps job postings from 210 companies to extract the most common jobs-to-be-done (JTBD) and score those based on how likely they are to be impacted by AI.

Key findings:

• RevOps is a reporting and analytics function at most organizations. The most common JTBD is “Build dashboards and recurring reports”, found in 68% of all job postings.

• Junior roles are the most likely to be disrupted by AI, regardless of company size. For some junior job posts, 100% of the included JTBDs can be fully replaced with AI, implying those roles may not exist in the near future.

• RevOps roles in smaller companies are more exposed to AI than those in larger companies. Ironically, the stakeholder and communication overhead found at larger companies may (temporarily) protect some of those roles.

Now, on to the details.

A little background

Some of you may remember seeing this radar chart from Anthropic making the rounds a couple months back:

I saw a lot of takes about it. My LinkedIn feed is mostly populated by sales folks so I saw a few posts highlighting that, of “knowledge work”-type jobs, sales was (slightly) safer from AI disruption. I think that was supposed to sound reassuring, but it really wasn’t.

Some people, however, questioned the whole concept:

Seeing this take, I said to myself, “Hey, why don’t I make an effort to score RevOps job exposure to AI?”1

A brief note on methodology

My goal was to zero in on “traditional” GTM-focused operations jobs at established companies. Given the industry standard 1:12 (ops:seller) ratio, there are plenty of jobs at stake there.

To do that, I (and my buddy Claude) sampled job posts from the last ~15 days aggregated by TheirStack with “revops”, “revenue operations”, “sales operations” and “marketing operations” in their titles at companies with more than 200 employees.2 This means the analysis does not include very small companies or new titles like “GTM Engineer”.

We assigned each job posting a company size band based on number of employees as well as a seniority level:

• Senior - Director-level or above

• Mid-level - Managers and senior ICs

• Junior - ICs with titles like analyst, specialist, etc.

Then, I worked with Claude to build a taxonomy of “jobs-to-be-done” (JTBD) that were represented across roles and put those into categories. After a few rounds, we ended up with 13 categories and 66 JTBDs. For example, the CRM & Systems Administration category contains 5 jobs to be done:

• Administer the core CRM

• Own GTM tech-stack integration

• Evaluate and onboard new tools

• Operate and architect AI-assisted workflows

• Administer CPQ and quote-to-cash systems

You can see the whole taxonomy here.

The final data set contains 237 sample job posts from 210 companies, each with a company size band, seniority level and a list of associated jobs-to-be-done from our JTBD taxonomy.

So, what did we learn?

RevOps, reporting for duty

RevOps is, more than anything else, a reporting and analytics function. Take a look:

The most common JTBD, found in 68% of all job posts, is building dashboards and reports. This doesn’t vary meaningfully by company size.

Breaking this down further by company size and role seniority, Reporting & Analytics is the top category in 7 of the 12 size x seniority buckets. The kind of reporting does vary by seniority: juniors build dashboards, while seniors are the keepers (and communicators) of the KPIs for the business.

Reporting is the most common JTBD, but how do different JTBDs come together to form a RevOps role? To answer that, I built a table showing how often JTBD categories appear together in a role.

To start, you can read this row-by-row.3 For example, of the 155 job postings that mentioned CRM & Systems Administration (A), 66% also mentioned Data Quality & Governance (B). Of the 57 postings that mentioned Territory, Quota and Capacity Planning (E), 100% also mentioned Reporting & Analytics (C).

What this means is that the dark purple columns appear in almost every job post, effectively forming the foundation of the RevOps role:

• Reporting & Analytics (C)

• Sales Enablement & Process (J)

• Cross-Functional Liaison (K)

• Operational Management & Issue Resolution (L)

I gotta say, that sounds about right to me based on all the RevOps roles I know. There are, however, a few interesting details that speak to deeper specializations within the overall RevOps landscape.

One clear area of specialization is marketing ops. Roles that mention Lead / Funnel Management (G) or Marketing Automation & Campaigns (H) rarely also mention core sales operations categories like Planning (E) or Comp (F). In fact, Marketing Automations & Campaigns never overlaps with Comp and has some of the lowest co-occurrence numbers across the board.

Comp (F) appears in the smallest number of job postings and—with the exception of the MOPs categories above—has high co-occurrence with basically every other category. This indicates that it’s frequently tucked in alongside other jobs and is rarely a role on its own. Territory, Quota & Capacity Planning (E) follows a similar pattern. Not surprisingly, these two categories are related. Of the roles that mention Planning, 53% mention Comp, which is the highest relationship with Comp for any category.

Armed with a deeper understanding of the overall structure of RevOps roles, we can use that to drill into the potential exposure RevOps roles have to AI.

Scoring RevOps AI “Exposure”

This is the effort that former-a16z-partner-turned-analyst Benedict Evans called “bullshit” in the post I screenshotted earlier. Maybe he’s right, but I still found it instructive.

When I talk about a role or JTBD’s “exposure” to AI, what I really mean is: How likely is that role to be either replaced or heavily altered by AI?

To try and figure out AI exposure, I assigned each of our 66 JTBDs an AI exposure label of low, medium or high. The rubric isn’t super complex:

• High - Structured system work (CRM config, querying, dedup, content production) that AI tools already do. Humans manage setup, oversight, and exception handling.

• Medium - AI handles analytics or workflows, but a human owns the framing, judgment, or final decision.

• Low - Stakeholder management, negotiation, strategic judgment, or people leadership. AI can help, but it can’t do the work.

I used Claude to assign the ratings to each JTBD but reviewed them manually. You can see the details in the full taxonomy. Reasonable people can disagree on the exact labels but, if anything, I felt like it was conservative.

To turn these labels into a quantitative measure, I assigned a numeric value to each: low = 0, medium = 0.5 and high = 1. With that in place, I could build an “AI Exposure Index” that ranges from 0 (minimal AI impact) to 1 (fully replaceable by AI) from a weighted average of JTBD mentions.4

Using this analysis, it’s clear some JTBD categories have way more AI exposure than others.

The JTBDs that are closest to pure data and workflows end up with the highest exposure. These are already heavily automated using traditional tools—AI just accelerates the process.

Data Quality & Governance leads the way. If you look at the underlying JTBDs in the taxonomy, it’s not hard to see why:

• Maintain data hygiene (high) - deduplication, data normalization and lifecycle-stage cleanup are all very AI-shaped.

• Define and enforce data-quality standards (medium) - defining the standards is human judgment, while enforcement (monitoring, automated remediation) is high-AI.

• Reconcile data across systems (high) - structured cross-system comparisons are straightforward for AI.

• Operate the GTM data acquisition & enrichment pipeline (high) - pipeline ops, vendor API orchestration, ingestion dedupe are all AI-shaped.

I was a little surprised that Reporting & Analytics didn’t end up higher on this chart. The mechanical process of fetching data and doing analysis is something AI can do easily. Deciding what to report on, how to interpret it and communicating it to stakeholders is something AI helps with but it doesn’t (yet) entirely replace a human. This article itself is probably a decent example of that.

All that said, the most common JTBD in the entire data set—Build dashboards and recurring reports—falls under this category and is very high AI exposure.

Finally, we can turn our attention to which roles are actually the most AI-exposed. To do that, I broke the data down by company size and seniority. Each cell shows the average AI Exposure score for job postings at that company size and seniority.

There’s a clear trend of reduced AI exposure as seniority increases.

It’s highest for junior roles—they’re doing the simplest tasks that are most closely related to data and systems. Some of those job posts even contained 100% AI-susceptible JTBDs. It’s not hard to imagine a world where there are far fewer of these kinds of roles.

Senior leaders fare significantly better. Their roles require some strategic judgment (hopefully!), meaningful resource allocation and stakeholder management. AI can help with these JTBDs, but it can’t outright replace them.

Interestingly, AI exposure tends to decrease in larger companies. My hypothesis is that this reflects the coordination overhead of larger organizations. No matter the seniority level, larger orgs require more of the job to go towards stakeholder management and cross-functional coordination—two things that have lower AI exposure.

Wrapping up

If anything, I think this analysis is too conservative. For any claim about high, medium or low AI exposure for a given JTBD, it’s best to add “right now”.

This time last year, all these values would have been significantly lower. There’s very little reason to believe that they won’t be significantly higher next year. This is a function of two things:

1. AI improvements - AI is now very good at the basics of accessing systems, retrieving data and doing analysis—even for complex tasks. There’s no fundamental reason to believe it won’t keep moving up the stack toward judgment, decision-making and communication.

2. Organizational change - If AI starts eating away at junior roles, that eats away at middle-management roles and results in smaller teams overall. If this happens across functions, human coordination overhead goes down for RevOps roles and the AI exposure goes up. It’s a self-reinforcing cycle.

I agree with Benedict Evans. It’s fair to question the methodology that goes into an analysis like this. The numbers may reflect an impossible level of precision, but the AI RevOps reckoning is very real.

Consider this a 3rd installment in my Actual Agent Architecture series (see part 1 and part 2) where I discuss our adventures making Gradient Works an agent-first company.

Today I want to share work we’ve been doing to make our outbound agent produce copy that’s both well written and relevant to the recipient. We’ve got a ways to go yet, but we’ve made meaningful progress.

First, a disclaimer. I don’t use AI to write these articles. If you think something sucks (like the title of this piece), it’s because I blew it and/or am corny, not because of AI slop.1

Speaking of slop… about 18 months ago, I said using AI SDRs was disrespectful. That was true in September 2024. The state of the art at that time was sending garbage to people’s inboxes at scale. In 2026, we have real agents with strong reasoning capabilities, access to historical relationship data and large memories. It’s definitely possible to use AI to do good outreach. People (and AI) can change.

About two months ago, we started experimenting with agentic outbound. I am vehemently not building a spam cannon. Instead, I want to build a system that can do a better job running relevant outbound campaigns than any human ever could.

Humans, after all, are limited in time, attention and the ability to distill relevance from lots of context. You try listening to 4 hours of calls or reading a quarter’s worth of company announcements and writing 2 crisp sentences that correctly connect the main topics to your value proposition. AI, however, does that extremely well.

Given the right access, context and skills, an AI agent should be able to do a better job for most messaging than a human would.

Armed with that thesis, I just needed a platform. I figured, why not use Claude + a headless Salesloft? Yes, that old crusty legacy platform. I know there are AI SDR platforms out there but a) we already have some Salesloft licenses, b) it has a surprisingly comprehensive API that I can connect to with our CLI2, c) I’ve already got Claude Code and d) I don’t want to spend Jordan Belfort money.

Once I got the first version wired up, it worked. The messaging it produced, however, was pretty meh. If I let it draft more than a couple sentences within a fixed template, it just came off as “too AI”. I know this because I review (and edit, if needed) every single one before it sends.

Someday I want to have this thing operating with less me-in-the-loop and that’s not gonna happen if it’s sending slop. So I set out to make it much better at writing.

Setup and eval loop

I decided to start with a reconnect cadence because it’s important to get this messaging right. After all, these are folks you may have met with many times before in a previous sales cycle. It’s also hard to make reconnect emails super-templatized without losing relevant nuance. It’s a great use case for AI, but only if it can write well.

Here’s how I set things up inside Claude Code:

1. The main agent fetches all the tasks in the Salesloft queue, organized by cadence and account

2. For each account:

   1. An account-draft-planner agent pulls in writing instructions and context and then drafts messages for each Salesloft task, storing each message in a markdown file.

   2. An account-draft-editor agent pulls in its own instructions, reads each message file and suggests edits (if any), logging the suggestions in the file.

   3. The main agent incorporates the edits and produces a new draft if the editor requests it. Then that draft gets sent back to the editor for another pass. This happens up to 3 times.3

When all was said and done (about an hour of chugging away in auto mode), I had a list of pre-drafted messages that represented the best the agents could do without my help.

After that, I went through the actual process of reviewing and sending the messages. The system goes through each one and presents the draft to me to approve or make changes. If I make changes, it logs those changes to the file.

Sadly, I had to make a lot of edits. Which I dutifully did for close to 50 emails over most of a full day. It sucked.

However, now I had a corpus of good copy AND the changes it took to get from semi-slop to sendable.

From there, I asked Claude to analyze the edits from both the editor agent and me. Then I had it group them into categories. Ultimately this is what we came up with:

• Composition and style - writing that sounds like slop

• Knowledge errors - factual mistakes and hallucinations

• Knowledge gaps - missing information I had that wasn’t available to the agent

Once I was satisfied with the analysis, I had Claude generalize all the suggested edits into rules which we used to update the reference files and subagent definitions for the planner and editor.

The rest of this article details the things we caught and how we tweaked them.

Composition and style

Any attempt at high-quality agentic outbound copy has to overcome two very big hurdles: AI-voice and sales-voice.

We know the AI tells:

• A “breezy” tone with short, choppy sentences which sound like a replacement-level B2B marketer suffering from terminal LinkedIn Brain

• Generic buzzwords like “leverage”4

• Empty prefixes meant to add emphasis like “Here’s the thing:” or “Let’s be clear:”

• The dreaded “it’s not X, it’s Y” (aka the “rhetorical reframe”)

• And—of course—the em-dash.

Sales-voice has its own tells:

• Waging war on pronouns.5 In an effort to make emails as short as possible, “I saw X” becomes “Saw X” and “We reviewed Y” becomes “Reviewed Y”.

• The low-effort CTA question like “Worth a look?”, “Open to 15 minutes?”

• Faux relevance like “Congratulations on what you’re building in <broad industry>!” followed by the non-sequitur pivot, “We help companies <do unrelated thing>”

• Aggressively lowercased subject lines. “quick question, hayes” indeed.

And this is just the relatively good outbound. My inbox is a cosmic gumbo of terrible grammar, poor formatting and failed variable replacements.

After reviewing the edits, this is the set of style-based anti-patterns that Claude and I came up with:

**Anti-patterns to avoid:**
- Generic buzzwords: "unlock," "supercharge," "leverage," "empower,"
  "streamline"
- **Rhetorical reframe:** "That's not X, it's Y" / "This isn't about X.
  It's about Y." / "Where we're different is…" / "What makes us unique
  is…" — reliable AI tell. Delete the setup, keep the second half, or
  rewrite entirely.
- **Vague ownership claims:** "That's our sweet spot" / "That's where we
  shine" / "That's what we do" / "That's the slice where X fits" /
  "That's where we tend to land" / "That's the gap we close" / "That's
  usually where we can help" — says nothing. Let the product description
  stand on its own.
- **Filler emphasis:** "Here's the thing:" / "Let's be clear:" / "Here's
  why that matters:" — just say the thing.
- Passive voice
- Warm-up openers and filler reasons-for-writing: "I hope this email
  finds you well" / "Been a while" / "Hope you're doing well" /
  "Reaching out because" / "Coming back around because" / "Following up
  on my note from earlier"
- Apologetic CTAs: "no pressure either way" / "happy to walk through" /
  "whenever works for you"
- **Em-dashes.** Don't use em-dashes (—) in outbound copy. The fragment
  after the dash has a specific grammatical relationship to the main
  clause — find the right conjunction or preposition and integrate it, or
  split into two sentences. Don't let the integration produce a run-on.

I want to give a special callout to em-dashes as the last bullet point there.

First off, it’s pretty funny that the rule itself is written in such a way that it violates the rule. When I asked Claude about this, it suggested it was more efficient this way as an instruction. ¯\_(ツ)_/¯

I like the occasional em-dash, but I don’t like how AI sprinkles them everywhere. I’m not alone. Em-dashes are probably the number one pet peeve people have about AI writing. Personally, I’ve spent quite a while battling em-dashes with my AI prompts and haven’t quite succeeded—but this time I had a breakthrough.

My agent was generating a lot of copy like this:

You met with [REP] last October — the focus was on EMEA pipeline coverage.

I would much prefer something like this:

You met with [REP] last October. The focus was on EMEA pipeline coverage.

Fed up, I got a bunch of examples, showed them to Claude and asked what exactly the em-dash is doing, grammatically. Claude informed me it’s acting as a sort of all-purpose concept connector. It either connects two different independent clauses (like the above example) or it replaces something called a subordinating conjunction. That was a new one for me! According to Grammarly:

A subordinating conjunction is a word or phrase that links a dependent clause to an independent clause. This word or phrase indicates that a clause has informative value to add to the sentence’s main idea, signaling a cause-and-effect relationship or a shift in time and place between the two clauses.

Grammarly has a handy list of subordinating conjunctions in the linked article. They’re words like as, because, since, when.

So, you can just replace something like:

Things went quiet after that — the new CRO was focused on other FY26 priorities.

with a nice little “because”:

Things went quiet after that because the new CRO was focused on other FY26 priorities.

Ultimately that led to the em-dash busting rule you see above. If you’re dealing with two independent clauses, just make them separate sentences. Otherwise, just find a nice subordinating conjunction. It seems to work. Finally!

Fresh off my victory over the em-dash, I then turned to an arguably more pressing matter: lies.

Knowledge errors

You can coax AI to write like a normal human, but if the stuff it says is wildly incorrect, you’ll still look like an idiot. This is why context is so important.

And the worst way to look like an idiot is to talk about your own company incorrectly.

As I was editing, I noticed two emails with bizarre errors. Both mentioned two Gradient Works products that most definitely do not exist: “Bonsai” and “Bullseye Books”.

I asked Claude to help figure out what happened. In both cases, it turns out we had a Salesloft note referring to “BB”. Internally, we sometimes use that to refer to Bookbuilder. Apparently the agent simply made up a product name that it felt might be applicable to the initials “BB”.6

These kinds of hallucinations used to be incredibly common with AI. Now it’s rare that a modern model will make this kind of mistake if given appropriate context. In this case, the error was due to missing context. I had forgotten to explicitly tell the agent to reference cortex (our agent knowledge base).

The fix was relatively straightforward. Claude suggested adding something like the following to the skill file:

**Don't invent product names.** The canonical product features live in
`cortex/gradient-works/GTM/Product Marketing/Features/`. If you're unsure which feature
fits a description, describe the capability instead of naming one. Never infer a
product name from an abbreviation in account/person notes.

Most of the time enabling AI really is like enabling a person, but not always. I wouldn’t necessarily expect a new employee to know for sure what “BB” meant. However, I would expect them to stop and ask if they were unsure. AI will typically plow through and hazard a guess unless you tell it not to.

I also noticed another kind of error, this time caused by irrelevant context. A couple emails talked about pipeline numbers and rep counts. Lucky for me, I was in some of those calls and those metrics didn’t sound quite right. I went back and compared the email to the call transcripts. Lo and behold, those metrics were never discussed.

After more debugging, it became clear the agent was conflating pre-call research notes saved in Salesloft with notes about discussions that actually occurred.

I’m still working on how to fix this one. I think the solution will involve two fixes:

1. Tell the agent that newer context supersedes older context

2. Add more explicit guidance about what context comes from verified conversations vs what’s research or speculation

Finally, this cadence showed where we have gaps in getting context from one agent to another. One of our agents generates detailed summaries of our closed opportunities. I originally used that to distill basic discussion points which I added as account notes in Salesloft for the outbound agent. It looks like this:

Unfortunately, that just wasn’t enough detail on the previous sales cycle for the level of detail I wanted in the copy. In particular, I really needed more data about meeting dates and attendees. Otherwise, the agent just tied everything to the last touch. To fix that, I found myself schlepping draft emails over to the opportunity agent to validate against its more comprehensive opportunity data context.

Next time, I’ll either distill down less or just give the outbound agent direct access to the full opportunity detail.

All these issues come down to context we had available but didn’t use properly. Another—more challenging—problem is context we don’t yet have accessible to our agents.

Knowledge gaps

The final problem was incorporating information from a) conversations that happened out of band and b) external signals.

As I evaluated messages, I could sometimes recall information that simply wasn’t available to the agent. This included emails that hadn’t been synced into Salesloft, LinkedIn DMs and actual memories of in-person conversations. This information led to complete rewrites to turn factually-correct-but-dry “reconnect” emails into messages between friends. Some of those (like the unsynced emails) are easy fixes. Some of the others (like recollections from an IRL lunch), not so much.

External signals are something we just need to get better at. I’d done some light enrichment before starting outreach, but I still found several hooks on LinkedIn that ultimately made me rewrite agent-drafted emails.

At some point there are diminishing returns to trying to gather every piece of context. Not everything in life can be documented in a markdown file. Humans aren’t great at remembering precisely what was said in a meeting 6 months ago but many of them (especially in sales) excel at maintaining social networks. That alone may be a reason to keep humans in the loop.

Wrapping up

You should take two big things away from this post.

First, it’s possible to defeat the em-dash using the power of grammar.

Second, agent enablement is hard work, just like it is for humans. Just tossing an agent at the problem won’t work (clearly). It requires real upfront investment in giving it what it needs to do a good job. It’ll be a slog, but I’m convinced my pipeline will thank me.

Last June, I wrote about the apparent reluctance of RevOps to embrace AI, citing ICONIQ’s 2025 State of GTM Report which showed RevOps teams lagging behind their GTM peers in AI adoption. After spending more words than I should have1 hypothesizing about why, I said that needed to change:

The last 6 months of AI development have put all the ingredients in place for a new phase of RevOps. Models can reason and analyze. They can reach into systems to get the data they need and take necessary actions. The technology is new and immature, but it’s here. Right now.

That was 10 months ago. AI, for most people, still meant chat (mostly ChatGPT). At best, you could connect a primitive MCP or upload a CSV and get some basic analysis back out. Then you could… well, you could paste that analysis somewhere else.

In retrospect, it’s not shocking that RevOps was slower to adopt AI. AI could output useful text, but it couldn’t actually do very much. The state of the art was remembering a few things between chat sessions and trying not to hallucinate too often. Forget about handling long-running multi-step tasks that safely access your files or modify external systems.

But, I can give myself a little credit for prescience. The basic ingredients were in place back then.

Fast forward to January of this year when Claude Code broke containment from its early life as a pure developer tool. AI could finally do useful tasks, access things and get better over time. Those shifts changed the relationship between RevOps and AI. I don’t have ICONIQ to back me up this time, but I’ve collected enough anecdata to be confident that RevOps is all-in.

And now it’s time for RevOps leaders to reckon with how their worlds have to change.

A different kind of 10x

I kicked off that RevOps post from June with a story about the RevOps org I ran at a publicly-traded company. We were a team of 50 supporting 600 sellers. This was 2019. AI agents were science fiction.2

Even then, that ratio of reps to ops felt bloated. It seemed obvious to me that we ought to be able to do the same work with a smaller team, but we couldn’t pull it off. Too much questionable data. Too many siloed systems. Too many ad-hoc requests. Too much “fuzzy” process that was 90% automation but fell apart without human engagement on the last 10%. We just had to have humans doing things.

Turns out I shouldn’t have felt bad about our ratio. Adam Schoenfeld two years ago published the broadest data I’ve seen on rep-to-RevOps ratios as part of his work at PeerSignal. Here’s what he found:

In aggregate we see a 12:1 overall ratio of Sales Reps (AE+SDR) to Rev Ops. That's 7,700 Rev Ops people supporting 91,000 sellers in our sample list of companies.

For those of you who don’t want to do the math3, 600:50 is precisely 12:1. We were right in line with the industry standard. And this was after PE-driven layoffs.

That 12:1 ratio was true for me in 2019 and true for Adam in 2023, but I think it’s due for a major revision.

GTM processes are still as ambiguous and exception-filled—as fuzzy—as ever. The difference is that AI agents mean this operational fuzziness no longer prevents automation. The proportion of work done by RevOps that can be done by AI-driven automation isn’t 100%, but it’s uncomfortably close.

Sales roles, on the other hand, have a much lower AI automation ceiling. I say this as someone who wrote a viral post called the 10x Sales Rep about how to get a mid-market rep to a $10M quota using AI.

The thesis of that post wasn’t wrong, per se. Sales reps can get radically more efficient than they are today, especially because most aren’t very efficient. However, humans still need to talk to humans and be in physical proximity to other humans. So while sales was faster to adopt AI than RevOps in the “chat-only” era, the proportion of total sales tasks that can ultimately be automated by AI is lower than for RevOps.

Put these different automation ceilings together and you get a recipe for radically different rep-to-ops ratios in the future.

Let’s say 90% of the work my 50-person team did in 2019 can be done by AI. That team shrinks to 5. Let’s say 50% of the work sellers do can be done by AI. That 600 person team becomes 300. That’s a 60:1 ratio.

That was for a mid-market sale. It wouldn’t be surprising to see 100:1 ratios for enterprise sales motions that retain a high “human factor”.4

A 100:1 RevOps org requires a different kind of team and a different set of skills.

How the work changes

Like all of us who are wrestling with how to harness agents, lots of RevOps practitioners will have to change their identity from being responsible for doing the work to being accountable for the quality of the work.

To make this concrete, in 100:1 RevOps orgs, agents will do the work of pulling together the data and preparing the GTM board slides—a human analyst won’t spend two weeks doing that. So far, so good. That stuff isn’t fun, anyway. But guess what? If the data’s inaccurate or those board slides are wrong, it’s your ass on the line, not Claude’s.

This massively changes the work we consider to constitute “RevOps”. I think the shift looks something like this:

This shift comes down to doing four jobs well: keep the context, govern access, orchestrate the agent fleet, and make yes possible.

Let’s look at each in turn.

Keep the context

RevOps has always owned the source of truth for data, process definitions, policies and—in concert with Sales Enablement—skills training for the GTM org. In AI agent parlance, that’s context. It’s always been necessary to maintain these things, but it’s often been possible to get by with it being fragmented and poorly documented because this information can be (lossily) transmitted from one person to another.

Agents need thorough, consistent, written context to do their jobs well. In a world with multitudes of GTM agents (both inside and outside of RevOps), someone needs to be sure they’re all singing from the same hymnbook. The job of maintaining, distributing and synchronizing context will naturally fall on RevOps.

Govern access

RevOps has long played a role in data governance, especially as it relates to CRM. The role RevOps plays with information security policies around authentication and authorization has been more limited. They rarely make the policies themselves—instead they enforce company-wide InfoSec rules in the GTM systems they control.

Those fundamentals probably don’t change much. However, the web of entities needing access to systems so they can read and write data will only get broader. What about the sales rep agent that needs to update Salesforce? Does it have the same privileges as a rep? The 6 agents that read and summarize Gong transcripts for different use cases? Where can they send that data? How about the finance data that goes into those board slides?

RevOps will have to partner more closely with the CISO and InfoSec teams to ensure an increasingly complex and interconnected set of agents with evolving access needs don’t rip gaping holes (or open silent back doors) in a company’s security posture.

Orchestrate the agent fleet

This is the most uncertain of all the areas. We have some principles of accountability and we have large human RevOps teams (and their management structures) as precedent, but we just don’t know how this area will evolve.

Maybe “bring your own agent(s)” (BYOA) will win out as the prevailing model. Or perhaps we’ll all buy pre-built agents from different companies. While I tend to favor BYOA, I’m sure the future will be at least somewhat hybrid.

Right now, there’s no clear technical winner in this orchestration problem.5 There are no standards and there are a lot of complex problems to solve. Nevertheless, demand is such that the fleet of agents will grow faster than the tools to manage them.

My guess is an agent orchestration approach will emerge first in software development (much like Claude Code did). RevOps must make it their mission to keep up with the state of the art and adapt quickly when a solution emerges.

Make yes possible

When I was running RevOps, I was frustrated at how often we had to say “no” to other parts of the business.

“No, we can’t change this process because it’ll break that process.”

“No, we can’t automate that because this system can’t talk to that system.”

“No, we can’t run that experiment because we don’t have that data.”

The root cause, I felt, was that our operations weren’t good enough. Years of underinvestment in systems and processes had left us in a place where every change was dangerous and every experiment might have unintended consequences.

I didn’t want to live like that. I wanted us to live in a world where we could say yes to more things. I wanted to adapt to change, run experiments and grow. To do that, we had to get better at our core operations mission. If we did that, we could make yes possible. “Make yes possible” became a mantra.

We’re in a time where experimentation is necessary for survival in GTM. A 100:1 RevOps org that successfully nails context, access and can orchestrate fleets of agents should be the ultimate yes machine—driving the cost of experimentation to near 0.

Wrapping up

The symbiosis of RevOps and agents is well underway. The logical consequence will be tiny RevOps orgs that support large sales teams at ratios that were simply impossible before. 100:1 rep-to-RevOps orgs are well within reason.

To get there, most RevOps professionals are going to have to learn new skills that operate at a different level of abstraction.

It’s not enough to know how to pull a report and build a chart. Can you enable an agent with everything it needs—from access to context—to pull the report and build the chart when you’re not around? Can you build an agent that interprets the report and automatically fixes the problem? Can you build an agent that spots and corrects potential problems before they happen so you no longer need the report and the chart?

This won’t be an easy transition. There will be fewer roles in RevOps with different responsibilities. I hate to say it, but not every operator will make this transition successfully. The ones that do will be in very high demand. I’ll share what I think this means for RevOps careers in a future post.

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

7 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?