Subscribe now

Thanks for reading this hand-rolled, 100% organic (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for reps and agents.

Rox → Revenue Agent for the Global 2000.

Sumble → High precision GTM data + intelligence.

Terret → The answer-to-action engine for revenue teams.

The lines between “GTM Engineering” and RevOps can be pretty blurry. Some people would even say they’re the same thing.

I completely disagree. But maybe not for the reasons that other people do.

Here’s my main point: There are fundamentally new and critical JTBD that GTM orgs need, but that a current (already overloaded) RevOps function aren’t suited to take on. This is why companies need to specialize and hire someone to do these (new) tasks.

But what are those tasks, and how should RevOps and GTM Eng teams divvy up the work? That’s exactly what I’m mapping out, today.

Let’s get into it.

When I published The Rise of the GTM Engineer back in November 2024, there were only around 200 new job openings for the role. Then, in 2025, the number of GTM Engineers increased 5X. And it has grown another 3X already this year (so far). But, I still get the same question from GTM leaders and founders I talk with: “How is this role different from what my RevOps team does?”

And, it’s a fair question. The title can be confusing. Because it’s nuanced, defined differently for different companies, and quickly evolving! As GTM Engineering becomes more and more popular, understanding how it fits in with RevOps is more and more important. This new function (title semantics aside) is too important to be overlooked because it’s confusing.

I spent all of my time from mid-2024 to early 2026 hands-on consulting (across 14 companies) building go-to-market systems and helping them operationalize AI—from a data, systems and people perspective. With that experience, and talking to dozens of operators this year, here’s how I’ve come to see the distinction between RevOps and GTM Engineering:

System of Record (RevOps) versus System of Action (GTME)

This is not a perfect analogy, but it’s a helpful framework to think about the swimlanes between RevOps and GTMEs.

RevOps: The System of Record.

Jeff Ignacio is one of the most respected voices in RevOps (for good reason). Here’s his mental model for what RevOps is responsible for:

• Designing workflows across sales, marketing, and CS, plus

• Equipping teams with tools and training, plus

• Serving as a strategic partner with data-driven recommendations, plus

• Managing the tech stack.

The job is to make sure the business has reliable data, consistent processes, and reporting that leadership can actually trust. In one of my favorite articles on the topic (What RevOps Actually Owns), Jeff said:

Here’s the defining shift: RevOps doesn’t exist to report on performance. RevOps exists to design and operate the revenue system that produces performance.

That system spans how strategy turns into execution, how teams hand off work, how incentives shape behavior, how data flows between tools, and how decisions are made and enforced.

When RevOps is treated as “advanced analytics” or “CRM admin plus,” the function becomes downstream of problems instead of upstream of outcomes.

The RevOps mindset is: How do we create structure and consistency? GTM Engineers, on the other hand, own motion.

GTM Engineers: The System of Action.

Clay coined the term. Their canonical definition is:

GTM Engineers build revenue engines using AI and automation. They combine growth acumen with technical chops to create scaled systems. Instead of coding software, they’re coding revenue.

Sounds… a lot like the RevOps definition, huh? So my perspective is, yes, GTM Engineering can be a subset of the RevOps universe. (I share data on which departments GTMEs report into, further down in this article.) But it’s a very particular part, which is becoming even more important.

Where RevOps asks “is the data clean?” and “is the process being followed?”, GTM Engineers are generally actioning that data. They’re the ones stitching together Clay, enrichment APIs, intent providers, account scoring, putting customer campaigns in motion, automating sales materials, and using the latest AI models to build workflows that span the entire lifecycle of the buyer journey.

For instance, a GTM Engineer might build an end-to-end workflow that automatically emails a prospect. That’s something a RevOps person would never do. But, that workflow relies on the scaffolding RevOps built—things like: account enrichment+tiering, contact-sourcing+persona bucketing, account ownership per rep. So, these JTBD are distinct, but intertwined. Symbiotic even.

Let me also take a second to clarify: GTM Engineering is also not just automating a bunch of top-of-funnel activities. I wrote more about this in my piece: Most Companies Are Using GTM Engineers Wrong. The role is bigger than top-of-funnel. GTM Engineers are (or can be / should be) a leverage multiplier in every department across the entire go-to-market motion.

The GTM Engineering mindset is: How do we drive (quantifiable) outcomes?

(One personal example of this: when I was in RevOps at Zoom video, my OTE was ~5% variable bonus against my goals; which were things like... build a playbook for the team, redo comp plan, integrate this new technology, etc. Whereas when I was a GTM Engineer at Apollo, my variable comp was ~25% because my goal was so quantifiable, more similar to a seller. My goals were to 1) book 1,600 meetings/quarter into net-new accounts without any SDRs and 2) book 400 cross-sell meetings into the existing customer base.)

A Framework for Drawing the Lines

Jeff Ignacio has a useful model for this: map out what RevOps owns vs. influences vs. supports. You could apply the same logic to GTM Engineering. Where the Venn diagrams overlap, you need explicit agreements (ie: swimlanes).

Here’s how Jeff visualizes it in his article Designing a RevOps Org:

RevOps defines what goes into the system of record and how it’s structured. GTM Engineering has the freedom to build whatever it wants outside that system, as long as it respects the rules for what comes back in.

Where They Overlap (and Where They Clash)

This is my current opinion. I am sure (and even expect) that it continues to evolve over time, so reply to this email if you disagree, I’d love to keep learning.

Here’s how I would define the swimlanes between RevOps and GTMEs:

FAQs on getting started with GTM Engineering

If you’ve bought into the concept that “GTM Engineering” work is different than RevOps work (or even a subset or evolution of RevOps work), then the next questions are:

• When should you hire a dedicated GTM Engineer?

• When should you separate (hire a dedicated) GTM engineer from RevOps?

• What department does GTM Engineering report into?

Read more

Subscribe now

Thanks for reading this hand-poured, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for reps and agents.

Rox → Revenue Agents for the Global 2000.

Sumble → High precision GTM data + intelligence.

Terret → The answer-to-action engine for revenue teams.

Happy Friday Saturday!

Wild times continue. This week, an employee bugged OpenAI’s office. And Elon finally demo’d a flying car.

Today, we’re back with another edition of the GTM Weekly Round-up. But first, I wanted to share my top takeaways from interviewing 20 GTM operators in San Francisco last week, at Clay’s conference, Sculpt.

Let’s get into it.

Lessons from interviewing 20 GTM operators at Clay’s conference

Last week, 2,000+ people gathered at Pier 48 in San Francisco to talk about modern go-to-market. I showed up with a camera man and a mic, and asked 20 GTM operators a bunch of questions. Things like: “What’s something you’ve built with AI recently?” “How are you currently thinking about ‘build vs. buy’?” “What’s your AI hot take?” “What hasn’t changed in the AI-era?” Etc.

Here are a few themes that most people I interviewed agreed on:

1. Data hygiene still decides everything. AI just makes bad data fail faster. I liked how succinctly Bruno (who leads marketing at Clay) put it to me: “AI activation without an infrastructure layer is useless.”

2. GTM engineering is still mostly stuck in outbound. Adam Schoenfeld, Crissy Saunders (CS2), and several others said the role has to reach into marketing, events, CS, and more.

3. You should buy the foundation and build on top of it. Most people I spoke with are building at the cutting edge of AI and GTM. To these type of people, it’s no longer about build versus buy. It’s build and buy. The question now is: when do you do which one?

4. Context is the next layer. Five different people named some version of a context layer, context engine, or semantic layer as the thing they’re building right now.

5. Human interaction becomes more valuable in the AI-era. Whether its conferences, prospect dinners, calls instead of automated emails, or getting on the plane to meet with a customer. Everyone agrees this is going to become more important, not less.

But, of course, not everyone agreed on everything. Here were some of the topics where there was not consensus:

1. Do people still buy from people? Most said yes, and someone told me that agents selling to agents is “total B.S.” But, one Director of GTM Engineering told me buyers already trust agents to make purchases for them. And Varun, one of Clay’s co-founders, told me they saw something interesting in early testing of their inbound SDR agent: prospects told the agent more than they tell human reps.

2. Building in-house is overrated. Almost every build vs. buy answer ended up talking about the sneaky cost of maintenance.

3. AI is the worst tool for outbound. Spicy. Jorge (Founder of The GTM Engineering Company) thinks buyers will learn to spot AI personalization the same way they learned to spot merge tags.

4. You should use AI less for things you’re less certain about. My friend, and former colleague, Andreas (Snowball Consult), told me that when he’s doing work for the first time, he does it by hand on purpose so it doesn’t run away from him. Charlie (of CS2) made a great case for a lot of workflows to stay deterministic, because adding an LLM makes them more expensive and less accurate.

5. “AI” does not just equal “LLMs.” Nate (founder of Fluint) says teams ignoring classical ML are leaving a lot on the table.

I’m going to publish a couple videos of these interviews over the next two weeks. But for today, here are the spiciest takes from last week:

Press play 👆 to watch on YouTube (or watch it on X here).

Weekly GTM Round-up:

• Join us on Tuesday at 9am PST for The Signal’s Live Show.

  Guests include Kyle Poyar (Growth Unhinged) and Maja Voje (GTM Strategist), who just published The 2026 State of B2B GTM.

  They’ll share the highlights from the report, what was surprising, the hottest GTM tools right now, and more. Their survey showed the #1 GTM channel is warm intros/referrals. So I’m also bringing my friend Richard Purcell on to demo how he runs this motion successfully.

  It’ll be a fun one → Register here.

  

• X went crazy over this 20VC episode with the SVP of Sales at Ramp (who announced a raise at $60B valuation this week. And announced Glass, a new AI workspace. they’re cooking). Anyway, this convo was great. Here were Harry’s takeaways. And here’s why you should listen to Max:

  

• Oldie, but goodie - about sales (h/t to Alex for resurfacing it this week):

  

• Travis Henry is maybe the best RevOps operator I personally know (he doesn’t post much online… I need to convince him to). Anyway, he recently moved from Snowflake to Temporal, as VP of RevOps. And he’s hiring a bunch of critical/early GTM ops roles. You should work with him if you can.

• Don’t @ me, marketers…

  

• Very true for most sellers in today’s market (I do not envy product marketers right now):

  

• Todd bringing the heat:

  

• Exa passed $100M in ARR this month. Crazy chart below. From Will’s post (CEO of Exa) this week: “We predict agents will search 1000x more than humans by 2030. Agents don’t search like humans. They write long, complex queries and want all the world’s data, not just the web. We’ve spent 5 years building a search engine designed for them.”

• Nooks is hosting a livestream next week, with Ghazi Masood (CRO, Replit) and Hannah Willson (CRO, Nooks) to dig into what changes for AEs when agents join the sales team (what agents can take on, where human judgment and relationships matter most, and how leaders can put this into practice to keep deals moving and drive performance). Register here: “The GTM Frontier: Building the AE Team for the Revenue Agent Era with the CRO.”

• Not wrong…

  

• Champion raised another $5 million to “put human relationships at the center of go-to-market,” bringing their total raised to date over $10M

• Mark with a pithy banger:

  

• Gartner dropped their magic quadrant this week for the Revenue Action Orchestration category (that’s a mouthful). Fun to see some new (AI-native) logos on it this year!

  

Alright, that’s it for today.

As always, thank you for your attention and trust. I do not take it for granted.

See you next week,
Brendan 🫡

PS: If you liked today’s post, send it to one person who would enjoy it.

Subscribe now

Thanks for reading this hand-poured, farm-to-table (human-written) newsletter.

Hey, y’all!

I’m back from a bit of travel and excited for today’s (guest) post on how to operationalize AI for revenue teams.

My guest is Pouyan Salehi, who I have known for about a decade now, and is deeply familiar with B2B revenue. He previously co-founded Scratchpad and PersistIQ. And now, he’s working on Clearskies, “the context layer for revenue.” He’s talked with dozens of companies about this problem, and spent a ton of time putting together today’s article. I’m really excited for how it turned out. I believe it is going to help a lot of revenue leaders think through this concept. And, I predict, the “context layer” is something that will continue to be a hot (and increasingly important) topic this year.

Alright, with all of that said, let’s get into it.

Most revenue teams I’ve talked to are in a similar place with AI. A few people on the team have built useful workflows and agents while the rest of the team is in one-off chats, if they use it at all.

This is a strange place to be stuck because the hard part, intelligent models, is supposedly behind us. The models are incredible now and the harnesses are improving rapidly. Just look at how much Claude Cowork and ChatGPT Codex have changed in the last few months, and at what Grok Bot can do immediately out of the box.

Usually it looks like this. A seller has an agent that drafts her follow-ups, and they’re good enough to send. A manager has a workflow that pulls his notes together before 1:1s and saves him an hour a week. The value is there but it’s dependent on whoever built it.

There are two states a team can be in. In the first, AI works for one person at a time. In the second, AI takes on meaningful jobs in the revenue function, across the whole team. I’ve started calling the gap between them operationalizing AI. Getting one person to the first is fairly easy now; helping a whole team reach the second remains a challenge.

The rest of this article is about why that gap exists and what closes it.

What it means to run on AI

Operationalizing AI means moving from one-off questions and chat to AI taking on meaningful revenue work that runs reliably, produces outputs the team trusts, and reaches the whole team. Reliable means the work happens whether or not someone remembers to ask for it. Trusted means the team acts on the output without checking it first, because it’s accurate and grounded in what actually happened with the customer. Team-wide means it runs for each person who needs it, not only for the person who built it.

Some of this work is scheduled, like a pipeline risk report that lands in Slack or Teams before the Monday forecast call. Some of it is on demand, like asking for a deal review ten minutes before a call. Both count as operationalized when the answer comes from the same complete, trusted context every time, for everyone on the team, rather than from whatever one person’s connectors happened to pull that day.

Plenty of teams have a pre-call brief or a post-call CRM update running, and that’s the right place to start. The test is whether it meets all three conditions. If the brief runs only for the rep who built it, or nobody can say what data it read, it’s a useful workflow and not an operationalized one.

Those examples are also a small corner of the work. When I ask a revenue leader what they’d hand to AI, they usually name three or four things, mostly around calls. But think about everything a revenue org does daily, weekly, monthly, and quarterly. There’s how you sell (Sales Execution): call prep, follow-ups, CRM updates, deal reviews, handoffs. And there’s how you run sales (Operating Rhythm): the pipeline review, the forecast, the leadership brief, coaching, win-loss, objection trends. Lay it all out and it’s dozens of jobs to be done, across sellers, CSMs, SDRs, RevOps, and sales leadership. Operationalizing means handing those jobs to AI one at a time, and when it’s working, each one is easier to hand over than the one before it.

Hurdles to fully operationalizing AI

We’ve talked to a lot of revenue teams about this, and the same six hurdles come up again and again. Here they are, with what each one costs a team.

No strategy on what to build. Most teams got licenses to Claude or ChatGPT and a mandate “use AI”, and skipped the step of deciding which jobs AI should take on first and who owns each one. One company told us their rollout to reps came with a single instruction, which was to use it for everything, so what got built was whatever someone happened to be interested in. The cost is spread across one-off experiments, three people solving the same problem three different ways, and a leadership team with no good answer for how the team is using AI.

The second workflow is as hard as the first. The idea carries over from the first workflow to the second, but the context doesn’t, so each new agent assembles the customer picture from scratch on every run: unifying records from the CRM, calls, calendar, and email, mapping activities, building timelines. That shows up as slow runs, a token bill that grows with each workflow because each one redoes the same assembly, and answers that don’t match: run the analysis on Monday and again on Tuesday, and the account has changed but the answer hasn’t.

Workflows break. The workflow ran on Tuesday, failed on Wednesday, and you found out the following Monday when the forecast report was a week old. Homegrown setups rarely have alerting, and neither do connectors on their own, so the job that was scheduled under one person’s account dies quietly when a rate limit hits or one of the six connectors it depends on breaks and the whole workflow stops. The failure is usually silent, and silent failures surface at the worst possible time.

It looks right, but it’s wrong. Most teams have yet to hit this one, because you only find it by checking (more on this below). One team looked into an analysis Claude had produced for them and found it had read five calls, when there were more than thirty with that customer. The output didn’t say it had looked at five; it presented itself as the answer. If you don’t know what data was behind your AI’s last answer, you have no way of knowing whether this is already happening to you.

Adoption is still hard. This was a problem before AI, and it’s a bigger problem now because agents produce far more output than people did. A link dropped in a Slack channel counts as delivery, and it still gets scrolled past. What gets used is output that shows up inside the work itself: the brief on the calendar invite, the risk flag on the opportunity record, the summary in the thread where the deal is already being discussed. One leader we spoke with shared that there wasn’t a single AI artifact his team used daily.

Brittle dependencies. Most homegrown setups run through one person: their account, their logins, and their understanding of how it’s wired. One revenue leader we work with built his own CRO brief out of a custom Salesforce MCP, an automation tool, a file watcher, and a laptop kept awake overnight, with a scheduled job to restart the VPN at 3am. It ran about 70 percent of the time, and on the mornings it failed, the leadership channel in Teams got last week’s brief instead of this week’s. If he’s out for a week and the brief stops sending, the rest of the team doesn’t know how to fix it.

Where connectors stop being enough

Some teams are wiring up connectors, and connectors are good at what they’re designed for: one deal, one call, one seller, the data sitting in a single tool, and a person who can eyeball the answer. They stop being enough when the job needs the whole customer picture: several tools, several people’s records, and months of history. Now the model has to assemble that picture itself, on each run, from whatever each connector returns, and it only knows what came back. It tends to miss that the contact in the CRM and the voice on last week’s call are the same person, and it rarely flags the email thread or conversation in Slack it skipped.

Two more limits matter for team-wide work. Email and calendar connectors are tied to one person’s account, so when a leader asks an agent about a deal, the agent reads the leader’s inbox and not the seller’s, and the thread that answers the question is usually in the seller’s. And a connector answers from whatever is in that one tool right now, so a question about how a deal got to where it is leans on whatever history that tool happens to keep, with nothing carrying over from the last run.

The customer context problem

Most of the hurdles above trace back to one thing. Customer context.

The models are not the issue, and neither are the harnesses. What they lack is any idea who your customers are, who your team is, or how you sell. The real record of a customer is spread across calls, email, calendar, Slack or Teams, and support tickets. The CRM holds a secondhand version of it, written up after the fact. So each time an agent runs, it has to reconstruct that record before it can start, and each reconstruction is partial, expensive, and a little different from the last one. That’s why the second workflow isn’t easier, why the answer is sometimes wrong, and why one broken connector takes the whole job down.

The fix is to build the record once, keep it current, and let each agent read from the same one, which is what a context layer is. When the context is already there, the agent does the job instead of doing the archaeology first. Brendan went deeper on why every revenue team needs a context layer in his piece on The Signal.

The accuracy point is hard to make in a demo, because a wrong answer looks exactly like a right one. So we measured it. We gave the same model the same 23 questions about five real accounts, with the same instructions, once through connectors and once through Clearskies. The stack was HubSpot, Scratchpad call transcripts, and Google Workspace. Each question was asked three times in each setup, 138 answers in all, and a separate model graded every answer against an answer key built from the source systems, with the system names blanked out, so it couldn’t favor either side.

Through connectors, the model got 43 percent of the questions fully right. Through Clearskies, it got 65 percent fully right. That’s 50 percent more correct answers from the same model on the same questions, 40 percent fewer invented facts, and the same cost per answer, with fewer tool calls to get there. Clearskies was ahead even on questions that only needed the CRM and calls, where connectors could see everything. The gap opened wide on questions that touched email or calendar, which is most of what a leader asks about a relationship: who’s been on the calls, whether the proposal went out before or after the last conversation, which meetings have no follow-up. There, Clearskies was fully right nearly twice as often. And on the measure this article is about, answers that look right and aren’t, the wrong-answer rate fell by three quarters across the whole test.

The reason is structural. Gmail and Calendar connectors are per-user, so there isn’t a way to give a model the whole team’s mail and meetings through them. The model reads one seat, and when the thread it needs is in someone else’s inbox, it doesn’t know the thread exists, so it guesses or confidently answers a narrower question than the one you asked. Clearskies syncs every user’s mail and calendar into one record, already matched to the account, so the thread is there before the question is. The model wasn’t smarter in one case than the other. It could see more.

And 65 percent is where the layer is today, not where it stops. We use this test to find what the context layer still misses and close it, so the number moves up with each release while the model and the questions stay the same. That’s the real case for a context layer over the alternatives. Build your own and you climb that curve yourself, release by release. Use connectors alone and the model is capped at what one seat in one tool can see. Use a layer that’s measured and improved on a schedule, and your agents get more accurate without anyone on your team touching them.

Where to start

Start with the context, since everything else gets easier once it’s in place. There are two ways to get there.

You can build it yourself. Vercel’s team has talked about building theirs, and it works, but it takes real data engineering to stand up and more to maintain as your sources and your business change. If you have the engineers and this is strategic for you, this is a legitimate path.

Or you can use one that’s already built. I’m biased here, because this is what we make at Clearskies, and the job it does is to give your agents the right customer context and the tools to take on real revenue work. You connect your sources once, and from then on you build from whatever AI provider you already use. The agents run for the whole team rather than in one person’s account, and the context works with whatever model you point at it, so when the next one comes out you connect it instead of starting over.

That last part isn’t hypothetical. The week Grok Bot came out, we connected it to our customer context in a few minutes, and it started proactively flagging deals to us without being asked.

What it looks like

Setting up the context layer takes about thirty seconds of your attention. You connect the CRM, the call recorder or recorders (plenty of teams have more than one), email, calendar, and Slack, and the matching happens in the background: identities resolved, each activity attached to the right account, one timeline per customer. What you end up with is one connection you can point any AI at, so you point three at it: Claude, ChatGPT, and Grok Bot. We put together this short demo to show how it comes together. The demo itself was made with Clearskies, Grok Bot, ElevenLabs, and a few design tools our team uses.

Clearskies demo

If you want to try it on your own data, start at app.clearskies.cc, or book a walkthrough and we’ll do it with you.

Pouyan Salehi is the cofounder and CEO of Clearskies, The Context Layer for Revenue. He previously cofounded Scratchpad and PersistIQ. If you’re working through this at your own company, connect with him on LinkedIn. He’s happy to compare notes.

Thanks again to Pouyan (and Nate!) for today’s article. Like I said at the top, I think this piece is going to help a lot of revenue teams. And this topic (the context layer as a P0 to operationalize AI for revenue teams) will become more important over time.

As always, thank you for your attention and trust. I do not take it for granted.

See you Friday for our GTM Weekly Round-Up,
Brendan 🫡

Subscribe now

Thanks for reading this hand-rolled, pesticide-free (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for reps and agents.

Rox → Revenue Agents for the Global 2000.

Sumble → High precision GTM data + intelligence.

Terret → The answer-to-action engine for revenue teams.

Happy Friday! 🌞

We’re back with another edition of the GTM Weekly Round-up.

Let’s dive in.

I’ll be in San Francisco next week for Sculpt.

Sculpt is Clay’s GTM conference (Thursday, Oct 8, Pier 48). They’re 95% sold out (2,000 tickets), but gave me a code for readers of The Signal.

Purchase here, and use THESIGNAL-VIP at checkout for 50% off.

I’ll be doing content at Sculpt. Roaming around with a videographer, doing mini-interviews of attendees. So, if you see me, come say hi and let me ask you a couple of questions! :)

The Signal + Sumble at Fieldwork Brewery

I’m co-hosting an event with Sumble on Thursday night at 7pm at Fieldwork Brewery, right across from Pier 48.

There are no panels and no pitches, just GTM nerds comparing notes on what’s working, and playing some fun yard games. It’s capped at 75 GTM operators. We’re already close to capacity, but reply to this email if you want to join.

Excited to see folks IRL next week!

Weekly GTM Round-up:

• Another week, another thing to keep up with. This week, it’s Jev. Here’s a great overview+example by my friend, Andreas Wernicke:

  

• Fun little prompt to try:

  

• Meta is going into Enterprise (all roads lead back to B2B SaaS, baby). And they hired the former CEO of MongoDB to run it. Crazy to see…

  

• Clarify launched Artifacts this week. Build anything you need to win the deal: reps can build one-pagers, proposals, mutual action plans, decks, and deal rooms right inside the CRM, with the deal’s emails, meetings, and history already loaded as context.

• I’ve been putting out some clips from an event I participated in last month, hosted by Rox (alongside presenters from XBOW, Clay, and OpenAI). Here’s a compilation of what people told me is not changing in the AI era:

  

• Great email framework:

  

• Chart of the week:

  

Alright, that’s it for this week.

I’m writing from my bed right now, after getting sick from my two kids who had Croup. So, I’ll leave you with this quote:

A healthy person has a thousand wishes, but a sick person has only one.

Enjoy your health!

And as always, thank you for your attention and trust. I do not take it for granted.

See you then,
Brendan 🫡

PS: If you liked today’s post, send it to one person who would enjoy it.

Subscribe now

Thanks for reading this free-range, non-GMO, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for reps and agents.

Rox → Revenue Agents for the Global 2000.

Sumble → High precision GTM data + intelligence.

Terret → The answer-to-action engine for revenue teams.

Happy Friday! 🌞

We’re back with another edition of the GTM Weekly Round-up: a (bite-sized) editorial plus a few links that are worth your time.

Let’s diveee right in.

Over the last two years, I have re-skilled in a more significant way than ever in my career. More than when I first learned what ‘SaaS’ meant, at the SF startup where I was the first employee and we grew to 100 employees in 3 years. More than when I become a SaaS founder and raised venture capital. Re-skilling at this stage in my career is really hard and scary and tiring and… FUN. It’s the most fun I’ve had in at least five years. And I want to argue why you should choose the white pill too.

Today’s post is not to be alarmist. I have no “AI course” to sell you.

Also, in all honesty, I’m writing this just as much for myself. Because, I still have a long way to go on this journey of re-skilling myself. I feel behind, even though I’ve invested 10s of hours each week for the last 100 (!!!) weeks.

For anyone who is going to retire in the next 10 years, they probably don’t need to learn how to adapt in the AI era. For anyone who is in their first 10 years of their career, they’re probably learning how to use AI without questioning if they ‘need’ to. I’m somewhere in the middle, like many of you reading. Which means, I have to actively choose to re-skill myself.

This tweet sums up the fork in the road right now:

Aviel goes on to say, in another post:

You are not mid or late-career, you are just getting started.

If you can stomach that I have some REALLY good news for you. The future looks awesome and you're going to do something great.

I don’t want to act out of fear (like “learn AI or you’ll fade into irrelevance!”).

Instead, I want to act out of excitement. Out of curiosity. Out of optimism!

I’m choosing to take the white pill.

That doesn't mean pretending the disruption isn't real (I subscribe to rational optimism). It means believing that what comes next can be better than what came before. AI is going to automate parts of our jobs. Some of those will be tedious tasks we're happy to drop. Others will be things we've spent years getting good at, maybe even things we love doing. DHH's take on coding is a useful way to think about it as it starts to hit go-to-market.

He said he’s moving from being a professional programmer to being a professional maker. I think something similar is about to happen in go-to-market. The job isn't disappearing. The job is changing. The people who embrace that change will move up the stack, spending less time on manual execution and more on judgment, creativity, strategy, relationships, and orchestrating AI to accomplish things that previously required entire teams. You can look at that future and mourn what's being lost. Or you can get excited about what's being gained. I'm choosing the latter.

Please watch this 2-min clip from this week, where DHH declared the end of hand-writing code at Rails World 2026:

AI has transformed software engineering.

AI has transformed customer support.

And now, AI is in the process of transforming go-to-market.

Practical examples if you’re in go-to-market today

• CRO: build reports (or a personal “RevOS”) in Claude Code like Tim.

• Growth/GTME: build a custom harness+UI like Cursor (with ChatGTM) or XBOW’s internal GTM system.

• RevOps: build an agent repo in GitHub like Nikko from Hightouch.

Be glad you had the opportunity to “chisel that prospect email by hand.” And what a privilege to have been there when we did it all by hand. And now, to be here, at the exact moment where we switch over to the new way of working.

Choose the white pill.

Weekly GTM Round-up:

• Niroshan, CRO of XBOW ($1B security company started in 2022) on how they’re building an AI-native revenue org. We covered it on Tuesday: How XBOW’s team built one of the most sophisticated internal GTM systems I’ve seen.

  

• Trigify (a signal platform focused on social engagement) announced it’s joining HubSpot. The second signal/intent provider that HubSpot has picked up (Warmly being the other one, a few months ago). Consolidation szn continues.

• Josh Braun is one of my favorite voices on outbound/messaging/sales. This week he reminded me why I like his framing so much:

  

• Jacob has been talking about context and taste for a long time now. I think many are going to realize the importance of these things (and tools like Clearskies) in the next year or so.

  

• My friend, Andrew McGuire, recently joined Navan to continue up-leveling their revenue engine. He’s hiring a Senior GTM Engineer. My favorite line from the jd: Implement the controls required for production agents, including evaluations, human review, observability, error handling, permissions, auditability, sensitive-data safeguards, and rollback paths.

  Reach out to Andrew and let him know I sent you.

• Jevon’s paradox strikes again!

  

• This was my favorite thing I read this week (it’s a super easy ~5 min read) Moats & the Barbell-ification of Software, by Mike Vernal of Conviction.

  

  The general thesis is that software moats are shifting, and you either need to be the big player in a space (doing everything, aka compound startup) or be a small company by design.

• I am already seeing this with CROs like Niroshan (XBOW), Tim (Hatch), Kyle (Owner), and Stevie (Vanta) living in the future (watch DHH’s full keynote here).

Alright, that’s it for this week. As always, thank you for your attention and trust. I do not take it for granted.

Tuesday’s post is on the swim lanes between RevOps and GTM Engineering. It should be spicy.

See you then,
Brendan 🫡

PS: If you liked today’s post, send it to one person who would enjoy it.

Subscribe now

Thanks for reading this hand-poured, 100% organic (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for reps and agents.

Rox → Revenue Agents for the Global 2000.

Sumble → High precision GTM data + intelligence.

Terret → The answer-to-action engine for revenue teams.

​Hey y’all!

After publishing Inside “ChatGTM”: Cursor’s Internal Sales AI Used by their 400+ Sales Org, I got a message on LinkedIn from a guy named Bruno, at a company I didn’t recognize: XBOW. My quick research showed me that XBOW is legit. XBOW’s AI hacker reached #1 on HackerOne’s leaderboard, the first time a machine outranked human bug hunters. Their founder is Oege de Moor, who created GitHub Copilot and GitHub Advanced Security. They were founded in January 2024 and have already raised $272M to date, most recently at a $1B+ valuation. Anyway, Bruno’s message to me said: “We have an internal tool that goes across the funnel (we use a bowtie model) and has a UI that is similar to Cursor’s and then there are all the backend jobs and a Slack Bot that complements it. It has been a game changer for our GTM teams.” I immediately set up a call to learn more.

Bruno Leardine (Director of GTM Engineering) also brought his CRO (Niroshan Rajadurai) and Head of RevOps (Justin Miller) to the call. One of the first things they told me is that they had decided to build a truly AI-native revenue org, based on their prior experience at GitHub. And they were going to build their revenue org the same way a modern product org runs: planning in sprints, building their tools in-house, and staying on the leading edge of agentic tools.

The tool they’ve built is one of the most sophisticated internal GTM systems I’ve seen. The first version was built by just Bruno, Niroshan, and Justin. And they were kind enough to give The Signal readers a behind-the-scenes look at:

• Their unique approach to building

• The most interesting capabilities of their in-house tool

• How they built the whole system with just 3 people

• How this compares to what I’m seeing in the industry

Plus, I’ll share how their approach ties into a big theme I’m seeing across the best GTM teams.

Let’s get into it.

The XBOW team’s unique approach to building

Most GTM teams don’t operate like a Product team. But this team has an atypical perspective based on their background at GitHub. Plus, they had specific constraints: as a cybersecurity company, XBOW can’t use the same off-the-shelf LLM products that others can, because they can’t just hand a third-party tool company-wide access to their Drive and Slack. So they built everything a bit differently.

1. Foundation before agents.

Justin (Head of RevOps) spent the first 6 months getting a standard tech stack in place: ZoomInfo, Salesforce, Gong, and others. But, eventually, they cut their sales stack from twelve tools down to just five (tools like Rox, Clay, and Sumble) and got the data model right. They also put in a lot of work with the field on where all the data should live. That was all before they even started building any agents. If you bolt an agent onto a messy stack, you’re going to get poor results.

2. Develop everything through rapid experimentation.

Justin told me they started experimenting, not only with what they were building internally, but also in their choice of partners. Working with nimble startups helped them experiment faster as co-builders / design partners. Bruno said: “It was clear to me that Rox was thinking about prospecting six to twelve months ahead, and that’s a burden I don’t need to have. So I can come and learn and be advised on the topic, and then go figure out other parts of the business that I don’t have a partner looking into.” These tools have become more popular recently (back then, they weren’t as well established), but the XBOW team knew they wanted to move away from the incumbent sales tech providers to try out some tools that could really help them level up. So they tested to see what worked and found some real winners.

3. Centralize the org’s knowledge.

They decided to centralize knowledge and context so the tool “knows the business cold” and sits on the source of the data. As Director of GTM Engineering, Bruno’s rule for every integration is to go to the raw source (the Slack API directly, for instance), with no middle layer.

Pro tip from Bruno:

The principle behind this is that the goal is to build agents that know what to verify and when reality has changed. Correctness of information is not a function of documenting everything, all the time. It comes from validation systems that help agents reconcile what is written, what is said, and what is actually practiced. I spent a lot of time trying to get this right at the beginning.

4. Cover the whole bow tie.

Both Justin and Niroshan (CRO) called out that they didn’t want to just stop at top-of-funnel. Their system runs “the full bow tie.” This is Jacco van der Kooij’s model that doesn’t just cover awareness through acquisition (like traditional marketing funnels), but also includes renewal and expansion. This matches something I believe more every week: the lines between sales, CS, and support are blurring, and a unifying layer across the whole customer lifecycle is becoming the obvious architecture when building a modern revenue engine.

The actual in-house tool the XBOW team built

Read more

Subscribe now

Thanks for reading this hand-rolled, 100% organic (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for reps and agents.

Rox → Revenue Agents for the Global 2000.

Sumble → High precision GTM data + intelligence.

Terret → The answer-to-action engine for revenue teams.

Hey, y’all! 👋

We’re back with another edition of the GTM Weekly Round-up: a bite-sized editorial plus a few links that are worth your time.

Let’s dive in.

I’ve been thinking about a question that a Product Manager at a company that will remain unnamed (but has a conference this week) asked me recently: “What do you think of [redacted], our agent?” I didn’t have the heart to tell them ‘I’ve never used your agent’ so I replied with generic feedback: I don’t want to use an agent inside the walls of a SaaS platform. Instead, I want my agent to use your software.

This post sums up my thinking:

I don’t want to use your agent inside your platform because you don’t have access to all of my context.

Your agents aren’t bad (in fact, I’m sure they’re great! These are smart people/teams building them). The problem is, your agent doesn’t have my context. It doesn’t have my Skills, personal preferences, Memory, access to other tools that my AI has access to (like email, slack, google docs, etc) or files on my computer.

Don’t build a new navigation system for a car, build CarPlay.

Let’s unpack this analogy. You could build a perfectly good nav system for a car, but it doesn’t know my home address, numbers of people I may call while driving, or what I was listening to this morning. Which is why everyone just plugs in their phone. The car’s job isn’t to be smarter than your phone; it’s to be the best possible screen for it. SaaS vendors are building the in-dash nav when they should be building for CarPlay.

By the way, the car still has context that your phone never will, like tire pressure, gas/charge left, check engine lights, etc. And the newest CarPlay pulls exactly that data in. The vehicle’s data flows to the driver’s platform instead of being walled off. The automakers betting on a walled garden are building a smarter dashboard to keep your phone out. I think the winners will be the ones who pipe their data into your system.

Example: Eric Nowoslawski used Grok Bot to build a Clay table via their CLI (you can watch a 2-minute clip here; from a recent episode of The Signal’s Live Show). This is a perfect example of Clay being okay with Eric having lots of context in his own systems, and using those to build inside their product in a more informed (context-aware) way. This creates a much better outcome.

UI/UX is changing (adapt or die).

There is a growing list of ways users now expect to interact with SaaS products (in addition to the traditional web application): inside chat interfaces like ChatGPT, Claude, etc, via MCP/API/CLI, Slack bots, Grok Bot, computer use. It’s exhausting, but necessary to build for users in 2026.

As Aurelian put it:

As a builder, you need to build for this new reality.

As a user, you should experiment with all these new surface areas.

As a seller, you need to position your product based on your buyer’s desires.

So much is changing so fast. It’s both exhilarating and exhausting. I’m just trying to have fun and enjoy the (wild) ride.

Weekly GTM Round-up:

• The most important read in AI/tech-land this week: We Must Pace the Frontier. Dario’s article even had Sam and Elon retweet it in agreement! Meanwhile…

  

• I’ve said this many times, and will continue to beat this drum: Sales is an AI-proof career. I argued for it in last week’s editorial (The best sales reps are problem-solvers) saying: “I’m bullish on sellers in the AI era. As more of knowledge work gets slurped into the labs’ models, and surrounding ecosystem, the value of human-led problem-solving is going to become more valuable, not less.” First Round published an amazing article this week, with the same thesis. Read the full article here: The Craft of Sales.

  

• My friend Nate, at Perplexity, is hiring a Sales Systems Engineer, Enterprise Operations, to own the technical layer underneath their enterprise sales motion. “This person will run CPQ, account and lead scoring, data orchestration, and the integrations that connect Salesforce, Snowflake, and the rest of our GTM stack.”

• Colossus dropped another piece of art this week, a piece on Zuck: A journey to the heart of history’s largest nonterritorial empire (it’s also on Spotify).

• Crazy/cool to see the companies building at the bleeding edge continue to innovate, and disrupt even themselves. Great 2-minute video by the legend, Rob Cook:

  

• The debate rages on…

  

• In honor of Dreamforce this week, I’ll end with a little montage of Marc Benioff bangers:

  

  

  

  Last, but not least, did you know: Marc came up with the idea for Salesforce while swimming with a pod of dolphins off the coast of Hawaii?

Alright, that’s it for this week. Have a great weekend!

As always, thank you for your attention and trust. I do not take it for granted.

See you next week,
Brendan 🫡

PS: If you liked today’s post, send it to one person who would enjoy it.

Subscribe now

Thanks for reading this hand-picked, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for reps and agents.

Rox → Revenue Agents for the Global 2000.

Sumble → Buying signals from tech stacks, people data, & active projects.

Terret → The answer-to-action engine for revenue teams.

​Come watch Eric Nowolawski build and launch an outbound campaign live (end-to-end) using Grok Bot and the Clay CLI. This Wednesday (Sep 16th) at 10am PST. Register here (if you can’t make it live, but register, I’ll send you the recording+recap afterwards).

I stumbled upon a year-old podcast episode of Jason Lemkin on Lenny’s podcast. The whole thing is worth listening to, but one idea stuck out to me and I wanted to highlight it today, before jumping into the Friday round-up.

The idea is something I believe deeply: the best sales reps are problem solvers.

Jason said this in the podcast episode:

Here’s the mistake that 99% of founders and sales reps make.

We’re not really selling in B2B. We’re solving problems.

Our job as sales reps in SaaS is to not sell a used car. We’re selling a Tesla Model 3 performance. It has competition. They might not need it this week, but it’s pretty darn good. “Let me help you get you into that Model 3 performance today. I’ve even got a special discount for the end of this month. Let me just help you. I’ve spent four calls answering all your questions and I’ve explained to you all the things and why the supercharging network is better than the regular one that doesn’t really work at the charger near your house. I’ve gone on Google and I’ve seen there’s no charging network near your house. There’s only superchargers.”

That’s the job of a SaaS seller because we’re not selling commodities.

I used to say the best reps are “sherpas” or “guides.” They help a buyer solve a problem, either with their software (or recommending another/better path if there is not a fit). They build trust, and have valuable expertise.

I was catching up with a founder recently, who is building in the sales space. And at one point he said something like “I mean, you know, salespeople are manipulative.” It wasn’t offensive, as much as it was shocking, how little he knew about the profession. But, that’s the general consensus still, even in B2B—that salespeople are mere manipulators that get paid a lot of money for playing golf in a vest during the day and put on a suit for their steak dinner that night. This is so obviously a misconception about the best sellers. They are curious, smart, problem solvers. And AI cannot automate them away.

To be a great problem solver, you have to be a great researcher/investigator (this is why “discovery” in sales is so important).

It's kind of ridiculous, but I actually like that some call recording tools show talk time percentage live on a call for a rep to see. Mine even has a BIG YELLOW BUTTON that appears when I talk for too long, saying “Monologue!”.

Ideally, a seller is speaking well under 50% of the time on a sales call.

My goal as a seller was always to pull, not push. “Pull” (information), not “push” (or, pitch, my product). In other words, maniacal focus on discovery. Which is downstream of curiosity, which is downstream of problem-solving.

It is only once you have this information that you can even assess if (or how) you might be able to solve their pain/problems (either with your solution, or recommending another path for them).

I’m bullish on sellers in the AI era. As more of knowledge work gets slurped into the labs’ models, and surrounding ecosystem, the value of human-led problem-solving is going to become more valuable, not less. It’s a great time to be a creative, thoughtful problem-solver. It’s a great time to be in sales.

Weekly GTM Round-up:

• My friend Eric Linssen runs Demand Collective, a newsletter and vetted slack community for Demand Gen practitioners. He’s hosting Demand Day: “a virtual summit with 9, 20-min sessions from real demand marketers sharing what’s working for them right now.”

  Save your spot! (Sep 24th at 10am PST)

• (ICYMI) Tuesday’s post was with a legendary revenue leader (who I used to compete with at the company I co-founded, Groundswell); I think Tim is the prototypical future CRO.

  Here’s my summary if you don’t want to read the whole thing (but you should read the whole thing :)).

  

• GTM Engineer role at Sequen (they announced a $90M Series B this week).

  I worked with Tim, their CRO, on a data/signal-based selling project last year. He’s smart and cool :) and I’m very bullish on what they’re building (they have crazy customers already, like Priceline, Wayfair, etc). There’s a ton of upside/opportunity. My favorite line from the job description: “Help shape how Sequen builds its GTM engine — the tooling, plays, and process are still being written, and you’ll hold the pen.”

• Miro was acquired by Bending Spoons for $1.35B this week (they also own: Airtable, Eventbrite, Vimeo, AOL, and more). Miro’s peak valuation was $17.5B, so it was bought at a 92% discount. I liked Jason Lemkin’s (one of the godfathers of saas/sales) take on it:

  

• Great, tactical read by Noah Adelestein of thegtmengineer.ai:

  How Lovable built an AI-native sales intelligence stack while scaling from a handful of reps to a global enterprise GTM org.

• Elon tweeting about sales (tech) was not on my bingo card for this year (see! “GTM Twitter” is totally going to become a thing! heh)…

  

• Clay announced their Series D at a $7.1B valuation. I commented on Varun’s announcement post saying “ser i thought claude code replaced yall?” (obviously, as a joke). But in reality, this raise is another datapoint showing Clay is still a critical piece of the AI-native GTM tech stack, and clearly their metrics internally show that if investors are still willing to pile money into the business.

  [Disclaimer: I own zero equity in Clay, but they do sponsor The Signal. Fwiw, I don’t have any equity in any gtm tech companies, or referral agreements; when it’s a sponsored post I say that explicitly.]

  With that said, here are two charts I put together (wild to see):

  

• For anyone who missed the tweet that broke the internet this week, here it is; 166M impressions is bonkers (I haven’t fully formed a strong opinion, but I’ll say this: we should be kind, gracious, open-minded and work together to build a wonderful future for humanity)

  

• Alright, that’s it. Enjoy the weekend!

  

As always, thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

PS: If you liked today’s post, send it to one person who would enjoy it.

Subscribe now

Thanks for reading this hand-rolled, pesticide-free, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → Revenue infrastructure for humans and agents.

Rox → Revenue Agents for the Global 2000.

Sumble → Buying signals from tech stacks, people data, & active projects.

Terret → The answer-to-action engine for revenue teams.

I used to compete directly with Tim Geisenheimer (he was running Correlated, while I was building Groundswell, both in the crowded “product-led sales”/PLG CRM space). And Tim was, by far, the best salesperson of the batch of ~20 competitors. We’ve stayed in touch, and over the last few years, I’ve watched Tim successfully build a killer Revenue team as CRO of Hatch, ultimately leading to an acquisition to Yelp. He recently showed me some of the stuff he’s personally building, and was kind enough to share it with us today (he also shares his tips for any revenue leader who wants to go from AI-dabbler to Claude Code/Codex/Cursor-pilled).

Today, Tim’s 100+ person revenue org runs downstream of Tim’s Claude Code sessions. Across 8 custom internal apps, 20 AI skills, and a whole system of self-reinforcing tools, he’s pushed his org to level up how they source, track, and close deals.

Tim opened a terminal for the first time in his life over winter break, just 8 months ago. Opus 4.5 had just dropped and he was spending a little too much time on X, and he got curious. Kids asleep, movie on, laptop open, while his wife made fun of him (...I’ve been there).

A few months later, Hatch (a top AI lead management platform) was acquired by Yelp for $300M. At the time, Hatch was doing $25M ARR and growing 70%. Things have only accelerated from there: since the close, his revenue org has grown from roughly 17 sellers to about 100. Tim says that Claude is a big part of what made all of this possible.

I’ve been on the hunt for GTM leaders at *scale companies (*dozens or hundreds of reps, complex gtm systems, and several products+personas, etc.) who are hands-on-keyboard with this stuff, and the list is short. Last month, I broke down how Nikko Georgantonis, Hightouch’s RevOps leader, runs their revenue engine on GitHub. I called Kyle Norton the most AI-pilled CRO in SaaS. Tim is coming for the belt.

Tim walked me through the whole machine he built at Hatch. Here’s what we cover in this article:

• How Tim got started

• How his system is actually structured

• The first two things Tim built

• What Tim and his team are building next

• Where Revenue leaders should start with Claude Code

• Takeaways

Alright, let’s get into it.

How Tim got started

The entry point was a Teresa Torres video when Tim was scrolling X on a Saturday night. Teresa tweeted that she manages her whole life with Obsidian and Claude Code, and Tim figured he could build a chief of staff on top of the same setup. He pulled in his calendar, meeting notes, and Slack. From there, he caught the bug…

I just got addicted. I started building things, messing around, learning how far I could go.

The transition from personal hacking to building a real system for his day job happened fast—out of necessity. Right as Tim started tinkering, the Yelp acquisition closed and the revenue org started scaling from ~17 sellers toward 100 people, which created lots of scaling problems that needed to be answered (and fast). How do we ramp reps faster? Who needs coaching, and on what specific things? Why did bookings dip last month in xyz segment? Where will this month actually land?

Tim told me the old way of doing things would have been to procure a bunch of software to solve these problems. But then it hit him… “I bet I can point Claude at a bunch of these.”

For the record, Tim does not know how to code. Keep that in mind for everything that follows.

How his system is actually structured

Tim can start a fresh session and ask any question he wants. So, for example, he could type in (or Superwhisper) “2 weeks ago we were doing a closed-loss analysis, pull it up and turn it into 3 slides,” and it does. Here’s how his system is able to answer any question he throws at it:

On the data side, MCP connectors and APIs feed Claude Code from HubSpot (pipeline and deals), ChartMogul (MRR and churn), Attention.com (thousands of transcripts), BigQuery (product usage), plus Slack, email, and meetings.

A system like this only works if you feed it (and maintain) the right context. Tim added 18 curated context files describing how Hatch goes to market, 43 memory files of gotchas and decisions, and (one of my favorite artifacts in the whole system) a “Sales Bible” distilled from 409 calls of Tim’s #1 rep. He studied what makes Hatch’s best seller good and wrote it into the files every agent reads. That tacit knowledge is gold.

It all lives in GitHub. “GitHub is the memory,” Tim says. “Commits are just different sessions. Anything I work on gets committed back. I don’t open GitHub. It’s just there.”

And Clay sits under the hood of it all. Enrichment runs in Clay and lands as HubSpot custom properties, so Claude reads it through the CRM. Tim has also started poking at Clay’s new CLI and API.

The system turns a bunch of little tasks into automations.

What used to be my Sunday night is now a single automation.

Daily. Upsell signals get scanned overnight and posted to Slack by rep at 7am. Every closed-won deal gets a CS handoff doc written from its own call history, hourly. At 5pm a headless agent sweeps Slack, email, and meetings into Tim’s task list and DMs him the digest.

Weekly. Rep, manager, and SDR scorecards roll up into his Monday leadership brief. A midweek deal-level forecast ships with risk scores and the top-15 must-win pipeline list. The Friday sales all-hands deck refreshes itself from live data.

Monthly. On the 20th, a scheduled agent emails Tim that it’s time to run the end-of-month deal push. At month end, a “path to close today” gets written for every late-stage deal (from the CRM plus the deal’s own calls), and an MRR decomposition explains what grew, what churned, and why, customer by customer.

The first two things Tim built

Read more

Subscribe now

Thanks for reading this hand-picked, pesticide-free, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → ML-powered data and account intelligence for AI-native GTM.

Terret → The answer-to-action engine for revenue teams.

Howdy y’all! 👋

Back with another Friday round-up: a bite-sized editorial by yours truly followed by a few links that are worth your time.

Let’s get into it.

Salesforce’s CEO, Matthew McConaughey, announced “Claudeforce” last week. It’s an integration between Salesforce and Anthropic/Claude (Salesforce owns 1% of Anthropic; turned $50M into $1B…so far; not bad!).

Okay, I know McConaughey is not Salesforce’s CEO (Uncle Benioff is). And Unc has been talking about going headless since April (impressively early, honestly) and this may seem like simply an extension of that vision. But, I think it’s a bigger tell.

Here’s the announcement video:

Here’s what they say in the launch video, in reference to the SaaSpocalypse:

It is not the end of software. It’s the end of software that makes humans do all the work.

So what’s replacing it? Software that can actually do.

Software stops becoming a destination, it starts becoming a teammate. Not another place to go. A presence right there with you. In the flow of work. At the moment work is happening.

He’s talking about Claude. Not Salesforce. People are no longer working out of Salesforce. Of course, if you talk to anyone in go-to-market, this has been the case for a decade. But now, they’re admitting it.

The launch of Claudeforce shows us four distinct lessons:

1. You have to meet reps where they’re actually doing the work today: in LLMs (where they have their context/preferences ‘saved’). In other words, work is happening in the LLM. Not the CRM.

2. With that said, sources of truth are still valuable in the AI era (not being vibe-coded away)—one could argue, more valuable.

3. The intelligence layer is increasingly moving out of your software stack and into the LLM (or custom harness, alongside models).

4. Software is moving from being a place of recording actions, to a place that takes actions (eg: agents). Here’s the line from the announcement video:

   Systems that don’t just record the business, but help run it. This is where software becomes action. This is where decisions become outcomes.

I’m not saying I think agentforce/claudeforce is going to be the biggest winner (maybe… though, I’m skeptical, and honestly haven’t heard a single person raving about using it). But I do think that a lot of people should be taking this as seriously as Uncle Benioff is. Whether you’re using software as a seller, buying software as a RevOps person, building something in-house as a GTM Engineer, or starting a company as a founder, this is a new paradigm. And you have to build in a different way.

I’m very bullish on companies building in this new way—Clarify is a great example; they’re building an autonomous CRM—where founders are okay admitting that work is evolving. They’re not trying to be the the cockpit where reps work 8-hours a day. That’s not how work happens anymore. You can’t jam an LLM into your product. Instead, you have to figure out how to jam your product into the LLMs. And I realize this is not easy… from a technical perspective (API/MCP/CLI), and/or from a business perspective (eg: it impacts pricing strategy, margins, marketing, account management, everything).

I certainly don’t have the answer. But I do know that the launch of Claudeforce is a warning shot to anyone in GTM. This is the beginning of a new way of working with software. One where agents and humans collaborate. The UI/UX changes. And we have the opportunity to rethink much of what we’ve held on as ‘true’ for the last decade. What a time to be in tech-land!

Other corners of the internet worth exploring this week:

• OAI dropped GPT-6 Astra, scoring a 99.9% on ARC-AGI 3 which is nerdspeak for what they later said about the model: “this is the start of the AGI era.” Sheesh.

• Anthropic is trying to “claudify” their go-to-market motion:

  

  So basically a GTM Engineer on steroids. If even Anthropic is hiring this role, every company will. Also… could this be a step towards the application layer (eg: building gtm tech that they commercialize? probably not, but I’ll be watching this closely!).

• NVIDIA acquired Hugging Face (a host for open-source AI models) for $12.9B (apparently an easter egg in the exact dollar amount lol). Speaking of hosting…

• The Signal hosted our first IRL event this week at a Sauna & Cold Plunge spot here in Austin. We had 25 gtm operators nerding out over tacos and beers before sweating and shivering together.

• Eric Nowoslawski tweeted this: “I know this’ll be hard to believe, but I can’t stand the content on LinkedIn anymore and thinking about stopping and just doing YouTube. The content quality on LinkedIn (maybe even including mine) is so bad. I spend all my time here and on YouTube.” I responded (see below) and now I’m starting to think… we should actually make “GTM Twitter” a thing. Peep the tweet to see who to follow on X (there were a ton of great suggestions).

  

• The whole OpenAI/Hugging Face story in plain English: The Rise and Fall of Agent Civilizations, by Dwarkesh Patel. Long read (or listen), but fascinating.

• Oh, and Cybercabs launched (including here in Austin, completely taking over). Wild to see this happen.

• Last, but not least… a big thank you to Krista and Eric for sharing how they’re using Grok Bot for GTM on this week’s Live Show (follow both of them on X). Here are my biggest takeaways from the conversation/demos. Watch the full show:

That’s it for today. If you enjoyed this post, I’d be grateful if you send it to one person you think would also like it.

As always, thank you for your attention and trust. I do not take it for granted.

Have a great weekend, gtm folks!
–Brendan 🫡

PS: Next week’s article is about a CRO who is personally using Claude Code to run his 100+ org. It’s wild. See you then. :)

Subscribe now

Thanks for reading this hand-rolled, gluten-free, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → ML-powered data and account intelligence for AI-native GTM.

Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

I’m feeling energized after spending a few days in SF this week, for an event with Rox, OpenAI, Clay and XBOW, where I got to run some interviews :) I’ll share some of that content soon.

Today’s post explores the rise and fall of the SaaSpocalypse and the nuance of where we go from here. At the end of this post, I’m sharing a few links to things I’ve been exploring (tools, articles, podcasts) that I think are worth your time.

Alright, let’s get into it.

Six months ago, Anthropic shipped Claude Cowork (Jan 12). Notably, it wasn’t a new model. It was an agent for knowledge work.

Then, on January 30th, Ant shipped 11 Cowork plugins (sales, legal, finance, support, etc) and Skills as markdown files.

Four days later the S&P software index dropped 4%, wiping out over $285B in a day (ruh oh… that’s a lot of “churn”). By the end of that week, over $1T (yes, trillion) of software market cap evaporated. Jeffrey Favuzza said there was a “get me out” style sell-off. He went on to say the—now infamous—line: “We call it the SaaSpocalypse.”

The argument was logical. It went something like this: “anyone can vibe code something in a weekend and AI agents are the future.” Remember Satya Nadella’s SaaS eulogy in December 2024?

SaaS businesses are essentially CRUD databases with a bunch of business logic. The business logic is all going to these AI agents.

Even Chamath got back in the arena, launching a company promising to rebuild the enterprise stack at 80% of the features for 90% off. And Sam Altman said we were “entering the fast fashion era of SaaS very soon.” People cancelled a bunch of tools and vibe-coded replacements over a weekend.

Then, this week, this happened…

Turns out, what Bill McDermott (ServiceNow’s CEO) said two months ago was right:

The market thinks maybe I can do everything with a language model and build the software myself. But that’s not gonna happen.

Building software with LLMs is possible. Replacing mission-critical enterprise software at scale is a completely different story. Custom software costs more, takes longer, creates support challenges, and increases complexity. Companies like ServiceNow and Salesforce will integrate AI. They are not being replaced by it.

So maybe “source of truths” are safe. But… HubSpot had its worst day in a decade (down 19%) last week. And Datadog also dropped 19% (but is still up 72% on the year). And of course, Airtable sold to Bending Spoons at a discount (for $1.3B; previously valued at ~$12B).

So, it’s more complex than ‘all saas bad’ or ‘all saas good.’ Just last week, Atlassian also had its best day since the IPO (up 35%), Twilio popped 20%+, as did Cloudflare.

Guillermo Rauch (Vercel’s CEO) recently tweeted something that resonated with me:

The SaaSpocalypse is both understated and overstated. Over because the key systems of record and storage are still there (Salesforce, Snowflake, etc.)

Understated because the software we are generating is more beautiful, personalized, and crucially, fits our business problems better.

I have seen that “generating a first version of an app” is very different from “replacing a product people still want maintained.”

It’s a tale of two cities.

Spencer Skates (Amplitude’s CEO) summarized it well on TBPN:

…on SaaS, the key lesson: the software you’ve already built, that is no longer a moat. Because whether it’s someone vibe coding it, or someone going after it at a company, they can replicate it pretty quickly.

And so the new key moat is speed of innovation.

What the SaaSpocalypse has gotten right is - if you look at the median SaaS company, their innovation has actually slowed to a standstill. It’s crazy how little they ship in terms of net new products.

There’s only a moat if we’re able to deliver the most bleeding edge capability.

If 10 agents can do the work of 100 reps, you can’t sell 100 seats anymore, you can only sell 10. I like how Jason Lemkin put it: “SaaS is being starved, not killed.” And you could even take it a step further, as Tomasz Tunguz posed the question (way back in 2024, before anyone had a name for the crash): “What does a software seat mean when a human is no longer operating the software?”

That is a GTM problem.

Who is the user of SaaS in the AI era? The human or the agent? Both?

If your product only works when a human is clicking around, that is a problem. If your product is something an agent can call (API, CLI, MCP), you just inherited a new buyer. I wrote about this a couple months back: Your next buyer won’t be a human. In it, I wrote:

If your buyer is a person, you send cold emails. You run events. You build inbound funnels. You create content for humans to read, evaluate, and share internally.

If your buyer is an agent, none of those motions work the same way. You’re not going to send a cold email to an AI agent. But you are going to optimize for AEO (agent engine optimization, the next evolution of SEO). You are going to build support documentation that looks very different for an agent versus a person. You are going to build features and tooling designed for agent-first workflows rather than human-first workflows.

There isn’t a conclusion to the story yet. That’s the fun part of this moment in time! :)

We’ve never lived through something like this before. And if you’re you’re building, or taking products to market right now, there’s never been a more exciting time. I don’t know how it all unfolds. But, I do know everything is up for grabs. Everything is changing. Everything is computer AI.

It’s not about “get on the train or be left behind.” But more optimistically it’s “get on the train, it’s so much fun!” I’m bullish on AI. I’m bullish on software. I think the AI era ushers in the biggest boom in SaaS that we’ve ever seen. Not all SaaS will thrive (or survive, for that matter). But much of it will. And those who can navigate this nuance will be the winners of the next decade.

Other corners of the internet worth exploring this week:

• Grok Bot for GTM “This is how I use Grok Bot for Enterprise GTM at SpaceXAI.”

• 2024: Clay is the bleeding edge. 2025: n8n replaces Clay. 2026: Claude Code replaces Clay. 2027: Clay is the bleeding edge. More here and here (I’m writing something on this subject that I’ll publish soon).

• Cool data showing the backgrounds of GTM Engineers (post from Danny Chepenko):

  

• Rox gathered 75 RevOps and GTM Engineers in San Francisco Tuesday night, and I did some interviews (sneak peek here). Bullish on in-person events in GTM these days!

• How to stand out in the slopification of the timeline:

That’s it for today.

As always, thank you for your attention and trust. I do not take it for granted.

Have a great weekend, gtm legends.
Brendan 🫡

Subscribe now

Thanks for reading this hand-poured, 100% organic, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → ML-powered data and account intelligence for Ai-native GTM.

Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

I am testing out a new format on this fine Friday: A weekly roundup. This week, I’m explaining one of the hot topics in the GTM space (triggered by a Paul Graham tweet), plus a few links to things I’ve been exploring (tools, articles, podcasts) that I think are worth your time.

Let me know if you think I should do this each week, or if you’d prefer no round-up. (Reply to this email, I read each response).

Paul Graham, the godfather of startups, dropped 13 words that absolutely obliterated the timeline earlier this month.

I think there are pros and cons of the term “GTM” gaining traction.

The good

Traditional sales was one subset of the overall go-to-market function. And at a startup, sellers are doing more than just selling. They’re also doing their own sales engineering, demand gen/sales development, running event follow-up, building enablement/playbooks on the fly, etc. “AE” (or “sales rep”) is limiting to the actual role. So it makes sense that startups would call their founding sellers “GTM”. I agree with Chris Balestras (who places lots of early sales hires at startups):

And even in large companies, “go-to-market” is a broader umbrella term.

From Stripe’s guide on What is a go-to-market strategy? How to create a GTM strategy for startups:

“Go-to-market” (GTM) refers broadly to the overall commercial framework a company uses to bring a product or service to customers, though in practice it is heavily centered around sales and marketing functions. While sales and marketing execute the core tactics, a complete GTM strategy is broader and cross-functional. It connects product positioning, pricing models, distribution channels, customer success, and revenue operations into a unified plan to acquire and retain buyers.”

Here was my way of explaining this…

The bad

Some people are using the title of GTM because they’re embarrassed to call themselves a salesperson (or AE).

First, because it’s low status, I guess? (I don’t see it that way :)). And, secondly, because prospects don’t want to talk to a ‘salesperson.’ Same reason we came up with ‘Account Executive’ or ‘Sales Development Representative.’ No one wants to talk to the ‘slimy used car salesman.’ But modern sellers are not slimy used car salesmen at all. I like how Irene Madrid put it:

Modern GTM means understanding yoru customer’s business before you ever pitch a product. Thinking like the CEO of their company. Getting obsessed with solving real problems, not just signing the deal.

So, maybe some people see this rebrand as warranted to escape this stigma? (I don’t think that’s necessary).

And here’s the final angle: some agency bros hijacked the term. “Lead gen” (aka cold email services) has become synonymous with “GTM” in some circles. A lot of people doing “meeting booking” as a service pivoted to doing “GTM work.” You can charge 50% more overnight, with that one rebrand. But this is brutal for the space. It undermines the value of what GTM actually means. It’s definitely not another name for “outbound.”

Conclusion

No matter where you fall on the argument(s), there’s no denying that “go-to-market” as a term is being used more today than ever before.

And, while there are many definitions (and hijackers of the term), I think it’s helpful for everyone to, eventually, get on the same page and use the term the same way.

So, what do you think of this trend of calling salespeople ‘GTM’? Reply with your thoughts! I read all responses.

Other corners of the internet worth exploring this week:

• Grok Bot launched this month. I’ve been using it a ton every day (for LinkedIn triage, editing, research, light design, “Chief of Staff” mode, Substack analysis and more). It’s the wildest AI experience I’ve had since Claude Code in December. Think of it like Claude Cowork meets Slack (but instead of humans, it’s bots that you create, and each one has computer use).

• Clay instituted an official AI Writing Policy that I think everyone should adopt (or create their own version). It’s soo so good (9k+ likes on the post, so I guess a lot of others agree).

• Lot of founders and revenue leaders are trying to figure out what a GTME/Growth Engineer should do (and if they should hire one). Much of the things they’re doing are newly unlocked things, thanks to AI. Here are some examples: 21 things a growth engineer does.

• A rare, and fascinating, interaction with Dario on X (responding to Gavin Baker’s comment that “Anthropic believes they could be the ONLY company left in the world”) → “I don’t usually spend much time on social media but I wanted to engage here because it really brings out the heart of an important conversation.”

• Ben Thompson (on Invest Like The Best) says the real money in AI is being made by Meta, not OpenAI or Anthropic: “The biggest impact of the models, the biggest monetization right now is probably not in Anthropic or OpenAI. It’s the incremental gain that is happening for Google and Meta.” And says Zuck shouldn’t be ashamed of the beautiful business model of ads, and that OpenAI should have done ads to support their consumer business sooner. (The entire conversation is worth a listen, or wherever you listen to your podcasts)

• In a leaked letter to Stripe’s investors explaining its acquisition of OpenRouter ($7.5B), Stripe founders say the singularity started January 1st 🤯

• X/Twitter open-sourced the algorithm for the “For You” page.

• Last but not least:

  

That’s it for today.

As always, thank you for your attention and trust. I do not take it for granted.

And let me know if you liked this edition (reply to this email!) and consider forwarding it to one person, it means the world to me.

Have a great weekend, gtm nerds!
Brendan 🫡

PS:
(Bonus nugget; the most beautiful website I’ve come across in a long time):

Our lives and homes are filled with things that once inspired similar awe. I tried to collect those feelings, in quotes…from people for whom what is now ordinary was brand new. A friar who met the inventor of eyeglasses, a founding father on the new smallpox vaccine, a woman in Iowa on her family’s first indoor bathroom. To look at a modern apartment through their eyes:

Click through it here: Ordinary Abundance.

Subscribe now

Thanks for reading this hand-poured, 100% organic, farm-to-table (human-written) newsletter.

Hey y’all! 👋

In November of 2024, I published an article titled “The Anti-AI SDR Company Coming Out of Stealth.” It was about Rox, led by Ishan Mukherjee (who exited his previous startup to New Relic). Fast-forward about two years, being anti-AI SDR turned out to be the right approach.

I wanted to follow up on that first deep dive that I wrote, especially in the context of so much that has changed across the GTM landscape, and get an update on what they’ve built since coming out of stealth. So, we’ll call this a deep(er) dive post. As a reminder, sponsored deep dives give me an excuse to go deep on products (and spaces) that I’m interested in writing about, even if they weren’t paying me (don’t tell them this ;)).

Rox is a revenue agent platform. They’re probably the fastest-moving company I’ve seen in the GTM tech space. “Cracked,” as the kids say. In under 24 months, Rox has gone from an unknown company to a force to reckon with. They’re building in SF and have raised over $80M across their Seed and Series A rounds from tier-1 investors (Sequoia, GV, and General Catalyst). And today, they’re launching Teams, the self-serve entry to their revenue agent platform, that any size team can use.

I’m excited to revisit what I wrote about ~20 months ago, unpack what Rox has been up to since then, and talk about where they’re headed from here.

Let’s get into it.

One of my favorite Paul Graham quotes is from a 2012 essay How to Get Startup Ideas. In it, PG says:

Live in the future, then build what’s missing.

Ishan and Rox are doing exactly this in the GTM world. They’re building for a world that does not yet fully exist, but is starting to emerge, and—if they’re correct in their bets—they’ll be perfectly positioned to support this new world with how they’re building Rox.

What I covered in my first deep dive

To recap, here’s what I said about Rox back in Nov of 2024 when they launched out of stealth:

1. Account-based agents. Rox’s central idea is account-based agents for quota-carrying reps. Traditionally, we think about task-specific agents or assistants (eg: an email-writing assistant, a research bot, a CRM plugin, etc). Rox flips this on its head. Instead of having agents for different tasks, Rox provides one dedicated agent per account. These agents scour public data, third-party data partners, and first-party tools like your CRM and data warehouse. Think: agents working 24/7 across every account in a seller’s book of business.

2. Software that gets smarter with time. I joke that gtm tech gets worse the more you use it, not better (looking at you, Salesforce… after several years of usage, it starts to look more like a 59-year old Mike Tyson trying to fight a 27-year old YouTuber… tired and past its prime). But, with Rox, it gets smarter the more you use it. Over time, the tuning kicks in and the more context you share with it, the better it will get.

3. Results, not “demoware.” I still remember what Ishan said when I congratulated him on their fundraise: “It doesn’t matter. What matters is: do reps find it useful? Does it make them more productive? And hopefully the productivity is significant enough where it changes the fundamental unit economics of the market. That’s pretty much our sole focus.”

4. Anti-AI SDR. My dumbed-down explanation of the product at the time was: “Perplexity/Claude Projects + Clay-lite + a slick workflow layer (plus… it uses dark mode—my kinda people).” It’s built for quota-carrying reps. Rox is explicitly anti-AISDR. It’s not trying to replace the human touch with automation, the way some are (and now walking it back). Their approach is to empower reps by helping them save time on: information gathering, wrangling, and all the other things that take time away from reps spending time IRL with customers. Fast-forward about two years, and this turned out to be the right approach.

5. Supercharge your best reps. Rox’s arbitrage is around the fact that reps don’t spend time in Salesforce anymore. And, maybe more interestingly, the data is not all in Salesforce anymore, but instead moving into the data warehouse (this is a very big deal). As the AI-era continues to unfold, I believe this data problem becomes even bigger, and the data architectural decisions will, therefore, become more important for GTM teams.

Building for humans AND agents

I was re-reading Rox’s Manifesto while doing research for this piece, and thought this excerpt was worth sharing to help (re)set the table today:

Our mission at Rox is to secure and grow the world’s revenue. We build revenue agents that either augment or automate the entire revenue life-cycle from inbound, outbound, deal management to renewals. Coding, Support and Legal agent categories are already maturing and are driving drastic productivity benefits. We believe Revenue agents will do the same.

Innovation in this vertical requires us to re-invent the way humans AND agents work from the ground-up across the data platform, the agent harness and the UI. As we explore the frontier, we will continue to post our learnings along the way for the community and incorporate our research into our product.

They even have a dedicated Research Program to help accomplish this audacious goal (seems their plan to deploy that $80M isn’t just on a bunch of google ads and SDRs), to solve the problem around why revenue agents are uniquely hard to build:

Revenue agents operate in one of the messiest data environments imaginable. A seller’s world spans CRM records, email threads, meeting transcripts, call recordings, LinkedIn profiles, company news, and dozens of other signals, all constantly changing.

What is Rox building?

Here’s how Rox describes themselves: “Rox is a revenue agent platform. Rox agents do the actual work of a sales team, like finding and researching prospects, running outreach, managing live deals, and handling renewals.”

Here’s my take: the old revenue stack is getting torn apart. And the best AI-native GTM teams are building a new stack to scale their revenue from $1M to $1T. This new stack makes legacy CRM and SaaS obsolete, designed for Revenue Agents to do more of the actual revenue work: everything from generating pipeline, helping execute deals, forecasting through renewals.

Anyone can hack together an agent over a weekend that demos well. But, deploying (and scaling them) into production in an enterprise revenue org is incredibly hard. To do it, you need three layers:

• Data: one unified foundation across every source

• Harness: makes agents reliable

• Agents: actually do the work for sellers

Let’s unpack each one and how Rox is tackling it.

Data (warehouse-native)

If you’re a GTM nerd (you’re reading this little newsletter, so you probably are), you’ll probably enjoy this video of Shriram Sridharan (Co-founder & CTO at Rox) explaining the history of the database (Siebel in the 90s), to cloud (Salesforce in 2005), to warehouse (today).

Shriram goes on to share the journey of modern GTM teams and how their data setup is impacted by layering AI into their system(s).

The whole (7 min) video is worth watching, but here’s the tldr:

1. The GTM data already migrated, out of the CRM and into the lake house.

2. That makes the lake house the system of record, the only place the full customer picture exists.

3. The lake house is now operational, which means you can run agents directly on your system of record instead of on a stale copy.

For teams setting up an AI-native revenue system, you have to rethink how your data is structured, or else none of the agentic workflows you layer on top will flop due to missing context or inaccuracies.

Harness

A revenue harness is necessary to make these magical models work for teams. They give you the right context about your business, while leveraging this powerful, alien technology that is LLMs.

Rox enables teams building their own custom revenue harness, by providing what’s missing with out-of-the-box technology. This enables teams to deploy agents reliably, safely, and at scale, by giving them the tools needed to do things like testing, governance, compliance, evals, and other (somewhat boring, but necessary) tasks to run agents in enterprise orgs.

As one example, I recently got a message from a (very impressive) GTM team who built a custom harness. They’re using Rox as a core piece of infrastructure to build on top of. This type of builder is more and more going to run GTM systems at the fastest-growing companies in the world. As Kyle Norton shared with us, you want to “build your intelligence and buy your infrastructure.” Rox is building said infrastructure, which means they’re well-positioned to slot into these types of teams/systems.

Agents

Rox is entirely focused on “revenue agents.” But, what does that actually mean in revenue orgs at mid-market and enterprise companies? Let’s jump into a couple of examples to show exactly how the best AI-native revenue teams are building agents using Rox.

Prospecting is dead as we know it. In Rox’s launch around outbound prospecting a week ago, Ishan said:

This isn’t a faster way to prospect, it’s the end of prospecting as a job that you used to do by hand. Your reps weren’t hired to click through contact lists, they were hired to engage with customers to close and grow them. So let the agents prospect, and live in Rox.

I don’t see this as AI replacing humans. That’s not what the best teams are doing. Instead, they’re using AI for certain tasks (like researching, admin tasks, etc) so that sellers have more time for creative and impactful work that AI cannot do. Agents enable (or superpower or augment) the best sellers on your team.

Another example of agents is having them run revenue end-to-end. “No SaaS, no CRM, no Enrichment. Just an agent.” This is a wild statement, but I think the right future (and apparently thousands of other people agree). Like I said earlier, Ishan and the team at Rox are living in the future, and pulling us into it.

Two years ago, Rox launched agents. And then, earlier this year, they hit an inflection point: their largest enterprise customers switched many of those agents from Copilot to Autopilot. Rox continues to help revenue teams build bleeding edge agents.

And (as of today) it’s all self-serve!

Rox has spent the last 2.5 years spending all of their time doing research and shipping products to solve problems at revenue teams in the world’s largest enterprises (AI-native companies like MongoDB, Ramp, WSP, Puma Energy, XBOW, and Together AI).

They’ve launched a dialer, live call coaching, AI sequences, custom apps for RevOps, automated workflows, org charts, inbound agent, account plans, deal review/forecasting, deck generator, mac app, voice mode, and (much) more. This company SHIPS.

And today, they’re opening up the entire platform to all, 100% self-serve. This is not a watered-down version of Rox. All you need to do is sign up, sync Salesforce, connect your data, and the agents are ready.

Give it a try (and let me know what you think if you do!) → Build your Revenue Agent stack today. Get a demo. Get started now.

That’s it for today! Let me know what you think of today’s post (I read all the replies).

As always, thank you for your attention and trust. I do not take it for granted.

See you next time*,
Brendan 🫡

*For the legends who made it all the way to the end, here’s a sneak peek of our next few posts:

• How a CRO manages his $30M revenue org through Claude Code

• A look under the hood of the GTM tool built by a Director of GTM Engineering at a $1B company

• The swimlanes between RevOps and GTM Engineers

Subscribe now

Thanks for reading this hand-poured, 100% organic, farm-to-table (human-written) newsletter.

Hey y’all! 👋

Something interesting is happening inside revenue teams right now. They have access to the best AI that has ever existed: incredible models and harnesses (eg: the agent tooling on top like Claude and ChatGPT) that get better every month. And yet almost every team I talk to is stuck in the same place: they can’t get all that intelligence to do consequential work with their revenue data. The limiting factor isn’t the model anymore. It’s context. AI doesn’t come out of the box knowing your customers, your team, how you sell, or what winning looks like at your company. And no model release will fix that.

The teams that solve context are handing real revenue work to AI: deep research across every deal, analyses they can trust and repeat, workflows deployed to a whole team. And the work compounds, because the system remembers. Everyone else is getting confident answers built on fragments, and most don’t know it yet, because the answers sound right.

The most AI-forward companies have already figured this out. Teams like Cursor and Vercel treat context infrastructure as part of their GTM strategy, with dedicated engineers building and maintaining their context layers full-time. But most companies aren’t doing that. Most can’t—or, frankly, shouldn’t.

That gap is the problem Pouyan Salehi built Clearskies to close. It launches today, open to any GTM team.

I’ve known Pouyan for over a decade. I first met him in San Francisco when he was building PersistIQ, one of the early sales engagement platforms, from the same wave as Outreach and Salesloft (and eventually Gong). Then he and his co-founder, Cyrus Karbassiyoon, built Scratchpad, the tool that made updating Salesforce feel so buttery that reps actually did it, which is why it spread fast, and organically. Now they’re building Clearskies, which they describe as “The Context Layer for Revenue AI.”

Even six months ago, almost no GTM leader was talking about a “context layer” for their team. Now it comes up in half the conversations I have. My bet: over the next 6-12 months, context becomes one of the most-discussed problems in go-to-market. That’s why I was excited for today’s sponsored deep dive into the context layer Clearskies is building.

Here’s what we cover today:

• What a context layer actually is

• What a context layer unlocks, starting with the hard stuff: deep research and win-loss analysis

• Where connectors stop being enough (and where they’re still great)

• Build vs. buy in the AI era

• Governance, portability, and the no-seat model

• Where this goes from here

Alright, let’s get into it.

What a context layer actually is

When I caught up with Pouyan recently, he laid out four layers of context:

1. Customer context → the full story of each account: deals, contacts, activity, commitments, risk. Identities resolved across sources, timeline ordered, with what’s changed since you last looked.

2. Team context → who’s selling: roles, reporting structure, segments, territories, tenure, quota, expertise, how they’ve performed.

3. Process context → how you sell: stages, methodology, definitions, approval paths, exceptions, what good looks like.

4. Business context → products or service lines, segments, pricing and packaging, strategy, OKRs, priorities.

Reminder: this is that stuff that foundational models don’t know, out of the box.

Customer context is the hardest of the four to wrangle. The real record of a customer doesn’t live in Salesforce or HubSpot. Your CRM is the secondhand version: the rep’s summary, hazy and half-right. The primary source is the emails, calendar invites, Slack threads, tickets, and call transcripts scattered across a dozen tools (Clearskies’ integrations list keeps growing), and a lot of it lives only in people’s heads.

The obvious fix is to pull all of those sources into one place. But that’s just a database. Context is what you get when the pieces are actually connected: the Acme opportunity in Salesforce, the calls, the email threads, the support tickets, and the Slack channel resolved into one account. Touch points ordered into one timeline, with changes tracked across the account’s history. Your sales process understood, so “stalled at Stage 3” means something. That’s a context layer. The connected picture, across all tools, kept current, so any AI can reason across the full story instead of rebuilding it from scratch on each new query. Revenue infrastructure that hands any AI the full picture of your customer, your team, your process, and your business.

What a context layer unlocks

The unlock isn’t just better answers to quick questions. It’s consequential revenue work—analysis and workflows you’d never have trusted AI with, done reliably enough to hand to a whole team, compounding as the system learns your business.

Start with the thing that’s hardest to fake: deep research and analysis across all of your revenue data. This is the difference between “search my CRM” and “go through every enterprise deal we lost last year—every call, every email, every Slack thread, every support ticket, across every rep—and tell me the real reason.” Done properly, win-loss means pulling each relevant deal, inspecting what happened on it end to end, finding a real answer per deal, storing it, and then analyzing the whole set. For hundreds or thousands of deals, that’s not something you can fake with a sample of your data. Ask a model to do it cold and it’ll hand you a confident answer built on a handful of data points and never mention that’s what it did. In revenue, those errors turn into bad commits, missed forecasts, and churn.

That’s where a context layer becomes an obvious need. A real analysis isn’t just a prompt. It’s the prompt plus the context, plus the memory of what you’ve already learned, plus the technique to run it the same way each time. And when it works, the answer shows its work: how many records it read, which sources, the per-deal summaries you can browse, and where the gaps are.

Once that’s in place, the same infrastructure (basically, a revenue brain, or “System of Intelligence”) does consequential work for every role:

• CEO: voice of the customer, built from what buyers actually said (not a survey), and briefs across the whole funnel.

• CRO: rep performance with the why behind numbers you already have. The dashboard tells you who’s behind quota; the layer shows what’s driving it: thin discovery, single-threaded deals, stalled next steps. Process gaps and objection trends across the pipeline, with the evidence attached.

• RevOps: pipeline health with the why attached: what’s at risk, what materially changed this week, and the recurring conditions that show up before deals stall or die as no-decisions. Plus win-loss, run the way I described above, across the entire book.

• Marketing: competitive intelligence from your own calls (which competitors come up, in which deals, what objections they raise, how they impact the deals, and how your team responds) and market trends straight from the source.

Analysis is half of it. The other half is execution: pre-call briefs that pull from the full history, post-call workflows, CRM fields that update themselves, handoffs that don’t lose the thread. One layer, feeding both. (Clearskies’ use-cases page has more.)

And there’s another new use-case that context unlocks: custom applications. As more teams build their own revenue apps and agents, the context graph is the definitive source to power them. You don’t have connectors to the application you just built; you need a layer underneath it.

What struck me is how far this reaches. It’s the whole team, from CEO to seller. It’s across functions: product, finance, marketing. And it’s across the entire customer lifecycle, from first discovery through handoff, expansion, and renewal. Each function has been asking the same questions about customers and rebuilding the answer in silos. But when you put one shared layer underneath, everyone’s questions get answered (from the same source).

Where connectors stop being enough

Since December, Claude and ChatGPT adoption inside revenue orgs has gone parabolic. Most teams are still early. They’ve turned it on, or they’re about to once security and legal clear the enterprise version, and they’re still working out what to do with it. But they know they should be using it (a lot of FOMO on the timeline, some of it coming straight from the board).

The more advanced teams are wiring up connectors (MCPs). And connectors are good at what they’re for. This isn’t connectors versus a context layer. The question is where each one fits.

Connectors shine on narrow, low-stakes work. One deal, one call, one rep, the data sitting in a single tool, a human who can eyeball the answer. They stop being enough the moment the job needs the full customer picture across tools, across records, across time, and across your entire revenue team. At that point the model reconstructs the picture from scratch on every run: slow, expensive, and every rebuild can come out a little different. Ask for the same pipeline review on Monday and on Tuesday, and you can get two different numbers. You can’t trust it to repeat, and you can’t safely hand it to a whole team. And the answer can only be as complete as the fetch. Nothing tells the model that the contact in the CRM and the voice on last week’s call are the same person, and nothing flags the email thread it never pulled. That’s why connector answers feel fine right up until they’re wrong.

A connector only knows “right now.” It reads whatever is in the tool at the moment you ask, and nothing persists. It can’t tell you what changed, when, or why: how a deal actually progressed, where it stalled, what happened after the pricing call. For anything that depends on how a customer or a deal evolved over time, a read of the present isn’t enough. You need a layer that retains memory.

Connectors are the right tool when the work is in one place, the scope is small, the stakes are low, and a person can quickly check the result. You’ve outgrown them when the work needs the full customer picture across tools and history, and when the output drives a real revenue decision. At that point, the team has to trust the answer without re-running the analysis, and the job is to find patterns and track change over time, not fetch or update one thing.

You’ve probably heard the advice to dump all your revenue data into a GitHub repo and point the model at it. But revenue isn’t code. In code, the context sits in the repo. In revenue, it’s scattered across all the tools your team touches, and stitching it together on the fly is exactly where connectors break.

Build vs. buy in the AI era

Building got dramatically easier (everyone knows this). I’m personally shipping working tools without writing a line of code. But, it’s more accurate to say what got easier is not one-shotting end-to-end production-grade solutions, but prototyping. A prototype is the starting line, not the finish. Getting to something you can rely on takes the patterns you only learn by doing the work. I don’t buy that all SaaS is dead. I think there’ll be far more software, and the unglamorous work of context, paired with expertise and taste, becomes the differentiator.

The context layer is where I see GTM leaders underestimate this the most, because it’s an iceberg. Above the waterline, a prototype comes together on a weekend: wire up a few connectors, load a database, point Claude at it. But it’s misleading. A database with a little data in it feels like a context layer. Below the waterline is what it takes to make it real. Things like identity resolution that holds up across edge cases, semantic search across millions of records (the average revenue team is not standing up a vector database and tuning search infrastructure), memory that persists and improves, permissions that hold. And below that is keeping it alive. Things like new tools being added, schemas drifting, techniques evolving, playbooks and processes changing, and the whole thing has to stay fresh enough to trust your revenue with. It’s less of a one-time project, and more of a permanent allocation of engineering, product, and design to internal plumbing.

Even teams with serious technical firepower like Cursor (who built ChatGTM), Ramp, and Rippling poured enormous effort into building and maintaining the context layer, including the custom harness: the tooling, memory, and orchestration around the model. Build vs. buy is a tale as old as time. You didn’t rack your own servers, you’re not vibe-coding your CRM, and you probably shouldn’t build your own revenue context layer either.

I recently published a piece with Kyle Norton: How to Think About Build vs. Buy in the AI Era (”Build Your Intelligence. Buy Your Infrastructure.”). Clearskies is the textbook case of infrastructure you buy, so your team can spend its time building the agents and workflows on top (that’s the “intelligence” part).

Clearskies also wrote a great piece on how operators are rethinking build vs. buy, with tactical examples from Vercel, a16z, and Browserbase. Including advice like: keep agents small, start with one job (not a platform), and keep GTM in the build loop. It’s worth reading the whole thing.

Governance, portability, and the no-seat model

Governance has to be part of the design. Execs have sensitive conversations with customers, HR sends confidential emails, board-level information floats around. You can’t just pipe your executives’ inboxes into Claude and start one-shotting agents. A real context layer controls what enters the shared context, with permissions and an audit trail. That’s the difference between a demo and something you can deploy across an enterprise.

Portability is the piece I find most interesting, and I think it’s changing fast. Right now most teams wire their tools straight into a single harness. Models are leapfrogging each other every few months, and if you’re hard-wired to one, you can’t move to a better one without rebuilding everything. When you own the context layer, the joins and the history live outside the model, so your answers don’t change when your model does. Swapping in whatever harness and model tops the benchmarks next is a lightweight change, not a migration. You get to select the best performance instead of being locked to one provider. (There’s an IP angle too: you keep your own decision-making and institutional knowledge instead of handing it to a single vendor. But the day-to-day win is simply being able to move.)

Kyle Norton put the compounding effect well:

[The winning companies] will be extremely deliberate about the intelligence layer. They will know what context matters, what memory should persist, what workflows create proprietary learning, and what parts of the system need to remain portable.

That is how AI maturity compounds. One good workflow becomes reusable context for the next workflow. One evaluation loop improves the next model output. One proprietary memory layer makes every future agent better.

The companies that win AI-native GTM will not have the most tools. They will not be the companies with the flashiest demos. They will be the companies whose systems get smarter every week because they own the memory that matters.

Which is why I keep coming back to “memory is the moat.” Clearskies made the same case (every revenue team needs its own brain) and built their layer so your context stays yours and works with any model or surface.

You can see the philosophy in how they price it. No per-seat licenses: you either pay as you go or pay a flat rate for the infrastructure, and the whole team gets access. And for the team using it, there’s no new app to learn. You use it through Claude, ChatGPT, Slack, or whatever surface fits. The app is for the builders and admins setting it up. The layer clears a higher bar than connectors where it matters: complete and current, shared across the team, governed, repeatable, portable across models, and priced so your token bill doesn’t balloon each time context gets re-stitched.

Where this goes from here

I expect the model and the harness to decouple. Open-source harnesses show up, and teams route task-specific models through their own context layer. When you own the context layer, you can plug it into anything.

Pouyan’s read on the market right now is that most companies’ “AI strategy” is “we bought Claude.” Few have done anything meaningful with it yet, and even fewer see context as the actual bottleneck; most assume connected tools and better models will sort it out. Which means the teams that figure out context now will pull well ahead of the ones waiting.

The adopt-AI-at-all-costs phase is already sliding into the rear-view mirror. CFOs are starting to look at the Anthropic invoice and ask, “what did we actually get for this?” The teams with a context layer their GTM org (and the rest of the company) can build on are the ones whose results compound. Everyone else keeps shipping one-off AI workflows they have to rebuild each time. That’s the asymmetric bet Pouyan, Cyrus, and the Clearskies team are making. After years of watching them go one layer deeper with each product they build, it’s the most convincing version I’ve seen yet.

Context as infrastructure is the story of 2026.

Visit Clearskies and start building for free, or book a 1:1 with their team.

Or, if you just want to chat more about context strategy and what you’re building, Pouyan is happy to connect and share learning → reach out to him on LinkedIn. He reads the comments here too, and he told me he’s happy to compare notes with anyone working through this.

That’s it for today!

As always, thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

Subscribe now

Thank you—*all 10,000+ of you!!! 🤯—for reading this hand-poured, 100% organic, farm-to-table (human-written) newsletter.

Happy Friday, y’all! 👋

We hit 10,000 subscribers this week.

I close every newsletter with the same line:

Thank you for your attention and trust. I do not take it for granted.

And I really do mean it.

I got back from vacation with my family last night (hence the photos of beach scenes throughout today’s piece). And this morning, with sand still in my shoes and the smell of sunscreen on my hat, sat down, genuinely excited to start working. What a gift. To be doing what I love—and have found “pmf” doing it.

When I started writing this newsletter, I wasn’t trying to build “a media company.” I genuinely did not think I could (or wanted to) do this full-time. I was simply trying to learn in public. I wanted a place to document what I was seeing as the old playbook was starting to fail, and a new playbook was emerging (in large part due to the rise of “GenAI”). This newsletter was a place to share the conversations I was having with operators who were heads-down shipping, while the rest of us were still figuring out what the new playbook even was.

Somewhere along the way, it became “a real thing.”

Now, there are over 10,000 weekly readers. Public company CROs and heads of RevOps, founders, and GTM leaders at OpenAI, Cursor, Ramp, Rippling, Anthropic, Vanta, Snowflake, Datadog, Baseten, Navan, Stripe, and many more. Operators who write me after every issue to push back, add context, or share what they’re building.

If you’re reading this: thank you.
(Your) attention is the scarce resource.
And I do not take it for granted.

A few things I’ve learned getting here

Quality beats scale. I’ve said this before, and I mean it: if I have half a million subscribers in three years, I have failed. I am building for a small group of people—by design (“nichemaxxing”). The goal is that the right people find this useful, not that everyone sees it.

Free, forever. I believe information should be free. Including not requiring an email gate on the archives. Trust compounds when you don’t make people jump through hoops to read. It’s also my own PLG motion :) which I deeply believe in.

Organic is slower, but better. Growth has been from word of mouth, LinkedIn posts, and people forwarding issues to a teammate. I have not spent a dollar on paid acquisition, and don’t plan to. Tortoise > hare:

Going full-time was the unlock. I’ve been able to do more interviews, deeper research, stronger live shows, and spend more time interviewing operators who don’t have 12-15 hours to write up what they’re doing. The GTM playbook is changing, and I want to create the place that documents what’s actually working. That was the bet I made. And it seems increasingly valuable in the AI era.

Some stats. I have published 106 articles, viewed over half a million times, and written 172K words (…don’t worry, I’m actively trying to work on making posts shorter… it’s hard!). Over 3M impressions on LinkedIn so far this year.

84% of subscribers are GTM leaders and founders. Below is the split across personas:

If you’re new (or want a refresher)

Here are the top/my favorite articles:

🤖 AI GTM

• Inside “ChatGTM”: Cursor’s Internal Sales AI Used by their 400+ Sales Org

  (SDRs are booking 3x qualified meetings and AEs are shaving ramp by 50%+. What Cursor’s Head of Enterprise Growth, George Hou, built. And whether you should build your own version.)

• 9 Lessons From 11 Growth-Stage Companies That Built GTM Agents In-House (Vercel, Ramp, LangChain, ClickUp, Deel, Vanta & others: what they built, their tech stacks, and what we can learn from them)

• How a $100M ARR Company Runs RevOps on GitHub; Inside Hightouch’s Agent Repo (Skills for every rep. A four-layer repo for RevOps. And three AI experiments that got pulled. With Nikko Georgantonis, Head of GTM AI & Systems at Hightouch.)

• 6 Ways GTM Teams are using MCPs and Claude/Claude Code Today

  + Video demos of real examples from our live event

• The best AI-native GTM plays you’re not running [Growth Unhinged collab] Automation doesn’t have to mean spray-and-pray. Now it doesn’t have to mean manual, either.

• 6 Ways to Modernize Your GTM Motion in 2026 (Lessons from working with 14 Seed-Series C companies in 2025)

🛠️ GTM Engineering

• The Rise of the GTM Engineer

• When Should You Hire a GTM Engineer?

• How to Become a GTM Engineer (8 Resources)

• Most Companies Are Using GTM Engineers for “Automated Outbound.” The Best GTM Teams Aren’t Stopping There.

• 26 FAQs about GTM Engineering in 2026

🎯 Prospecting

• “Micro-Campaigns”

• The best automated GTM plays you’re not running

• 6 “Evergreen” GTM Plays (and the tools to run them)

• How to automate signal-based selling

• How to Source 7-Figure Deals on Outbound (AI can’t do this)

• 7 Ways to Generate Pipeline (in Q4 of 2024)

• Inside Eric Nowoslawski’s AI-Powered Cold Outbound Machine

🧰 GTM Tech

• Clay Just Drained Its Own Moat (On Purpose)

• GTM Tech’s Race for Power *and* Ease of Use

• The “System of Intelligence”

• The $100B+ Winner in GTM Tech Will Sell Labor, Not Software

• Should You Buy an AI SDR?

• ProspectingStack.com

📊 Research Reports

• GTM Tech Stacks of the Fastest-Growing Private B2B Companies

• 54% of the Fastest Growing B2B SaaS Companies have a GTM Engineer

Two small asks

1/ Forward this to one or two people who geek out on AI × GTM the way you do. A founder. A RevOps lead. A GTM Engineer on your team. Send them this email, or this link: Best of The Signal. It’s free and ungated.

2/ If you’ve gotten value from The Signal, go check out one of the partners who make it possible for me to spend 100% of my time on this.

Thank you to Clay, our presenting partner.

Bruno, Varun, and the team took a big bet on me and The Signal early on. And I’m very grateful. (The best part is, I was already singing Clay’s praises for over a year while I was consulting, without being paid a dollar, so it has been a no-brainer to partner with them).

And to our supporting partners:

• Attention → AI Agents for RevOps.

• Clarify → The Autonomous CRM. Sell more, admin less.

• Clearskies → The Context Layer for Revenue AI.

• Nooks → All your outbound. One AI workspace.

• Rox → Revenue Agents for the Global 2000.

• Sumble → Buying signals from tech stacks, people data, & active projects.

• Terret → The answer-to-action engine for revenue teams.

The Signal literally wouldn’t be where it is today without the support of these companies.

So, do me a favor and request a demo (or sign up for their free product) today if you’ve found value in the content that my caffeine-infused fingers frantically type each week. And let them know The Signal sent you their way; that will help me continue creating valuable content.

What’s next?

I don’t know where this journey will lead me. But I’m loving it for now, and plan to continue down this road until I can see what’s around the next curve. With the same goal as the day I first published in Nov of 2023: to separate the signal from the noise as the new GTM playbook emerges.

I’m grateful you’re here in this little weird little corner of the internet with me.

Thank you for your trust and attention—I truly do not take it for granted.

See you next week,
Brendan 🫡

PS: Photo credit to my wife, Britt.

Subscribe now

Thanks for reading this hand-poured, 100% organic, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → ML-powered data and account intelligence for Ai-native GTM.

Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

Earlier this month, Clay shipped a public API and CLI. Something every GTM Engineer building at the cutting edge has been begging for for the last 6+ months. And the one thing almost everyone (myself included!) said they’d never be able to ship.

The consensus logic was simple: Clay’s stickiness lived in its UI. Open it up, and the moat drains. Adam Robinson polled “all of the smartest Clay pundits in the world” and they told him Clay would absolutely never do it (by the way, I told him the same thing when we talked on the phone last month).

They did it anyway (I was wrong), which makes Clay’s decision to go this direction all the more noteworthy. Today, I’m sharing my personal opinion of what it means for our space.

What Clay shipped

On July 8, Clay released an API, a CLI, and an Agent Plugin that bundles both (plus MCP and skills) into a one-line install for Claude Code, Codex, and Cursor. From Kareem’s announcement:

I found two things notable:

1. It’s available on every plan, including legacy self-serve. And work triggered through the API or CLI burns the same credits as work done in the product. No API tax.

2. The comments read like a pressure valve releasing. GTM engineers, growth leads, RevOps operators, and even CROs, who started building in Claude Code/Codex/Cursor 6+ months ago and have been switching to tools that work natively inside these coding agents.

   

Why everyone said they’d never do it

Back in April, I wrote out why I didn’t think Clay could (or would) release a public API without crushing their business (and even texted it to Adam). Clay’s moat had three layers.

Layer one: negotiated access+pricing to 150+ data providers (for more, see: aggregation theory). This allowed builders to work across multiple data providers in a single workflow/Clay table. And also enabled the—now ubiquitous—‘waterfall’ feature (which everyone is now copying).

Layer two: workflow lock-in. Your enrichment logic, your templates, your prompts, your team’s muscle memory, all living inside Clay’s environment. This second layer is the expensive to rebuild, which is the real switching cost.

Layer three: Their go-to-market motion. I think the most underdiscussed/underrated. They accidentally stumbled into it. Selling to agencies (“Claygencies”) who build content on their behalf, creating a magical, organic flywheel for Clay. I unpacked this topic back in January of 2025: Clay’s Moat (not a sponsored post).

A public API threatens both #1 and #2. Once an endpoint exists, someone builds an abstraction layer on top of it. Your workflow logic moves out of Clay’s system and into your own codebase, where it’s portable. Clay becomes the backend instead of the product.

But there was always a counterpoint: Clay charges per credit, not per seat, so the unit economics shouldn’t care about the delivery mechanism. However, an API doesn’t kill revenue directly. It kills stickiness, and lost stickiness kills revenue over time.

Adam Robinson heard the same thing that I outlined above:

All of the smartest Clay pundits in the world told me they’d absolutely never ever do it. What does THAT tell you about the state of the world?

My Take: You’re an idiot if you’re building UI for people.

…Leave it to Adam to make my point more crudely bluntly. :) (Hello if you’re reading this, Adam 👋)

Why they did it anyway

Demand. Again, Adam put it well:

This way of doing things is in such high demand that a $5B darling unicorn is willing to satisfy it, even though it’s very not good for the stickiness of their business.

Two things I’d add.

First, the users changed. The most technical (and often highest-spending) slice of Clay’s market now builds in Claude Code, Codex, and Cursor. I’ve seen this shift happen firsthand (myself included). GTM builders don’t want a UI. They/we want an endpoint. You can see examples of GTM teams building in Claude Code during an event back in April (which feels like a decade ago).

Second, Clay had every excuse to sit still. $100M+ ARR. 14,000 customers. A $5B valuation. Enterprise NRR above 200%. Clay shipped the feature its own moat argued against, in the fastest-shifting stretch software has ever been through. Most companies at that scale defend. Clay went on the offense. Adapting to the (quickly) shifting environment. Impressive to see.

This isn’t the UI dying, either. As my friend (and the person who first showed me Clay), Andreas Wernicke, said in the comments:

This and UI have to coexist.

It just stops being the only door in. Here’s an excerpt from a piece I published recently about building agents inside your CRM:

The pushback (and what it tells you)

This is just the start for Clay.

Matthew Quan (Product at Clay) responded to a common question in the announcement post:

Clay isn’t porting its UI to an API, feature by feature. They’re rebuilding the primitives around what agents do well: workflows as code, no row caps, and an agent that converts the old format into the new one.

For builders of GTM tech

An API, a CLI, and MCP support are no longer “nice-to-haves” in 2027. They’re “need-to-haves.” Your most technical users (RevOps, growth, GTM engineers, and increasingly even the SDR and sales leaders hacking in these tools) already build out of the terminal, and they won’t use products that can’t meet them there.

I understand that this isn’t just a simple feature. It’s a product decision, a pricing and packaging decision, an architecture decision, a positioning decision, and a go-to-market decision.

Building API/CLI/MCP-first forces the whole org to re-orient around it. And I realize it’s a big and scary decision. But if even Clay is doing it—and remember, this was supposed to kill their business model—you probably should too.

For buyers of GTM tech

When a vendor ships a real API, your workflow logic moves out of their UI and into your own repo, where it’s version-controlled and under your control (see: “AI sovereignty”). That vendor is choosing to win your renewal on capability every month instead of on sunk cost. Reward that choice with your budget, and be suspicious of the UI-only, seat-walled alternative.

Second, buying and building stopped being opposites. The old question was build vs. buy. The new motion is: buy the infrastructure (data, enrichment, execution, agents) and own the intelligence. Even if you’re building in-house tooling, and more teams are than ever, you should be buying infrastructure from Clay and other agent-native companies (like Rox, Sumble, Attention, Nooks, Clearskies, etc.).

Buyers used to ask “will my team actually log into this?” Now they’re asking “can my agents call this?” API, CLI, and MCP coverage moves from an afterthought to a first-order buying criterion, next to data quality and price.

Within 12 months, I think the vendors who treat the agent as a first-class user will win the most technical, highest-spending slice of the market—operators building in the terminal. And if you’re an operator in GTM, become someone comfortable in the terminal.

It’s unclear how it’ll unfold exactly (which makes this moment so exciting!). So, please reply to this email with what you think happens from here! I’d love to continue to evolve my thinking here. Regardless, it’s a blast to watch as the space shifts so fast, and we all figure out the new playbook together.

That’s it for today!

As always, thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

Related posts:

• Inside “ChatGTM”: Cursor’s Internal Sales AI Used by their 400+ Sales Org (SDRs are booking 3x qualified meetings and AEs are shaving ramp by 50%+. What Cursor’s Head of Enterprise Growth, George Hou, built. And whether you should build your own version.)

• How to Think About Build vs. Buy in the AI Era (“Build Your Intelligence. Buy Your Infrastructure.” With Kyle Norton.)

• 9 Lessons From 11 Growth-Stage Companies That Built GTM Agents In-House (Vercel, Ramp, LangChain, ClickUp, Deel, Vanta & others: what they built, their tech stacks, and what we can learn from them)

• 54% of the Fastest-Growing B2B SaaS Companies have a GTM Engineer (Research Report by The Signal)

Subscribe now

Thanks for reading this hand-rolled, 100% organic, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → Buying signals from tech stacks, people data, & active projects.

Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

If you’ve spent any time on LinkedIn this year, you’ve seen a post claiming “your sales team needs to put all your sales context in a GitHub repo!” Routing logic, field definitions, playbooks, all versioned, all readable by agents. But, often, the person making this claim is a one-man agency owner. So, I’ve been on the hunt to find scale companies running this playbook. Today, we explore one such company.

I first met Tejas, CEO of Hightouch, when we both lived in the Mission district in San Francisco; I was working at Zoom Video, and he had a new little startup and was trying to sell me (I tried to buy, but couldn’t get through procurement with my dinky title). It’s been a blast to see them absolutely ripping over the last 6 years. Hightouch crossed $100M ARR in April (they’ve grown more than 100% in each of the past two years) and raised a $150M Series D at a $2.75B valuation in March.

I recently sat down with a legend, Nikko Georgantonis, the Head of GTM AI & Systems at Hightouch. What they’ve built is one of the more sophisticated GTM systems I’ve seen. And this is not an agency guy who did a Claude Code project over a weekend. This is what AI adoption looks like inside a revenue org that’s scaling fast enough to have real stakes.

Here’s what we cover in today’s post:

• The two-pillar setup

• Pillar 1: Skills for every rep

• Pillar 2: The four-layer agent repo

• Why a repo instead of a tool

• What’s working for them right now

• What they tried that got pulled back

• RevOps becomes the agent wrangler

Alright, let’s get into it.

Nikko describes his job in two parts.

Part one is adoption. He’s going to QBRs and teaching the revenue org what skills are and why they matter. The deliverable is a library of packaged skills that reps actually use.

Part two is automation. His team has historically owned the system admin work of RevOps (data cleaning, lead list uploads, field hygiene, answering “can you update this account” requests in Slack). He’s handing that work to agents.

What caught my attention is how differently he architected each pillar. The rep-facing stuff is deliberately simple. The RevOps stuff is where the sophistication lives.

The two-pillar setup

↳ Pillar 1: Skills for every rep

The skills pillar isn’t overly complex. The highest-usage skills are things like account research. What makes them work is how prescriptive they are. Every skill follows the same formula: Here’s where to look, what to do, what good looks like, what you shouldn’t do.

A few things stood out to me about how he runs this:

Skills are overlaid onto the customer engagement process. He’s not building random one-off prompts. Each skill maps to a stage of how Hightouch engages customers, and it covers the whole revenue org: AEs, SEs, post-sales.

Reps choose their tool. Skills run in Claude or Glean, whichever the rep prefers. Nikko manages both. Either way, the skill taps into Hightouch’s internal brain through Glean’s MCP, which gives it access to Gong calls and internal docs.

Forking is the point. He ships the prescriptive version, and reps fork it to fit their own workflow.

The BI unlock for leaders. Skills can call Omni (their BI tool) to pull live metrics. That opens up manager and CRO use cases: scheduled skills that send weekly pacing reports without anyone asking for them.

↳ Pillar 2: The four-layer agent repo

This is the part Nikko was most stoked about.

All of the logic for his RevOps agents lives in a GitHub repo. Execution happens in n8n. The repo has four layers:

1. Context. The documentation that used to live in Notion, made machine-readable.

Their customer engagement process. Lead routing logic. How territories get cut. Forecasting definitions. Every opportunity and account field, audited and defined. Any agent can reference any of it.

2. Coordination. The routing layer.

Example: Hightouch has an internal RevOps Slack channel where people ask for account updates, flag duplicate leads, request list uploads, etc. The number of possible request types is too large for one prompt. So the first agent is a router. It classifies the request and hands it to the right specialist agent, passing notes along with it. Longer-term, this layer is how lead routing and scoring move from rule-based to probabilistic.

3. Memory. Agent history.

The example that made this click for me: Nikko has an agent that sends sales managers a report on each AE’s milestones, how they’re pacing, and a recommendation for what to fix. When it runs again two weeks later, it reads the recommendation it gave last time and factors that in. Some memory belongs in the warehouse. Recommendation history belongs in the repo.

4. Prompts. The actual prompts.

Most people would let these live inside n8n. Nikko keeps a skeleton in n8n that calls the prompt files in the repo instead.

One important note: reps never touch the repo. They see the outputs (a Slack reply, a field in the CRM, a report, a human-review step in the sequencer/dialer). Skills are how reps build. The repo is how RevOps builds.

Why a repo instead of a tool

Notably, Nikko told me he can’t make tooling bets right now.

Is n8n the right workflow tool today? Yes. Will it be in six months? No idea. Eight months ago, his “skills” were Glean agents. Then the technology moved. He’s watched his own stack rotate underneath him fast enough that betting the logic layer on any single vendor feels reckless.

So the investment goes into the layer that survives tool churn. Context, coordination logic, memory, and prompts, written crisply enough that they can be connected to whatever executes next. When something better than n8n shows up, the migration is re-pointing an execution layer, not rebuilding a brain. This aligns with the thinking Kyle Norton shared on “owning your intelligence” (ie: you should not buy your gtm brain)—you want control, portability, and compounding advantage.

Because everything is documented in one repo, he can point an LLM at it and ask where the redundancy is, where logic is duplicated, and how he should restructure. The system becomes legible to the tools that maintain it. To me, this is the obvious/inevitable future. And why, even companies like Clay, are going API/CLI-first.

And the endgame, in Nikko’s words, is that his job just becomes Claude Code. n8n has an MCP now, so he can do the development in Claude Code and have the documentation write itself back to GitHub. Salesforce admin changes that document themselves. Agents checking the outputs of other agents. His team’s old admin backlog, from data cleaning to lead list uploads, handed off. He says they’re system is starting to compound.

(One aside for anyone who read our ChatGTM piece: Cursor skipped the repo entirely and fetches everything live. Different problem. ChatGTM serves reps operational data that goes stale in hours; Nikko’s repo holds business rules that should outlive any tool. Live data gets fetched. Business logic gets committed.)

What’s working for them right now

Territory planning on a digital maturity score. This one predates the agent repo and Nikko was almost dismissive of it (”it’s been around for a bit”), but it might be the most valuable thing he showed me.

He built a Clay workflow that enriches every account with a digital maturity score: does this company run a data warehouse, does it do omnichannel marketing, does it operate a loyalty program, plus other boolean attributes. “Financial services” is a broad industry, and the “digital maturity score” is the next layer down. This bespoke scoring system separates the Chimes of the world from a credit union down the street. And it’s how Hightouch cuts territories today.

The manager pacing reports. Covered above, but it’s a pattern you can steal ~pretty easily: scheduled skill, pulls defined metrics from BI, gives each manager a per-AE diagnosis and recommendation, remembers what it said last time.

Betting on AI-native vendors. One example: Hightouch is replacing a legacy sales engagement platform with Nooks’ sequencer. A Series D company swapping a legacy sales engagement platform for a smaller, AI-native vendor is atypical, but the reasoning maps to everything above: he wants tools with real MCP workflows built in, not APIs with MCP slapped in front of them. As Nikko told me, “It’s easy to tell the difference.”

What they tried that got pulled back

I asked Nikko what hasn’t worked (I find that knowing which potholes to avoid is sometimes more helpful than sharing an exact roadmap of what to build).

1. Black-box reports. Hightouch built agents for proactive analytics: check the dashboards, diagnose what changed, recommend what to do. That works. But, where it broke was mixing in net-new metrics that nobody had defined before. Users didn’t trust them. People are pessimistic toward AI output by default, and an undefined metric inside an AI-generated report reads as a black box. The lesson he took is that agents can diagnose metrics your team already trusts. They shouldn’t invent new ones.

2. The asset-building skill. The team at Hightouch shipped a skill that helps sellers build customer-facing assets, but he’s rolling it back (for now, at least). The failure mode is subtle. The skill does 40-50% of the work. Experienced sellers know exactly what bad looks like, so they finish the remaining half with no problem. But new hires can’t identify which half is theirs to do. So for the people who needed help most, the skill amplified slop instead of raising the floor.

3. Fully automated outbound. For enterprise sales, Nikko isn’t bullish on “automated outbound”, and Hightouch didn’t find success with it. Where automation does work for them is inbound: handling demo-request follow-ups. Nikko clarified this one:

100% automated outbound we are bearish on, but agent-assisted we are bullish (and why we bought Nooks).

RevOps becomes the agent wrangler

Nikko wrote in a recent post that the RevOps job is heading toward agent wrangling, and after seeing his setup, the phrase fits. Entire post below, I think it’s helpful to read:

Look at what’s actually left for his team once this system matures. The admin work is delegated to agents. The tribal knowledge is codified in the context layer. The reactive Slack-channel work gets triaged by a router. What remains is designing the system: deciding what context agents get, how they hand off, what they remember, and checking their work.

That’s a real answer to the question I keep chasing: who should own AI inside the GTM org?. At Cursor, it was a growth leader who built a product. At the 11 growth-stage companies I profiled, it was usually a GTM engineer, RevOps, or a technical founder. At Hightouch, it’s RevOps with engineering habits: version control, documentation, composability.

The tools will keep rotating. Nikko is planning for that instead of fighting it. Six months from now, the executor might not be n8n, and the retrieval layer might not be Glean, and for Hightouch, it won’t matter much, because none of the logic lives there.

RevOps is evolving. And I suspect the early-adopter hacker/tinkerer-type builders, like Nikko at Hightouch, will be the people running systems for AI-native GTM teams in the coming years. I’m excited to continue exploring the new playbook being built.

» » »

Thanks to Nikko for sharing the awesome stuff he’s building over at Hightouch (a terrific product/team).

Connect with Nikko Georgantonis on LinkedIn if you want to learn more from him (and he’s currently hiring a GTM Engineer!).

That’s it for today!

Thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

Other posts:

• The head of enterprise growth at Cursor showed me the internal Sales AI he built (they call it “ChatGTM”) that’s helping their SDRs book 3x qualified meetings + decrease AE ramp by 50%+. It’s another example of an awesome in-house build.

• Best of The Signal (my favorite articles) → broken out into categories across AI GTM, GTM Engineering, Prospecting, GTM Tech, & Research Reports)

Subscribe now

The go-to-market industry has spent decades getting very good at one half of the job. We can tell you why you lost the deal. We can tell you which rep is sandbagging, which region is slipping, and which competitor keeps showing up in your closed-lost. What almost none of it does is change what happens on the next call. Exposing a problem is much easier than solving it.

Justin Shriber, Terret’s CEO, has been thinking about this problem space his whole career. He started at McKinsey, where he watched clients drop suitcases full of cash for root-cause analysis, only to watch the deck get put on a shelf to collect dust. Later, he ran large sales orgs at Oracle and LinkedIn and saw the same thing from the other side. Finding the answer is the easy part. Getting a rep in a different time zone, who only talks to HQ 2x/year, to change behavior on a live deal is the hard part.

What Terret is building aims to close this gap—between the right answer and someone acting on it.

And that’s why I’m excited to explore this topic (which is even more relevant in the AI era) in today’s sponsored deep dive on Terret.

Here’s what we cover in today’s post:

• Background: building “Cursor for sales”

• F1 analogy: the analyst, the pit crew, and the driver

• The closed-loop system (and why MEDDIC is dead)

• Build vs. buy: why governance, not effort, is the real argument

Alright, let’s get into it.

Building “Cursor for Sales”

Terret didn’t start here. The company began doing forecasting and conversation intelligence, the same category as Clari or Gong. Somewhere in that work, Justin realized the forecast wasn’t the valuable thing they’d built. The valuable thing was the platform underneath it. Because they were born in an agentic world, they’d built an AI-native system that pulled data from every revenue-facing source and used inference to join and normalize it, without a six-month warehouse project. Today, people call that a context graph or a revenue graph. Terret had one running years before the term got popular.

Once you have this, forecasting becomes just one of many use cases. The same loop runs on whatever question you point it at: why the forecast slipped, why pipeline is stalling in a segment, why one rep’s deals progress twice as fast as everyone else’s, why a product line isn’t landing. Terret is more generalizable than any single point solution. In a recent conversation, Justin told me:

I wanted to build “Cursor for sales.” Cursor doesn’t have one narrow kind of code that you write. And that’s what I was trying to create. Get to the right answer, but then implement it to the point where you actually have a working solution that is delivering a result or an outcome.

Cursor doesn’t lock you into one narrow kind of code. It sits a layer above. Similarly, Terret wants to sit a layer above forecasting, coaching, or competitive intel, to take revenue teams from answer to action.

Terret can stand up a demo on a customer’s own data in 48 hours using just CRM and conversation intelligence, run a POC with real results in two weeks, and fully deploy in a month. Their goal is to show a CRO something about their business that they didn’t already know within those first 48 hours.

F1 analogy: the analyst, the pit crew, and the driver

Justin shared a metaphor to explain how they differentiate in the market.

1. The McKinsey Analyst (”Ask”)

Imagine dropping a McKinsey consultant into your revenue org who has read every email, every document, every CRM update, and listened to every call, with perfect recall. That’s the revenue graph paired with a trained LLM. Ask it why win rates in EMEA dropped last quarter and it can actually answer, because it can pull the lost deals from CRM, the call transcripts from your CI tool, the email threads stuck in individual inboxes, and the product usage from wherever it lives, then normalize all of it. CI tools can’t do that alone. CRM can’t. And building your data warehouse to do it will take half a year and still stumble over unstructured data.

The hard part isn’t the question. It’s that sales has a deterministic half and a non-deterministic half. Art and science. The numbers are deterministic. The why behind them is not. LLMs are great at the why and bad at the numbers. Ask one how much you closed in North America last quarter and it’ll give you a different figure each time, then fold the second you push back. (We’ve all questioned our LLMs and heard them say: “You’re absolutely right! Sorry about that, it’s 12% MoM.”).

Terret’s forecasting legacy is what let them solve this. Forecasting is a quantitative problem, so they already had a deterministic approach to generating numbers. They give the model prescriptive instructions, then run a series of checks to confirm it computed what it was told to. The result is a system that gets the number right every time and explains the why behind it.

2. The F1 Pit Crew (”Operationalize”)

The analyst tells you what to do. The pit crew makes it real for everyone else. This is where playbooks, rep scripting, and the rest of the artifacts get built and pushed out at scale, with no human assembling slides. An answer (even a great one) is worthless if the “insight” just collects dust in an Enablement Playbook in Notion. The pit crew turns it into a motion the whole team can run.

3. The Driver (”Activation”)

The first two get you a great answer and a living playbook. Activation is making sure the artifacts actually get used, which is where most of this falls apart. Hand a rep a script and you have no idea whether they followed it. Terret watches rep behavior against the script, grades it, and feeds specific, evidenced coaching to both the rep and the manager so everyone moves the same direction.

This is the end of enablement as we’ve known it, and the start of what Justin calls “micro-enablement” moments. I ran ops and enablement for a 100+ BDR org at Zoom Video a few years ago, and the model was brutal even then. You’d launch a new product into a new market, run a training, and maybe half the team absorbed it. And the information would go stale a month later, buried in a portal nobody opened again. Micro-enablement flips this on its head. Instead of one stuffy session at SKO with hungover reps in an 8 a.m. ballroom, you get a script before the call, a 30-second grade after it, and a coaching point from your manager that same week. A rep gets more reinforcement on one playbook in a week than the old model delivered in a year, and every touch builds on the last.

Other things you can build when you have an analyst, pit crew, and driver in one continuous loop:

• Run a win analysis on EMEA over the last four quarters, and 3 minutes later you’ll have a root-cause analysis and competitor battle cards of how to overcome them.

• A living playbook built from your best reps actual language that your top closers use, not language a product marketer invented.

• Before a call, the agent scripts an opener pulled from top reps, anticipates the objections she’s likely to hit, and adapts to where the deal is and who’s in the room.

• After the call she gets a scorecard (she scored an 8 out of 10) with evidence of what she did well and what to fix.

• At the end of the week her manager gets a coaching sheet across every deal.

[A side note worth mentioning: Justin thinks the CRO role is about to change shape completely, and he frames it as a shift from Leonard Bernstein to Miles Davis. The old great CRO was Bernstein. A score, a rehearsed orchestra, everyone hitting their notes, and the team that played the written music best won. The market moves too fast for a score now. Miles Davis ran a loose framework and improvised as the music moved under him. “If you were Lenny Bernstein, one of the greats, your career is done,” Justin told me. “You can’t compete in sales like that anymore.” Harsh, but I think this is directionally correct.]

The closed-loop system (and why MEDDIC is dead)

Years ago, when I was running a company, one of my taglines was: “Actions > Insights”. The last decade of GTM was the decade of smarter/better/more “insights.” Endless Looker and Tableau dashboards, scorecards galore, and endless Salesforce reports. All of it sitting there waiting for a human to notice and act. My company wanted to automate the action instead of it sitting in a Tableau dashboard. When I said this to Justin (Actions > Insights), he (graciously) corrected me: “Insights plus actions is the way to build a revenue system today.” He’s right. Insights alone are shelfware. Actions without the insight behind them are guesses. You want both, wired together.

That wiring creates a closed loop. Terret’s agent sits on the calls. When a new objection comes up that isn’t in the playbook, it captures how other reps handled it, and by the end of the day, that response is in the bank. The system knows which questions got asked in deals that closed and which got asked in deals that died, and it feeds that back into the playbook automatically. The playbook isn’t a document someone updates quarterly. It’s a living, breathing thing that learns from what actually works.

Justin believes MEDDIC is dead too. It’s the qualification framework that came out of PTC in the mid-1990s, the one John McMahon is known for, built in part because PTC didn’t have a real product yet and needed rigor to compensate. It’s a great framework. It’s also 30 years old. Why run a static rubric from 1995 when the system can build you a qualification model from what your own closers actually do? Terret can fully automate MEDDIC if you want it, score against it, and suggest the next move. The better version is your own MEDDIC, derived from your top performers, not from a consultant’s template or an enablement manager’s best guess.

Build vs. buy: why governance, not effort, is the real argument

The obvious question from a CRO or a founder is, why not just build this myself with Claude and a few MCP connections? Justin shared what he’s seeing and why building in-house is not the right choice for most companies.

The first problem is governance. Your revenue data lives in systems with completely different access models. Email is user-based. CRM is hierarchical. If you MCP a model directly into each of them, you’re pulling data across those boundaries and trusting the LLM to decide what any given person is allowed to see. That’s a bad bet to make with customer data and competitive data. Terret builds the revenue graph with permissioning baked in, resolved against your CRM hierarchy, so the governance holds.

The second problem is cost. Ask a model to stitch together data from five systems on the fly and you’ve asked it to rebuild a small data warehouse on every single query. That’s how you burn tokens and end up with an unpredictable bill. Terret pre-packages the exact slice of data a given question needs, so the model gets a micro-payload instead of everything. That’s also why Terret can charge a fixed price instead of consumption-based pricing, which is the line that makes the CFO lean in.

The third is concentration risk. Build your stack on one model provider and you’re betting that provider wins. Terret runs a cocktail of models on the back end, swaps in whatever’s best as it ships, and manages that risk for you. You’re not married to one vendor’s roadmap.

None of this means building is always wrong. Stripe builds. Cursor builds. Ramp builds. But there are maybe twenty companies on earth with the engineering depth to build a true in-house solution for their revenue team (and keep maintaining it). For everyone else, building a context graph, a governance layer, and a multi-model router from scratch is a bad use of the next nine months. For reference, doing the same thing on something like Agentforce is a 6-9 month project with dedicated engineers on permanent integration duty. Terret needs your CRM, your email and calendar, and one RevOps person to keep an eye on it.

(Read more here: How to Think About Build vs. Buy in the AI Era | “Build Your Intelligence. Buy Your Infrastructure.” With Owner.com’s CRO, Kyle Norton. And Terret is a great example of infrastructure you should buy to build on top of.)

The takeaway

Terret’s main goal is to be more powerful, cheaper, and faster. Powerful because the analyst, the pit crew, and the driver run as one loop instead of three disconnected tools. Cheaper because of fixed pricing and one vendor instead of <several others> + a warehouse + an integration team. Faster because a playbook that used to take a product marketer six months now takes three minutes (and updates itself).

The answer was never the hardest part in sales. What was: getting the answer into a rep’s hands at the moment they need it, knowing whether they used it, and if it worked. Terret is the first thing I’ve looked at that treats that as the actual product instead of an afterthought. I’m excited to continue to watch what Justin and the team at Terret build in the space.

PS: Below is a 4-minute walkthrough of Terret that I recorded:

If you want to learn more about Terret, reach out to their team (and be sure to let them know The Signal sent you).

That’s it for today.

Thank you for your continued attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

Subscribe now

Thanks for reading this hand-rolled, 100% organic, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → Buying signals from tech stacks, people data, & active projects.

Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

Wild week in gtm-tech land. HubSpot acquired Warmly and Zoom acquired Common Room. This comes just after the acquisition of Pocus by Apollo.io. I suspect consolidation continues to happen in the space.

All the while, more companies are deciding to build certain parts internally. Cursor’s Head of Growth, George Hou, gave us a look behind the curtain of what he built at Cursor (one of the wildest in-house builds I’ve seen).

This week, we’re graced with the presence of another goat of gtm, Kyle Norton. Kyle is the CRO at Owner.com, runs The Revenue Leadership Podcast/Newsletter, and (according to my calculations) is the most AI-pilled CRO in all of SaaS. He recently published a piece titled “Don’t buy your GTM brain” (worth reading in full, if you haven’t already).

The “Build vs. Buy” question is on every GTM leader's mind right now.

So, after reading Kyle’s piece on it, I caught up with him to go a layer deeper on this topic (and how it works at Owner.com). I also share my own experience from the last two years of co-building GTM engines/AI workflows alongside internal teams.

In this piece, we cover:

• How AI changed the calculus in favor of Build>Buy

• The pitfalls of building (it’s not all sunshine and rainbows)

• The risk of outsourcing (buying) your intelligence layer

• Why you can’t outsource your AI strategy

Alright, let’s get into it.

How AI changed the calculus in favor of Build>Buy

For most of the last decade, build vs buy wasn’t much of a debate. Building was slow, expensive, and, unless you had spare engineers and a very specific need, you bought the tool and moved on.

AI changed the calculus. Since the model jump in late 2025 (the 4.6 moment), building went from “expensive, slow, probably not worth it” to a real option. You can spin up a working prototype in an afternoon. Things you would have paid a vendor six figures for, you can now build yourself and customize to your precise needs.

I’ve personally seen this up close. For 18 months, I embedded inside teams to build+ship AI-powered GTM systems (things like: data orchestration, signal-based selling, scoring, routing, ICP mapping, automated outbound, and more). The results of these systems were often magical. I saw the possibility of AI to create real leverage.

The ROI ceiling (with AI) is higher than it used to be. Old sales automation got you a 10-25% bump. The right AI build can double+ a team’s output.

Here’s what Kyle said:

The old build vs buy conversation usually centered on cost, implementation time, customization, and whether engineering had the capacity. Those still matter, but they are incomplete for AI.

The better AI build vs buy filter has 2 categories.

First, infrastructure. These are the parts of the stack where reliability matters more than differentiation. Dialers, core CRM plumbing, enrichment pipes, call recording, data warehousing, identity, permissions, security, and the underlying models in most cases. Buy these unless you have an unusually strong reason not to.

Second, intelligence. These are the parts of the stack where your company’s unique judgment matters. ICP definitions, lead scoring logic, account prioritization, territory design, pre-call research, deal strategy, customer context, coaching philosophy, messaging, qualification standards, and the evaluation loops that determine whether AI output is actually good.

That second category is where I get much more cautious.

At Owner.com, the point is not to build AI for the sake of building AI. That’s AI performance theater. The point is to build systems that make our GTM motion better because they encode what we know about our customer, our market, our reps, and our operating model.

That is why the line I used at SaaStr matters: buy your infrastructure, build or own your intelligence.

“Own” is important because it does not always mean build every component from scratch. You can use vendors and still own the intelligence if you control the data, understand the logic, can export the memory, can evaluate the outputs, and can move the learning if you need to. You can also build something internally and still fail to own the intelligence if it is a fragile one-off workflow nobody understands.

Ownership is not about ego. It is about control, portability, and compounding advantage.

We’ll come back to this point.

The pitfalls of building (it’s not all sunshine and rainbows)

Building is easier now. But also messier. Here are some pitfalls to avoid:

Swimlanes.

Inside a hyper-growth company, it’s never one team executing a tidy little roadmap. At Owner.com, Kyle has three different groups shipping production AI: an applied AI function under BizOps and data, the product org, and RevOps. Kyle shared an example where one team built a tool, but it was incinerating API calls into the CRM, wasn’t compliant with another piece of their stack regulations, and broke part of the rep workflow somewhere else. They understood the adjacent motion well enough to build for it, and not well enough to avoid breaking it. Kyle’s response wasn’t “stop.” It was “build it with RevOps, dedicate me engineers who work only on GTM tech, and do the requirements and roadmap properly.” You can’t have one person YOLO a tool that breaks other things downstream.

You need an actual engineer.

Not a “GTM engineer” in the LinkedIn sense, which has come to mean a Clay-table operator building lists and a few automations. Kyle calls his function applied AI on purpose, to draw that exact line. Once something has to run in production every day, you need real software engineers. Kyle’s discipline is to push everything into GitHub so a human can inspect what exists, and to not run tools whose outputs you can’t see.

Budget for maintenance.

When I was consulting, we would build the engine and then “pass the keys” to the team. But we would have problems after we left if there wasn’t a person (or team) in-house to maintain (and build on) the engine we deployed. Because the systems were complex (and in some cases brittle), a CRO of a Series A company is not going to open the workflow builder to rewrite ICP logic when the market shifts, or debug a chain that broke because something upstream changed. That isn’t a knock on them. It’s not their job, and they shouldn’t have to reverse-engineer a system they didn’t build. But you have to budget for this reality.

Things decay, and some should be killed.

Kyle revisits internal builds around the 90-day mark and asks whether each one is still worth it. They’ve deprecated things. They’ve even killed things and then brought them back. One example: their lead-routing system worked well, then the person who built it got pulled onto other priorities, it degraded, reps drifted back to assigning leads by hand, and they had to rebuild it to win them back.

You need evals.

Evals are how you know the thing actually works. They are often the difference between a V1 that demos well and a production tool reps use every day. Most of the work in closing that gap is boring. When Owner.com built AI pre-call research, the applied AI lead flew to Toronto and sat beside the reps for a week. They would hand a rep a batch of leads, watch them work it, hear “this is weird” or “this is wrong, here’s why,” go fix it, hand them a fresh batch, run it again. The feedback in those sessions becomes the product. Builders focused on these feedback loops are indistinguishable from an early-stage founder building alongside their first customers.

Most teams treat the launch as the finish line. In reality, it’s the starting line. The real cost of “build” isn’t the build; it’s the standing capacity to keep the thing alive after it ships. If you can’t fund that capacity, you should buy.

The risk of outsourcing (buying) your intelligence layer

Buy your infrastructure.

The dialer, the CRM plumbing, enrichment pipes, call recording, the underlying models. The places where uptime, reliability, compliance, and scale matter more than uniqueness. There’s no prize for vibe-coding a mediocre dialer that goes down during a call blitz on a Tuesday morning on the last week of the quarter.

Build your intelligence (or at least own it).

ICP definitions, scoring logic, account prioritization, pre-call research, deal strategy, coaching philosophy, messaging, and the eval loops that decide whether the AI’s output is any good. The places where your company’s judgment is the actual product.

The reason this matters more with AI than it did with old software is that AI systems learn from the workflow and compound. The risk is rented learning. Here’s how Kyle explained it:

The risk is not that AI vendors are bad. Many of them are excellent. The risk is that GTM leaders treat every AI decision like normal SaaS procurement. The normal SaaS procurement process asks: “does this tool solve the problem?”

AI-native procurement also asks: what does this tool learn, where does that learning live, and who controls it?

The worst version is a black box that owns both the workflow and the memory. You get productivity, but the learning compounds somewhere else. The vendor gets smarter across your usage. Your company gets dependent.

Again, that might still be worth it in some cases. But it should be a conscious trade, not an accidental one.

“Own” does not mean “build from scratch.” You can use vendors and still own the intelligence if you control the data, understand the logic, can export the memory, can evaluate the outputs, and can move the learning when you need to. The inverse is equally dangerous. You can build something fully in-house and still fail to own it, if what you built is a fragile one-off that nobody left in the building understands.

Why you can’t outsource your AI strategy

The intelligence layer has to stay yours, and the capability to build and maintain it has to live inside your office walls (digitally). You can’t buy your brain from a vendor, and you can’t outsource your AI strategy either.

Which is why the most interesting thing in my conversation with Kyle wasn’t the framework. It was him. He’s a CRO who gets his hands dirty and thinks like a product leader, and that combination is what future GTM leaders will look like, more and more.

I asked him whether a CRO should know how to build a product roadmap. Two years ago, he would have said, no. Today, he said, “Yes, or at least someone senior on the revenue side has to.” His path into systems thinking came from Shopify, where if you couldn’t speak Product, you were treated as lesser than. He learned the discipline to be taken seriously there, and then realized the frameworks themselves were the unlock as a CRO (customer discovery with reps to build requirements, user stories, something close to Agile inside RevOps, etc.).

Kyle’s results of owning the GTM brain in-house speak for themselves. At Owner.com, an AE at ~$150k OTE brings in roughly $3M ARR. A 20x comp-to-close ratio compared to their competitors running door-to-door motions.

Looking forward

Kyle shared where he lands on the quickly evolving debate of Build vs. Buy:

I am bullish on AI vendors. I am also bullish on internal GTM engineering. The answer is not one or the other. The winning companies will be pragmatic. They will buy a lot of infrastructure. They will use best-in-class vendors where vendors are clearly better. They will move fast.

But they will be extremely deliberate about the intelligence layer. They will know what context matters, what memory should persist, what workflows create proprietary learning, and what parts of the system need to remain portable.

That is how AI maturity compounds. One good workflow becomes reusable context for the next workflow. One evaluation loop improves the next model output. One proprietary memory layer makes every future agent better.

The companies that win AI-native GTM will not have the most tools. They will not be the companies with the flashiest demos.

They will be the companies whose systems get smarter every week because they own the memory that matters.

Don’t build everything but don’t buy your brain.

Buy your infrastructure, build your intelligence. But don’t build a brain you can’t keep alive, either.

That’s it for today!

Thanks to Kyle Norton for the conversation. Go read his original piece, “Don’t buy your GTM brain,” over at The Revenue Leadership Podcast and subscribe to his newsletter + podcast.

And, as always, thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

Related posts:

• Inside “ChatGTM”: Cursor’s Internal Sales AI Used by their 400+ Sales Org (SDRs are booking 3x qualified meetings and AEs are shaving ramp by 50%+. What Cursor’s Head of Enterprise Growth, George Hou, built. And whether you should build your own version.)

• 54% of the Fastest Growing B2B SaaS Companies have a GTM Engineer (Research Report by The Signal)

• 9 Lessons From 11 Growth-Stage Companies That Built GTM Agents In-House (Vercel, Ramp, LangChain, ClickUp, Deel, Vanta & others: what they built, their tech stacks, and what we can learn from them)

• Most Companies Are Using GTM Engineers for “Automated Outbound.” The Best GTM Teams Aren’t Stopping There. (21 real examples)

Subscribe now

Thanks for reading this hand-rolled, 100% organic, farm-to-table (human-written) newsletter.

Presented by:

Bring AI agents, enrichment, and intent data together and turn insights into relevant, timely action. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → Buying signals from tech stacks, people data, & active projects.

Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

George Hou (Head of Enterprise Growth at Cursor) and I caught up recently, and he (sort of sheepishly) mentioned an internal tool he had built for the sales team at Cursor. I (not so sheepishly) asked him to share more. Before I knew it, he was screen-sharing and saying things like “I can’t show you that part,” which, of course, made me all the more curious. :)

I’ve gotten to know George, and a few of the folks at Cursor, over the last year or so, and I see them as some of the most impressive people in go-to-market. Not just by resume, but by how they think from first principles, how they ship, and how little ego they carry. It’s a vortex of talent over there.

George is a legend, and a kind supporter of the work I’ve been doing with The Signal. So, he was down to give me (and y’all!) a peek behind the curtain of exactly what he built (thanks for sharing with us, George 🫡).

ChatGTM is gaining crazy adoption within Cursor’s 400+ person sales org, and it’s helping their SDRs book 3x more qualified meetings and decrease AE ramp time by 50%+.

Here’s what we cover in today’s article:

• What ChatGTM actually is

• Why they built it

• But why not just use Claude Cowork, ChatGPT, or Glean?

• The question on every Revenue Leader’s mind: Build vs. Buy

• Who owns AI x GTM initiatives inside Cursor

• The results across their 400-person sales org

• Three lessons from George

Alright, let’s get into it.

What ChatGTM actually is

Reps describe ChatGTM as AI that already knows their accounts and how they sell. The easiest way to understand is to watch it work, so here’s a day in the life.

• 7:30am, on the subway: their morning digest is waiting in Slack: context on today’s meetings and who’ll be in them, overnight news across their accounts, and key territory trends: usage spikes, fresh signups, new exec hires.

• 8:00am, at the desk: 25 outbound messages are already drafted, each tied to a signal and paired with a landing page personalized for the contact’s tech stack and role. The rep just reviews, tweaks, sends. The send is native to Gmail or Outreach, so there’s no copy-paste required.

• 8:45am, prepping for a call: the brief flags that the exec hates a hard pitch from an article she just published, so the rep walks in prepped on how peers approached her problems.

• 9:00am, on the call: the exec lobs a curveball about migrating off legacy infrastructure the rep has never heard of. A quick question to ChatGTM answers it live. They leave with next steps booked and the exec says she doesn’t need a POC.

• Between meetings: every call already has its recap email drafted and waiting, plus custom follow-ups to the threads that went quiet.

• 3:00pm, prepping tomorrow’s exec meeting: the rep builds the whole business case in one thread: the three why’s, the value drivers, a CFO-ready one-pager and deck. Then he maps the org chart to see who else needs to be in the room and how to reach them.

• 4:00pm: a Slack digest pulls everything worth catching up on: product releases, account updates, DMs. Where a release is relevant to an account, it drafts tailored outreach for them to review.

• Thursday, before the forecast: ChatGTM scans every deal, its notes, stage changes, and next steps, then assembles the forecast and drafts the weekly update for their manager and account team.

• Start of a new quarter, strategizing a new book: the rep kicks off ChatGTM on a research job that would’ve taken weeks: every intent signal, usage trend, past Gong call, and Salesforce record, plus each account’s key initiatives and tech stack. It comes back with a stack-ranked plan for how to spend the quarter.

^{The morning digest reps work from: pre-drafted messages, each with a landing page tailored to the contact’s stack, role, and seniority.}

The feed (UI) is the visible part. Underneath it, ChatGTM goes directly to the sources (eg: Salesforce, Gong, data warehouse, LinkedIn, third-party data vendors, and the open web) and pulls context on demand. This is a very unique approach (more on this later).

Roughly 70% of usage is outbound and account research. The other 30% is more varied (and interesting). One rep describes ChatGTM as her “fleet of agents.” She described it as a manager who coaches her before an external sales call or even an internal forecast meeting (“What are things that my manager will stress test me on?”).

Read more