Subscribe now

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

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

Hey, y’all! 👋

I recently had a chance to sit down with Alec Paul, the founder of SalesBrand.

He’s the guy behind some of the best B2B CEO brands on LinkedIn (like Adam Robinson, Gal Aga, and others). He doesn’t post for them (he’s not a “ghostwriter”). He teaches them how to post for themselves, what to say, and how to say it. Hence: “The Rick Rubin of LinkedIn” (as Sam Jacobs described him). He makes the artist sound like themselves, but better.

I asked Alec to look over my LinkedIn feed and rip it apart. And, apart, he ripped it.

I recorded the conversation (just for myself). But then, after the fact, I realized some other people would find it valuable. So I asked Alec if I could share a summary of our conversation, and he said yes. So, here we are. :)

So, let’s get to it.

Tip #1: ➜ “Double my impressions” is not a silly goal

At the beginning of the call, Alec asked me what my goal was, and I (reluctantly) told him: I want to double my impressions on LinkedIn. I half-expected him to tell me that was a vanity metric.

Instead, he said, “That’s not silly. That’s a great goal.”

But with one important qualifier: it needs to be the right impressions. Doubling your reach means nothing if you’re reaching the wrong people. If your content starts going wide and attracting a general audience that doesn’t match your niche, you’ve traded depth for breadth. And for a newsletter like The Signal, depth is the whole business model. The readers are coming back because the content is made for them, not for everyone.

So yes, chase eyeballs. But measure the quality of the views, not just how many.

Tip #2: Spread your posts out

I was posting three times in one day, then going dark for three days. Alec’s reaction was immediate: stop doing that.

Spread them out. One thought leadership post. One lighter post (more on that later). Consistency matters more than volume spikes. The algorithm rewards it and your audience starts expecting you.

His rule of thumb when you do post more than once in a day: space them at least 4 hours apart. Back-to-back posts cannibalize each other’s reach.

Tip #3: Every post needs to pass the “What is this about?” test in two lines

This one was the biggest takeaway from my conversation with Alec.

Alec scrolled through my feed and kept saying the same thing: “I have no idea what this post is about.” He’d get to line four or five before figuring out the topic. “By then, most people have already scrolled past.”

If a reader can’t tell what your post is about in the first two lines, you’ve already lost them. The hook can’t be an afterthought. It’s the thing that gets people to stop scrolling on their feed.

Related: Alec’s 10% Strong-Opinion Test. If less than 10% of people strongly disagree with you, your opinion isn’t strong enough. The reaction you’re chasing is “Amen, someone finally said that” from part of the audience while others push back.

Tip #4: Screenshot, don’t “reshare”

Alec saw what I’ve been doing and said he’s seen it work for others too. Where you screenshot a tweet, paste it into a LinkedIn post, add your own commentary on top. It consistently outperforms LinkedIn’s native reshare feature (I wish LinkedIn made an effort to make “reshares” a real part of their feed, like it is on X… maybe one day… cc LinkedIns-Product-Team).

The screenshot is the visual hook. Your commentary is the post.

Tip #5: Never double-link

I had a post with both a Substack link and a Luma link. Alec flagged it instantly. “I don’t think I would do the double link.”

One link per post. Pick the one that matters most. If you’re torn, put the secondary link in the first comment.

Tip #6: Cut the link preview

LinkedIn auto-generates a link preview box when you include a URL. It looks terrible and it tanks reach. Alec pointed to multiple posts of mine where the link preview was the problem (see example below).

The fix: use an image instead of letting LinkedIn auto-generate the preview. Put the link in the first comment, or write it as plain text (eg: TheSignal.club; no https://).

Note: If you schedule a post and then edit it after publishing, the link preview often comes back. Watch for that.

Tip #7: Tag strategically, or don’t tag at all

I had a post with a bunch of company tags. Alec’s framework: only tag companies and people you believe will actually engage. Clay and Attention will engage. Salesforce and HubSpot probably won’t.

Too many tags, especially from big companies that aren’t going to respond, makes it look like engagement bait. Small, LinkedIn-active companies and individual operators are worth tagging. The big dogs are busy and don’t care. And that hurts reach.

Tip #8: Link to conversion-optimized pages

I don’t know how to solve this yet (since I use Substack).

Alec looked at my Substack page and said it’s not designed to convert. He’s right. Substack is great for writing and distribution, but the landing pages aren’t optimized for cold traffic.

His recommendation: for gated content (reports, data, tools), link to a dedicated page with an email gate. Not Substack. I may test this in the future. The newsletter link in my LinkedIn bio and profile can still point to TheSignal.club, but when I’m driving traffic from a specific post, it should go to a page that’s built to capture emails.

Tip #9: Collect outcome-based social proof, not compliments

People DM me all the time saying they love my content, and sometimes I share those. Alec’s point: “that’s nice, but it’s not useful for growing.”

The social proof that actually converts is outcome-based. “I attended your MCP webinar last quarter, built an automated account scoring system the next week, and got promoted two months later.” That social proof is a great LinkedIn post. “Your content is amazing” is not.

When someone messages you saying they love what you’re doing/building, dig deeper. Ask what they achieved because of what you shared. Ask what changed. Get the outcome. Then turn it that into a post (with their permission).

Tip #10: Break your newsletters into individual LinkedIn posts

I published a piece called “9 Lessons from 11 Growth-Stage Companies Building GTM Agents In-House.” It did well on Substack (above my average number of views for a piece). Alec looked at it and immediately asked: “Did you break all these 9 lessons into individual posts?”

I hadn’t. I should have. (I still should.)

Each lesson is its own LinkedIn post. “Here’s how Vercel built an inbound AI agent. Here’s the stack they used.” That’s a week of content from one newsletter. I sometimes spend 15+ hours on a Substack piece. But don’t spend any time driving traffic to it (outside of existing subscribers). This is something I need to spend more time doing.

Tip #11: Nichemaxxing

Alec shared an article with me, where TBPN’s Isaac Medeiros coined a term: nichemaxxing. The idea is that if The Signal ever hits 100,000 subscribers, I’ve failed.

That sounds counterintuitive. But it means I’ve gone too broad. I’ve diluted the audience. I’ve started writing for “people interested in business” instead of “B2B GTM operators who want to know how the best teams are using AI right now.”

As Isaac put it:

How do brands win in a world where content is democratized, algorithms feed you perfectly tailored interests, and everyone can compete for attention? The answer is nichemaxxing. Real experts. Real points of view. Real people delivering real value. Things AI can’t easily reproduce.

In a world where AI can generate infinite generic content, the moat is specificity. A niche audience, served by someone with real experience in their exact world, is the one thing that gets harder to replicate, not easier.

This works for a SaaS founder building content as they try to win a market.

Tip #12: “Has changed,” not “is changing”

Small language detail, big positioning implication. I was describing The Signal’s thesis as “the go-to-market playbook is changing.” Alec corrected me in real time: “Has changed.”

He’s right. “Is changing” is passive. It implies you’re watching from the sidelines. “Has changed” is definitive. It implies you know what the new playbook is and you’re going to show them.

The meta point here is: every word in your positioning matters. This one word made the whole thing sharper. You have to take a stance to stand out. Controversial takes get attention.

Tip #13: Video matters, but start scrappy

Alec and I talked about video for a while. His take: Zoom-style talking head video is going to be hard on LinkedIn because the feed is saturated with it. Everyone’s on Zoom all day. They don’t want more of it in their content.

If I’m going to do video, it needs to be either high-production (not necessarily expensive, but better than a Zoom call) or interview-based with screen shares showing real workflows and tools. The visual has to be interesting enough to stop the scroll.

But he also said, “Don’t wait for the perfect setup.” TBPN’s first episode was filmed in a terrible-looking office. Start now, improve over time.

Tip #14: Don’t invest in the company page

I asked Alec if I should be posting more on The Signal’s LinkedIn company page. His answer was fast: “Not worth your effort, probably. You can keep it alive so it looks like you have a presence. But the reach from a company page is a fraction of what you’ll get from your personal profile. And the time you spend trying to grow it is time you’re not spending making your personal content better.”

Anecdotally, I almost never read posts from company pages (I feel like they are ads), but I read plenty of posts from founders talking about their products/markets. People buy from people. Same thing applies here.

A few more from Alec’s playbook

These didn’t come up in our conversation, but they’re worth stealing. I found these when I (Claude) was doing research on Alec’s perspectives:

15. Old Way vs. New Way. Don’t post about your company and how great it is. Contrast how something used to be done with how it should be done now, and cast yourself as the narrator of the shift. Your company becomes a character in your story, not the subject of it. (source)

16. Content Market Fit. Post 10–15 times, then look at which posts drove profile views and DMs, not likes. Double down on those formats. That’s how you find your version of PMF for content. (source)

17. Lead your headline with your title, and use “CEO” not “Founder.” At VP and above, leading with your title means other execs accept connection requests without clicking through. “CEO” also signals more authority than “Founder” on LinkedIn. (source)

18. The first-comment cheat code. Follow 2–3 creators with 100K+ followers, ring their bell, and jump on the post immediately with a substantive comment. An alternative framework, a resource, a real opinion. Not “great post.” Your comment shows up in their audience’s feed, passively. (source)

19. The “steal their audience” search hack. LinkedIn Search → People → All filters → set location + industry → Followers of → add a competitor or industry authority → Show results. Instant ICP list, no Sales Nav required. (source)

20. Don’t hire a ghostwriter. This is Alec’s own position, despite being one of the best in the game: “The main thought leaders write their content. Once you start, it gets easier.” He calls his role “publicist and acting coach,” not writer. (source)

21. AI-written posts have a Welshian accent. His warning on AI tools: “ChatGPT was trained on Justin Welsh, and that’s why 90% of the AI LinkedIn posts you see have a Welshian flair to them.” The tools make everyone sound the same, which undercuts the one thing that actually works: authenticity. Avoid AI-slop! (source)

I believe founders and operators who build authentic audiences on LinkedIn over the next 12 months will have a meaningful distribution advantage over everyone else. The ones who wait will be competing in a much more crowded field.

And this will be even more true, as our feeds fill up with more AI slop with each passing day.

Follow/reach out to Alec Paul to learn more from the guru, directly. He’s legit.

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

See you next time,
Brendan 🫡

Related posts:

• Attention is the Scarce Resource in the AI Era Why More Founders Should Leverage LinkedIn Content in their GTM Strategy

• The Increasing Value of Quality Content as part of the Modern Marketing Playbook

• The Barbell Strategy of Pipe Gen

Subscribe now

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

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

Hey, y’all! 👋

Another dizzying week in AI-land. Anthropic launched Claude Design (60M videos on their launch video on X is bonkers), and allegedly killed Figma overnight (its stock was down 8% on the news). And SpaceX announced a deal with Cursor, for the right to acquire it for $60B later this year, or to pay $10B for work they’re doing together. The companies said they’ll collaborate to build “the world’s best coding and knowledge work AI.” (Oh, and SBF would have been up 15,000x on his investment in Cursor, totaling $114B had the FTX holdings not been sold in a fire sale.)

I can’t keep up. But, keep up, we must. Speaking of…

Every company knows they should be using AI in their go-to-market org. The fastest-growing companies have at least one person dedicated to this role.

Yesterday, while eating my lunch, I was listening to the latest 20VC podcast, and when Aaron Levie went on this rant (clip below), I was screaming “that’s a GTM Engineer!” (or AI Ops. Or <whatever you want to call it>).

The point is, the smartest companies have someone helping their GTM team build leverage through systems, automation, and AI. Instead of just scaling with headcount.

Listen to the 40-second clip below:

It’s different than traditional JTBD of a RevOps person (though this person could sit under the RevOps org).

So, naturally, I went down a rabbit hole that led me to our second Research Report by The Signal.

Here’s the punchline:

→ 54% of the fastest-growing B2B SaaS companies have ≥1 GTM Engineer.

Here’s what’s in today’s Research Report:

• The surface-level count is a trap

• The hidden bench of (GTME) talent

• If you’re hiring one

• Top technologies in GTME job postings

• The companies without a GTM Engineer

• What I think happens next

Alright, let’s get into it.

The surface-level count is a trap

The title “GTM Engineer” is the newest, shiniest label, but the function has existed under different names at Stripe, Ramp, Databricks, and others for a while. Clay didn’t invent the job. But they did standardize the name.

I pulled the numbers across 63 of the fastest-growing SaaS companies I track (OpenAI, Anthropic, Stripe, Ramp, Notion, Databricks, Cursor, Vercel, Webflow, Plaid, and 53 others). When I filtered on the literal “GTM Engineer” title, only 10 companies showed up. That’s the story most people believe: “GTM Engineer” is a Clay phenomenon, everyone else has one token hire at most.

That story is wrong. Once I looked at the actual work instead of the label, 34 of 63 companies have someone doing GTM Engineering today.

When I ran the strict title search first, here’s what came back: Clay (20), Vercel (2), Webflow (2), 1Password, Abnormal, Anthropic, Canva, Databricks, Descript, Miro (1 each).

If I stopped there, the story would be “Clay invented a role nobody else has really adopted.” That’s what most people say when they dismiss GTM Engineers as a fad. It’s also why most hiring managers still think of this as an experiment rather than a new role that is necessary to scale an AI-native GTM org.

But the word “engineer” is doing a lot of work in that title. The companies that have been doing this for years didn’t use the term “GTM Engineer.” They’d often be called “Growth Engineers.”

The hidden bench of (GTME) talent

When I dropped the strict title match and looked at any combination of “GTM” plus “engineer” or “engineering” (regardless of phrasing), the picture changed completely. Shout-out to Sumble, inside Claude Code, for helping me wrangle this data.

A few examples of adjacent titles found:

• GTM Systems Engineer, Senior Engineer / Member of GTM Team, GTM Field Readiness Engineer, Senior GTM Systems Engineer, Data Engineering Manager – GTM, Data Science Manager – GTM, Lead Analytics Engineer for Marketing and Sales, Analytics Engineer – GTM, and GTM Systems Engineer.

If we add in Growth Engineers (Stripe, Supabase, Grafana Labs, HeyGen, Figma, Monte Carlo, Postman, Scribe) and the Hightouch/Fireworks-style “GTM & Growth | Data and AI” ICs where the word “engineer” doesn’t appear in the title, but the work obviously is, it adds another 14 companies (we’ll call these “Tier 2”), and brings the total to 34 companies.

If you’re hiring one

Stop screening by a specific title. The best candidates for a GTM Engineer role right now are often titled Analytics Engineer, Growth Engineer, GTM Systems Engineer, or Data Engineer on a revenue-adjacent team. They maybe haven’t ever applied to a “GTM Engineer” role because the title didn’t exist when they took their current one.

The skills that matter: SQL, API integrations, comfort with tools like Clay and Claude Code, ability to read a GTM motion end-to-end.

If you’re looking for a framework on when to hire a GTM Engineer, I wrote about that last April. The short version: if you have a manual playbook that’s working today, a GTM Engineer can help you scale it. That hasn’t changed. What’s changed is that you have a much bigger candidate pool than “people with the exact title.”

Top technologies in GTME job postings

Here are the most frequently mentioned tools and technologies in GTME job listings:

Using Clay does not make you a GTM Engineer. But, if you’re a GTM Engineer, you likely know how to use Clay. :) And you’ve probably gone down the Claude Code rabbit hole the last few months. Avoid “Gear Acquisition Syndrome.” But at the same time, use the latest tools to give you leverage.

The companies without a GTM Engineer

29 of the 63 fastest-growing private B2B SaaS companies still don’t have a GTM Engineer.

Some are genuinely early-stage (Decagon, Abridge). Some are running lean PLG motions without many sellers.

And others have the role dispersed in other places. For example, I asked Kyle Norton, CRO of Owner, if I was missing something in the research I did, and he told me: “We have people doing the GTME jobs to be done but we don’t call it that. It’s Applied AI and Data Science doing it.”

What I think happens next

Again, 54% of the fastest-growing private B2B SaaS companies have a GTM Engineer.

That’s a pretty wild stat, considering only between 3-7% of private B2B SaaS companies have at least one GTM Engineer on staff (with the lower bound applying when you insist on the literal job title and the upper bound when you include adjacent Growth Engineer and GTM-scoped RevOps Engineer roles). This collapses to <1% at seed/Series A and rises to 8%+ at scale-up and enterprise SaaS. [Source]

This means the fastest-growing B2B SaaS companies are an order of magnitude more likely to have at least one GTM Engineer in-house.

In 12 months, it’s likely the industry will converge on a single title. Maybe “GTM Engineer.” Or GTM Architect, Growth Eng, or something else.

But semantics (on the title) aside, I predict this chart continues to grow over time.

GTM Engineer job postings by year (2022–2026):

*Note: 2026 projection is 826 postings through day 112 of 365, linearly extrapolated to a full-year run-rate of ~2,692. Actual full-year total will vary with hiring seasonality.

The category went from nonexistent to one of the fastest-growing GTM roles in three years.

Every company knows they should be using AI in their go-to-market org to scale without adding too much headcount.

54% of the fastest-growing companies have at least one GTM Engineer—someone dedicated to helping their GTM team build leverage through systems, automation, and AI.

Let’s see what this data looks like in a year. (Or who knows, maybe by then ASI is here, and none of this will matter anyway.)

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

PS

↳ ICYMI, our first Research Report was on: The GTM Tech Stacks of the Fastest-Growing Private B2B Companies. Find the most up-to-date data here: ProspectStack.com/top-tech-stacks. I hope it’s helpful!

See you next time,
Brendan 🫡

Subscribe now

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

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

Happy Friday, y’all! 👋

Things continue to ramp up (including Allbirds—yes, the shoe company—pivoting to an AI company and ripping 600% in a day lol). Plus, potentially the biggest day in AI so far this year: Claude, Codex and Perplexity all with massive drops.

Today’s post is a little shorter than usual, and a seed of an idea that I hope to flesh out more over the coming months. Reach out to let me know how you’re building your GTM motion to support AI agents as a new buyer.

ICYMI: Recap of our live event on Tuesday (including ~7 min videos of each of the 6 presentations) → 6 Ways GTM Teams are using MCPs and Claude/Claude Code Today

Six months ago, if you asked me what an AI-native GTM playbook looks like, I would have said: the same motions as 2022, but supercharged with AI. Better outbound. Smarter enrichment. AI workflows for ICP mapping and tiering. A GTM Engineer running workflows instead of an SDR manually copy-pasting from a spreadsheet. Same motions, faster/better execution.

I don’t think that’s the full picture anymore.

The more I build inside Claude, the more I notice something that should worry (or excite) every GTM leader reading this: I’m not buying the way I used to. I’m buying through agents. And I think a lot of your future customers will be, too.

Here’s what we’re covering today:

• What “AI agents as buyers” actually looks like in practice

• Why the GTM motions themselves change (not just the tools)

• Meet your new buyer persona: “AI Agent Amy”

• What to build for right now

• The asymmetric bet

Let’s get into it.

What “AI agents as buyers” looks like in practice

I use Supabase as my database. I’ve never been to their website. I’ve never requested a demo. I’ve never signed up for a free trial through their marketing site. I discovered it, evaluated it, and started using it entirely through Claude.

Same story with Resend. And a growing list of tools.

And the data backs this up. Lavanya Shukla (formerly Head of Growth at Weights & Biases, now Managing Partner at Improbability.vc) published a piece called The Agent Flywheel that put numbers to what I’ve been feeling anecdotally.

When Claude Code adds email to a project, it picks Resend 63% of the time. It picks SendGrid 7% of the time. SendGrid has been around since 2009. Twilio paid $3B for it. They have a full enterprise sales motion, dedicated IPs, and 15 years of track record. None of that matters to an agent.

Resend launched in 2023 with zero users and now has 500K developers. Supabase went from 1M to 4.5M developers in 12 months. As Lavanya put it, “your product is no longer your UI. It’s your API.”

The companies I keep reaching for are the ones that are most integrated into the agentic workflow I’m already in. They have a robust MCP integration. They have a CLI that actually works. Their API is clean. Their docs are written for machines, not just humans.

I didn’t go looking for these companies. They were surfaced by the tools and workflows I was already building in. That’s a fundamentally different buying motion than anything we’ve seen in B2B SaaS.

Why the motions themselves change

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.

I should note: I don’t think AI Agent Buyers will fully replace Human Buyers—instead, it will be an additional buyer that GTM teams/workflows will need to support.

Here’s a visual we put together to show this “old world” vs. “new world” evolution:

Meet your new buyer persona: “AI Agent Amy”

Every GTM team has the slide. Marketing Mary. CIO Steve. Personas with names and headshots and buying preferences.

I think every company now needs to add a new persona to that deck. I’ll call her “AI Agent Amy.”

AI Agent Amy doesn’t read your blog posts. She doesn’t attend your webinars. She doesn’t click your nurture emails. But she does evaluate your API documentation. She does check whether you have an MCP server. She does look at your developer community to see if real people are building real workflows on your platform.

Right now, AI Agent Amy might account for 1% of your pipeline influence. Maybe less. The bet is whether that 1% becomes 10% in 12 months. Or 30%. Or more than 50%.

If you believe that agentic workflows are here to stay and growing (I do), then building for this persona isn’t optional. It’s an asymmetric bet with huge upside and very little downside.

What to build for right now

This is early. There is no playbook yet. But the pattern I keep seeing from the companies that are winning in agent-first workflows comes down to a few things:

A world-class API and CLI. Not an afterthought, not a v1 that barely works. The real thing, battle-tested.

Native MCP integrations. If your product doesn’t show up inside Claude, Cursor, or the agentic coding tools your buyers are living in, you don’t exist to this persona. Even Uncle Benioff is going this route (honestly, impressive to see). “Our API is the UI.”

Documentation written for agents, not just humans. This means structured, predictable, complete. Agents don’t skim. They parse. And here’s the uncomfortable truth from Lavanya’s analysis: agents will choose a slightly worse product if it’s easier to implement. From the agent’s perspective, a product it can execute is strictly better than one it can’t. Technical superiority means nothing if an agent can’t figure out how to use you.

Community-driven use cases. The companies winning here have active communities showing how to build real workflows on top of their tools. That’s the new word-of-mouth for AI Agent Amy. And it creates a flywheel: developers who succeed with your product publish their configs, other developers clone them, and your tool spreads across thousands of agent deployments at once. Each cycle makes the next one easier.

The asymmetric bet

I want to be clear: I am not saying AI is going to replace salespeople. I am saying AI is going to replace a growing percentage of buyers. The human on the other side of the deal is still there. But the discovery, evaluation, and initial adoption? That’s increasingly happening through agents and agentic workflows, not through your website’s pricing page.

If you believe that trend compounds over time (like I do), then right now is the time to start building for it. Not that you need to overhaul your entire GTM motion tomorrow, but the companies that start now will have a meaningful head start on everyone else in 12 months.

Andrej Karpathy said it best:

“It’s 2026. Build. For. Agents.”

If you’re building new, creative GTM approaches specifically geared toward AI agents as a buyer persona, I want to hear about it. Reach out. I’d love to showcase what you’re building in the coming months.

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

Other nuggets from the week:

Kyle does it again, arguably the most AI-native CRO on planet earth: What World-Class AI in GTM Looks Like

Bret Taylor of Sierra on AI agents, outcome-based pricing, and the OpenAI board - on Cheeky Pint (with John Collison, co-founder of Stripe):

Have a great weekend!

See you next week,
Brendan 🫡

Subscribe now

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

Hey, y’all! 👋

A couple of weeks ago, I put out a post on LinkedIn that basically said: I want to gather some GTM operators to share examples of AI agents/workflows they’ve built using MCPs and Claude/Claude Code. There was a lot of interest, so I put together a live event. Close to 800 people registered. And almost 400 builders joined live (wylin). Six people presented what they’ve built using MCPs inside Claude (across chat, cowork, and code).

And what I saw across all six presentations was a pattern I think most GTM teams are going to feel very soon: the gap between teams that have connected their tools to AI and teams that haven’t is getting wider every week.

MCPs are the connective tissue. They let Claude talk to your CRM, your data warehouse, your call recorder, your prospecting tools. Without them, Claude is smart but blind. With them, it becomes something closer to a second brain that actually knows your business.

• Claude is powerful.

• GTM tools are powerful.

• But when you combine the two, it’s a real “1+1=10” situation.

I had a blast seeing all the creative ways GTM teams are using MCPs to build inside of Claude. It’s a pleasure to learn alongside everyone at this particular moment in time.

I hope this post inspires you to build something for your team. Even if that means you don’t read this entire article. That’d be a win in my book. :)

Each presentation has a video on YouTube (smash that subscribe button on The Signal’s YouTube channel while you’re there 😂).

Here are the use cases:

1. How an SMB AE at Zendesk Uses Sumble + Claude Cowork to Build Micro-Campaigns (Eric Fitz, AE at Zendesk)

2. How Nooks’ RevOps Team Created a Company Brain with Claude Code by Building a DIY Data Warehouse and a custom MCP to query data from HubSpot, Mixpanel, Nooks, and more (Josh Nelson, RevOps/GTM Engineer at Nooks)

3. How Clarify’s MCP Turns Claude into a Full-Cycle Sales Assistant (Vinayak Mehta, Software Engineer at Clarify)

4. How Attention Auto-Clusters Churning Prospects and Triggers Targeted Outreach with Claude Code (Anis Bennaceur, Co-founder & CEO at Attention)

5. How WorkSpan Built a Headless Context Layer so Reps Get Everything They Need Directly in Claude Chat (Sam Gong, SVP Marketing at Workspan)

6. How 25 Agents in Slack Run MintMCP’s GTM Org, Built with Claude Code and Custom MCPs (Jiquan Ngiam, Co-founder & CEO at MintMCP)

Alright, let’s get into it.

1. How an SMB AE at Zendesk Uses Sumble + Claude Cowork to Build Micro-Campaigns

(Eric Fitz, AE at Zendesk)

Eric is an SMB AE at Zendesk. He has 1,800 accounts. Every rep who’s had his territory for the past five years has had the same data. He needed an edge and found it in Sumble.

Eric’s workflow starts in Claude Cowork with the Sumble MCP connected. He uses Cowork (not chat) because it needs a bigger context window. He uploads a CSV of his full account list, then asks Claude to do something very specific: identify which of his 1,800 accounts have call center technology.

Why call centers? Because at Zendesk, if a company runs a call center, they auto-qualify for every other type of support Zendesk offers. It’s the biggest deal type. And until Sumble, there was no tool that could reliably surface call center usage.

Sumble pulls this from a combination of HTML stack detection, job posting data, and historical hiring signals. Out of Eric’s 1,800 accounts, it found 61 companies with call center tags.

From there, Claude finds director-level+ contacts at those companies using Sumble’s MCP, then drafts personalized emails for each one. Eric showed a draft where Claude referenced the prospect’s exact tech stack (TalkDesk, Five9, Genesis) in the subject line. Nobody else is sending that subject line.

Eric also built what he calls the “Zendesk Sales Brain,” a Claude Skill where he pointed Claude at Zendesk’s public-facing Help Center and had it learn every major sales play, competitive positioning angle, and product capability. That context now feeds every prompt.

Eric works in batches of ~30 contacts per micro-campaign. At a 4% reply rate, that’s one reply per batch. If he runs 30 batches, that’s 900 contacts and 30 potential conversations. He drafts them in Claude Cowork, which pushes them into Gmail drafts, and then he sends them from his phone.

Eric said he’s sent roughly 5,000 emails using Sumble-sourced data, and only 10 have bounced. That’s a 99.8% deliverability rate.

He showed an example where the workflow surfaced a contact whose LinkedIn title was “Implementation Manager” but whose actual job description (pulled by Sumble) showed she runs the entire call center. Eric explained how he never would have found her searching by title alone. The MCP is what makes Sumble’s data layer actionable inside Claude rather than living in a separate tab.

• Try Sumble (it’s free) at Sumble.com. Then set up their MCP inside Claude. Have fun. :)

• Connect with Eric on LinkedIn.

2. How Nooks’ RevOps Team Created a Company Brain with Claude Code by Building a DIY Data Warehouse and a custom MCP to query data from HubSpot, Mixpanel, Nooks, and mor

(Josh Nelson, RevOps/GTM Engineer at Nooks)

Josh is a GTM Systems Engineer at Nooks. Small RevOps team. And like most small ops teams, he was drowning in ad hoc data requests. Finance needs a list of CSMs for every invoice. Leadership wants to know how many calls an SDR made that turned into closed-won deals. Everybody wants a report, and the data lives in five different systems. Classic.

So, naturally, Josh decided to build a data warehouse from scratch 🤪. During a hackathon, using Claude Code.

He set up a Postgres database on Render (free tier to start, a couple hundred bucks a month once the data volume grew), then built ETL pipelines that pull data from HubSpot, Mixpanel, Nooks’ own product database, ChiliPiper, and their CPQ tool (Subskribe). The ETLs run every few hours via cron jobs, keeping the database current.

On top of that, he deployed Redash, an open-source SQL query tool. Redash sits on top of the Postgres database and lets anyone write queries against it. And every query in Redash has its own API key, which means Claude Code can call Redash, run a query, and return the result.

Josh showed the progression: drag two CSVs into Claude, ask it to match CSM names to invoices. Two minutes, done. Then he realized if Finance needs that report regularly, why is he still manually pulling CSVs? So he automated the entire thing.

Then Josh built a custom MCP server (also hosted on Render) so his teammates could access the database through Claude’s UI. No terminal. No IDE. Just open Claude, connect to the MCP, and type “How many calls did Noah make this quarter that ended in closed-won deals?” Claude queries Redash, joins the tables, and returns the answer. Within 10 minutes, he had a working MCP with OAuth, and his teammate was querying the database in plain English.

He also figured out how to embed Redash reports into HubSpot dashboards (via iframe). So leadership gets their reports exactly where they already look, and Josh can build custom HubSpot reports that wouldn’t be possible to do natively.

The whole thing would have taken a year and a database administrator two years ago. Josh built it during a hackathon weekend with Claude Code.

(By the way, Nooks is productizing a version of this in their new sales engagement platform. I think they should name it JoshBrain.)

• Check out Nooks.

• Read more details (including costs) here: How I built an interactive company brain for our RevOps team.

• Connect with Josh on LinkedIn.

3. How Clarify’s MCP Turns Claude into a Full-Cycle Sales Assistant

(Vinayak Mehta, Software Engineer at Clarify)

Vinayak is a software engineer at Clarify. Clarify is building an autonomous CRM, and they launched their MCP server a few months ago. Vinayak walked through four use cases, all inside Claude chat.

1. Updating a CRM from text message screenshots.

A couple of Clarify’s customers chat with prospects on iMessage. Instead of going back to Clarify to manually enter deal details, they just paste a screenshot of the text conversation into Claude. Claude reads the image, extracts the relevant info, and uses Clarify’s MCP to create the company, person, and deal object automatically.

2. Prospecting and campaign building.

Vinayak typed a natural language query: “Find me VPs of Sales in New York who work at Fortune 500 companies.” Claude used Clarify’s lead finder, found around 2,000 results, imported 10 for the demo, and created a list in Clarify with full contact details including emails. Then he asked Claude to build a 3-step email campaign for those contacts. Claude drafted the campaign, and because Clarify syncs all your sent emails, it matched the rep’s actual writing style.

3. LinkedIn ad retargeting workflow.

This one came from Chris Eberhardt on Clarify’s marketing team. They run LinkedIn thought leadership ads, and every week LinkedIn sends a list of which companies are engaging most. Chris built a Claude skill that takes that list, sends it into Clarify’s lead finder via MCP, finds people (specifically, their personas: founders and heads of sales) at those companies, and enrolls them in an outbound campaign. Automated intent-to-outreach pipeline. This is a killer ABM play.

4. Parsing contracts to update deals.

After closing a deal, a rep pastes the contract PDF into Claude. Claude reads it, extracts the deal amount, contract start date, signer name, job title, and uses Clarify’s MCP to update all the deal fields automatically. No manual data entry.

Across all four, the pattern is the same: Claude does the thinking, Clarify does the CRM work, and the rep never has to leave the Claude chat window.

• Try Clarify (it’s free) at Clarify.ai. Add the MCP via Claude’s connectors (Settings → Connectors → Browse → search “Clarify”).

• Connect with Vinayak on LinkedIn

4. How Attention Auto-Clusters Churning Prospects and Triggers Targeted Outreach with Claude Code

(Anis Bennaceur, Co-founder & CEO at Attention)

Anis is the Co-founder & CEO of Attention. His thesis: the best outbound intelligence is already sitting in your call recordings (and emails/slacks). Most teams just don’t know how to extract it.

He showed a workflow that starts with one prompt in Claude Code: search Attention’s MCP for discovery, demo, and intro calls from the past 90 days. From those conversations, Claude extracts why prospects are evaluating Attention, what tools they’re coming from, what their compelling events are, and what specific language they use to describe their pain (“your best messaging is not written, it’s found”).

That output gets pushed to internal markdown files (Anis calls it his “second brain”), which Claude then uses to build prospect clusters. Not basic ICP segments. Actual persona pockets with names Claude generated on its own (so cool to see!).

He showed two of them.

• Pocket 1: “The RevOps Builder at a Scaling SaaS Company.”

• Pocket 2: “The Frustrated Veteran.”

These aren’t arbitrary labels. Each pocket includes real examples from past calls, the exact pains those people described, the value prop that resonated, targeting criteria (role, seniority, headcount range) and recommended messaging.

Claude then pushes these clusters into Clay’s connector to enrich the data further: firmographics, growth signals, years of experience, company characteristics. The result is a set of 5–10 hyper-targeted persona pockets, each with its own outreach playbook.

The workflow runs on a schedule. Every day, Claude Code pulls the latest calls from Attention’s MCP, looks for new patterns, updates the persona clusters, and sends a Slack notification with any new learnings or outbound ideas. Anis reviews them in the morning and shares the best ones with the team.

He shared this is how you run outbound experiments that get a K-factor above 1. Every new customer conversation generates new intelligence. A fraction of that intelligence produces a new insight. That insight creates a new micro-campaign. That campaign generates new customers, who generate more conversations.

Attention’s MCP isn’t just a raw transcript dump. Their “superagent” batches analysis across 25 calls in parallel, structures the output for LLMs, and surfaces patterns that a basic call recorder MCP can’t. The quality of the MCP matters just as much as having one. They’re truly building an AI-native GTM product.

• Learn more about Attention at Attention.com.

• Connect with Anis on LinkedIn.

5. How WorkSpan Built a Headless Context Layer so Reps Get Everything They Need Directly in Claude Chat

(Sam Gong, SVP Marketing at Workspan)

WorkSpan is a complex product with a complex buyer. Sam’s team had been experimenting with AI for two years: N8N flows, Clay tables, Claude projects, OpenAI agents. Every deployment required loading context. And that context went stale almost immediately.

Sam looked at Octave (a context layer tool) a year ago and passed. It was a dictionary of objects: products, segments, personas, use cases, competitors, proof points. Filling it out would take weeks of manual work.

Then Octave added an MCP.

Sam got on a one-hour call with Octave’s team, opened Claude Code, uploaded three days of SKO transcripts and workshops, and the MCP auto-populated about 60% of Octave’s objects. The tool went from “I’ll never set this up” to “we can’t live without it” in a single session.

Now Octave is WorkSpan’s shared context layer. Sam updates it from Claude after every product meeting, every positioning change, every new competitive development. One prompt: “Hey Claude, we just released a new integration. Update Octave.” The MCP handles the rest.

Sam showed an account plan for Snowflake that Claude generated using Octave. It identified four potential sales plays, ranked them by relevance, pulled in specific reference customers for each play, and flagged an AWS migration mandate that’s time-sensitive. No rep would have assembled that on their own.

The same Octave context then flows into pipeline reports, rep onboarding, and prospecting flows. Update it once, and it compounds across every AI-powered surface in the org. Sam said it best:

“I would not have bought this tool without the MCP.”

• Try Octave (for free) at OctaveHQ.com.

• Connect with Sam on LinkedIn.

6. How 25 Agents in Slack Run MintMCP’s GTM Org, Built with Claude Code and Custom MCPs

(Jiquan Ngiam, Co-founder & CEO at MintMCP)

Jiquan is the Co-founder & CEO of MintMCP. His team is five people. One AE driving seven-figures in pipeline. They’re running a 1-to-5 human-to-agent ratio across the entire business.

His setup was the most advanced architecture anyone showed. Claude Code runs in a sandbox, connects to all their MCP services, uses GitHub as a long-term memory system, and interfaces with the team through both Slack and scheduled tasks that run on a heartbeat (meaning the agents wake up on their own, do work, and report back).

He showed two agents live in Slack:

• Charlie is their call analysis bot. After every sales call finishes, Charlie pulls the transcript via MCP, runs it against Gong best practices that JQ loaded in, and posts a coaching breakdown in Slack. Notes, next steps, what went well, what to improve. No one has to go into a dashboard. It just appears in the channel.

• Peter is their procurement agent. Peter wakes up every morning and every evening, reviews every active deal, checks every open ticket, and pings the humans (including JQ) with reminders. “Hey, this deal needs attention. Hey, this ticket hasn’t been updated.” JQ joked that sometimes he’s not sure if the AI reports to him or if he reports to the AI.

He also showed a live demo of a Claude workflow that pulls recent LinkedIn (he used me as the example, which was fun), identifies who’s engaging with those posts, cross-references against their ICP, and outputs a Google Sheet of prospects to reach out to. All running through custom MCPs for LinkedIn data, Google Sheets, and their CRM.

Jiquan’s team has 25 agents running across engineering, sales, marketing, and prospecting. They use GitHub as the memory layer, which means agents remember what they did yesterday, last week, and last month. You can train them just by talking to them in Slack: “Do this differently next time.” And they will.

The governance piece is important, too. Jiquan’s company (MintMCP) helps enterprises connect Claude to internal systems with proper auth, permissions, and tool-level access controls. For example, their Attio MCP bundle is read-only. Agents can pull deal data but can’t write to the CRM without human approval. That kind of fine-grained control is what makes the difference between “cool experiment” and “I trust this to run at 6 AM while I’m asleep” at a large company.

• Learn more about MintMCP at MintMCP.com.

• Connect with Jiquan on LinkedIn.

As I watched the six different presentations, there was one clear pattern to me:

1. Connect your data to Claude (safely) → 2. Let it think → 3. Automate what works → 4. Move on to the next idea.

In six months, every serious GTM tool will have an MCP. The ones that don’t will get left behind. And the reps and ops people who are building AI-native workflows—like these six—are going to start lapping everyone else.

Let me know if we should do more of these types of live events.

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

See you next time,
Brendan 🫡

Related resources:

• 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)

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

• The GTM Tech Stacks of the Fastest-Growing Private B2B Companies (Research Report)

Subscribe now

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

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

→ Join 700+ tomorrow for How GTM Teams are using MCPs and Claude/Claude Code.

I’ve written a lot about the GTM Engineer role over the past 18 months. When you should hire one, what they should work on, how most companies are using them wrong, and FAQs about the new role. And, more broadly, AI/innovation.

But I hadn’t seen a company treat these things the way Vanta does.

Vanta created a position called Founder in Residence, GTM Innovation. The person in it, Shashank Khanna, is part product manager, part engineering manager, part hands-on builder. He identifies areas of automation across Vanta’s entire go-to-market org, prototypes the initial solution himself, then hands it off to a team of GTM Engineers who report to him. The main goal is to “build AI-first workflows across sales, marketing, and customer success.”

Shashank’s background is what makes this unique role work. He has a CS degree from UCLA, engineering stints at Amazon and SoFi, and was a startup founder/CEO that went through YC. Tldr: he’s a unicorn hire. Someone who can talk to a VP of Sales about pipeline and then go build the system that fixes it.

In this post, we cover:

• What is an “AI in Residence”?

• What is a state machine?

• V1: Three pillars (eliminate busy work, enable reps, scale best plays)

• V2: The state machine approach and Vanta’s in-house AI SDR

• How Vanta decides what to build next

• Vanta’s first-party data advantage

• The AI in Residence org chart

• Takeaway

Alright, let’s get into it.

What is an “AI in Residence”?

I went back and found Christina’s (CEO of Vanta) original post (see below) about their search for an AI in Residence:

A few things stood out to me when reading this:

1. It’s a tops-down initiative (from the CEO directly). True, full-on AI transformation has to be done this way, in my experience.

2. This is new, weird, uncharted waters. An entrepreneurial-type person is required.

3. AI-first workflows across all GTM departments (sales, marketing, customer success), not just pipe gen.

Very cool jd. I hope—and expect—to see more like it. We’ll get more into the specifics of the role, and where it sits, towards the end of this post. But first, what is Vanta building with this role?

What is a state machine?

Last week, when I asked Shashank how Vanta thinks about applying AI across their go-to-market org, he told me the core framework is: treat your GTM motion like a state machine.

A state machine is an engineering concept. At any given point, a system is in one defined “state.” When certain inputs change, the system transitions to a new state. Think of a vending machine: it goes from “waiting for money” to “item selected” to “dispensing.” Each transition is triggered by a specific input.

Shashank’s argument is that most GTM workflows already behave like state machines. We just haven’t modeled them that way.

Take outbound. At any given point, there’s an optimal combination of ICP, persona, signal, and play. When a relevant event happens (a new competitor launches, a regulation changes, funding dries up), the optimal state shifts. Your ICP scoring should change. Your personas should change. Your messaging should change. Most teams adjust these manually, slowly, if at all.

Vanta is trying to model these systems programmatically so they can adjust automatically.

V1: Three pillars

When Shashank’s team started, they organized their work around three pillars:

1. Eliminate busy work → Take the repetitive, time-consuming tasks that reps do every week and automate them.

2. Scale best plays → Identify what’s working for individual reps and deploy it across the org.

3. Enable reps to build their own agents → Give reps access to tools so they can experiment on their own.

Each of these pillars produced real, live systems that are running today.

By the way, last month I wrote about 3 AI workflows Vanta shipped in a single day (during a Clay hackathon); you can find them here: 9 Lessons From 11 Growth-Stage Companies That Built GTM Agents In-House.

Eliminate busy work (example: the QBR workflow)

This is Vanta’s most popular automation. Before this existed, CSMs and AMs would spend 2-4 hours per week preparing for QBRs. They’d manually pull customer data, check product adoption, assess health metrics, look for upsell opportunities, and build a deck.

Now there’s a button in Salesforce that does all of it. One click. Magic.

When a rep clicks it, the system runs account research using Clay, Snowflake, and Workato as an ETL pipeline, with LLM calls (via Anthropic’s API) at each stage. It checks the customer’s progress within Vanta (how much of their SOC 2 is complete, risk indicators, health metrics), identifies upsell opportunities (did they raise funding recently?), and generates a formatted slide deck using Google Slides and Google Docs APIs.

The automation has been triggered over 1,500 times since launch. Vanta has since expanded the same pattern to pre-call decks, post-call decks, and value engineering workflows.

Enable reps (example: Dust.tt and bottoms-up agent building)

For the third pillar, Vanta chose a platform called Dust.tt and gave every rep access. No formal training program. No mandated use cases. Just: “here’s the tool, experiment, go build.” (Dust just published a case study about how Vanta uses them if anyone wants to learn more.)

The value of this approach is less about any individual agent a rep builds and more about the signal it generates for Shashank’s team. The tacit knowledge of the best reps is stored in their brains today. An exercise like this codifies it. And then, when you see organic adoption of an agent across the rest of the team, you know where to double-down. We’ll talk more on how this feeds prioritization below.

Scale best plays (example: signal detection and social listening)

Vanta uses Clay Audiences to monitor what they call “interesting events” across their prospect and customer base. Champion job changes, funding rounds, headcount shifts, etc. (changes in a rep’s book of business).

These events get routed through a tiered alerting system.

• Tier 1 signals go directly to an AE.

• Tier 2 might go to an SDR.

• Unowned accounts get round-robined.

And so on.

The events themselves are stored as objects in Salesforce, so when a rep opens an account, they can see the full history of what’s happened.

This isn’t AI in the generative sense. It’s data engineering (deterministic steps) combined with smart routing. But it’s the kind of infrastructure that compounds over time as the signal library (and learnings from outcomes) grow.

V2: The state machine approach

V1 was about automating individual workflows. V2 is about connecting them.

The state machine framing means modeling entire GTM functions (SDR, AE, post-sales, even paid spend) as systems with defined inputs, states, and transitions. The AI SDR is the first full implementation of this idea.

Vanta’s in-house AI SDR

Vanta made a deliberate decision to build their AI SDR in-house rather than buying an off-the-shelf tool. Shashank’s reasoning: once you’re at a certain scale, the art of understanding what resonates with your specific buyer is too nuanced for a generic product.

The system works like this:

• Start with TAM. Load accounts into a Clay table. Filter by size, geography, existing opportunities. Scrape each website to confirm they’re alive, they sell software, the founder still works there. Enrich, ICP score, run AI research, and do a compliance gap analysis (specific to Vanta’s business: does this company have SOC 2? Do they have a competitor badge on their site?).

• If the score passes the threshold, the system finds relevant contacts and classifies them by persona. Vanta has defined archetypes internally (”Suzy Security,” “Emilia Engineer,” “Forest Founder”) and the outreach sequence is mapped to the persona, the company’s compliance posture, and the signal that triggered the play. A competitor customer gets a competitive rip sequence. A fresh Series A with no SOC 2 badge gets a different approach entirely.

• Emails send automatically through Outreach from individual rep accounts. LinkedIn tasks get queued for reps to send manually (Vanta is a security and compliance company, so they won’t use tools that operate in gray areas like automated LinkedIn messaging), and call steps also created as tasks for reps.

One smart decision: the AI SDR only works accounts that are not in Salesforce. No owned accounts, no existing opportunities. This eliminates territorial friction with human reps and creates a clean environment for testing. They can compare AI SDR performance against the rest of the SDR org without contaminating either dataset.

Shashank was candid that results are still TBD. The system is live but early. He could come back next month and say they shut the project down. That kind of intellectual honesty is refreshing when every company wants to claim their AI initiative is 10x-ing pipeline. (I’ll report back on this one!)

For the AI SDR specifically, they track open rates, meeting booked rates, opportunities created, and emails sent, benchmarked against the human SDR org. My prediction is, reps won’t get replaced entirely, but they’ll be augmented with tools like this, especially in down-market (SMB) segments.

How Vanta decides what to build next

Shashank’s team serves sales, post-sales, marketing, RevOps, and customer success. If they purely stack-ranked projects by revenue impact, sales would win every time and post-sales would get nothing.

So they balance two things: objective impact to the business (pipeline generated, revenue influenced) and coverage across departments. RevOps gets AI-powered rules of engagement resolution (an agent that detects ROE escalations and provides initial resolution). Post-sales gets a customer success platform with churn risk models and upsell detection. These projects may never move the top-line number directly, but they keep the whole org moving forward.

The Dust.tt experimentation layer also feeds prioritization. When a rep-built agent gets organic adoption, that’s a signal to the central team that the workflow is worth investing in.

Shashank’s team catalogs every SDR workflow across EMEA, APJ, and North America, identifies tasks that reps already do manually, and automates them. The baseline outcome is to save reps X hours per week.

Vanta’s first-party data advantage

One thing that stood out to me (and worth calling out) is that Vanta has a massive first-party data moat feeding all of this.

With hundreds of reps running outbound sequences, they have deep data on what works. Open rates, reply rates, meeting booked rates, closed-won rates, all segmented by persona, sequence, geography, and company profile. Add Gong call recordings on top of that, and you have a system that can learn which messaging resonates with which buyer at which stage.

This is why the state machine framing makes sense for a company like Vanta but would be premature for a 5-person startup. You need volume to make the model valuable. Vanta has the volume.

The AI in Residence org chart

Shashank operates like an early-stage founder inside a scaled GTM org. He owns planning, roadmap, hiring, enablement, and the actual engineering work. His team of GTM Engineers each specialize in different areas of the motion, and Shashank builds the first version of every major project before handing it off.

The backgrounds of the GTM Engineers on the team vary. Some come from software engineering. Some come from business systems and RevOps. Some are more comfortable with point-and-click tools, and others write code. Shashank believes you can’t hire the perfect candidate for this role. Instead, you build the team in aggregate. Pair the person with deep sales context with the person who can write Python. The composition of the team matters more than any individual hire.

Enablement is a big part of the job that doesn’t get talked about enough. Shashank spends significant time in all-hands meetings, 1-on-1s with reps, and sessions with sales leaders, selling the tools his team builds internally. The best automation in the world is useless if reps don’t adopt it. (I’ve seen this first-hand, and it’s painful). Vanta’s approach is to make minimal changes to existing rep workflows whenever possible, reducing the friction of adoption. Meet them where they’re at.

My personal take on comp: If a GTM Engineer’s work directly generates pipeline and revenue, tying comp to outcomes aligns incentives in a way that base salary alone doesn’t. Companies that figure out the right comp structure (high upside potential for performance of outlier experiments/agents) for this role will attract better talent, imho.

Vanta is hiring GTM Engineers

If you want to build at the bleeding edge of AI and GTM, Vanta is hiring GTMEs right now. Shashank was kind enough to give us a look behind the curtain on the way Vanta is building their AI-native GTM engine. So, hopefully as a thank you a few great candidates come their way! :) Reach out to Shashank directly or apply on Vanta’s careers page.

Takeaway

Vanta’s approach reinforces something I keep seeing across the best, AI-native GTM orgs: AI isn’t a one-time project. It’s a new operating model.

The companies treating it as a one-off initiative are getting lapped by the ones building internal teams, modeling their GTM motions as systems, architecting infrastructure, and iterating continuously. The job is to get everyone up the (AI) ladder as fast as possible.

The Founder in Residence title is a signal in itself. Vanta isn’t assigning AI to an ops analyst as a side project. Or giving ChatGPT/Claude licenses to reps and saying “go use this and share what you learn!” They created a dedicated role with real scope, an engineering team (big resource investment), and a mandate to rethink how the entire go-to-market org operates.

I could see every company north of $50M ARR have some version of this role in the next year or two. The ones that build it now will have a compounding head start on everyone else. It’s moving from giving reps AI to use, to using AI as core infrastructure to run a modern GTM org.

As always, thank you for your 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.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

Hey, y’all!

Big month in tech/gtm-land so far. Apollo acquired Pocus. Rox acquired Persana AI. Inflection acquired Keyplay. Consolidation szn continues. Todd Bussler (CEO Champify) joined Clay’s Enterprise Sales team. Florin Tatulea joined ZoomInfo as GTM Engineer in Residence. And 46 more companies launched an “all-in-one sales tool.”

Meanwhile, Claude announced they passed $30B ARR (adding $11B in a month (!!!)). And their latest model is “too powerful to release.” Marketing play? Idk. Oh, and yesterday they launched agents too. Dario and crew are absolutely cooking.

Register for The Signal’s event on Tuesday: How GTM Teams are using MCPs and Claude/Claude Code.

I’m amped to unpack today’s topic.

For the last couple of years, with almost complete unanimity, the founders and revenue leaders I speak with agree that the old GTM playbook no longer works.

What’s more interesting is the conversation that follows. The “well then, what does work today?”

There’s a new playbook starting to emerge. I’ve seen it. And now that I see it, I can’t unsee it.

At its core, it’s an AI-native playbook. What it looks like is being written in real time. One way to think about it: by the end of 2027 “the 30 ways every GTM org should be using AI” will be very clear. But that playbook doesn’t exist yet—not fully.

A handful of these “30” are established today (eg: AI inbound, CRM enrichment, etc).

What’s most exciting to me, most energizing, is shining a light on the companies that are building the new playbook right now. These are companies that decide to reorg around becoming AI-native. When you look at Block (led by Jack Dorsey), Shopify (led by Toby), or Intercom/Fin.ai (led by Eoghan taking the reins again), it’s clear that even incumbents can—and have to—“re-found” themselves from first principles with the tools at our disposal today. I mean, my gosh, just look at this chart of Intercom:

And of course, there are companies that started in the last few years that are uniquely able to get way ahead and reach revenue milestones that we’ve never seen before, like Cursor, Lovable, Harvey, and others.

This week, one of the most AI-native orgs, Ramp, released an article worth unpacking. Written by Geoff Charles, Ramp’s CPO, the title is “How to Get Your Company AI Pilled.” My mind started racing to how GTM Teams can/should adopt this framework. So, I decided to steal… or I mean borrow… the piece and adapt it specifically to: How to get your GTM team AI pilled.

Here’s what we’re covering today:

• The numbers behind Ramp’s AI transformation

• AI proficiency is a learning curve, not a light switch (and what that means for your GTM team)

• “Creative destruction” (your GTM stack’s shelf life will shrink)

• Hub and spoke: how to organize your GTM team around AI

• Give your GTM team a stage, not a mandate

• Remove every constraint between your people and AI

• What this means for every GTM org right now

Alright, let’s get into it.

The numbers behind Ramp’s AI transformation

Some context on what Ramp has actually done. Ramp’s AI usage is up 6,300% year over year. 99.5% of their team is active on AI tools. 84% use coding agents weekly. They shipped 1,500+ apps on an internal platform in six weeks, from 800+ different builders. Non-engineers now account for 12% of all human-initiated PRs on their production codebase, thousands per month, using Ramp Inspect, their home-built coding agent.

They did this by modifying their hiring process and talent management. They gave everyone unlimited budget to build, learn, and experiment. They created leaderboards. They reorged teams around the people who see the future. They celebrated wins at all-hands. They pushed every single person and leader to build.

This is a $32 billion company. Operating like a startup when it comes to AI adoption.

Now, most GTM orgs reading this are not Ramp. But the principles behind what they did apply to every revenue team trying to figure out AI.

AI proficiency is a learning curve, not a light switch

Geoff lays out four levels of AI proficiency at Ramp:

• L0 (sometimes uses ChatGPT, hasn’t changed any workflows)

• L1 (built custom GPTs, dabbled in Claude Code)

• L2 (built an app that automates part of their job, committed code), and

• L3 (systems builders who build infrastructure that levels everyone else up).

So for GTM teams, this might looks something like this…

• L0 is the SDR who uses ChatGPT to rewrite a cold email. Fine, but not compounding.

• L1 is the RevOps lead who has built custom GPTs for objection handling and started using Clay for enrichment.

• L2 is the GTM Engineer (or the ambitious ops person) who has automated a signal-based outbound workflow end to end, from trigger to personalized sequence.

• L3 is the person who builds the internal systems that make every rep more effective: the enrichment waterfalls, the scoring models, the automated QA on pipeline (infrastructure running revenue org, and agents in production).

Most GTM teams I’ve worked with or spoken with have a few L1s and maybe one L2. Almost nobody is at L3. And that’s the what to aim for on the learning curve.

As Geoff puts it: the job is to get everyone up the ladder.

Three things make that possible at Ramp, and they translate directly to GTM: start with tools that meet people where they are (low bar, high value), raise expectations as tools mature, and match the mandate to the tooling. If you tell your AEs they need to be using AI but your CRM doesn’t have an AI layer and your enrichment is still manual, you’ve burned credibility before you started.

“Creative destruction” (your GTM stack’s shelf life will shrink)

Geoff said that many of the tools Ramp shipped in January 2026 were already obsolete by the time the article came out in April, replaced by better versions, often from the same builders. They’re comfortable with a shelf life of weeks, not months.

Their data democratization journey illustrates this well.

• Phase 1 was Notion AI over piped data.

• Phase 2 was a Slack-based Snowflake research tool.

• Phase 3 was encoding that research into coding agent skills.

• Phase 4 is making data research interactive and self-improving. Each generation made the last one irrelevant.

Now apply that to GTM. How many teams are still running the same outbound stack they set up 12 months ago? The same sequences, the same enrichment logic, the same qualification criteria? In a world where Clay ships new integrations weekly, where LLMs get meaningfully better every quarter, where new agent frameworks launch every month, a static GTM stack is a depreciating asset.

The best GTM teams I’ve seen are treating their workflows the way Ramp treats their internal tools: build it, use it, learn from it, replace it when something better becomes possible. The teams still running “set it and forget it” automations from mid-2024 are falling behind.

Hub and spoke: how to organize your GTM team around AI

Ramp tried centralized first (one team builds everything), then decentralized (every team builds their own). Both failed. The answer was a hybrid: a small central team builds the platforms and plumbing, while functional teams build on top and feed the roadmap.

For GTM orgs, this maps cleanly. The “hub” is your GTM Engineer, RevOps, or a small AI/automation team. They own the data infrastructure, the enrichment pipelines, the integrations, the shared workflows. The “spokes” are your reps (XDR, AE, AM, CSM) building on top of that infrastructure for their specific use cases.

Ramp’s results from this model are worth noting. A risk analyst automated 16 hours per month of financial modeling. A sales ops lead replaced a spreadsheet-based comp model across three orgs in 48 hours. An L&D lead built a training simulator in 15 minutes. Someone in finance built a contract reviewer that saves 45 minutes per contract. None of them were engineers.

An AE can now build their own account research workflow. A CSM could automate renewal risk scoring. A demand gen lead can build a micro-campaign generator. These people don’t file a ticket. They find their own pain and build. The hub’s job is to make that possible by operationalizing and scaling those learnings. Or else they’ll just be one-off projects or shelfware.

Give your GTM team a stage, not a mandate

“Mandates decay. Culture is what remains.”

At Ramp, they built the culture through visibility. A Slack channel (#ramp-uses-ai) that now has 1,000+ members and spawned 40+ team-specific channels generating 20,000 messages per month. AI office hours every Friday with 40-50+ people showing up. AI onboarding for new hires, rebuilt four times as ambition grew. All-hands sessions where everyone from the CEO to a first-line operator demos what they’ve built.

The competitive dynamic this created was powerful. Ramp found that their top AI users are often their highest performers. AI proficiency compounds like any other skill: the more reps you get, the better you become.

Office hours help. Workshops help. But the single biggest unlock is getting someone to experience a real result on day one. The best teacher is the AI itself, by the way. :) For example, if you’re in a tool and don’t know how to do something, ask Gemini (top-right of Chrome) for help. It’s magic.

For GTM teams, this means don’t start with a training deck on “how to use AI for sales.” Start by getting your reps a tool that solves a real problem they have today. Account research. Prospect enrichment. Call prep. One win on day one does more than a month of enablement sessions.

You want your AEs sharing their AI workflows in Slack. You want your top-performing SDR showing the team how they built a prospect research agent. You want your RevOps lead demo’ing a new AI workflow at the team standup. Public building creates a flywheel that no mandate or training session can replicate.

Geoff said that on every team, there’s one person, the ambitious sales ops lead, the frustrated product operator, the eager data scientist who gets curious, gets sucked in, and becomes a contagion for their teams. Find those people. Make them visible. Give them resources.

Remove every constraint between your people and AI

Geoff says the number one way companies kill AI adoption is by treating it like a procurement decision. Budget approvals. IT reviews. Token limits. Connector requests that sit in a queue for weeks.

Ramp took the opposite approach. They treated AI usage as an infinite learning budget, killed token limits and access restrictions, and removed every IT bottleneck on connectors. Their cost math is worth repeating: token consumption per employee isn’t even close to double-digit percentages of their salary. If someone is 2x more productive with AI, you should be willing to spend their entire salary again in tokens.

Remove all friction across the GTM org. Let your sales rep try that new AI tool without requiring a long procurement process. Top-up your SDR who hit their Clay credit limit mid-month. Allow your RevOps lead to connect their CRM to an AI agent that IT is trying to block. Every one of these is a wall between your team and their next breakthrough.

What this means for every GTM org right now

Ramp didn’t start with a master plan. In Geoff’s words, all they had was a culture and talent, and they kept doubling down on what was working. And watched it compound.

That compounding came from the intersection of all these things reinforcing each other: better tools, higher expectations, more visibility, fewer constraints.

Get your GTM team to at least L1, then give them the tools and freedom to reach L2. Build a hub (even if it’s one person) that handles the infrastructure. Create a stage where builders are visible. Remove procurement friction. And most importantly, accept that whatever you build today should be better in 90 days. If your outbound stack from Q1 still feels state-of-the-art in Q3, you’re not moving fast enough.

The gap between AI-native GTM teams and everyone else is widening every quarter. And it’s not because of the tools. The tools are available to everyone. It’s the culture, the expectations, and the willingness to keep rebuilding.

The most important lesson from the whole article is the simplest one: just get started.

The best time to plant a tree? 20 years ago.

The second best time? Today.

By the end of 2027, the top-performing GTM orgs will look nothing like they do today. The ones that start building now will have a compounding head start that’s impossible to catch. You just have to keep building.

Top Posts of the Week (Claude edition) 👀

• Claude Skill built for Hightouch’s GTM team: Automated account intelligence alerts. By Nikko Georgantonis.

• How to use Claude for RevOps. By Hassan Irshad.

• “I’ve used Claude Code for every day for the past two months. 90%+ of GTM work can now be done here.” By Rees Bayba.

• Tyler Larson, on Monte Carlo’s sales team (zero coding background) built a fully automated renewal portal in a day.

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

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

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

Happy April Fool’s Day (aka: Who has the most creative marketing team Day)!

One quick thing before we jump into today’s Research Report (which took over 30 hours of research), register for our webinar/hackathon on April 14th: How GTM Teams are using MCPs and Claude/Claude Code.

(We’re capping it at 300, and we already have 184 registered—just announced today).

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

65% of the fastest-growing private B2B companies use Clay. Zero use an off-the-shelf AI SDR.

We analyzed the GTM tech stacks of 62 of the fastest-growing private B2B companies to find out what the best companies actually use. The results challenge a lot of conventional wisdom about what a modern GTM stack looks like.

We pulled technographic data from Sumble, enriched with Clay, and used Claude to cross-reference customer logo walls, case studies, review sites, and vendor websites across dozens of GTM tools.

The result:

(Side note: this is the kind of research that would have taken weeks to do manually. Having access to tools like Sumble, Clay, and Claude made it possible to build and verify this entire dataset in a fraction of the time.)

The best way to view the full interactive dataset (searchable, sortable by valuation, headcount, sales team size, and number of tools) is to visit: ProspectingStack.com/top-tech-stacks.

This post covers the highlights and takeaways:

• The companies in this dataset

• Three companies’ GTM stacks worth studying

• Top categories:

  • CRM

  • Sales Engagement

  • Data Enrichment

  • Intent & Signals

  • Data Orchestration

  • Dialers

  • AI SDRs

  • Data Infrastructure

• The default stack

• What this data tells us

• The full dataset

Alright, let’s get into it.

The companies in this dataset

We built the list of fast-growing (private) B2B companies by looking at a combination of revenue growth and headcount growth. And used several sources, including lists like the Forbes AI 50, Forbes Cloud 100, CNBC Disruptor 50, and Enterprise Tech 30. The companies had to be doing at least $10M ARR and not public.

We plan to update this list over time.

Three stacks worth studying

Before we get to the category-level analysis, here are three stacks that stood out.

Rippling (31 tools, 4,947 employees, $13.5B valuation) has the largest GTM stack in the dataset. They run the full traditional stack (Salesforce, HubSpot, Gong, Outreach, Salesloft, ZoomInfo) alongside modern tools (Clay, Common Room, Amplemarket, Nooks). They also have deep data infrastructure (dbt, Snowflake, Fivetran, Airbyte, Census, Hightouch, Segment). This is what a mature, heavily-invested GTM org looks like.

Vercel (28 tools, 724 employees, $3.5B valuation) punches way above its weight. A 724-person company with 28 GTM tools and 4 data orchestration platforms (Zapier, Make, n8n, Tray.io, Workato). They’re running Clay, Sumble, Common Room, and Fireflies alongside the traditional stack. This is a company that’s automating its GTM motion aggressively. We wrote about the agents Vercel built in-house in our last post: 9 Lessons From 11 Growth-Stage Companies That Built GTM Agents In-House.

Drata (24 tools, 581 employees, $3.0B valuation) shows what a lean but sophisticated stack looks like. Every tool has a clear job: 6sense + Demandbase for intent, Clay + ZoomInfo + Apollo + Clearbit for data, Outreach for sequencing, Gong for conversational intelligence, and Clari for pipeline visibility.

Again, you can see the full GTM tech stack of any company in the dataset at ProspectingStack.com/top-tech-stacks.

CRM

Salesforce and HubSpot run everything

Every single company in this dataset runs Salesforce. 100%. HubSpot is right behind at 95%. Most run both (HubSpot for Marketing, in many cases).

Modern CRMs like Attio are starting to appear, but they’re still in single digits.

Uncle Benioff’s grip on the growth-stage and scale-stage B2B market is inescapable.

Sales Engagement

Gong is the most adopted GTM tool after CRM

This one surprised me. Gong at 84% adoption is ahead of Outreach (71%) and well ahead of Salesloft (40%). Gong has become the default operating system for how these companies understand their customer conversations. Though more companies are starting to layer in Attention.com on top (or replacing Gong in some cases).

Outreach leads sequencing at nearly 2x Salesloft’s adoption rate. Clari shows up at 37%, which makes sense for companies at this stage that need forecasting rigor. Worth noting: Clari and Salesloft recently merged. Yet another consolidation move in a category that used to have clear lanes. That means a single entity now touches 77%+ of these stacks across both forecasting and sequencing.

Amplemarket is the newcomer at 8%, showing up at early-adopters like Rippling, Vanta, and Deel.

Data Enrichment

Clay is now the #2 data tool, ahead of Sales Navigator

ZoomInfo still leads at 73%. But Clay is on their heels at 65%, ahead of Sales Navigator (57%), Clearbit (41%), and Apollo (24%).

Clay went from “that cool/weird Clay table thing” to a core infrastructure tool at nearly two-thirds of the fastest-growing private B2B companies. Companies like Ramp, Rippling, Grafana Labs, Drata, and Notion are running Clay alongside (or replacing parts of) the traditional enrichment stack.

Intent & Signals

6sense and Demandbase still dominate, but the category is fragmenting

6sense (38%) and Demandbase (32%) still own the intent category. They’re the two that show up in nearly every mature stack.

But a new class of signal tools is gaining traction. Common Room (19%), Sumble (11%), and Unify (11%) are showing real adoption at these companies. They’re smaller, lighter, and more tightly integrated into sales workflows than the traditional ABM platforms.

You could argue Clay should also be included in this category, but we decided to exclude them, and focus this section on the purpose-built signal and intent tools: the legacy ABM platforms vs. the newer signal-native tools.

As I’ve watched this space evolve, it’s clear that (marketing) intent data is becoming less valuable for sellers, and are being replaced by more transparent (sales) signal providers.

Data Orchestration

This is where RevOps/GTM Engineers live

65% of these companies use Clay. And over half use Zapier (54%). Workato is at 41%. Make at 21%. n8n at 19%. Tray.io at 16%.

This is the connective tissue of the modern GTM stack. The way these companies wire together their enrichment, sequencing, CRM, and intent tools is where most of the operational value comes from. And it’s exactly the layer that a GTM Engineer owns. Without thoughtful architecting of data orchestration, automation/agentic workflows will break (eg: sending emails to customers that shouldn’t be receiving them, false internal alerts to reps, bad data in reporting, etc.).

The companies with the most tools in this dataset aren’t just buying more software. They’re building autonomous workflows, which are only possible because of the unsexy work of data orchestration.

Dialers

Most of these companies don’t cold call (yet)

Orum shows up at 7 companies. Nooks at 6. The vast majority of these companies don’t have a dialer in their stack yet.

Which makes sense based on the profile of these companies. Many of them are product-led or inbound-heavy companies where cold calling isn’t a primary motion. But for the ones that do run outbound via cold calls, Orum and Nooks are the two names that keep coming up.

AI SDRs

Zero adoption (so far)

None of the companies use an off-the-shelf AI SDR.

These companies are building custom outbound workflows with Claude + Clay + Outreach/Salesloft (see: 11 Growth-Stage Companies That Built GTM Agents In-House), not buying autonomous agents.

That likely says more about the technical DNA of these companies (they have the engineering talent—including GTMEs—to build in-house) than it does about the AI SDR category, which is still early and finding its footing at different company profiles.

Data Infrastructure

The invisible foundation

One thing that jumped out: dbt and Snowflake are nearly as common as Gong. dbt shows up in 84% of these stacks. Snowflake at 79%. Fivetran at 48%. Segment at 43%.

These aren’t GTM tools in the traditional sense. But they’re the plumbing underneath the GTM stack. The companies that run the most sophisticated go-to-market motions are the same ones that invested early in data infrastructure. That correlation is worth paying attention to. This aligns with what Kyle Norton shared with us in our AI x GTM Summit, that Data foundations is Phase 1 in his AI Transformation Roadmap for Revenue Leaders.

What this data tells us

A few patterns jump out when you look at the full dataset:

The “core three” are non-negotiable. Salesforce, Gong and Snowflake/dbt appear in 80%+ of these stacks.

Clay is infrastructure now. At 65% adoption, Clay has crossed from “nice-to-have” into “default.” It’s the second-most adopted data tool behind only ZoomInfo, ahead of LinkedIn Sales Navigator. I suspect they’ll jump into the core stack (80%+) within the next year, if not sooner.

The intent category is splitting. Legacy ABM platforms (6sense, Demandbase) still have the largest footprint, but newer signal tools (Common Room, Unify, Sumble) are landing at the same companies. These aren’t replacements, but additions. The “System of Intelligence” may shape up to be a stack, not a single platform.

Off-the-shelf AI SDR adoption is zero at the top. The companies with the most technical talent and the most aggressive growth targets are not buying autonomous AI SDRs. They’re building their own workflows.

The full dataset

The complete interactive dataset is live at ProspectingStack.com/top-tech-stacks.

You can search by company, filter by category, sort by valuation, headcount, sales team size, or number of tools, and click into any company to see their full stack.

Data sourced from Sumble and Clay, plus Claude to pull customer logos from websites and review sites.

If you found this Research Report useful, share it with someone who geeks out on GTM tech stacks.

And if you think we’re missing a tool or a company, reply to this email or reach out to me, Brendan Short, on LinkedIn (the dataset is a living thing, and we’ll keep updating it).

As always, thank you for your 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.

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

Nooks → Agent Workspace for Intelligent Outbound

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

11x.ai → Accelerate growth with a digital GTM workforce

Hey, y’all! 👋

It’s hard to open LinkedIn or X without seeing a “we replaced our entire {sales team} with Claude Code” post these days. But, what I’ve noticed: most of those posts are by some dude who runs a 4-person agency.

So I started collecting growth-stage (ie: “at-scale” companies with large sales teams—dozens or hundreds of sellers) who have deployed AI agents into their (complex) go-to-market orgs. Larger teams means higher stakes and more complexity across: people, teams, and (maybe most importantly) data systems.

I have curated 11 examples of teams that have built and deployed AI agents in-house. They spent months thinking through edge cases, data architecture, and production reliability. Wrote custom code, connected multiple tools via API or MCP, shipped it to production, put it in front of their sales teams, and (again, maybe most importantly) got positive outcomes.

Vercel went from 10 inbound SDRs to 1.
LangChain saw a 250% increase in lead-to-qualified-opportunity conversion.
Ramp has over 80% of sales workflows running through their internal platform.

The proof is in the pudding (as they say).

Alright, let’s get into it.

What they built

LangChain → GTM Agent with Memory and Account Intelligence

This is the most technically detailed example I found. Published just last week by Vishnu Suresh and Jess Ou on the LangChain blog.

Before the agent, every outbound started the same way: a rep toggling between Salesforce for the account record, Gong for call history, LinkedIn for the contact, and the prospect’s website for context. Fifteen minutes of research before a single word was written.

Their agent triggers on new Salesforce leads, checks whether anyone has already reached out, gathers context (including full meeting history from Gong), and sends a Slack draft with reasoning and sources for the rep to approve. Nothing goes out without explicit human review.

Two things make this one stand out:

First, the memory system. When a rep edits a draft in Slack, the system compares the original against the revised version. If the changes are substantive, an LLM analyzes the diff and extracts structured style observations—what changed, what it implies about the rep’s preferences. Those observations get stored per rep, and every future run reads them before drafting. Each edit teaches the agent. A weekly cron job compacts these memories to prevent bloat. That’s a genuine learning loop, not just prompt tuning.

Second, account intelligence. Every Monday morning, the agent pulls data from Salesforce and BigQuery, checks the outside world for funding rounds, product launches, and AI initiatives, and generates account-level reports. For sales, it surfaces expansion opportunities and competitive moves. For their deployed engineering team, it flags account health—usage trends, upcoming renewals, customers running low on credits. Two audiences, two different reports, same underlying data.

Results: 250% increase in lead-to-qualified-opportunity conversion from December 2025 to March 2026. 3x more pipeline dollars. Reps reclaimed 40 hours per month each. 50% daily active usage and 86% weekly active usage across the sales team. Reps increased follow-up with lower-intent leads by 97%.

ClickUp → 2 People Doing the Work of 40 SDRs

Kyle Coleman (Global VP Marketing) shared on LinkedIn that ClickUp has built an internal AI SDR program they call “programmatic pipegen.” The system runs alongside ~30 human XDRs, monitoring over 100 signals across ClickUp’s PLG user base (using Pocus) and automating outreach for speed-to-lead. Human XDRs handle phone calls and strategic account work. The AI SDR feeds them pipeline.

The entire AI SDR motion is orchestrated by just 2 people. Kyle estimates it would take ~40 SDRs to operate at the same scale without the AI, data science, and automations they built. The human XDRs and AI SDR operate in concert, not competition (5 XDRs were promoted to AE the same week Kyle posted about this).

Deel → AI-Augmented Sales Workflow Across 7 Use Cases

Mike Gallardo (Sales Director) shared on LinkedIn that Deel built an AI-augmented sales workflow covering 7 core use cases:

• AI-generated first touches analyzing role, company, funding, and web activity.

• Discovery prep surfacing pain points and prior conversations.

• Call debriefs summarizing decision criteria and power structures.

• Objection handling predicting legal, security, and procurement pushback.

• Real-time competitive battle cards.

• 24/7 AI-powered customer Q&A.

• Deal strategy alerts when new stakeholders engage or risk builds.

Results: 90% of the team hit quota in Q4.

Vercel → Inbound Lead Agent that replaced 10 SDRs with 1 (and open-sourced it)

Drew Bredvick leads Vercel’s GTM engineering team. Here’s what their agent built:

1. Form submission → enrichment (Clearbit, ZoomInfo, etc.)

2. Lead Agent kicks off → deep research on the company/person

3. AI makes a qualification decision → categorizes into buckets (qualified, follow-up, support, not sales-related)

4. Slack notification → pings the SDR with full context + reasoning

5. Draft email ready → for qualified leads, we’ve already written the response and pushed it to Outreach

The human’s job went from “do research, qualify, write email, send” to “review AI’s work, press send.”

It’s like we gave them the controller to a video game instead of making them play the boring parts.

They open-sourced the architecture (here).

They also built a retrieval layer on turbopuffer—indexing every Gong call, Slack thread, and email chain into a vector search database, organized by Salesforce account. The agent queries that account-specific history at runtime so it has real context, not just whatever fits in a prompt.

Beyond inbound, Vercel has since built agents for close/loss analysis (reads Gong calls and extracts why deals were actually lost—not the seller’s excuse), objection extraction (pulls objections from sales calls and routes product gaps to engineering teams), and field feedback aggregation.

ROI from the agent: 32x

• Cost: ~$60K/year (engineering hours + AI API costs)

• Savings: $2M+/year (headcount reduction + efficiency gains)

Ramp → “Ramp Revenue” Internal GTM Platform

Parth Gujare (Senior Product Manager) shared on X that Ramp has been building its own internal revenue stack they call “Ramp Revenue.” The mandate was to help the sales team drive more pipeline and build the most efficient GTM org in the world.

It’s powered by a customer data platform that processes millions of records daily (including internal data, external data, and CRM data) plus a unified action layer with agents embedded directly in seller workflows. Sellers don’t toggle between a dozen systems to figure out who to reach out to or what to say. The agent surfaces it.

Over 80% of sales workflows are now powered by Ramp Revenue.

Worth noting: Ramp also built an internal coding agent called Inspect that now accounts for roughly 30% of merged engineering pull requests. This is a company that builds by default. When they looked at the GTM vendor landscape, they decided they could do it better themselves. That’s a bet most companies can’t make, but for Ramp, it’s consistent with how they operate.

Vanta → 3 AI Workflows Shipped in a Single Day

During a Clay<>Vanta AI Hackathon, the team built and deployed three AI-powered GTM workflows in approximately 8 hours:

• AI-powered trust center mockups tailored to each prospect’s brand for outbound personalization

• A Chrome extension automating manual SDR research—gave 70+ new SDR hires the power of Clay without full tool onboarding, saving multiple hours per day

• An AI call transcript analyzer that transforms hours of conversation into actionable insights flowing into custom presentation decks

All 3 workflows were presented to the entire company the same day. The SDR research Chrome extension now serves 70+ new hires.

A few more examples

Owner.com’s Kyle Norton (CRO) manages a 100+ person sales team with AI agents embedded across workflows. He trained his first agent himself, every single day for a month. Reviewing outputs each morning, finding what’s wrong, refining. His take: agents require the same onboarding you’d give a new hire. The first 30 days are daily training. The first 1,000 outputs need manual review. Norton has also said their AI agents are now better than a mid-pack AE or SDR. Not better than the best, but better than the 50th percentile. (More on Kyle’s thought process here: Learn, Build, Scale: A Revenue Leader’s AI Transformation Roadmap.)

SafetyCulture built four AI agents across their GTM workflow using Retool, ZoomInfo, HubSpot, Gong, Salesforce, and Redshift: AI-powered lead enrichment calling 5 data providers in parallel, an Auto BDR for personalized outreach and meeting booking, an AI lifecycle personalizer for feature recommendations, and a custom app layer replacing clunky GTM systems with a single-pane-of-glass view. Results: 2x increase in opportunities created. 3x increase in meeting booking rates. BDRs save 30 minutes per opportunity. 80%+ of the team uses the custom app daily. (Profiled by Kyle Poyar in Growth Unhinged.)

Sendoso built 3 custom agents using Anthropic’s framework: a contract scraper that OCRs closed-won PDFs and feeds them to Claude, a deep research engine with a self-hosted vector database pulling from Snowflake product-usage data, and an AI proposal generator. They went from 15+ BDRs to 4 BDRs generating 30%+ more pipeline than the original 15 produced. Their key insight: nobody else has their proprietary product-usage and contract data, so external AI SDR tools can’t replicate what they built.

Docebo’s Emily Pick (Product Marketing) used Claude Cowork to rebuild Docebo’s ICP from scratch over a weekend. She fed it two SFDC reports (all customers by ARR, plus all closed-won and closed-lost opps from Q4 with win-loss notes), a local folder of win-loss interview transcripts from H2 2025, and 25 account briefs generated through the Glean MCP pulling from Salesforce, Gong, CRM notes, emails, and call recordings. The output: two fully defined ICPs with complete attribute sets, the data case for each, deal triggers, qualification criteria, competitive landscape, and an activation guide.

Zapier now runs more AI agents than it has employees (800+ agents across the company). Wade Foster (CEO) shared his top agents by department on LinkedIn. The sales-specific ones include: automatic call prep, an outbound assistant, sales chat attribution tracking, a Gmail auto-replier, and a smart lead qualifier.

The patterns across these builds

After going through all of these examples (plus a handful of others I researched but didn’t include), here are nine lessons worth calling out.

1. The data work is the actual project

Every team that successfully deployed an agent had to solve a data problem first. Not a model problem. Not a prompt engineering problem. A data problem. I have talked about this before.

Drew Bredvick’s team at Vercel tried the obvious approach first—stuff all the context into the prompt. Gong transcripts, Slack messages, Salesforce records. It overflowed context windows almost immediately. So they built a retrieval layer on turbopuffer, indexing their entire GTM corpus per Salesforce account. That architecture is the reason the agent works.

Ramp built an entire internal CDP that processes millions of records daily before the agents could sit on top of it.

LangChain connected their agent to Salesforce, Gong, BigQuery, Apollo, Gmail, LinkedIn, and Exa for web research. The first step before any code was defining what data sources the agent needed and how they’d be connected.

The lesson: if your CRM is a mess, your enrichment data is stale, and your conversation intelligence isn’t connected to anything, you’re not ready for agents. You need to start with a data cleanup project.

2. “Shadow your best rep” is the new requirements doc

Drew Bredvick said something in his writeup that I think is the single most important line: before writing any code, he spent a week watching Vercel’s top-performing SDR.

What signals made her excited about a lead? What made her immediately disqualify? How did she research companies? What did she include in emails that got responses?

He called it the “revealed preference” approach—watch what the best people actually do, not what the playbook says they should do.

LangChain took a similar approach but formalized it differently. Before writing production code for any workflow, they define what success looks like and build a small scenario library grounded in situations their reps actually face. They expand that library as the agent matures. By the time something ships, they have an eval suite that catches regressions and runs in CI automatically.

Kyle Norton at Owner.com echoed this from the CRO seat. He trained his first agent himself. Every single day for a month. His take: if you haven’t personally trained an agent, you have no idea what you’re talking about. The CRO or whoever owns the motion needs to be the one doing the training, at least at first.

The pattern is consistent. The agent doesn’t invent the motion. It scales what’s already working. If you don’t have a winning playbook worth cloning, you don’t have an agent project.

3. Every team had someone who owned the project end-to-end

Parth Gujare at Ramp is a Senior Product Manager with a CS degree and an MBA from Wharton. He’s a technical PM who thinks in systems.

LangChain’s agent was built by Vishnu Suresh and Jess Ou—engineers embedded in the GTM org.

Kyle Norton at Owner.com is a CRO who personally trained the first agent daily. Hands-on involvement, not just exec sponsorship.

Drew Bredvick is a GTM Engineer at Vercel. He writes code. He built the agent architecture in Next.js, set up the vector search infrastructure, and wired the Slack integration for human-in-the-loop approval.

Emily Pick at Docebo is a product marketer who connected SFDC, Gong, and Glean through Cowork—no code, no engineering team involved.

In every case, there was someone who took ownership of the full loop: understanding the workflow, connecting the data, building the agent, and iterating with the team. Sometimes that person is a GTM Engineer who writes code. Sometimes it’s a PM who thinks in systems. Sometimes it’s a marketer or operator who knows how to connect tools and feed them the right data. The common thread isn’t a specific job title, but someone willing to get their hands dirty and iterate daily.

4. The most successful programs are led by tiny teams

ClickUp’s entire AI SDR motion is run by 2 people, doing the work of 40 SDRs. Vercel’s GTM engineering team is small. Sendoso cut from 15+ BDRs to 4 while generating 30% more pipeline. When I was running the auto-SDR function at Apollo, it was just me booking 1,800 meetings a quarter across 20+ reps.

These aren’t massive engineering projects with 20-person teams and 6-month timelines. They’re small, scrappy GTM engineering efforts. Usually 2–4 people assembling tools, writing prompts, connecting data sources, and iterating daily with the sales team.

5. The tech stack is remarkably consistent

Across every example I looked at, the building blocks are similar: Salesforce as the CRM and system of record. Gong or Attention for conversation intelligence. Some combination of Clay, Clearbit, ZoomInfo, or Apollo for enrichment. Slack for human-in-the-loop approval flows. An LLM (usually Anthropic or OpenAI) for reasoning and generation. And an orchestration layer—whether that’s Clay, a custom build (Vercel, Ramp), a framework (LangChain Deep Agents), or a workflow tool (Zapier, Retool).

Nobody is building exotic AI infrastructure from scratch. They’re assembling agents from existing building blocks with good engineering and thoughtful product thinking. The barrier to building useful agents is lower than most people think.

6. The biggest differentiator is proprietary data

The companies seeing some of the best results (eg: LangChain’s 86% weekly active usage across their sales team, ClickUp’s 2-person team replacing 40 SDRs, Deel’s 90% quota attainment) are feeding agents internal data that no third-party tool can replicate.

Ramp’s Parth Gujare made this point implicitly with “Ramp Revenue”: the platform processes millions of internal, external, and CRM records. That’s the moat. Not the model. Not the prompt. The data only they have.

7. Most of these agents are doing the boring parts of sales

LangChain’s agent: lead research → context gathering → personalized draft → Slack approval. Ramp’s agents: surface who to reach out to and what to say. Deel’s agents: research, prep, competitive intel, call debriefs. Vercel’s lead agent: form intake → enrichment → qualification → routing → email drafting. The human reviews and presses send.

All hugely valuable. Vercel saved $2M+. LangChain’s reps reclaimed 40 hours per month each. But these agents aren’t closing deals. They’re not running discovery. They’re not navigating complex enterprise buying committees. They’re doing the tedious, repetitive, high-volume work that SDRs and AEs spent most of their time on (and that most reps didn’t want to do anyway).

Even the more advanced use cases, like Vercel’s close/loss analysis, LangChain’s Monday morning account intelligence reports, or Deel’s deal strategy alerts, are pattern matching and summarization tasks. Important tasks that weren’t getting done before. But not the creative, strategic, interpersonal work that makes a great AE great.

This is less “AI is eating sales” and more “AI is eating the admin tax on sales.” That framing is more accurate imho. And more useful if you’re deciding where to start.

8. The build itself isn’t technically novel, but shipping to production is hard

I almost didn’t include this one because I don’t want to take anything away from what these teams built. Shipping to production at scale is genuinely hard. The results are real.

But if you look at what the agents are doing under the hood (form processing, data enrichment, LLM-based qualification, structured output, RAG over internal data, email generation) none of it is cutting-edge AI research. These are well-understood patterns stitched together with good engineering and thoughtful product thinking.

What made these projects successful wasn’t technical novelty. It was: access to clean, connected data. Deep understanding of the sales workflow being automated. Someone bridging the gap between AI capabilities and the GTM team’s needs. And organizational willingness to iterate daily.

LangChain’s memory system, where the agent learns from each rep’s edits, is probably the most sophisticated pattern in the group. But even that is a straightforward feedback loop: store the diff, extract style preferences, inject them into future runs.

Technical hurdles have come down. Now, the hurdles to get over are coordination and execution.

9. The build vs. buy calculus has changed

The calculus for the age-old question of build vs. buy has changed because building is dramatically faster, cheaper, and more accessible than it was a few years ago (even six months ago!).

Vercel’s lead agent was built in a weekend. The $2M+ in savings came from deploying it. LangChain’s agent went from concept to 50% daily active usage in a few months. Vanta shipped 3 production workflows in a single hackathon (with support from Clay).

The question isn’t “should you build or buy?” The question is: do you have someone willing to own this end-to-end, and do you have the data infrastructure to support what they build?

Both are valid paths. Ramp and Vercel built because they have engineering cultures that expect it. Your company might get the same results from chaining Clay + an LLM + Slack + your CRM with a GTM Engineer who knows what they’re doing. Or a product marketer who knows what data she needs and how to connect it.

What’s changed is that the floor for building has dropped so far that the build option is now accessible to companies that never would have considered it before. A Series B with a single GTM Engineer can build and deploy a lead qualification agent in weeks, not quarters. A product marketer with Cowork can rebuild an ICP over a weekend.

My bet: within 18 months, “we built our own” will be as common as “we use Outreach” is today. You can

The teams that start now (even with something basic) will have a meaningful head start on everyone else.

Company table

That’s it for this week.

As always, thank you for your 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.

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

Nooks → Agent Workspace for Intelligent Outbound

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

Hey, y’all! 👋

The term “GTM Engineer” continues to be one of the most polarizing topics in go-to-market. I first wrote about it back in November 2024 (The Rise of the GTM Engineer), and the questions haven’t slowed down. If anything, they’ve gotten sharper. What does the role actually entail? Is it just RevOps with a new name? Do they need to code? How do you pay them? Is it a fad?

I’ve spent the last year and a half working closely with GTM Engineers, hiring them for clients, and consulting companies on how to build this function. So I figured I’d take the most common questions I get and answer each one as directly as I can.

I had the pleasure of collaborating with Patrick Spychalski, Founder of The Kiln (a Clay Agency that was recently acquired), on this piece. Go follow Patrick on LinkedIn! He’s incredibly smart and building at the bleeding edge.

My goal is to take you on a journey with these 26 questions. We’ll start with the skeptic questions: Is this role even real? Then move into the operator questions: How do I actually hire for this and run it? And finish with the forward-looking questions: Where does this all go?

Here are the high-level categories we cover:

• Defining the role

• What they actually do

• Skills & profile

• Hiring

• Running the role

• Looking forward

Let’s get into it.

26 FAQs about GTM Engineering in 2026

Defining the role

1. What is a GTM Engineer?

A GTM Engineer uses AI, automation, and data to create efficiency, pipeline, and business growth within a go-to-market organization.

You can think of the ideal GTM Engineer as someone who floats around an org looking for things that can be improved, using the latest tech — someone who is constantly curious and tinkering with whatever revolutionary AI tool came out that week. It is a very AI-forward role, and most companies hiring for them view this role as just one of many that they will need to hire to put their organization through “AI transformation”. It’s a role defined by one’s ability to navigate their company’s complex problems, assign solutions to them, and know which tools to implement to drive positive outcomes.

A GTM Engineer is someone who gives your company leverage. I believe it’s someone who does more than just top-of-funnel. This role works across all of your go-to-market, not just outbound/lead gen. Sales, marketing, customer success, account management. Anywhere there’s a process that can be improved with data, automation, or AI, a GTM Engineer can add value.

I wrote more on the definition of the role here: The Rise of the GTM Engineer.

2. Is GTM Engineering just RevOps?

In many cases, a GTM Engineer is a subset of RevOps (and in some cases, should probably live under RevOps). But a GTM Engineer is not just RevOps rebranded. The jobs to be done are quite different, and the goals vary too. Unlike most RevOps objectives, GTM Engineers can create systems that directly drive pipeline and are shown on the frontend to customers, either from the marketing or sales fronts. And more importantly, the role exists because of new technologies—mainly AI and automation—that didn’t exist a few years ago. A RevOps person manages systems, processes, and data governance. A GTM Engineer builds, automates, and ships things that create pipeline and revenue. There’s overlap, but the mandate is different.

3. What’s the difference between a GTM Engineer and a Growth Engineer?

They’re pretty similar, honestly. The main distinction: a Growth Engineer is typically an actual engineer (they code). A GTM Engineer doesn’t necessarily need to know how to code, though it helps, and they’ll probably learn some Python and SQL over time.

The other difference is scope. A Growth Engineer is typically focused on getting people into top-of-funnel and driving product adoption. A GTM Engineer, in my opinion, can work across multiple departments of the go-to-market org (not just acquisition).

4. Is “GTM Engineer” a role that Clay made up?

No. And yes. Clay originally started calling their internal sales reps “GTM Engineers.” These were people who helped deploy Clay within their customers. They didn’t want to call them salespeople. Think of it like a Figma employee who helps a client implement Figma — you might call them a “Design implementation specialist” or something similar.

Then the broader market latched onto the term and ran with it. But, Clay didn’t invent the job to be done. The role has existed at companies like Ramp, Stripe, and Figma for years—they just called them something else (usually a growth engineer, growth, or a RevOps person with technical chops). The market is simply giving it a name now.

5. Is this just a fad?

No. Maybe the title changes over time (titles often shake out). But someone who uses AI and automation to create leverage across the go-to-market org? I’m highly confident that role will exist in two years. And five. And ten.

The role will also go through its own changes. Tools like Claude Code make building GTM workflows much easier than before, and new tools to replace the old tool will come out every other week. However, the profile of a GTM Engineer—a curious, somewhat technical, and creative person to deploy these systems—will likely be there regardless.

I also think every IC (eg: AEs, SDRs, CS reps) will be using AI more and more. The tools will get much better. But there will always be leverage in having a dedicated person finding opportunities, identifying friction points, and building systems or deploying agents to take advantage of them.

What they actually do

6. What should a GTM Engineer actually work on?

This is where most companies underindex. A lot of teams hire a GTM Engineer and point them exclusively at outbound. That’s a fine starting point. But it’s only scratching the surface.

A GTM Engineer can build across the entire go-to-market org. Outbound pipeline generation, yes. But also: personalized sales decks based on industry and persona, automated competitive displacement campaigns, post-event follow-up workflows, CS-driven upsell and expansion plays, churn prevention alerts, enrichment and data hygiene systems, onboarding sequences for new reps, and more. Basically, anywhere there’s a manual process that touches revenue, a GTM Engineer can probably build something better.

7. Is this role only relevant for outbound-heavy companies?

No. There are many use cases beyond outbound.

You could hire a GTM Engineer who does zero outbound, and they would still give you incredible leverage across customer success, account management, marketing ops, event strategy, community, and more.

Again, I believe some of the best use cases for a GTM Engineer are completely outside the scope of Outbound.

One great example of this is: CRM Enrichment. Many enterprise companies (I would venture to say nearly all of them) have a massive data issue on their hands. The majority of what is supposed to be in their CRM is either outdated, not there at all, or structured incorrectly. This is a multi-million dollar problem for thousands of businesses worldwide, and has nothing to do with outbound. A great GTM engineer can solve this problem through well-orchestrated data and systems, bringing 10x their salary in value through 1-2 workflows.

I wrote more about this here: Most Companies Are Using GTM Engineers for “Automated Outbound.” The Best GTM Teams Aren’t Stopping There.

8. What tools do they use?

A lot. They should probably use Clay (but not only Clay), enrichment tools, Claude Code or similar AI coding assistants, tools like Attention for call recording+extracting actionable data, and be deeply comfortable in the CRM. They should have a strong opinion on tech stack, and that opinion should be evolving constantly (including connecting APIs themselves). Because for a GTM Engineer, the tech stack is evolving faster than any other department.

One important caveat: they should be comfortable adopting tools quickly, but not switching too fast. You need to actually execute, not just constantly tinker with new shiny objects. Avoid Gear Acquisition Syndrome.

You can find the best-in-class GTME tools here: ProspectingStack.com.

9. Do you have to use Clay to be a GTM Engineer?

No. But frankly, most GTM Engineers have gone down the Clay rabbit hole, and it’s a pretty good litmus test in my mind. If you’ve spent 100+ hours in Clay already, you’re probably pretty well-positioned for the technical side of a GTM Engineering role. Clay isn’t the only tool, but it’s become the default training ground for this skillset.

Clay is also a great medium to understand the core thinking patterns that make a GTME great. Sure, you could start your learning journey in Claude Code, but there’s something about the table format in Clay that lends more to that “building block” mentality many GTM engineers adopt when putting together workflows. The puzzle pieces come together a lot easier when you’ve seen them hundreds of times in action.

Since the start of 2026, many of my GTME friends and colleagues have now started to incorporate Claude Code into their workflows (for example: Eric Nowoslawski’s AI-powered cold outbound machine). I anticipate this being more prevalent over time. It’s simply much easier to build using natural language than it is to click around a complicated UI. Once the models get good enough to handle concurrency engineering and Anthropic has a few go-to data providers built in, things could change significantly.

Skills & profile

10. Do they need to know how to code?

No. But they definitely need to be comfortable working with APIs. And more and more, I’m seeing GTM Engineers adopt things like Cursor and Claude Code, writing scripts, connecting APIs, and building more sophisticated automations.

So, while they don’t need to know how to code per se, they need to be comfortable coding. There’s a difference. They need to be able to work with technical tools, connect APIs, debug workflows, and think like a builder.

11. Do they need to know how to work with AI?

Yes. This is a core part of the role. Nobody is an expert at AI right now because it’s all so new. But a GTM Engineer should be incredibly curious about AI. They should be deep down the AI rabbit hole. They should be working with AI tools for dozens of hours every single week. If they’re not spending meaningful time experimenting with AI, they’re going to fall behind fast.

Most companies that hire a GTM Engineer will also view them as a de facto AI advisor, as they understand how closely they’re working with AI-centric tooling every day. This is for good reason: the job is centered on delineating between what AI should be involved in for a project vs what it shouldn’t. Knowing how far you can take AI in a given direction is imperative to being a good GTME.

12. How does a GTM Engineer work with SDRs? Do they replace them?

No, definitely not. But some of the work a GTM Engineer does will probably automate activities in the lower end of your market. For example, companies with an ACV below $10K per year, you might want to fully automate outreach to that segment (or deploy a digital worker or agent).

But segments at companies that are going to pay you $50-100K+ a year? You’re augmenting the work of SDRs, not replacing them. Finding rich data points, operationalizing signals, generating draft emails—but a human SDR (or AE) is still running a motion on larger deals. Human-in-the-loop for the last-mile is key in the enterprise. And that’s not changing anytime soon.

Hiring

13. When should you hire a GTM Engineer?

I like this question. Not enough people are talking about it. I wrote a whole piece on this: When Should You Hire a GTM Engineer?. Here’s my rough idea:

The short answer: once you have a playbook that’s working internally and you want to scale it, that’s when you bring in a GTM Engineer.

Alternatively, it could be worth bringing a GTM Engineer on any time you have either 1) a long-tailed list of problems that you know could probably be solved by one, or 2) a problem large enough to where hiring one is justifiable from an ROI standpoint. You may not have created a great system for cleaning your CRM up yet, but if it’s valuable and you get pitched a good enough way to solve it, then it could be worth making the hire.

There are also great consulting options (ie: GTM Engineering as a service, like at The Kiln) where you can work with someone for 3-6 months before committing to a full-time hire (and/or do both!). This lets you de-risk the decision and make sure the role is going to give you real leverage. It also gives you perspective on what GTME to hire—should they lean more towards an ex-software developer, or an ex-AE who loves Clay? Should they specialize in data acquisition and standardization, or should they know what a good outbound campaign looks like? It’s easier to make these determinations after giving some experts a whirl at your projects.

14. Should you hire internally or externally?

I don’t believe you can (or should) outsource your AI strategy. And a GTM Engineer is one place where that reality shows up. External GTMEs are meant more as an implementation partner for the ideas you (or somebody else in the firm) has come up with internally. When it comes to a full-time team member, though, they will start coming up with those ideas themselves.

Like I mentioned in question #13, I think you can (and likely should) contract with somebody externally for 3-6 months to see if this is a fit. Agencies have seen dozens of companies. They know the pitfalls to avoid. Have been tinkering with AI, automation, Clay, Claude Code, Clawbot, etc., every day for the last 2 years. Use that expertise to your advantage by working with them. Let them show you where the leverage is, what type of person you need full-time, and help you build a job description. That’s a very low-risk way to start. But eventually, somewhere around Series A–C+, a SaaS company should have a GTM Engineer in-house.

15. Where do you actually find GTM Engineers?

There’s no established talent pipeline yet. Most are coming from RevOps, growth, or SDR backgrounds. I’d point people to Clay’s website under their new GTME Talent Hub. Or you could approach somebody from a one or two person Clay agency as a starting point (I’m seeing this quietly happen).

But the best place? Find somebody internally. Maybe an ops analyst or an SDR who wants to become more technical and is already hacking on AI stuff, dabbling in Clay and Claude Code on nights and weekends. Give them the path to continue down that road. Promote them, give them resources, give them a budget to go upskill themselves. That’s the highest-ROI move. Because they already have all the context of your business and teams. I wrote about resources and paths to becoming a GTM Engineer in How to Become a GTM Engineer (8 Resources).

16. What seniority level should you hire at?

Start with someone who is hands-on-keyboard. Even if they’re a “principal-level” GTM Engineer, they should still be an IC, not managing a team. This role is about building and shipping, not delegating. There is a range, of course, and you can find a large spectrum. I talk about this more in question #21 about compensation.

17. What does the interview process look like?

Give them a specific task and see how they solve it. That’s the core of it.

But there are also quick signals you can pick up in conversation. Ask them: what’s your favorite AI tool right now? What’s something you hacked on over the weekend? You can tell very quickly if someone is genuinely AI-curious and in the tools every day, or if they’re just asking ChatGPT a question a couple times a day.

You want somebody who has personally deployed an agent. Who understands prompting. Who, right now in early 2026, is dabbling with Claude Code or set up OpenClaw (ie: someone building at the bleeding-edge). Have them share a project they built themselves. Not something someone else built. A GTM Engineer is hands-on-keyboard. They are an IC, not a manager. Run the interview process with that in mind.

One more tip: the best ones are naturally curious themselves. The people who have independently stumbled upon these tools, worked with them, built workflows, and seem to love the “hacker” mentality are often the people we find to be the best.

18. What’s a good job test for a GTM Engineer?

I think you should test for two things:

• First, practical skills → Can they use Clay (or something similar) to enrich data, build workflows, and create real outputs?

• Second, soft skills → Can they think strategically, communicate clearly, and understand the business context behind the work (eg: talking about your ICP, key personas, value/unique selling proposition, etc.)?

You need both.

Running the Role

19. Where should they report?

Honestly, I don’t have a perfect answer. A lot of people today would say RevOps, and they might be right. But there are use cases where they might roll up to a COO directly. Or sit inside a marketing org, or even the sales org. I think about this similarly to where you’d place an SDR function—it depends on what executives you have and who is best suited to manage this person and give them the right context and air cover (CRO’s org vs. CMO’s org).

Given that a GTM Engineer can help many different departments, the risk of putting them under one department means they’re siloed in their potential for your company.

So, one thought experiment would be to have a GTM Engineer not report to a singular person. Sure, they should have a main report, like a CRO, but they have to work so deeply in different parts of an org that it would actually be counterproductive to have them siloed off in one department. For example, they may need to chat almost exclusively with a CMO for a month to build something there, and then completely ignore them the next month to build something for a RevOps lead. They should be judged on their net value add across these orgs, and the person making that judgement call should not be partial to one of them over the other. More on this in the next question.

20. Who should prioritize what a GTM Engineer works on?

It depends on the seniority of the GTME. One of the big differentiators when hiring is: are they just executing what they’re told, or are they building the strategy and executing? Both are valid. But, they’re very different hires.

In either case, you want the CRO/CMO (plus the founder and the Head of RevOps) driving the “roadmap” of the GTME. For instance, if there are 20 possible projects, someone needs to direct the prioritization. Should the GTM Engineer focus on outbound? Or cross-sell and upsell? Or churn prevention? Those are very different workstreams.

Even the most strategic, senior person needs the business context as they’re ramping. They don’t know the business like an existing founder or executive does.

21. How should a GTM Engineer be compensated?

This is a tough one because there’s a big range of hires in this role. You can find a more junior person—maybe someone who isn’t US-based—and pay them less. Maybe they’re doing some automated outbound, running Clay tables, keeping things operational.

But someone deep in the details and strategic? That’s a different hire. This person isn’t just executing a plan. They’re coming up with the plan alongside the VP of Sales, CRO, or CEO. That person needs to be paid at least $220-250K+ OTE.

My hot take: I think a GTM Engineer should have something like 25% of their OTE in performance-based comp (eg: variable). Similar to what an SDR or AE might have. This role is directly responsible for outcomes, so the comp should reflect that performance-based upside.

22. How do you measure success?

It depends on where they sit. The most common starting point is top-of-funnel: how many meetings are they booking? How much pipeline are they generating? How much of that pipeline is converting to Stage 1?

As you expand the GTM Engineer into other departments (eg: customer success, account management) you might measure them on upsell and cross-sell revenue. Event-related work (pre-event outreach, post-event follow-up) is fuzzier to quantify, but you should still try to tie them to specific outcomes they’re helping drive, either directly or indirectly.

At The Kiln, success is often measured based on the project, or projects, that the GTME works on. For example, a CRM enrichment project will have KPIs related to data quality and structure. Outbound projects tie to pipeline generation. Response automations are tied to speed. This is what makes comp for these roles so hard, because their cumulative success has to be a composite function of several different metrics.

Looking forward

23. What happens to this role when AI tools get easier to use and reps can do it themselves?

I think the role will still exist, but AEs, SDRs, and other ICs will absolutely do more “technical” things over time as tools improve.

Think of it as a spectrum. I believe it takes 50-100 hours minimum to get really good at Clay. Clay is more flexible and powerful than incumbent data providers or sequencing tools. And something like Claude Code is even more flexible and powerful than Clay, but has a steeper learning curve.

Where you start on that spectrum depends on where you are in your GTM journey, where you are in your AI deployment journey, and what people and resources you have. The GTM Engineer role evolves with the tooling, but the need for someone who sits at the intersection of strategy, systems, and execution isn’t going away (in fact, I believe it will grow in value).

24. How does this role evolve as the company grows?

This is the best part of a GTM Engineer! Whether you’re helping 3 reps or 3,000 reps, a GTME is building systems that scale. So, it doesn’t matter if you’re building a personalized sales deck workflow for 3 people or 3,000. That workflow looks exactly the same. What changes is the number of tokens consumed. Your AI bill may go up, but the work of the GTM Engineer scales beautifully. It really is magic (sorry to nerd out on this stuff, but I assume if you’re reading this, you nerd out on this stuff too).

25. How long does it take for a GTM Engineer to ramp and show ROI?

It’s harder to justify ROI than an AE or SDR, but easier than many marketing hires. The results—especially if they’re focused on pipe gen, even in part—are very quantifiable. Pipeline generated, meetings booked, conversion rates improved. You can tie numbers to the work.

The other thing I’d say is more anecdotal: you will feel the strategic impact of this person within 60 days (or even a lot less). The systems they build, the friction they remove, the ideas they surface—it shows up fast if they’re good.

26. What’s the career path for a GTM Engineer?

My honest answer: I don’t know. This role didn’t exist two years ago. I don’t know exactly what the trajectory looks like yet.

But I think there’s a world where a great GTM Engineer is going to be paid incredibly well and will want to stay an IC—just like in the engineering world, where principal engineers exist and thrive without managing people. I think that will and should exist for GTM Engineers. The path isn’t necessarily about managing a team. It’s about expanding scope and impact. Maybe AI Ops eventually is a better name for this role.

The short answer is nobody knows where this career path leads because it’s so new. But if you’re thinking about getting into GTM Engineering, I think it’s one of the most interesting places to be in your career right now. You’re on the bleeding edge of AI. You’re deploying AI at scale inside your company (for real). And I can’t be more bullish on AI as a long-term tailwind for these people. From a career perspective, that gives you a lot of optionality. Whether as a GTM Engineer yourself, or hiring one and embedding them on your team.

» » »

The GTM Engineer role is still early. The conversation is (currently) outpacing the adoption. But I strongly believe that the companies that figure this out now—and give the role real scope beyond outbound—are going to have a meaningful head start.

If you have questions we didn’t cover in this FAQ, drop them in the comments!

Thank you for your attention and trust,
Brendan 🫡

Subscribe now

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

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

Hey y’all! 👋

I recently sat down with Eric Nowoslawski to talk about how he’s building one of the most technically advanced AI-powered cold outbound machines in the world.

In fact, he may be the best person I know when it comes to modern-day outbound. Hard stop. Fun fact: I have had notifications on for his LinkedIn posts for the last couple of years. I don’t have notifications on for anyone else. He’s that good at outbound—and sharing what he’s learning. So, I was excited to codify his current thinking in Q1 of 2026, as it relates to outbound, how he’s using AI, what tools he’s using, and much more.

This post is longer than usual, so feel free to skip sections that aren’t relevant to you (I couldn’t bring myself to cut any more gold nuggets from what he shared with me).

Eric runs Growth Engine X. Which has 52 concurrent clients (he’s worked with companies like Notion, Intercom, Instantly.ai, Clay, and Secureframe), he rips 2 billion tokens per day through OpenAI, and has 250 Clay tables running simultaneously.

Maybe most interestingly, he’s also never written a line of code. Until 45 days ago, when he started using Cursor and Claude Code. But since then, he’s written 2 million lines of code.

Here’s what we cover:

• Claude Code vs. Clay (and when to use each)

• The GTM tech stack: Flexibility vs. power

• How GTM teams should learn AI coding

• The marshmallow test for building internal tools

• How Eric cut a $15K/month OpenAI bill

• Top 3 changes in outbound in the last 6 months

• Summary

Follow Eric on LinkedIn! https://www.linkedin.com/in/outboundphd/ (👈 I mean… even his LinkedIn URL tells a great story!)

Claude Code vs. Clay: When do you use each?

A year ago, the people I knew who were going all-in on Clay have added Claude Code to their stack since the start of this year.

Eric’s take: It’s an obvious evolution. Clay’s original hypothesis (when it was founded 8-9 years ago) was to give software engineering powers to as many people as possible. They thought a spreadsheet interface would help visualize integrations since people were used to Excel.

The company blew up when they found the GTM use case (and particularly, with agency owners at the beginning—including Eric’s agency). That’s why it’s a household name in go-to-market now.

But Claude Code gives software engineering capabilities to everyone on another level. Instead of setting up columns and clicking around, you can use your voice to set things up. And it compounds—when you figure something out once, you save it and reuse it.

Why Clay still matters:

1. Edge cases and visual building. Even with perfect models, some edge cases are easier to solve with a visual builder.

2. Software maintenance. People underestimate how much effort it takes to maintain code. Eric had something working perfectly two days ago—it’s broken now.

3. Claygent. Still a marvel of a GTM feature.

4. API queuing. Clay’s native integrations handle rate limits automatically. If Prospio has a 10 requests/second limit and you’re hitting it across 50 tables, Clay manages that. With Claude Code, you’d have to build that yourself.

5. Pre-negotiated contracts. Clay has 150+ data providers. Some you can get APIs for directly, but many are pre-negotiated. Maybe you just want one data point from HG Insights—do you want an HG Insights contract, or do you want to spend a few Clay credits?

Eric’s current split:

Claude Code handles TAM building and email finding. Then everything flows into Clay for “final mile delivery”—whatever AI enrichment needs to happen, Claygent calls, and pushing leads into SmartLead.

The GTM tech stack: flexibility vs. power

I shared a framework with Eric that I continue to revisit: a visual of how GTM tools trade off ease of use against flexibility and power.

• In the bottom right: Incumbent data and sequencing tools. Super easy to use, but not very flexible or powerful.

• In the middle: Signal-based tools that productized signals/automation (think: person-level intent that’s much better than 6Sense/Demandbase). More powerful, but harder to use.

• Further up: Clay. Pretty hard to use, but very flexible and powerful.

• Even further: n8n and Make.

• At the very top left: Hand-coding something (using Cursor, Claude Code, etc.). Most powerful and flexible, but historically the hardest to use.

What’s notable in this current moment in time is that all of these tools are rapidly getting easier to use as vibe coding (AI) improves with the models. Clay is already easier to use than it was a year ago (see: Sculptor). AI coding is getting easier (Lovable is a great example—an incredibly easy UI sitting on top of coding); people who can’t write a line of code are now shipping software. And now, Claude Code.

For GTM leaders, the question isn’t “which tool should I use?”

It’s “where on this spectrum should my team be investing time?”

The answer is probably: move up the curve faster than you think you should.

Here are the tools Eric is actually using day-to-day in his agency:

• Prospeo → contact and company data

• RapidAPI → access to various APIs

• Clay → orchestration and final mile delivery

• Apify → web scraping

• Exa and Parallel.ai → AI-powered search

• Supabase → database

• Railway → internal apps

• Trigger.dev → background workers and jobs

The world is kind of my oyster” with these tools. Between them, I can build almost anything I need without waiting on engineering.
–Eric

How should GTM teams learn AI coding?

I asked Eric if companies should hire external help or train their internal teams.

His answer: Everyone needs to use these tools. It’s mandatory. He went on to say:

We’re in a bubble.
(If you’re reading this newsletter, you’re likely at the bleeding edge of AI x GTM. But, the vast majority of the world has not ‘seen the light’ yet.)

Eric told me a story. His brother’s wife went to Princeton, works at BlackRock, has been promoted multiple times (she’s a very smart person). She only started using ChatGPT two months ago. She has no idea Claude is a product!

We think everyone knows how easy it is to scrape Google Maps or enrich a CRM. They don’t.

Someone at McKinsey told Eric their biggest challenge for some portfolio companies is updating job titles in their CRM. Eric’s response: “Oh, do I have a plan for you.”

The problems are basic. The solutions are now accessible. That’s the gap.

He tells his team constantly: You must use these tools. And as a leader, it’s incumbent on him to give them access while maintaining a security posture (some platforms don’t offer individual employee API keys, so he’s working around that with sandbox environments.)

This is true for Eric, as an agency owner. But I believe it is also true for a CRO at a SaaS company. The most “AI-native” teams I’ve come across are those where the CEO is personally vibe-coding at night, and execs are constantly using AI to get things done faster. This naturally trickles down.

Five things everyone in GTM should try with Claude Code:

1. Customer insight discovery. Look at your CRM—leads from last month, closed deals, lost deals. Find patterns between them.

2. Basic TAM building. Connect to an API like Prospio. Pull your entire TAM and put it into a database.

3. Build your own database. Pay $3 for Supabase. Get used to what it feels like to have your own data infrastructure. (Note: this is obviously not feasible for MM/Ent orgs, where there is data governance and structures already in place, like a data warehouse)

4. Analyze your recorded calls. Pull all your calls, ask Claude questions. How could I improve? What do we talk about most often? (Tools like Attention.com are custom-built for this)

5. Build your own email finder. Most email tools just guess permutations and validate. Get a MillionVerifier account, guess the six most common email permutations, validate all of them. The one that comes back valid is the email.

The compound learning effect:

Eric reminded me that the more you use Claude Code, the more it knows what good looks like. How you want things written. How you built things in the past. Eventually, you’re one-shotting things. But, you have to start small/narrow.

One more thing for GTM leaders:

I made the point during our conversation that AI doesn’t replace people; it scales whatever you already have. If you’re good at writing emails, AI scales good emails. If you’re sending bad emails, it scales bad emails.

AI amplifies existing quality. It doesn’t create quality from nothing. The companies that will win are the ones with strong fundamentals—good positioning, good offers, good copy—who then use AI to scale those fundamentals.

This is why “AI will replace SDRs” misses the point. The real question is: which SDR teams have the foundations worth scaling?

The marshmallow test for building internal tools

Every Friday, Eric used to spend four hours on domain management:

• Pull all domains across all customers

• Get reply rates for 7-day and 14-day windows

• Put it in a spreadsheet

• Manually calculate averages per client

• Flag anything outside the average for cancellation

• Upload cancellations to a sheet

• Move backup domains to active

• Order new domains

• Update Supabase

(That’s a short version. There are more steps.)

The framework:

1. What is the overall thing you want to accomplish?

2. What are the tiny steps within that?

3. What API documentation is tied to each step?

4. What does “done” look like for each step—not just the end?

The marshmallow test (the team-building exercise where you build the tallest tower with spaghetti and a marshmallow).

The teams that win build version one, make sure it works, then build version two on top. The teams that lose say, “We think we can make this two feet high,” and build the whole thing at once.

Eric advises to start: don’t have Claude build the whole thing. Build itty bitty fraction steps.

• First, get me the replies of just one customer.

• Get me the domains and replies of five customers.

• Now get all of them.

• Now give me suggestions for which to cancel (reply rate below 0.7%).

Do micro tests. Verify each step. Describe in the prompt what you’re testing and how you’ll verify it. Manually review the output and correct what’s wrong and update the prompt accordingly.

Your code base will grow. Claude will learn what you want. And eventually, you’ll one-shot things. But start small.

Bonus tip: The Loom transcript trick

Eric tells his team that when you’re doing something manually, record a Loom video while narrating what you’re doing. Talk through each step out loud.

Then take the transcript and give it to Claude.

Now you’ve done two things at once: you got the actual work done, and you have documentation for automation. Claude can read exactly what you did and start building a version that does it for you next time.

Think of it like you’re training a (digital) co-worker.

This is especially useful for tasks you do repeatedly but haven’t had time to automate. You’re not adding extra work. You’re just narrating while you work. The transcript becomes the prompt.

How Eric cut a $15K/month OpenAI bill

Once you’re operating at Eric’s scale—2 billion tokens per day across 52 clients—cost optimization becomes real.

Eric was spending $15,000 per month on OpenAI. Enough that he got assigned an enterprise account rep.

When he told her he was thinking about switching to open-source models on OpenRouter, she didn’t try to sell him. She asked: “Have you tried the Batch API and cached inputs?”

Solution 1: Batch API

For high-volume clients (the ones sending 30,000-100,000 emails per day), Eric moved to the Batch API. Instead of processing leads in real-time, they plan out every lead they’re going to reach out to and process them all in a single, cheaper batch.

Solution 2: Cached Inputs

This one is buried in OpenAI’s pricing page. If you send the same prompt prefix repeatedly, OpenAI recognizes it and gives you 50% off input tokens for the cached portion.

The trick: most GTM people structure prompts like this:

1. Tell it what you want

2. Give it the data

3. Add constraints and rules

4. Add examples

The OpenAI rep told Eric to flip it—move the variable data (step 2) to the end of the prompt. Keep the instruction layer static. That triggers cached inputs more often.

It’s not an exact science. It doesn’t trigger every time. But at scale, it triggers enough to matter.

Future cost reduction: Rented GPUs

Eric went down a rabbit hole on Vast.ai—renting GPUs to process AI requests for $0.60/hour. He got a GPU up to 16 requests per second on a 5,000-token input. At scale, that’s a million requests per day for $12-13.

His first use case: Google Maps contact finding. When you’re trying to find the CEO of a business that doesn’t have a LinkedIn profile, you need to scrape their website, parse through the content, and extract the owner’s name and email. That’s a lot of input tokens with potentially no output. Perfect task for cheap compute.

Top 3 changes in outbound in the last 6 months

1. Domains are dying faster than before.

Eric has observed that domains are getting burned quicker ever before. This is why he built the system he described earlier—the one that takes four hours every Friday to manage across 52 clients.

The system tracks:

• How many domains are active across all customers

• Reply rates over 7-day and 14-day windows

• Which domains are underperforming (below 0.7% reply rate)

• How many backup domains are ready to rotate in

You need a system to monitor this at scale (especially as an agency owner), and you need backup domains ready to go. Eric keeps his budget flat by constantly rotating (canceling underperformers, moving backup domains to active, ordering new ones).

If you’re running high-volume automated cold email in 2026 and don’t have a domain health monitoring system, you’re flying blind. For most companies, building in-house, SmartLead or Instantly solves this for you.

2. LinkedIn strategy (don’t orchestrate with email):

Eric helps clients with LinkedIn but won’t press the buttons—too much liability if accounts get banned (I agree).

But his advice on strategy is clear: don’t orchestrate LinkedIn with email. You can send way more emails than LinkedIn messages. There’s gold in LinkedIn contacts that email can’t reach.

Instead, use LinkedIn sparingly—for these three plays:

• Monitor case study company pages. When someone in your ICP engages with a post from your case study company, reach out. Don’t say “I saw you liked Clay’s post.” Say “I’m a video agency and I do the video stuff for Clay. Would love to talk.”

• Website de-anonymization. Install every tool—Leadfeeder, Snitcher, RB2B, Visual Visitor. Use their free trials. Whichever gets you the highest reply rate, keep it. Automate LinkedIn messages to people who visit your site.

• Competitor content engagement. Anyone in your ICP engaging with your competitors’ content gets a normal outreach message (don’t mention the engagement).

3. Email as an ad platform:

This idea has been in Eric’s head for two years. Cold email has become an ad channel.

Facebook’s data shows the advertisers who test the most make the most money. Best advertisers run 50+ ads simultaneously.

The difference: Facebook makes it easy to orchestrate tests. You set up your audience, click a few buttons, and the test is running. Facebook even finds the best-performing audience for you.

With cold email, orchestrating the list to enable 20+ simultaneous tests was painful. You had to set up SmartLead campaigns, Clay tables, formulas to route leads to the right campaigns...

Now with Claude Code? Set up SmartLead campaigns programmatically. Distribute inboxes programmatically. Write if-then statements for routing. Launch 20 campaigns in one go.

Treat cold email like Facebook ads. Run 20-50 campaigns at once. Test subject lines, CTAs, case studies, offers. The technology finally makes this possible.

TAM requirements: Why 100K contacts is the minimum

Eric believes you need 100K contacts in your market to do automated outbound (especially if you’re paying an agency). He won’t take clients with fewer than 100,000 contacts in their TAM.

Why?

Paying an agency for a 4,000 account TAM doesn’t make sense. Even if Eric is successful, he’ll be successful for a month or two, then they’ll run out of people to email.

He still thinks those companies should do cold email. But instead of paying agency fees, they should set it up themselves with Instantly or Smartlead for $500-1,000/month. And do less scale.

Summary

Eric is building what I think the best GTM teams and agencies will look like in 2-3 years: AI-powered infrastructure that delivers outcomes.

The key themes:

1. We’re in a bubble. Most people have no idea what’s possible with these tools. The problems are basic. The solutions are now accessible. That’s the opportunity.

2. Claude Code is the next tool in the stack. The GTM engineers who mastered Clay are now building with Claude Code. But Clay still has a role for edge cases, maintenance, and native integrations.

3. Move up the flexibility/power curve. The tools are getting easier. If you’re only using incumbent sequencing tools, you’re already behind. If you’re on Clay but haven’t touched Claude Code, start now.

4. The leadership mandate is real. Eric tells his team: “You MUST use these tools.” It’s the leader’s job to give access while maintaining security. This isn’t optional anymore.

5. Start small with AI coding. Break everything into micro-steps. Verify each one. Build your code base over time. Don’t overthink organization—AI will find what it needs.

6. AI scales your existing quality. Good foundations get amplified. Bad foundations get amplified, too. Invest in the fundamentals first.

7. Treat email like ads. The technology now exists to run 20-50 simultaneous email campaigns. The best outbound teams will operate like the best media buyers.

8. 100K TAM minimum. If you can’t scale, don’t pay agency fees. Do it yourself.

The gap between operators building this way and everyone else gets wider every month.

Follow Eric Nowoslawski on LinkedIn — He posts daily on cold outbound and AI-powered GTM.

→ Eric runs Growth Engine X, working with clients including Notion, Intercom, Instantly.ai, Clay, Secureframe. Talk with him if you’re looking for help scaling your outbound engine.

Thank you for your attention and trust,
Brendan 🫡

Subscribe now

Hey y’all!

I’m excited about today’s post.

You probably know Nooks as a dialer (a best-in-class dialer, for that matter), coaching platform, and virtual sales floor - to help some of the world’s best sales teams prospect more efficiently. They’re beloved by reps and managers alike (a rare statement).

But they’re announcing something big this week: Nooks is officially expanding into sequencing.

And I am stoked to share what I find most interesting about this move in today’s sponsored deep dive: why it’s interesting for Nooks in particular, what it means for the GTM tech space, and how it will positively impact sales teams.

I’ve gotten to know Dan Lee (CEO of Nooks) recently. And I had the pleasure of working with Patrick Donnelly (Founding Sales Team member) earlier in my career—he’s a phenomenal sales operator, and a legend. When people I respect join a startup, I take note.

Here’s what we cover today:

• The old outbound model is showing its age

• Why now? (Consolidation szn continues)

• What is AI Sequencing?

• The dialer advantage

• Humans + agents, working in tandem

• Conclusion

Alright, let’s get into it.

The old outbound model is showing its age

For a decade, the outbound playbook looked roughly the same. Build lists. Write sequences. Dial. Hope something lands.

In January of 2024, I wrote that The “Predictable Revenue” Playbook is Dead; RIP (2011-2023).

The tools built around that model reflected it. Sequence management. Task queues. Activity logging. They were designed to manage manual work—and they did that reasonably well, for a while.

But the model was always brittle. Reps bouncing between five different tools. Sequences going stale after a few months. Best-practices being lost as reps got promoted. CRM data drifting further from reality with every sync error. RevOps spending half their time reconciling duplicate records.

AI didn’t create these problems. But it does make them impossible to ignore.

The new GTM playbook runs on agents, signals, and real-time intelligence. The infrastructure to run that playbook looks completely different from what we had before. Most of the tools we’ve been relying on weren’t built for this new world.

That’s the gap Nooks is going after.

Why now? (Consolidation szn continues)

Two things are happening at once.

First, the expectation for what AI should do has shifted.

A year ago, teams were excited about AI writing a cold email. Today, they expect AI to figure out who to email, when, and why… and then draft it. The bar moved from automation to intelligence. Chatbots, to agentic workflows. I’ve felt this in my daily workflows and consulting work. We’re early. But, it’s wild what is possible today. And it’s all changing so fast.

Second, teams are actively cutting tools.

Back in November of 2023, I published an article titled, Consolidation szn (The race is on...) | 6 sales tech unicorns chasing after the elusive “one-stop-shop”. In it, I argued that companies will need to expand their offerings over time, or else get squeezed by other all-in-one sales tools. So, seeing Nooks expand is right in line with that prediction. And they’re doing this with AI at the core of their product.

Sales teams are approaching legacy SEP renewals and asking a harder question than they used to: is this tool earning its spot in the stack, or just surviving on switching costs? The answer, increasingly, is the latter.

Both of those forces point in the same direction. And why a launch like this lands differently in February 2026 than it would have, even just one year ago.

What is AI Sequencing?

Nooks launched AI Sequencing this week! They call it the industry’s first Agent Workspace for Intelligent Outbound.

The concept is worth unpacking. Most people know Nooks as a dialer. A really good one. AI Sequencing takes the platform into a different category: a unified workspace where prospecting, enrichment, sequencing, email, LinkedIn automation, and calling all live in one place.

The keyword is unified. Not integrated. Not connected via API with a two-hour sync delay. One system. This is going after the classic, and elusive, compound start-up (and all the gains that come with it). AI agents monitor real-time buying signals (think: CRM activity, call transcripts and discpositions, LinkedIn, web data, etc.) to surface the right prospects at the right moment. They draft personalized outreach grounded in actual account data. Worth calling out: the email drafts come with built-in hallucination guardrails.

The agents generate outreach based on real account data, not generic AI slop. Reps still review and send. This unlocks speed without sacrificing accuracy or brand control. The agents guide reps toward the highest-value next action. And the whole thing stays CRM-first, so your data doesn’t live in some shadow system that drifts from your CRM over time.

Reps stay in control. Agents handle the busywork.

Think of it less like a tool upgrade and more like a new system of work for outbound, where humans and agents work together (more on that later).

The dialer advantage

I find Nooks’ move into sequencing interesting because it’s clearly differentiated from a startup just bolting on features.

They’ve spent the last five years building—and earning—a reputation as a best-in-class dialer (parallel dialing, virtual salesfloors, call coaching, and more). Thousands of reps have been using it daily, running live conversations, and generating a massive amount of unstructured data in the process.

Call transcripts. Conversation outcomes. Rep behavior patterns across thousands of accounts. What messages landed. Which signals actually preceded a booked meeting.

Most sequencing platforms don’t have that rich context. They have CRM fields and email open rates. Nooks has something much richer. And when you train AI agents on that kind of data, they can reason more like a top (human) rep.

This is why I find their expansion notable. They’re not guessing what good outbound looks like. They’ve watched it happen, at scale, for years. That’s a real advantage that compounds over time as the product learns. Most sequencing tools go stale. Sequences bloat. Data drifts. The more you use them, the messier they get. Nooks is designed to do the opposite: every interaction—every call outcome, every email reply, every signal that preceded a booked meeting—feeds back into the system. The agents get smarter. The sequences stay fresh.

It’s a continuous learning loop, and it’s one of the harder things to replicate if you’re building on top of a legacy data model. Which is what I’ve argued for a while around the concept of a “System of Intelligence” that gets better the more you use it, not worse.

Humans + agents, working in tandem

The part of Nooks’ vision I find most compelling is the philosophical bet underneath all of it.

A lot of AI sales tools are chasing one of two approaches: full automation (the AI does everything, no human required) OR light feature addition (sprinkle AI on top of an existing workflow). Nooks isn’t locked into only one.

The Agent Workspace model is built around humans and AI agents working together in the same system. Agents reason, prioritize, and draft. Reps make judgment calls, build relationships, and close. Each makes the other better over time. It’s not either/or. It’s both.

This is the right bet (imho). The best outcomes in outbound still come from human judgment applied at the right moment. The rep who reads the room on a cold call and pivots the pitch entirely, the one who knows when to go off-script. AI isn’t replacing that intuition.

Nooks’ team shared an analogy with me, which I think is spot on as the opportunity in front of them:

Just as Cursor reimagined the IDE for AI-assisted coding and Harvey redefined legal work with AI agents, Nooks is re-architecting outbound around humans and AI in one shared workspace.

AI can eliminate all the friction around those moments. So reps spend their time on what actually requires a human.

That’s the new GTM playbook. And Nooks is building the infrastructure to run it.

Conclusion

The tools that dominated outbound for the last decade were built for a different era—one where the job was managing tasks, not intelligence.

Nooks’ big bet is that the future of outbound is a shared workspace where humans and agents operate together, get smarter with every interaction, and run the entire motion from one place. Starting from the dialer—where they’ve already earned trust—and expanding outward from there.

It’s an optimistic view of where this all goes. A perspective I share. I’m excited to see where they go from here, as this week’s launch propels the sales world into the future, yet again.

Reach out to Nooks’ team to see how they can help your sales team get more intelligent with outbound in 2026, and let them know The Signal sent you.

Thank you for reading. I appreciate your attention and trust.

See you next time,
Brendan 🫡

Subscribe now

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

Presented by Clay.

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

Nooks → Agent Workspace for Intelligent Outbound

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

Hey y’all!

I’m coming off a long weekend, catching some turns in the mountains in Utah 🏂. Rested, recharged, and a bit sore.

Meanwhile, the world continues to get crazier and harder to navigate. My goal is to continue to separate the signal from the noise in our little corner of the world—GTM.

I was on a call recently with the Head of RevOps and Systems at a unicorn. They’re looking to hire a “GTM Engineer.” But they were resistant to the GTM Engineer title. Five minutes in, I understood why. Their mental model was: GTM Engineer = automated outbound. That was it.

That’s a real thing worth hiring for. But it’s only one piece of a much larger pie.

After all, GTM stands for go-to-market. Not “top of funnel.” Not “lead gen.” The full GTM motion includes: marketing, sales development, sales, customer success, and account management. It’s every team that touches a customer—from awareness to renewal. Therefore, a GTM Engineer embedded in a GTM team isn’t just an outbound machine. They are (or can be / should be) a leverage multiplier in every department across the entire go-to-market motion.

So, today, I am unpacking this concept.

Because I don’t hear enough people talking about it. And, if you’ve been reading The Signal for a while, you know I’m incredibly AI-pilled, and I believe that in the AI-era, a GTM Engineer (or whatever you want to call it) is one of the best ways for a modern GTM team to get leverage.

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

• A GTM Engineer is not just sending automated outbound

• 21 non-pipe gen use cases a GTM Engineer can build

• The Product Manager analogy

• Where to start (and expand)

• Examples of broader GTME JDs

Alright, let’s get into it.

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

A GTM Engineer is not just running automated outbound.

That’s the version most people have in their head right now. Someone who builds some workflows, enriches leads, and fires off (high volume) sequences. An automated SDR. Top-of-funnel, all day.

I understand why. It’s the most visible use case. It’s what gets posted about on LinkedIn. It’s what many vendors are selling. But if that’s where your mental model stops, you’re missing what this role can actually do for your GTM team.

I first wrote about The Rise of the GTM Engineer back in November of 2024.

The term has gotten more attention since then—and stayed just as polarizing. Part of that is the word “engineer” itself. Most GTM Engineers aren’t software engineers. Many don’t write code, though Claude Code and tools like it are quickly changing that. Real engineers find the title triggering. Fair. And some of it is because people are still arguing a GTM Engineer is “just RevOps rebranded.”

But the bigger problem isn’t the title. It’s the job description being written around the wrong use case.

21 non-pipe gen use cases a GTM Engineer can build

Here are some examples of things a GTM Engineer can (and should) build that have nothing to do with prospecting/pipe gen:

1. AI-generated sales decks for AEs. Pull the industry and buyer title, hit a knowledge base, and generate a custom deck before the meeting. No more one-size-fits-all slide decks.

2. Call grading. Take the transcript, check whether the rep referenced relevant customers in similar industries, whether they hit the pain points tied to that buyer’s role, and whether they followed the suggested talk track(s).

3. Customer health scoring. Post-sale. Give account managers a real view of their book: upsell potential, cross-sell opportunities, churn risk. Built on rich context and actual signals, not gut feel.

4. Pre- and post-event workflows for marketing. The work required before and after events is painfully manual. A GTME can create tremendous leverage here (obviously, only worth exploring if events are a big motion for your team).

5. Lead magnets built to educate. Vibe-coded tools, calculators, and interactive content. Built fast and focused on generating real value for a specific person or micro-segment.

Here are 16 more ideas (again, none of which are top-of-funnel use cases):

• RevOps: Sales territory planning, TAM+ICP sourcing engine, Forecast accuracy tracking.

• Marketing: Automated case study generation, ABM campaign orchestration across channels, Personalized web pages (or ads) at scale.

• Sales: Automated competitive battlecards, Win/loss analysis, Proposal/SoW generation for AEs, Contract redlines, Re-engagement campaigns for closed/lost deals, Internal knowledge base search for reps.

• Customer Success: QBR prep/deck creation, Product feedback routing, Support ticket intelligence, 1:1 Customer onboarding automation.

The Product Manager analogy

The more I describe the role of a great GTM Engineer, the more it sounds like a PM (or what I did early on as a founder/CEO).

The best GTM Engineers operate like The Mom Test:

The whole point is to avoid building something nobody wants by having real conversations that surface real pain points, then letting those insights shape what you build.

They’re not assuming they know what to build. They’re interviewing the top reps and leaders to find what’s being done manually today that could be automated org-wide. They’re talking to founders to surface the projects that never make the priority list. Then they build, ship, and measure what comes out the other side.

Ask → build → ship → learn. That feedback loop is what makes the role compound over time.

Where to start (and expand)

This is a journey. Sometimes you genuinely just need someone focused on top-of-funnel. That hire can be junior and narrowly scoped. And that’s a legitimate starting point for a GTM Engineer!

But the key phrase here is starting point. That same person, given room to grow, is perfectly positioned to expand as new use cases emerge and as they learn the business.

Examples of broader GTME JDs

Some job descriptions are starting to get this right, and talk about GTM Engineers working on use cases beyond just pipe gen.

Vanta’s job description is a good example (GTM Engineer, AI):

And so is this JD from Descript that I shared last year.

The framing is less “Clay and spray” and more “internal AI product owner for the GTM team.” Some companies are putting “AI” in the title instead of “GTM Engineer” — which might be a cleaner entry point for orgs that don’t want the baggage of the word “engineer.”

The title may shake out.

But, what won’t change is the jobs to be done. I believe that in 18 months, ~every company will have this person embedded in their go-to-market org. And the companies that hire this person now—and give them real scope beyond outbound—will have a meaningful head start over their competitors.

If you’re looking to hire a GTM Engineer, or already have one, and their only objective is top-of-funnel (ie: doing “automated outbound”), you’re leaving a ton of value on the table. The faster your team realizes this, the further ahead you'll get.

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

See you next time,
Brendan 🫡

PS: Here are 6 things that caught my attention this week:

1. Something Big is Happening

2. THE 2028 GLOBAL INTELLIGENCE CRISIS

3. OpenClaw: The Viral AI Agent that Broke the Internet - Peter Steinberger | Lex Fridman Podcast

4. Stripe CEO, Patrick Collison, says: “There’s a reasonable chance that 2026 Q1 will be looked back upon as the first quarter of the singularity”

5. Is SaaS Dead? Software Stocks Have Massively Crashed. Here’s What Founders Need to Know. Jason Lemkin on TBPN.

6. YouTube playlist (6 videos) of each ~20-minute session from the AI x GTM Summit

Subscribe now

Thanks to the companies that made the AI x GTM Summit possible! (+stats/notable attendees)

Learn, Build, Scale: A Revenue Leader’s AI Transformation Roadmap

The Future-Ready Revenue Leader

We closed out the AI x GTM Summit with Kyle Norton, CRO at Owner.com.

Kyle is the most AI-pilled CRO in SaaS (that I know of). And he, and Owner, are crushing. A lot of that success traces back to their aggressive early adoption of AI in their go-to-market machine. Plus, he somehow has the time to share what he’s learning with other revenue readers on The Revenue Podcast (👈 check it out). He’s the goat.

And Kyle didn’t disappoint in his session. He gave us frameworks for thinking about AI transformation, what “AI-native” actually means for leaders, and how to prioritize use cases without wasting time on vaporware.

Here’s what he covered:

• The AI reality (this is about survival, not the future)

• What “AI-native” actually means (and what it doesn’t)

• The new revenue leadership skill stack

• AI transformation roadmap (data → capabilities → use cases)

• The 5P prioritization framework

• Adoption principles that actually work

• Bonus: Generative + Deterministic

• How much time does Kyle personally spend on AI?

Follow Kyle on LinkedIn!

[Suggested Spotify playlist while reading this series]

IYMI:

• Session #1 → Sorting the World into your CRM (GTM gold is stuck in your top seller’s brain: How to extract + operationalize it) || YouTube video of Matthew and Andreas’ full session (22 mins)

• Session #2 → Infrastructure for agentic GTM: data stack, orchestration, and activation || YouTube video of Nico’s full session (23 mins)

• Session #3 → Getting agents deployed into your GTM systems: pitfalls, opportunities, and best practices || YouTube video of Joe’s full session (19 mins)

• Session #4 → Nuanced Viewpoint on AI-Generated Outbound Email Copy | YouTube video of full session (22 mins)

• Session #5 → Automating Signals that Work in Your Specific Market | YouTube video of full session (23 mins)

Alright, let’s get into it.

The AI reality (this is about survival, not the future)

Kyle opened with a quote from Jason Lemkin at SaaStr:

That was from May 2025. The bar has only gone up since then.

Kyle’s perspective: maybe you’re not cooked in 2025. But in 2026? We’re going to see a great bifurcation in go-to-market outcomes. Companies using AI heavily to create leverage versus companies that don’t.

This isn’t theoretical anymore. Owner’s sales team is 3-4x more productive on a per-rep basis than their competitors. Kyle said his CFO thought he was doing the math wrong when they looked at OTEs to quota and outcomes.

Because they’ve stripped so much tedious, monotonous work from reps and used AI to make them more productive, Owner can reinvest those savings elsewhere. They can outspend competitors on brand, engineering, and growth. For instance, they hired Alex Hormozi’s head of media to run media for Owner (a hire you can only make if you’re not spending wildly on sales and marketing). Wild.

That advantage compounds. And it started with early AI adoption. Owner has nine high-impact AI use cases in production. Their first one went live in December 2022.

What “AI-native” actually means (and what it doesn’t)

Most people think “AI-native” means they use ChatGPT for answers and Salesforce formulas. That’s not the bar anymore.

You, the CRO or CMO, need to evaluate tools, pilot one, pick one, figure out the evals and context engineering, and get it into the world.

AI-native is:

• First principles understanding (you know why models hallucinate, the difference between pre-training and post-training)

• Daily tool usage and genuine curiosity

• Systems thinking

• Personal experimentation (4-8 hours per week minimum)

AI-native is NOT:

• Using ChatGPT to draft emails and find recipes

• Delegating AI to Rev Ops

• Waiting for “better” tools

Being an occasional user of AI is like being an occasional user of the internet.

For a lot of Owner’s early implementations, Kyle was hands-on keyboard with his RevOps and data teams. He’s vibe-coded his own apps (none of which worked that well in production fwiw, he admitted). But going through the process—watching YouTube videos, building things, breaking things—is what builds fluency and intuition.

The new revenue leadership skill stack

The “people person” manager (who knows how to hire, train, coach reps, and bring home the number) archetype is going away.

Not everywhere at once. Enterprise will be slower. Markets without AI-native competitors will lag. But if you’re competing against a systems-engineering, AI-native thinker, you’ll be losing and won’t realize why until it’s too late.

Kyle laid out the new skill stack for revenue leaders:

1. Systems orchestration. You’re managing humans and agent teams now. You have to think about how all these things coordinate together.

2. Depth beyond your core function. If you’re a sales leader, you can’t just think about sales. You need to understand implications into onboarding, growth, CS. Agents might work across these functions. The lines are blurring.

3. Continuous improvement discipline. Be extremely analytical. Understand the math. Know how to improve the revenue system through data and experimentation.

4. Change management for AI. This is one that Kyle only recently added to the list. The companies that can change the fastest are going to win. Driving adoption is as important as the technical implementation.

AI transformation roadmap (data → capabilities → use cases)

Kyle laid out three phases:

Phase 1: Data foundations

Nothing in AI works without good data. This is the “do not pass go, do not collect $200” moment.

Third-party data:

• Market, account, person, contact, intent, signal data

• Proprietary 3P data (stuff you can scrape and enrich that competitors don’t have) is a competitive moat

• Most of your team is wasting most of their time because they don’t have the right data about expected value of next best action

First-party data:

• What’s happening in your customer journey?

• Data from your product, users, and team

• Unify, clean, structure

• High-impact first tool: AI CRM enrichment (Kyle uses Momentum)

Documentation:

• AI loves written docs

• More people are writing things specifically to be used by LLMs

• Your knowledge base becomes your AI foundation

Phase 2: Capability building

Kyle’s 70/20/10 model:

• 70%: Level up leadership. You and your team need to become AI-fluent. Build AI literacy into leadership development. Do the work.

• 20%: Hire expertise. A GTM AI leader with a track record of building (not just talking). Usually sits in Rev Ops.

• 10%: Strategic consulting. Time-bound projects for specialized expertise. But don’t outsource the transformation.

What doesn’t work:

• Hiring consultants to “lead transformation”

• Expecting your current team to figure it out alone

• Traditional training programs

What works:

• Leading transformation from within (*note: I’ve seen this first-hand; ideally, it needs to come from the CEO/founders/execs)

• Safe-to-fail experimentation environments

• Learning culture, not training programs

Kyle suggested to find answers from your network, events like the AI x GTM Summit (kind of him!), Twitter/X, YouTube, and LinkedIn to a lesser extent.

Phase 3: Use case identification

Kyle called out the main issue where people randomly pick AI projects based on who calls them or cool things on LinkedIn. Projects peter out. Teams get fatigued. Then, when you want to implement the next thing, nobody believes you.

You need a prioritization framework.

The 5P prioritization framework

Kyle adapted this from Annie Duke’s work (Thinking in Bets, How to Decide):

1. Possibilities. What’s your opportunity landscape? Map all the ways AI could improve your biggest priorities.

2. Payoff. If that thing works, what’s the ROI? You want big wins, not 5% improvements on small parts of the team.

3. Probability. What’s the realistic likelihood of success? How speculative is this? Some AI bets are well-proven now. Vet vendors by asking for references.

4. Perspiration. How much effort is required? Does it need product time, rev ops work, and marketing to completely change how they operate? That’s probably not set up for success.

5. Prioritization. Expected Value ÷ Perspiration = Priority Score

Example: If the payoff is $10M in pipeline and $1M in closed-won, and the probability is 50%, the expected value is $500K. Now divide by the effort required.

Down-weight stuff that has big potential payoff but insane effort. Find things with similar expected value but much less organizational lift.

Easy wins Kyle recommends:

• Automating CRM enrichment after calls

• Support automation

• Inbound AI SDR

Adoption principles that actually work

Kyle’s five core principles:

1. Foundation before flash. Fix your 3P and 1P data. Ace CRM hygiene. Don’t worry about avatar-based sales or AI solution engineers until the foundations are solid.

2. Adoption is everything. Nothing matters unless reps actually use these tools. Early investments should make their jobs easier. If the language makes them feel like you’re trying to replace them, nothing will get traction.

3. Learn before you scale. Force vendors to do pilots. Get rigorous with references. Test in small groups of reps or small batches of data. Have a testing infrastructure. Evals should be on point.

4. Integration over addition. Don’t add new surfaces. If you add one, consider taking away one. Owner pushes most AI outputs to reps in Salesforce. Salesforce is their surface. Pre-call research happens elsewhere, but reps don’t have to click through to another tool.

5. Cultural transformation > technical implementation. Spend at least as much time on driving adoption as on technical components. Spotlight what works. Slow-roll to the organization. Don’t deploy through a Slack announcement and wonder why nobody uses your cool AI stuff.

Bonus: Generative + Deterministic

Kyle added a bonus tip: Many AI implementations fail because they’re stacking generative layers on top of one another. That’s how you get slop.

You need deterministic layers to provide structure. If a big part of a vendor’s value prop is how little work it requires (”We figure out your positioning, we identify your market, we pick prospects, we generate messaging, we send them...”), be skeptical. That’s a lot of generative steps with no human input or deterministic structure.

How much time does Kyle personally spend on AI?

Kyle personally spends 10+ hours learning and tinkering with AI each week.

Podcasts, Twitter, YouTube, playing with tools himself. He gave an example: Gemini 3 came out, and even though all his stuff is in ChatGPT with tons of memory and projects, he spent two hours that night running the same prompts in both tools, comparing outputs, testing atomic reasoning vs. chain of thought.

His wife is watching TV. He’s got one AirPod in, exploring.

It’s hard to even say how much time, because my life… every part of my day… is informed by AI now. Ten hours is just the exploration and learning stuff. Not an hour goes by that I’m not in one of these tools.

And even with that, he feels behind. Which made me feel better, because I constantly feel behind!

The Bottom Line

Kyle’s session was the perfect closer for the summit. It zoomed out from tactics to strategy—what it actually means to lead a revenue org in the AI era as a CRO of a fast-growing SaaS company.

The framework:

1. Get AI-native yourself. Daily tool usage. First principles understanding. Build something with your own hands.

2. Fix data foundations first. 3P and 1P data. Documentation. CRM hygiene. Don’t pass go until this is done.

3. Build capability internally. 70% leveling up your team, 20% hiring expertise, 10% strategic consulting. Don’t outsource the transformation.

4. Prioritize ruthlessly. Map possibilities, estimate payoff and probability, calculate expected value, divide by effort.

5. Drive adoption like your job depends on it. Because it does. Cultural transformation matters as much as technical implementation.

The companies that figure this out will be 3-4x more productive than their competitors. That advantage compounds.

This isn’t about the future. This is about survival today.

Watch the full session on YouTube (28 minutes):

Grateful for Kyle closing out the summit. If you want more from him, subscribe to the Revenue Leadership Podcast—it’s excellent.

Follow Kyle Norton on LinkedIn.

→ Kyle is CRO at Owner.com, host of the Revenue Leadership Podcast & SaaS GTM Advisor & Investor.

That’s a wrap on the AI x GTM Summit session recaps!

Thank you to all 645 of you who registered, attended live, asked questions, and engaged. Thank you to all six speakers for sharing so generously. And please go check out the awesome sponsors that made this event possible: Rox, Attention, Clarify, Sumble, Instantly.

Excited to publish more (deeply researched, opinionated) content in the coming months.

Thank you for your attention and trust,
Brendan 🫡

Subscribe now

Thanks to the companies that made the AI x GTM Summit possible! (+stats/notable attendees)

Automating Signals That Work in Your Specific Market

The Alpha Is in the Niche Signals

Publicly available, third-party signals are becoming commoditized.

Job postings, website visits, LinkedIn engagement. Everyone’s tracking these now. They’re better than nothing, but the real alpha is in niche signals.

At the AI x GTM Summit, Soham Maniar (a modern RevOps ninja) shared what actually works in signal-based selling. Soham is one of those RevOps people who makes the job feel creative and fun while still being rigorous. He’s currently at Nominal.io and has built signal engines at companies like Weaviate and others.

Our conversation covered how to think about signals, where the real value is, and how to operationalize all of this without drowning in noise.

Here’s what we covered:

• Setting the stage: TAM → ICP → SBM

• AI-enabled company tiering (custom ICP)

• The three-circle overlap (ICP + engagement + readiness)

• Niche signals are the alpha (plus real examples)

• Timing matters more than copy

• How to find the right signals for your business

• Who owns this? (RevOps, GTM engineering, SDR leaders)

• Operationalizing signals without creating noise

Follow Soham on LinkedIn! He’s a legend.

[Suggested Spotify playlist while reading this series]

IYMI:

• Session #1 → Sorting the World into your CRM (GTM gold is stuck in your top seller’s brain: How to extract + operationalize it) || YouTube video of Matthew and Andreas’ full session (22 mins)

• Session #2 → Infrastructure for agentic GTM: data stack, orchestration, and activation || YouTube video of Nico’s full session (23 mins)

• Session #3 → Getting agents deployed into your GTM systems: pitfalls, opportunities, and best practices || YouTube video of Joe’s full session (19 mins)

• Session #4 → Nuanced Viewpoint on AI-Generated Outbound Email Copy | YouTube video of full session (22 mins)

Alright, let’s get into it.

Setting the stage: TAM → ICP → SBM

I opened this session with a framework that I use to think about targeting. The “signal-based market” are a small set of accounts that are the most likely to respond and have a sales conversation if you reach out to them today.

TAM (Total Addressable Market) is your entire potential market. Use this for market sizing in your investor deck, not for GTM planning. Revisit ~annually.

ICP (Ideal Customer Profile) is the profile of your best-fit customers. Tier accounts by fit in your CRM. Revisit ~quarterly.

SBM (Signal Based Market) is the subset of your ICP that’s signaling intent right now. This changes daily or ~weekly.

Here’s how the numbers might look:

• TAM: 150,000 accounts

• ICP: 30,000 accounts (Tier 1: 5k, Tier 2: 10k, Tier 3: 15k)

• SBM: 112 accounts (today)

Those 112 accounts are the ones most likely to take a sales meeting with you today. You’re not blasting all 30,000 accounts every week. You’re using signals to identify which ones to reach out to and when.

AI-enabled company tiering (custom ICP)

Before you can identify signals, you need to know what a good account looks like.

The smartest GTM teams are moving beyond basic firmographic data. And using AI agents to find “rich” data points—stuff that’s specific to your business, not the same attributes everyone else is using.

Why:

• Basic firmographics (industry, employee count, revenue) are commoditized

• AI can find custom data points that actually correlate with your best customers

How:

• Enrich accounts with AI workflows

• Use bespoke data points in a scoring formula

• Automate company-fit scoring so it runs forever—every new account gets tiered automatically

The output of this system tags Accounts in your CRM with High fit, Medium fit, Low fit, Unqualified (or Tier 1, 2, 3). Then, you layer signals on top.

The three-circle overlap (ICP + engagement + readiness)

Soham shared a framework he’s used at multiple companies: a Venn diagram with three overlapping circles.

Circle 1: ICP/Firmographic/Technographic Score

• Do they match your ideal customer profile?

• Right industry, size, tech stack, etc.

Circle 2: Engagement Score

• How engaged are they with your content?

• Website visits, event attendance, content downloads

Circle 3: Readiness Score

• Are they showing signals that they’re ready to buy?

• Pricing page visits, compliance/security page views, specific high-intent actions

No individual circle is interesting on its own. The magic is in the overlap. The center of the Venn diagram is the sweetspot.

When you look at accounts that score high on all three—ICP fit, engagement, and readiness—you’re looking at your hottest opportunities. That’s where your SDRs should be spending their time. That’s where your AEs should start their pipe gen blocks.

Niche signals are the alpha (plus real examples)

Everyone’s using the same signals: job postings, website visits, LinkedIn engagement. Those are fine. But the alpha is in the niche signals. The creative signals specific to your business that competitors aren’t tracking.

My Turing test for a good signal: If someone inside the company describes a signal to you (an outsider) and I don’t even know what the words mean, it’s probably a good one. :)

Example 1: Terms of service updates

I worked with a company in the data compliance space. One signal we used was when a company updated their terms of service page.

I had no idea this was even a thing, much less trackable (scrapeable). But when companies update their terms of service, they legally have to notify all their users. People write in asking to be removed from lists. It creates a bunch of work.

This company helps handle that process. So when they detect a terms of service update, they reach out: “Saw you just updated your terms of service. We help with that whole process you probably just felt the pain of over the last two weeks.”

Out of 30,000 accounts in their ICP, 122 updated their terms of service last month. Those 122 get the outreach. Timing is perfect. Relevance is high.

Example 2: Technical documentation paths

At Weaviate (AI/vector database company), Soham saw a strong correlation between visitors to technical documentation and deal outcomes.

So, he would create pathways within technical docs to understand if there’s a correlation between people going from doc A → B → C. Does that pattern tell you something about an incumbent tool they’re using? Or a specific part of your product they’re struggling with?

Example 3: New restaurant locations

Soham mentioned Kyle from Owner (the final speaker at the AI x GTM Summit). When you’re selling to SMB restaurants, how do you even figure out where they’re at?

Now you can detect when a new location opens. You can figure out if surrounding restaurants have foot traffic. You can find correlations between types of restaurants and success patterns.

Five years ago, this was impossible without lots of manual work. Now you can build it with the cutting-edge tools.

Timing matters more than copy

Soham’s hot take (which I agree with completely):

“Mediocre AI copy can work if it’s landing at the exact right time.”

He gave a great example: if he got 20 emails after this webinar with the subject line “Loved your webinar,” he’d open all of them. Even if they were AI-generated. Even if there was no human in the loop.

But if those same emails arrived two weeks later? His likelihood of opening them drops dramatically.

Timing is the unlock.

How to find the right signals for your business

This was one of the most practical parts of the conversation. We discussed how you actually figure out which signals matter for your specific market.

Step 1: Talk to your best sellers.

Soham’s first move at any new company: talk to 5+ sellers. Ask them to walk you through recent deals. They may not realize they’re telling you about signals, but they are.

“Hey, this deal came in from this place. Then I looked up this thing. Then I sent 12 emails and a phone call finally worked...”

You can dissect a ton from that conversation.

I would also add that talking to the CEO and/or founders of the company will generate a bunch of good ideas, too.

Step 2: Ask what a great lead looks like.

Ask your top rep: “When you show up for a 30-minute demo, what does a great lead look like? What do you research before the call? What do you look for?”

They’ll tell you. And whatever they’re looking for—that’s a signal you can potentially automate.

Matthew also talked about this in session #1 of the summit.

Step 3: Backtest everything.

Soham’s caveat to the whole subject of signals was that they have to matter at the end of the day. They have to generate real pipeline. And eventually, closed deals. Not just vanity metrics like replies.

You can generate all the meetings you want. But if the signals aren’t converting to revenue, you need to re-evaluate and keep iterating.

Who owns this? (RevOps, GTM engineering, SDR leaders)

Here is Soham’s take on ownership:

RevOps sits at the top layer. They see across marketing, sales development, AE pipeline, post-sale, CS, account management, upsell, renewal—the whole lifecycle.

GTM engineering works under or closely with RevOps. They build the workflows and automations.

SDR leaders are the unsung heroes. The SDR role is two functions: research and outreach. AI and signals can 10x both. But you need to stay close to your SDR leader to figure out what to prioritize.

If you’re a RevOps person trying to do this alone without input from sellers and SDR leadership, you’re underwater.

Operationalizing signals without creating noise

Soham’s framework to operationalize and automate signals for every account:

1. Ignore completely. Some accounts just don’t deserve attention right now.

2. Warm outreach at scale. Marketing nurture, automated sequences.

3. Manual human effort. Real sales outreach from a rep.

What’s different now: you have AI-led options in the last two categories.

• Marketing nurture can be AI-led (tools like Profound, AirOps for GEO).

• Sales outreach can be AI-led SDR work or human-led SDR work.

On alerts:

Sales-led alerts make sense if you have a smart way to action them. But alerts just for alerts’ sake create noise.

You need to build the proper Salesforce architecture to track which alerts actually work. That’s the level of rigor required.

On prioritization:

It’s just as important to figure out what to cut as what to prioritize. Don’t try to touch everything with a marketing email just because you can.

Soham asks, “What are the 100 customers you’d be most proud to have won at the end of the year? Work backwards from there.”

Tool agnostic (start small, iterate quickly)

Soham’s closing advice was around being tool agnostic. Clay, Common Room, Sumble, etc. You can accomplish similar things with most of them. What matters more: understanding your problems and jobs to be done before you engage with vendors.

By the way, I agree. I think it’s important to avoid “gear acquisition syndrome.”

His approach:

• Minimize vendor spin (it’s exhausting and isn’t critical)

• Index on high velocity, high support, ability to pivot

• Start with a couple signals, not a master doc of every signal on the planet (huge!)

• Backtest with real results

• Iterate quickly

“Start small, iterate quickly, always backtest with your real results and data. You can spin up a pretty good signal engine really quickly.”

The Bottom Line

Signals are powerful, but only if they’re the right signals for your specific business.

The commoditized stuff (job postings, website visits, LinkedIn engagement) is table stakes. The alpha is in the niche signals that are specific to your market, your product, and your buyers.

The formula:

1. Tier your ICP → Use AI to enrich and score accounts by fit

2. Layer signals on top → ICP fit + engagement + readiness

3. Find niche signals → Talk to your best sellers, mine their research process

4. Backtest everything → Real pipeline, real revenue, not vanity metrics

5. Start small → A couple signals, iterated quickly, beats a master plan that never ships

The 112 accounts in your “Signal-based market” today are different from the 94 accounts next week, and 133 the following week. That’s the point. Signals are dynamic. Your outreach should be too.

Timing is the unlock. Niche signals are the alpha.

Watch the full session on YouTube (23 minutes):

Grateful for Soham for sharing how modern RevOps leaders are building AI-native GTM machines today. If you’re thinking about signal-based selling, he’s one of the best operators in the space.

Follow Soham Maniar on LinkedIn.

→ Soham is currently at Nominal, building RevOps and GTM infrastructure for a hardware-focused company. Previously at Weaviate (AI/vector database), Mixpanel, AWS, Twitter, Bluewolf and others.

The final session summary of the AI x GTM Summit will be in your inbox next: Learn, Build, Scale: A Revenue Leader’s AI Transformation Roadmap, with Kyle Norton (CRO of Owner.com).

Thank you for your attention and trust,
Brendan 🫡

PS: Check out the sponsors that made this event possible: Rox, Attention, Clarify, Sumble, Instantly.

Subscribe now

Thanks to the companies that made the AI x GTM Summit possible! (+stats/notable attendees)

Is AI copy good or bad? The reality is not so binary. It’s more nuanced. But that’s a horrible “hook” on LinkedIn or X, so you don’t see those posts going viral.

One camp says AI copy is garbage. “Soulless slop that’s destroying cold outbound.”

The other camp says AI copy is the future. “Personalization at scale, finally.”

For this session at the AI x GTM Summit, Eric Linssen (my Chief Vibes Officer of the event) did a live teardown (with the audience) of four cold emails. What worked, what didn’t, and what this tells us about the state of AI copy in 2026.

Here’s what we covered:

• The game: AI or Human? (4 email teardowns)

• What makes AI copy good (when it works)

• The AI “tells” everyone notices now

• Timing matters 10x more than copy

• Stop asking, start giving (proactive value)

• Human in the loop for the final mile (for now)

• Subject lines, deliverability, and other details that matter

Follow Eric on LinkedIn (and apply to join Demand Collective if you’re a DG practitioner—or send to a DG friend or colleague)!

[Suggested Spotify playlist while reading this series]

IYMI:

• Session #1 → Sorting the World into your CRM (GTM gold is stuck in your top seller’s brain: How to extract + operationalize it) || YouTube video of Matthew and Andreas’ full session (22 mins)

• Session #2 → Infrastructure for agentic GTM: data stack, orchestration, and activation || YouTube video of Nico’s full session (23 mins)

• Session #3 → Getting agents deployed into your GTM systems: pitfalls, opportunities, and best practices || YouTube video of Joe’s full session (19 mins)

Before getting into the examples, I wanted to share a basic cold email framework I’ve been using for over a decade. I was taught this framework in my first job as an SDR, and it still works great as a prompt/example when scaling experiments with AI. Here’s the framework:

And here’s the framework applied to an example:

AIDA is another framework that works well.

Alright, let’s get into the other examples and reactions/lessons from them.

The game: AI or Human? (4 email teardowns)

We showed four cold emails to the audience.

Email #1: Cursor

Subject: Saw your AI tooling req

Hey {{first_name}},

Noticed {{company}} is hiring devs with AI coding tool experience. Sounds like you’re serious about building this into how the team works, not just letting people experiment.

That’s the hard part. Most eng orgs I talk to are stuck between “everyone uses whatever” and “we should probably have a strategy here.”

Happy to share what’s working for teams making that shift if useful.

Audience rated it around 7/10.

You can pull keywords like this from tools like Sumble.

Eric’s take: “Two things make this good. One, the specificity—AI tooling req, hiring devs with AI coding experience. That’s two very specific signals. You couldn’t send this to just anyone. Two, the tone. It says ‘devs’ not ‘developers.’ It says ‘rec’ not ‘requisition.’ It feels human.”

The audience was split on whether it was written by human or AI. Most guessed AI (correctly), but a few said human. That’s a good sign. It means the copy passed the “turing test” for some people.

Email #2: Lovable

Subject: React + Supabase + Tailwind

Hey {{first_name}},

Was reading {{company}}’s job post mentioning React, Supabase, and Tailwind. That’s exactly the stack Lovable outputs out of the box.

Curious if your team’s explored using AI to scaffold new features or spin up internal tools faster. A few companies with similar stacks have cut their prototyping time from weeks to hours.

Worth a quick chat to see if it fits your workflow?

Audience called this one “slop.”

Eric: “The AI breath is strong on this one.”

The problems: “Was reading” feels robotic. “That’s exactly” is a tell. “Curious if your team’s explored” is the kind of phrasing no human actually uses. The whole thing reads like it was assembled from parts, not written.

Email #3: Attention

Subject: Saw you run MEDDIC

Hey {{first_name}},

Since {{company}} uses MEDDIC, I bet your reps struggle to update those fields after every call (but there’s gold when they do).

Attention auto-populates MEDDIC (and whatever other frameworks or fields you use) straight from the conversation. No manual entry, no CRM hygiene nagging, no end-of-quarter data cleanup scrambles.

Worth 15 mins to see if it fits how your team runs?

This one was written by AI (Claude). The audience thought it was pretty good.

This one worked better because the signal is clear (MEDDIC usage). The pain is relatable (reps not updating fields). The value prop is specific (auto-populates from conversation). Again, tools like Attention (previous calls), Rox, and Sumble give you data that you can get creative with to build unique signals for your market.

My critique: I don’t love “Worth 15 mins?” as a CTA. Asking for time in a cold email is a big ask. More on that below.

Email #4: Stripe

Subject: Saw your post on cross-border payments

Hey {{first_name}},

Just read your LinkedIn post about the headaches of paying international contractors, so I figured this might be timely.

Stripe just rolled out Stablecoin Financial Accounts that lets you hold, receive, and send stablecoins in 101 countries. Settlements are near-instant, and transaction costs are about half what you’re paying on traditional cross-border rails.

If international payments are a growing line item, might be worth a look.

Happy to walk through how it works if useful.

AI also wrote this one. The audience had mixed reactions. Some liked it, some didn’t.

The signal here is solid (LinkedIn post about cross-border payments). The timing is good. But the copy feels a bit dense, and “might be worth a look” is soft.

What makes AI copy good (when it works)

Across all four examples, a pattern emerged.

The good ones had:

• Specific signals. Not generic firmographics. Real signals that show you did research.

• Human tone. “Devs” not “developers.” Short sentences. Contractions.

• Clear pain → value. I have this problem, you solve it, here’s how. Again, think about this framework: Connection Point, Pain, Gain, CTA.

The bad ones had:

• Robotic phrasing (“AI breath”). “Was reading,” “Curious if your team’s explored,” “That’s exactly”.

• Generic structure. Could be sent to anyone with minor tweaks.

• No real insight. Just restating what you found, not adding perspective or tying it to your company’s value prop.

The AI “tells” everyone notices now

Eric pointed out something important: the bar is rising every few months.

A year ago, “noticed” was fine. Now it’s a tell. Same with m-dashes (—). Same with “exactly.” Same with overly structured sentences.

The audience is getting smarter. People assume every cold email is AI until proven otherwise. One person in the chat said: “By default I assume every outreach email is AI from now on.”

That’s the new baseline. Your AI copy has to be good enough to pass that filter.

Timing matters 10x more than copy

I strongly believe that email copy (human-written or AI-written) matters far less than reaching out to a company at the right time.

If I’m actively looking for a CRM and some CRM vendor sends me a mediocre cold email, I’ll probably respond. I’m in market. The timing is right. The copy can be average.

The inverse is also true. If I’m not looking for a CRM and someone sends me a perfectly crafted, beautifully personalized email with common connections and rich context... I’m still not responding. I’m not in market.

Timing is 10x more important than copy. Maybe 100x!

The implication (if true) means that you should spend more energy on signal detection (finding accounts that are in-market right now) than on copy optimization. Though the copy does matter. The signal is the unlock.

Stop asking, start giving (proactive value)

Another theme that kept coming up was that the best cold emails give something, not ask for something.

“Worth 15 minutes?” is an ask. You’re asking for their time.

You should try to proactively give them something instead (even a unique insight). Ideally, it’s something so valuable they’d be willing to pay money for it. But, you’re giving it to them for free.

Examples from the session:

CRM audit for Attention: Instead of asking for 15 minutes, run an automated audit of their open opportunities. Show them: “You have 842 open opps. 72% have MEDDIC fields filled out accurately. Here’s your 28% gap.” That’s useful. That’s value.

Candidates for Bravado: Bravado has a database of sales candidates. When a VP of Sales opens a job req for Enterprise AEs, they don’t just pitch the database. They query it, find 2-3 candidates that match the job req, and send those profiles in the email. “Hey, you should chat with Sarah, Mary, and John. Here are their profiles. Want to see more like them?”

The VP of Sales gets actual candidates in their inbox. Their immediate question (”Are the candidates any good?”) is answered before they even have to ask. That email only works if you send it now. Wait six weeks and they’ve already hired those AEs. The window closes.

That’s what “proactive value” looks like. Not a generic lead magnet. Something specific to their situation that answers their next question.

Timing + proactive value + specificity = response.

Human in the loop for the final mile (for now)

One thing I feel strongly about: fully automated outbound isn’t there yet.

AI is very good at research. It can pull signals, enrich accounts, draft personalized emails. In most cases, the final mile—the moment before you hit send—should still be a human. Especially in the enterprise.

Why? Because there’s always context that the AI doesn’t have. Maybe you met this person at a conference last year. Maybe their company just had layoffs, and the tone needs to shift. Maybe the AI pulled a signal that’s technically accurate but feels off when you read it.

A human catches that. An agent doesn’t.

My recommendation: AI does 90% of the work (research, drafting, prioritization). Human does the last 10% (review, tweak, send).

The exception: inbound and quasi-marketing use cases (like if someone downloads a whitepaper, emailing attendees before or after an event, etc). These are lower-stakes, higher-volume, more templated. The cost of a miss is low.

For true cold outbound to accounts you really care about (like a top 500 target/named account)? Human-in-the-loop is the way. At least for now. For your Tier 3 accounts (lower ACV deals), go ahead and automate away!

Subject lines, deliverability, and other details that matter

A few other things came up in this session.

Subject lines:

• Keep them short (three words or less is ideal).

• Make them conversational, not “markety”.

• “Saw your AI tooling req” works. “Cursor + {{company}}: AI Coding Strategy” doesn’t.

Deliverability:

• If your emails don’t land in the inbox, nothing else matters.

• Use tools like Instantly for warming and rotation.

• If you’re sending from lookalike domains (not your primary), keep signatures text-only—no images, no links. And sadly, I would recommend you fully disable Open and Clicks because they both hurt deliverability.

Signature blocks:

• Text only if you’re sending from secondary domains.

• If you’re sending from your primary domain and you have high transactional email volume (like Ramp or Zoom), you have more flexibility.

The Bottom Line

AI email copy is neither good nor bad. It depends on the context whether you should use it or not. But, the foundational models are getting incredibly good at cold email when you give it the right context (and examples). I wouldn’t have said that at the beginning of 2025.

The formula that’s working:

1. Signal first. Find accounts that are in-market right now. This matters more than copy.

2. Specificity. Use real signals in your emails. Not generic firmographics.

3. Human tone. Read it out loud. Does it sound like a person wrote it?

4. Give, don’t ask. Proactive value beats “Worth 15 minutes?”

5. Human-in-the-loop. AI does the research and drafting. Human does the last-mile review before send.

The bar is rising. Your AI copy needs to be better than it was six months ago just to stay even. But if you nail the timing and add real value, cold email (with the help of AI) can absolutely work.

Timing is the unlock. Copy is the execution.

Watch the full session on YouTube (22 minutes):

Thanks again to Eric for co-hosting this one with me.

The “AI or Human?” live teardown format was fun. Might have to run it back sometime.

Follow Eric on LinkedIn (and if you spend $100K+/mo on ads, apply to join Demand Collective—Eric’s community)!

I can’t stop thinking about this tweet (yes, it’s about AI)

Session #5 summary coming next: Automating signals that work in your specific market.

Thank you for your attention and trust,
Brendan 🫡

PS: Check out the sponsors that made this event possible: Rox, Attention, Clarify, Sumble, Instantly.

Subscribe now

Thanks to the companies that made the AI x GTM Summit possible! (+attendee stats/notable attendees)

Getting agents deployed into your GTM systems

Pitfalls, opportunities, and best practices with Joe Rhew

“Agents” is the buzzword of the moment. Everyone’s talking about them. But very few people have actually built and shipped one into production.

Over the last 12 months, exploring this space, my experience with agents has been much more nuanced than the (social media) hype suggests. You’re not going to replace all your workflows with agents. You’re not going to let AI run wild on your prospects. Especially in the enterprise. The reality is messier—and more interesting! And figuring out that messiness is where the alpha is today (because, so few GTM teams are actually deploying agents at scale).

In Session #3 at the AI x GTM Summit, Joe Rhew broke down what he’s learned deploying agents for clients at The Workflow Company. I’ve found that Joe is usually about six months ahead of the curve on AI in GTM. What he’s building today is what everyone will be talking about in six months. And he’s not just building theoretical toys or shiny demos. He’s shipping real agents, automated workflows, and everything in between, into production.

For example, he didn’t build his slides/presentation in Google Slides or even Gamma. He built it in github lol (check it out). Legend.

Here’s what he covered in this session:

• The spectrum: workflows vs. agents (definitions + when to use each)

• Context engineering > prompt engineering (the new skill)

• Unified context powers everything (build once, use everywhere)

• Live demo/examples: deterministic vs. agentic workflows

• Lessons learned (6 principles for deploying agents)

→ Follow Joe on LinkedIn! He consistently shares (bleeding-edge) ways he’s using AI in his company.

[Suggested Spotify playlist while reading this series]

IYMI:

• Session #1 → Sorting the World into your CRM (GTM gold is stuck in your top seller’s brain: How to extract + operationalize it) || YouTube video of Matthew and Andreas’ full session (22 mins)

• Session #2 → Infrastructure for agentic GTM: data stack, orchestration, and activation || YouTube video of Nico’s full session (23 mins)

Alright, let’s get into it.

The spectrum: workflows vs. agents (definitions + when to use each)

Joe was one of the first people to help me understand the subtle, but important differences between a workflow and an agent. And why you would want to use one versus the other (or a combination!).

He laid out the spectrum:

Workflows → A predetermined, deterministic set of steps. No LLM involved. Think Zapier automations or HubSpot sequences. You control 100% of the inputs and outputs.

Agentic Workflows → Still has a predetermined sequence, but there’s an AI step in the middle. You send a prompt to an LLM, get a response, and turn it into structured output (like JSON) so you can do something deterministic with it. Example: “Write a sequence of three emails and return them in JSON format so I know exactly where to find each one.”

Agents → Tools on loops with a goal. You give the agent an objective and some tools, and it runs loops—calling tools, observing results, thinking, acting—until it reaches the outcome. You’re not feeding it deterministic inputs or expecting deterministic outputs. You’re trusting it to figure things out.

The key insight: these aren’t competing approaches. They’re a spectrum. And the best GTM systems use all three—starting deterministic, adding AI where it helps, and reserving full autonomy for the right use cases.

I came into 2025 thinking agents would replace workflows entirely. My thinking has evolved. There are real advantages to hard-coded, logic-based components: predictability, cost savings, debuggability. The future isn’t “agents everywhere”—it’s knowing when to use each approach.

Context engineering > prompt engineering (the new skill)

Remember when “prompt engineer” was the hot new role? That’s already evolving.

“Context engineering is the delicate art and science of filling the context window with just the right information.”
—Andrej Karpathy

Not more. Not less. Just the right amount of information.

This matters because there’s a degradation of performance when you cram too much context into an agent. And there’s terrible output when you give it too little (eg: try having ChatGPT write a cold email for you, without any other context about your business or previous interactions you’ve had with the prospect). The skill is knowing exactly what to include.

Prompt engineering example:

“Write me a cold email. I target heads of sales at Series B companies.”

The LLM gives you something generic / not useful.

Context engineering example:

Feed the LLM: your product info, the exact persona (eg: VP of Sales), the prospect’s LinkedIn data, and your writing guidelines for cold emails and good examples. Then ask the LLM to do the same task.

Same AI/model, different context = completely different results. It’ll be personalized, relevant, on-brand, and contextual. And actually usable.

The shift: instead of crafting clever prompts, you’re architecting what information the AI has access to. That’s the new skill to develop.

Unified context powers everything (build once, use everywhere)

The real magic of this new way of building is knowledge (context) compounding over time.

Joe showed how The Workflow Company stores their GTM context: markdown files in a GitHub repo. Products. Personas. Messaging. Campaign angles. Guidelines.

The best part is, he didn’t type any of it out manually.

He pulled in emails, Slack messages, marketing website copy, LinkedIn posts—fed it all to an LLM with some feedback—and it generated the structured context files. The AI built its own knowledge base.

And now that context powers everything:

• Workflows (automated sequences)

• Agentic workflows (personalized emails)

• Full agents (research and strategy)

The magic: Update your knowledge once, and all your AI systems use it immediately. No code deploys. No manual syncing across tools.

This is the foundation that makes agents actually work. Without unified context, every AI touchpoint is starting from scratch. Or worse, working from inconsistent information.

Live demo/examples: deterministic vs. agentic workflows

Joe showed two versions of the same use case: handling a website visitor (a play I’ve written about before).

Demo 1: Deterministic workflow (human-in-the-loop)

RB2B identifies a website visitor. The visitor’s LinkedIn URL hits a Slack channel. The system automatically processes the LinkedIn profile and surfaces who they are.

Then it stops. And waits for a human.

Joe explained why: “I get a bunch of hits from people that I don’t want to talk to. People that aren’t a good fit. So I manually tell the system to generate a sequence.”

Only after human approval does it research the prospect and draft emails. Then those emails can be enrolled into a sequence.

This is agentic, but with guardrails. The AI does the work, and the human makes the decisions.

Demo 2: Full agent (conversational, autonomous)

Joe chatted with a Slack bot.

He asked: “Tell me about the personas we target at WFCO.”

The agent read the personas markdown file, checked what other files were available, and responded with the full breakdown (eg: target personas, anti-personas to avoid, everything).

Then he asked it to evaluate a specific prospect (me! 👋): “Based on those personas, is Brendan Short a close match? Let’s think about our outreach strategy.”

The agent used tools to fetch my LinkedIn profile, read my recent posts, pulled in messaging guidelines and product info, and concluded: “Strong fit, but not as a traditional customer. He’s a content creator, thought leader, influencer. Not a buyer—but valuable as a referral source, network access, credibility builder, content collaborator.”

Which is exactly why I invited Joe to speak at the summit! Wild to see it so spot-on in its reasoning.

The agent then suggested partnership outreach instead of a sales approach and drafted appropriate emails.

The feedback loop:

Joe then told the agent: “Based on this, let’s add an appropriate persona for Brendan to our context.” This is a perfect example of how interactions with agents should be an ongoing thing that informs the context as your GTM (and learnings) evolve over time.

The agent proposed adding a new “Influencer/Referral Partner” persona to the personas file. Just like that, the system evolved — not through a scheduled “persona review meeting,” but as a byproduct of doing actual work.

What most people understand: agents automate things intelligently and with agency.

What most people miss (and the real unlock of using agents): every task you run through the system generates byproducts—edge cases, new patterns, gaps in your framework. Most tools let those insights evaporate. An AI-native unified context system captures them and feeds them back in. So, the work improves the system. And the system improves the work. It compounds.

Lessons learned (6 principles for deploying agents)

Joe closed with principles from deploying these systems into production.

1. Start deterministic

Build reliable workflows before adding AI autonomy. Full control over inputs and outputs first. Then layer in intelligence.

2. Human-in-the-loop always (at first)

Approvals are cheap. Mistakes are expensive. Phase out human review slowly as you build confidence in the system.

3. Keep agents internal

Use them for research and brainstorming before you ever let them touch anything customer-facing. Joe’s Slack agent doesn’t send emails until he explicitly tells it to. Less risk of public messes.

4. Shared context foundation

Same knowledge powers all your AI tools. Build it once, build a mechanism to update it well, and you don’t have to worry about consistency.

5. Build modules → tools

Test a function until it’s reliable, then wrap it as a tool you can give to agents. Modular design lets you swap components in and out.

6. Minimize abstraction

With Claude Code, you can talk directly to an LLM and have it write scripts, code, whatever you need. The cost of abstraction layers (drag-and-drop UIs, etc.) is becoming too high. Work closer to the metal.

The Bottom Line

Joe’s session reframed how I think about agents in GTM. He helped me evolve and expand my thinking about the pros and cons of workflows.

It’s not about replacing everything with AI. It’s about building a spectrum of automation—deterministic where you need reliability (and cheap scale), agentic where you need flexibility, and fully autonomous only where you’ve earned the right to trust it.

The foundation is context: unified, structured, continuously updated context that powers every AI touchpoint in your system.

The framework (summary):

1. Build your context layer (products, personas, messaging, guidelines)

2. Start with deterministic workflows

3. Add AI steps where they help

4. Keep humans in the loop

5. Graduate to full agents only for internal, low-risk use cases

6. Let the system learn and evolve

The teams that get this right will have GTM systems that literally get smarter over time (you can think of this as building a “System of Intelligence” in-house). And the teams that skip the foundation (context layer) will wonder why their agents keep hallucinating and their automation feels chaotic, complaining that AI is overhyped.

Watch the full session on YouTube (19 minutes):

I appreciate Joe giving us a glimpse into the future of how we’ll use AI in GTM!

Follow Joe Rhew on LinkedIn.

→ Joe runs The Workflow Company (wfco.co), an AI-native GTM operations firm that builds GTM systems across the full spectrum — from deterministic workflows to autonomous agents, all powered by unified context. If you’re trying to figure out how to actually ship this stuff into production (not just talk about it), reach out to him directly. He’s truly building at the bleeding edge.

Session #4 summary coming next: Nuanced viewpoint on AI-generated outbound email copy.

Thank you for your attention and trust,
Brendan 🫡

PS: Check out the sponsors that made this event possible: Rox, Attention, Clarify, Sumble, Instantly.

Subscribe now

Thanks to the companies that made the AI x GTM Summit possible! (+attendee stats)

Infrastructure for agentic GTM: data stack, orchestration, and activation

RevTech Lessons From The Trenches with Nico Druelle

Everyone’s talking about AI agents. But not many people are talking about what makes them actually work.

The unsexy answer: infrastructure. Data unification. Real-time enrichment. Orchestration logic. The plumbing underneath the shiny demos.

Without it, you’re running automation on top of a broken foundation. Your agents inherit your data problems—and execute them at scale.

In Session #2 at the AI x GTM Summit, Nico Druelle laid out what he’s seen working inside companies like Linear, Descript, Canva, and others. Nico runs The Revenue Architects and has spent the last year deep in the infrastructure that powers modern GTM motions: building ABM programs, real-time enrichment systems, and the orchestration layers that make agentic workflows possible.

His session was a masterclass in what it actually takes to build this stuff. Not theory. But hard-earned lessons from the trenches.

Here’s what he covered:

• Doing ABM right (1st party data → custom signals → curate accounts)

• Real-Time Enrichment (Canva’s PQL example)

• Most teams still ignore the foundational gaps (3 pillars)

• The prize: a post-CRM era (before/after comparison)

• 3-layered stack (unified data → orchestration → rep interface)

• Building the right team (where to hire, reward, place)

Go follow Nico on LinkedIn!

Alright, let’s get into it.

Doing ABM right (1st party data → custom signals → curate accounts)

Nico started with two companies that have cracked ABM: Linear and Descript.

Both are successful PLG companies. Both brought Nico in to build product-led sales motions. And both went straight into ABM—not as a marketing program, but as a company strategy.

Why ABM? Because single-channel GTM doesn’t work anymore.

Cold outbound is saturated. Paid is getting diluted. You need a coordinated mix of channels working together. That’s what ABM does well (when done right).

Nico walked through a three-step process:

Step 1: Data unification.

Build an internal “ABM brain.” Stitch together data from CRM, warehouse, LinkedIn paid ads, product usage—everything. Aggregate at the domain level. Then fetch additional domains in your TAM that haven’t been exposed to your sales motion or product yet.

The result: a unified representation of your entire addressable market.

Step 2: Custom signals and curation.

Layer 20-30 custom data points per account. Not generic firmographics. Stuff that actually matters for your ICP.

Nico gave examples:

• Descript: Number of YouTube videos published in the last 30 days. (If you’re selling video editing software, this is gold.)

• Linear: Percentage of engineering headcount against total company headcount. (Engineering-heavy orgs are their sweet spot.)

Run these signals through an ICP score. Rank all accounts. Then curate the top tier—start small, maybe 500 accounts—with alignment across product, marketing, and sales.

Step 3: Orchestration.

This is where most teams fall apart.

Orchestration means being crisp on the rules of engagement. Who owns what. What touchpoints happen through which channels. Human outreach or agent? Making sure you’re not crossfiring (eg: three different teams hitting the same account with conflicting messages on the same day).

To orchestrate well, you need visibility: Where is this person in the paid funnel? Where are they in the product? Where are they in the outbound sequence? Where are they in the CRM?

That requires the unified data layer from Step 1. Without it, you’re guessing.

The takeaway: ABM isn’t a campaign. It’s a system. Alignment + focus → clarity → momentum → lower CAC, better win rates.

Nico’s second example showed what’s possible when you take this data-first approach even further.

Real-Time Enrichment (Canva’s PQL example)

Nico spent Q2 and Q3 at Canva building something powerful: real-time enrichment on top of their data warehouse.

The use case: any email collected through the product or any marketing asset triggers immediate real-time enrichment. Not batch processing overnight.

That enriched record includes a fully contextualized view of the user—who they are, what company they’re at, what signals suggest about their intent and fit (ICP score), product usage patterns, marketing engagement history, etc.. All computed the moment the lead enters the system.

From there, the system makes a routing decision: Should this go into an agent flow? Or into a human-driven GTM play?

Here’s what that looks like in practice:

A free user signs up. Within seconds, the system enriches their profile and scores them. High-fit account, senior title, already activated core features? Route to an agent that triggers a personalized onboarding sequence and alerts an AE. Low-fit account, junior title, casual usage? Route to a nurture flow—no human touch needed.

The key: this decision happens instantly, based on complete context. Not hours later when a batch job runs. Not days later when an SDR manually reviews the lead. Right now.

This is the infrastructure that makes agentic GTM possible. Without real-time enrichment, you’re always working with stale data. Your agents are making decisions based on yesterday’s picture. Your reps are reaching out to people who’ve already churned or converted.

The companies investing in this layer now are going to have a serious advantage because their systems can act with the same context a human would have, but at machine speed.

That’s what good looks like. But from what I’ve seen, most teams aren’t there yet.

And in the AI era, the cost of not fixing this has gone up dramatically. Data quality has always mattered. But when humans were the only ones acting on data, bad data meant inefficient reps. Now, with agents and automation, bad data means bad decisions executed at scale—faster than anyone can catch them. Mistakes compound with AI.

The gap between teams who have this infrastructure and teams who don’t is about to widen results. Exponentially.

Most teams still ignore the foundational gaps (3 pillars)

Before you can build the future, you have to fix the foundation. And, again, most teams haven’t.

Nico laid out three pillars where he sees consistent gaps:

Pillar 1: System of Orchestration

The problem: Missing key 1st or 3rd party data. Poor implementation of enrichment, intent, or research.

If your data foundation is broken, everything downstream breaks too. You can’t orchestrate what you can’t see.

Pillar 2: System of Context

The problem: Siloed teams with no unified customer view. Disjointed understanding of customer interactions. Misaligned definitions. Broken attribution.

Marketing thinks an account is cold. Sales thinks it’s hot. Product thinks it churned. Nobody’s looking at the same picture.

Pillar 3: System of Engagement

The problem: Generic outreach. Crossfiring communications. Missing ABM strategy. Weak outbound muscle.

This is where “friendly fire” happens. Three people from your company email the same prospect in one week with different asks. The prospect gets annoyed. The deal dies.

Nico’s point: these aren’t advanced problems. They’re foundational. And most teams skip past them to chase shiny tools.

Fix the foundation first. Then you earn the right to build what comes next.

The prize: a post-CRM era (before/after comparison)

So what does “good” look like?

Nico painted a picture of two worlds:

CRM-era workflows (the old way):

• Disconnected tools, static data

• Rep toggles between platforms

• Generic playbooks

• Missing feedback loops

The command center model (the new way):

• Unified context, real-time

• Rep works in one place

• Custom signal → action

• Continuous feedback loop

In the old model, the rep is the integration layer. Reps are manually stitching together information (context) from Salesforce, LinkedIn, Gong, Slack, the product, and their own memory. That’s exhausting. And it doesn’t scale.

In the new model, the system does the stitching. The rep shows up to a “command center” that already knows everything—and surfaces the right action at the right time.

Nico believes this is where the most productive teams are heading. Some are already experimenting with it. The productivity gains are real. (And I couldn’t agree more!)

So how do you actually build this?

3-layered stack (unified data → orchestration → rep interface)

To build the command center, you need the right architecture. Nico broke it into three layers:

Layer 1: Unified Data + Context Layer

This is the brain. It knows everything—CRM data, product data, marketing data, enrichment, signals, conversation history. All stitched together at the account and contact level.

Layer 2: Orchestration Layer

This is where agents and plays live. The logic that decides: what action should happen next? Who should take it? When?

Layer 3: Rep Interface (Command Center)

This is what the rep actually sees. A single surface that pulls from the context layer and the orchestration layer to show: here’s your priority account, here’s why, here’s what to do.

The key insight: most teams try to build Layer 3 first. They buy a shiny new tool and hope it solves everything. But without Layers 1 and 2, the command center has nothing to show.

Start with the data. Then build the orchestration. Then build the interface.

The architecture is clear. But who actually builds it?

Building the right team (where to hire, reward, place)

The biggest bottleneck Nico sees is staffing this modern GTM engine.

GTM engineering is a new function. There are maybe a few hundred people on LinkedIn with that job title. The talent pool is tiny.

So where do you find people?

First option: Adjacent roles

Look for people in GTM systems, GTM technology, revenue operations, or growth operations. They already understand the motion and the metrics. The ramp-up is manageable.

Second option: Data engineering and analytics

Especially if they’ve been exposed to GTM projects—building dashboards for marketing or sales leaders, for example. They have the data skills. They understand the stakeholders. Small jump to GTM engineering.

Third option: Solution engineers

They’re technical. They understand buyer problems. They know how to translate between business and systems.

Fourth option: Young SDRs, CSMs, or AEs

Specifically: people from quantitative fields with systems-thinking minds. They have context on the sales motion. They might need more ramp-up on the technical side, but when it works, it works well.

How to reward them:

Nico likes an 80/20 split (base/variable). The variable component is tricky—pipeline created is one option, but GTM engineers work across the funnel. Retention, AE productivity, expansion. It varies.

His recommendation: track number of experiments launched and number of successful experiments. Velocity of experimentation is a leading indicator of quality.

Where to place them:

Reporting structure matters less than squad composition. Nico’s seen GTM engineers report to Head of Growth, Head of RevOps, even VP of Sales. What matters is the team around them:

• Someone who owns the experiment roadmap (Head of Growth, GTM PM, etc.)

• A data analyst to build reports and handle data structure

• A CRM/systems person for complex integrations

The goal: let the GTM engineer focus on launching experiments and learning, not getting stuck in Salesforce permission hell.

The Bottom Line

Nico’s session was a reminder that the “AI-native GTM” future everyone’s talking about requires real infrastructure.

You can’t bolt agents onto a broken foundation. You need:

1. Unified data — everything in one place, at the account and contact level

2. Real-time enrichment — so your systems work with current information, not stale snapshots

3. Orchestration logic — rules that determine what happens next and who does it

4. A command center — a single interface where reps can actually work

And you need people who can build this. GTM engineers. A new function for a new era.

Data has always mattered. But in the age of agents, it’s the difference between automation that helps and automation that hurts. The teams that invest in this infrastructure now will compound their advantage. The teams that don’t will wonder why their AI tools aren’t working.

The foundation is the unlock.

Q&A Highlight

One audience question stood out:

“If the context for effective agents is scattered across dozens of tools—Slack, project management, CRMs, Google Drive, Notion, Gong—who builds and maintains the integrations and ingestion pipelines? Is this internal? A mix of vendors?”

Nico’s answer: two approaches.

Option 1: Point solutions (“buy”). Tools like Octave that connect to Gong and other context sources, then expose that context via API or MCP. Self-reinforcing—every new transcript adds potential new ICP signals.

Option 2: Build a knowledge graph in-house (“build”). Store all your context, build a knowledge graph, and have your agents tap into it.

Who owns it? Usually someone on the GTM systems team or a GTM engineer.

Watch the full session on YouTube (~20 minutes):

I’m incredibly grateful for Nico sharing his hard-earned knowledge on building modern GTM systems so openly with us.

Follow Nico Druelle on LinkedIn.

→ Nico runs The Revenue Architects, helping companies like Linear, Descript, Canva, Kong, Scriptwork, Resolve AI, and Attention build modern GTM Systems designed for AI.

If you’re looking for help building your data stack, orchestration layer, or GTM engineering function, shoot him a DM on LinkedIn (especially if you’re a PLG company). He’s one of the best in the game.

ICYMI: Session #1 summary: Sorting the World into your CRM (GTM gold is stuck in your top seller’s brain: How to extract + operationalize it).

Session #3 summary coming next: Getting agents deployed into your GTM systems: pitfalls, opportunities, and best practices.

Thank you for your attention and trust,
Brendan 🫡

Subscribe now

Thanks to the companies who made the AI x GTM Summit possible! (+attendee stats)

Sorting the World into Your CRM

GTM Gold Is Stuck in Your Top Seller’s Brain: How to Extract and Operationalize It

Your best rep knows something the rest of the team doesn’t.

They can look at an account and feel whether it’s a fit. They can scan a LinkedIn profile and know if someone’s worth the call. They’ve spent years absorbing patterns, building intuition, and developing taste. And all of that knowledge lives in their head.

This tacit knowledge is the stuff you know but can’t easily explain. Ask a top performer why they chose to prioritize one account over another, and they’ll often struggle to articulate it. It’s years of pattern recognition compressed into instinct.

Tacit knowledge is incredibly valuable. But, it’s also fragile.

When they get promoted, it walks out the door with them. When they leave for a competitor, they take the playbook too.

This is the central problem of go-to-market right now. We’ve spent decades building systems to capture activity data. Calls logged. Emails sent. Opportunities created. But the actual intelligence that makes top performers perform? That’s never been systematized.

Until now.

At the AI x GTM Summit, Matthew Silberman (founder of Terra Firma) and Andreas Wernicke (founder of Snowball Consult) laid out a practical roadmap for extracting the tacit knowledge trapped in your best sellers’ brains and how to turn it into scalable, repeatable GTM infrastructure.

Here’s what they covered:

• AI: The age of intuition

• Now you ICP it, now you don’t

• Solve all your problems (in just four easy steps!)

• Step 5/∞: ABC, Always be…calibrating

• Unstructured world → Structured

• AI agent misconceptions

• AI agent building in 2026

• A real example: qualifying LinkedIn engagers

• 22-minute video of the full session (Youtube)

Follow Matthew and Andreas on LinkedIn!

Alright, let’s get into it.

AI: The Age of Intuition

Matthew started by naming what everyone’s thinking: no one wants to contribute to the AI slop machine.

It’s already bad enough. And some predictions for 2026 suggest email and other channels are going to be totally destroyed by low-quality AI-generated content. We might all cross a threshold as humanity and start to believe that any online interaction is AI-mediated in some way.

But the most valuable resource will remain human. Taste, human touch, creativity, intuition. You know it when you see it. And your team probably already has it.

The formula Matthew laid out: humans invest, learn, and intuit. AI structures and scales.

Now You ICP It, Now You Don’t

Most companies define their ICP once. Maybe twice. They use the same tired firmographics: industry, headcount, revenue range. And then they wonder why their outbound isn’t converting.

Or worse, when you ask them who their ICP is, they say: “We sell to whoever buys.”

But your top sellers don’t think in firmographics. They think in patterns. When Matthew interviews GTM teams, he digs past the surface-level definitions. He asks about specific closed-won deals. Play by play. What happened in that first discovery call? Why did the prospect take the meeting? What had they experienced the week before that made the timing perfect?

These are the details that actually matter. And they’re almost never captured in your CRM.

Your market changes fast. But most GTM teams don’t change their ICP definitions at that same pace. That’s the gap.

Solve All Your Problems (In Just Four Easy Steps!)

Matthew’s framework is deceptively simple. Four steps. But don’t let that fool you. The real work is in the depth, not the complexity. “Simple, but not easy.”

Step 1: Grab your podcast mic.

This is where Matthew’s journalism background shows up. He treats internal interviews like investigative reporting. Deep conversations with GTM leaders, product teams, and founders. Analyzing closed-won deals with the rigor of a post-mortem. Recording everything.

The goal isn’t to ask “Who is our ICP?” The goal is to ask “Why did this specific deal close?” and then keep asking follow-up questions until you hit something real.

Step 2: Structure your intuitions.

Raw meeting notes are useless if they sit in a folder. Matthew uses a set of AI prompts (built inside Notion) to transform interview transcripts into structured ICP definitions. These aren’t your typical “Series B SaaS companies with 50-200 employees” descriptions. They go much deeper.

The output is something you’ll actually want to revisit. Something you can refine over time as you learn more.

Step 3: Discover your first-principles data points.

This is where it clicks. Once you have structured ICP definitions, you run another prompt to extract the niche data points behind those definitions.

Think about it this way: if you met a perfect-fit account in the wild, how would you know? What signals would tell you they’re qualified? These are the data points you need to enrich. And they’re almost never the standard fields you’d find in a data provider.

Step 4: Put it all together for outbound experiments.

The final prompt takes your personas and data points and generates a list of plays to run. Specific combinations of who to target, what signals to use, and how to craft the message.

Then you test. You see what books meetings. Or don’t. And you feed those outcomes back into the system.

Step 5/∞: ABC, Always Be…Calibrating

Matthew made a point that stuck with me: this is why it’s called GTM engineering.

It’s not a one-time project. It’s not a linear process where you complete step four and you’re done. It’s circular. Iterative. Ongoing.

You build intuitions. You refine your ICP definitions. You experiment with enrichments to learn what actually matters. You run plays and review results. Then you go back to the beginning and harvest more intuitions based on what you learned.

GTM is a living, breathing thing. Always evolving. Just like a product does. Or your CRM. It’s never “done.”

The diagram in Matthew’s slides shows this as a continuous loop. Four quadrants, always spinning:

1. Build and harvest intuitions

2. Refine definitions and scoring rules

3. Experiment with enrichments and signals

4. Run plays and review results

If you’re treating ICP work as a quarterly exercise, you’re doing it wrong.

Unstructured World → Structured

After Matthew laid out the strategy, Andreas took the baton to walk through the execution.

His opening slide summarized the talk: “How to Sort the Messy World.”

Because that’s what AI agents actually do. They take unstructured information from websites, LinkedIn profiles, job postings, and public data, and they turn it into structured fields in your CRM. The messy world, sorted.

Andreas showed a simple example: a home services website with icons for heating, cooling, plumbing, and electrical. Unstructured. Messy. But when you run it through an agent, you get a HubSpot record with clean picklist values: HVAC, Plumbing, Electrical, Other. Plus a company score, a market focus classification, existing solutions detected, Google review count, hiring signals, and lead sources.

Here are the (not so simple) steps to make this happen with an agent:

That transformation is the whole game. Take what you see on a website and turn it into fields you can filter, sort, and act on.

AI Agent Misconceptions

Before diving into the how, Andreas addressed three misconceptions he sees constantly.

That cost number is worth pausing on. Andreas showed a screenshot: Total Cost to AI Provider: $0.00087. Fractions of a penny per classification. When agents are built well, you can enrich your entire TAM for a couple of hundred dollars. Often, this means using your company’s LLM API instead of Clay credits (or otherwise).

The cost only runs wild when you build fast without thinking about optimization.

AI Agent Building 2026

Andreas shared a comparison that captured the shift happening right now.

The old process (2024):

Website → Agent Building → Agent Outputs → Data Transformation → Integration → CRM

The new process (2026):

Context → Context → More Context → Agent → Output

Context is everything. And by context, Andreas means:

• Company context: What does the client care about?

• Agent context: How should the prompt be structured?

• Foundational documents: Deep definitions of concepts that matter to the business

Andreas doesn’t write prompts from scratch anymore. He builds foundational documents first. Deep definitions of the concepts he’s trying to classify. Then he uses those documents as context when building agents in Claude Code, asking it to generate structured prompts following his framework.

The result: agents that classify with high confidence, explain their reasoning, and cost fractions of a penny per company.

A Real Example: Qualifying LinkedIn Engagers

Andreas walked through a real workflow he built.

The scenario: Brendan (hey, that’s me! 👋) posts something on LinkedIn. 50 people engage.

The lazy approach (don’t do this):

DM all of them with AI-generated fake personalization. “Hey, noticed you liked Brendan’s post. I really love your thinking about remote work in the Caribbean. By the way, want to buy GTM engineering services?”

This contributes to the AI slop machine. It doesn’t work.

The better approach (precision targeting):

Run them through qualification gates:

1. Pull LinkedIn profiles

2. Check: Are they in a leadership role? (Andreas works best with CROs)

3. Look up the company

4. Check: Is the company the right size?

5. Check: Is it a lead gen company? (If yes, filter out. They’re probably competitors.)

6. Check: Does the company have 5+ sales roles?

7. Only then: Identify pain points, analyze LinkedIn posts, determine GTM topics they care about

8. Only then: Take action

That fifth gate is where the foundational document approach pays off. Instead of asking an LLM “Is this a lead gen agency?” (vague, inconsistent), Andreas built a comprehensive document defining what constitutes a modern lead generation company. That document becomes context for the classifier. The result: high confidence classifications that explain their reasoning.

Result: 50 engagers → 4-5 genuinely qualified prospects worth real outreach.

The Clay workflow Andreas showed had columns for each of these gates. Most rows showed “Run condition not met” because most engagers didn’t pass the filters. That’s the point. You’re not trying to reach out to everyone. You’re trying to reach out to the right people–and only the right people–with something relevant to say.

The Data Quality Process

Andreas closed with a framework for ensuring quality at scale.

It’s a loop. (Everything in GTM engineering is a loop.)

This is why these engagements aren’t 3-week projects. Building systems that work in production take iteration. It takes partnership between the builder and the GTM team. It takes patience.

But once you have it, you have something powerful. A system that can sort the messy world into your CRM. A system that captures the intuition of your best sellers and makes it available to everyone. A system that (finally) gets better over time.

The Bottom Line

My takeaway from Matthew and Andreas:

The scarcest resource in go-to-market right now isn’t data. It’s taste. Human touch. Intuition. The stuff that makes your best rep, your best rep.

AI can’t create that intuition. But it can help you extract it, structure it, and scale it.

The process:

1. Interview deeply

2. Structure the intuitions into ICP definitions

3. Translate those definitions into enrichable data points

4. Run plays and learn what works

5. Feed learnings back into the system

6. Repeat… forever

Build with intention (take foundations seriously). Build for relevance (bespoke to your market). Build with great context (what does good look like). That’s how you get outsized results.

PS

I shared this draft with Andreas to get his feedback, and we ended up having a long conversation about how much has changed in the 45 days since this session happened (from Dec 15th to Jan 30th). If you’ve been keeping up, you’ve felt this too. Claude Code, in particular, has really had a moment.

The big shift that Andreas believes (and I agree) is that building AI agents is quickly becoming commoditized (thanks to Claude Code, Claygents, and many other tools like Rox).

Which leaves the more strategic and valuable question: what should you build?

When you can build anything (not if, but when), having the human discernment to decide what to focus on at a particular GTM org is going to be the most important task in 2026. Taste.

The space is moving faster and faster. I’m excited to watch it unfold, and the wave together.

Watch the entire (22-minute) session on YouTube:

I’m grateful for Matthew and Andreas sharing so freely! It gives me energy to navigate this exciting new GTM playbook with legends like them.

Follow Matthew Silberman and Andreas Wernicke on LinkedIn.

→ Matthew runs Terra Firma, building GTM engines for seed to Series B startups backed by YC, Felicis, CRV, and Greycroft. Co-Lead Clay Club New York. And Technical Advisor at TCP.

→ Andreas runs Snowball Consult, shipping custom GTM systems for companies like Hatch, Exporty, Blueprint, and Workspan. And he’s also the Clay Club New York Lead.

They’re the real deal. So, if you’re looking for advising or consulting, I can’t recommend them enough. Please reach out to them to see if they have the capacity to work with your team.

Session #2 recap coming next: Infrastructure for agentic GTM: data stack, orchestration, and activation (PLG-focus).

Thank you for your attention and trust,
Brendan 🫡

Subscribe now

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

I’m excited to have Attention as one of our partners for The Signal this quarter.

Last April, I wrote a deep dive on Attention: The Army of AI Agents That Turn Your Sales Conversations into Action. Since then, they’ve continued to grow and innovate.

→ Attention is building AI agents for RevOps.

Attention captures all of your sales touchpoints (call recordings, emails, meetings, CRM activity) and turns them into a data layer for RevOps to build on. Their AI agents read what’s happening and take actions for sellers: CRM updates, follow-ups, coaching scorecards, whatever you need.

The product is horizontal, so there’s no single “use case.” Instead, think of it as a tool to build things you want, using all your sales activities (now structured and actionable).

Learn how their AI agents can help your sales org this year, at Attention.com. Let them know The Signal sent you!

Hey, y’all!

We’re only a few weeks into the year, and I already feel behind on everything that’s happening in tech/ai/gtm. The fomo is real. Agents are working on our behalf, yet I’m sipping a cold brew manually as I type. Maybe by the end of this year, that’ll get automated, too.

But jokes aside, in my 13 years in GTM, I’ve never seen this much change in the GTM playbook.

I re-skilled myself more in 2025 than in any year in the past decade.

AI has left the bag. And, like it or not, it ain’t going back in.

The Signal is a little corner of the internet for GTM nerds (founders and operators) to navigate this new world as we discover the new playbook—together. The plays, the roles/org chart design, and the infrastructure (tools) to run it. And there’s clearly appetite for this type of content. We grew 2.7x growth over 2025. I feel the pull of “product-market fit” every day. Thank you.

Hopefully, the graph continues on a similar trajectory in 2026. Let’s see!

Today, I’m sharing the five ideas that came up the most last year. These are the “stickiest” concepts that we explored in 2025.

Alright, let’s get into it.

Idea #1 → “Micro-Campaigns”

Outbound is getting harder every month. See: Outbound Email’s Rise in Volume is Unsustainable. One way to break through the noise is to be relevant and timely. Micro-campaigns are a great way to do this.

Here’s how I define “micro-campaigns”:

• Small, highly-targeted lists of, say, 50-250 contacts.

• These lists are generated using *very* specific filtering and/or signals (usually using AI/agents at least for certain parts).

• Each list (aka “micro-campaign”) is relevant this week, but won’t be next month.

The old way of “list building” is evolving, thanks in large part to AI. You just, quite literally, couldn’t do this stuff before.

The most important component is around timing. If you don’t reach out ~right away, you’ll lose the (sales) opportunity.

Another related concept is signal-based selling (even the CPO of HubSpot is talking about it as the future of GTM).

More context (including examples) here: “Micro-Campaigns”.

Idea #2 → GTM Tech’s Race for Power *and* Ease of Use

This topic is important for anyone planning their team and stack for 2026.

Even if you’re building evergreen plays in Clay (“fully automated”), the power and flexibility comes at a cost—namely, ease of use (or, lack thereof). I’m not saying anything the product team at Clay doesn’t already know. And they’re improving the product (and education) fast. But for now, you need someone who has spent, I think, 50-100 hours in Clay, to really master it (maybe even a dedicated GTM Engineer).

I don’t think you have to have a GTM Engineer or Clay expert to use Clay. But, to get the most value out of it (and use it to its fullest capabilities, which is… a lot), you do need someone who knows their way around a Clay table/workflow.

At the other end of the spectrum are the incumbent data providers (and sales engagement platforms) that are the least flexible (and thus, arguably, the least powerful), but the easiest to use. These can, and should, be used by non-technical users like SDRs, AEs, SDR Managers, etc. Along with RevOps folks.

Then, in the middle is a new, emerging category of players (signal-based selling platforms)—companies like Common Room, Pocus, Sumble, Unify, UserGems, Warmly, etc. These sit somewhere in the middle on the spectrum.

The race? Who can get to the upper-right-hand of the 2x2 matrix first.

If you’re re-evaluating your GTM stack, I hope this gives you a helpful framework for deciding which product (or category) is best for your team.

(Also, check out a site I’ve been slowly working on, here: ProspectingStack.com)

More here: GTM Tech’s Race for Power *and* Ease of Use.

Idea #3 → 6 Ways to Modernize Your GTM Motion (lessons from working with 14 Seed-Series C companies)

Here are the 6 things I now suggest in every engagement, based on what we learned from 14 deployments (please steal/tweak/implement them yourself):

1. AI-enabled Company Tiering (“Custom ICP”)

2. AI-enabled Contact Sourcing + Categorization (aka Key Buyer Personas)

3. Signal-based sales plays (evergreen)

4. AI-generated (drafts of) emails

5. Reporting/Attribution

6. Data orchestration (architecting a system of intelligence)

If you want more context about any of these, read the full article here: 6 Ways to Modernize Your GTM Motion in 2026

Idea #4 → Should You Buy an AI SDR?

Another 2x2 matrix. The general premise of this visualization could also be used to answer the question of: “Should we automate this outreach or do manual outreach?”

The answer is not one or the other—it’s nuanced. But, it should be calculated and considered carefully.

Then, with confidence, execute against the plan and iterate as you get more data.

More on the concept here: Should You Buy an AI SDR?

Idea #5 → The Rise of the GTM Engineer

The term “GTM Engineer” is a cocktail of wide-ranging ingredients: exuberance, anger, and confusion.

I have learned to lean into areas that are this polarizing. Especially when I feel strongly about the topic. Spoiler: I think the role of “GTM Engineer” is real, and here to stay. Semantics aside, I believe most GTM orgs will adopt the role in the next few years and the early adopters will gain a competitive advantage.

But even the true believers have unanswered questions. What does the role exactly entail? And what does it not include? How is it different than RevOps? Or Growth? Is it just someone who uses Clay and AI to do outbound? How should a GTM eng be compensated? Do they need to know how to code? Can I outsource this role? And much more.

I have tried to distill what I’ve learned about this emerging role in a few posts. And I plan to interview the best GTM teams in the world this year, to help share how they think about this new role (or lack thereof). So, more to come on this topic.

In the meantime, here are three posts about GTM Engineers, for anyone exploring it:

• The Rise of the GTM Engineer (published Nov 2024)

• How to Become a GTM Engineer (8 Resources)

• When Should You Hire a GTM Engineer?

🛠️ GTM Engineer School

If you, or someone you know, is looking to become (or up-level) as a GTM Engineer, check out GTM Engineer School—I know them well, and they’re some of the best in the business. Cohort 3 starts on Feb 16th (to Apr 17th). Agenda and details here: GTM Engineer School.

And they’re giving The Signal readers 15% off with this code (while supplies last).

Still hungry for more?

Full archive here (70+ issues).

And, here are more highlights 👇

🤖 AI GTM

• How to Scale GTM with AI & Automation, Instead of Headcount

• My AI Journey: Not One Lightbulb Moment, but 100 Sparks that Gave Me Deep Conviction (& why you’re not behind on AI)

• Why Building AI-Native is the Biggest Opportunity of this Decade

• I was Bored with SaaS. Until I Fell Down the AI Rabbit Hole.

• The Widening Gap Between AI-Natives vs. AI-Nots

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

• Should You Buy an AI SDR?

🛠️ GTM Engineering

• The Rise of the GTM Engineer

• How to Become a GTM Engineer (8 Resources)

• When Should You Hire a GTM Engineer?

🎯 Prospecting

• The best automated GTM plays you’re not running | Automation doesn’t have to mean spray-and-pray [Growth Unhinged x The Signal]

• 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)

• “Micro-Campaigns”

🧰 GTM Tech

• The “System of Intelligence”

• Consolidation szn (The race is on...) | 6 sales tech unicorns chasing after the elusive “one-stop-shop”

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

• Sequences 2.0 (AI-First)

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

• ProspectingStack.com (✨ new)

The Signal has been the place where I document what I’m learning—in public. And share what I’m seeing the best teams do (learning from the good, the bad, and everything in between) and how to navigate the quickly evolving GTM landscape.

I’m excited to continue exploring the future GTM playbook with each of you this year. Thank you for your attention and trust. I do not take it for granted.

PS: I’ll be sharing a summary+recording of each of the six sessions from the AI x GTM Summit. (Here is data on companies/roles that attended the summit, for anyone interested). Be sure you’re subscribed to receive those in your inbox.

See you next time,
Brendan 🫡

Subscribe now

Happy holidays, y’all!

Thanks again for supporting the AI x GTM Summit last week. Still blown away by the turnout. You can see the stats from the event here: summit.thesignal.club.
(I vibe-coded this in Claude, so blame any bugs on AI)

I’m excited to continue to lean into content going into 2026. And I’ll be sharing some exciting updates on this front in January. :)

But, for today’s post, I wanted to reflect on the year of consulting I did and share some of the lessons from it. We’re all figuring out this new playbook together. I haven’t had this much fun in SaaS GTM in years (seriously).

If you haven’t started to take AI seriously, it’s not too late. Come on in, the water is warm, and the rabbit hole runs deep. 🐇 🕳️

Here’s a quote from a piece I wrote in June: My AI Journey: Not One Lightbulb Moment, but 100 Sparks that Gave Me Deep Conviction (& why you’re not behind on AI)

9 out of 10 experiments I’ve tried with AI failed (probably more tbqh).

I worked with 14 Seed-Series C companies in 2025 to help modernize their GTM strategy. And today, I wanted to share the 6 things I now suggest in every engagement, based on what we've learned.

Please steal/tweak/implement them in 2026.

Alright, let’s get into it.

1/ AI-enabled Company Tiering (Custom ICP)

This isn’t 2019.

Stop using the same, basic attributes that everyone is using from their b2b database, like: location, industry, employee count, revenue.

Instead, use “rich” data points. AI can find those for you.

Examples of data points used for High/Medium/Low Fit (or A/B/C/F or 1/2/3/4 tiers):

• Updated privacy policy page in the last 30 days (custom scraper/AI workflow)

• $500M in online revenue and have lots of products being sold online (custom prompt)

• Using snowflake, bigquery, databricks, or redshift (scraped from job descriptions via Sumble) and have 5+ data engineers

• PLG SaaS company that has a price point below $100/month, and at least 1 Researcher at the company (custom scraper/AI workflow)

Then, layer in the basic data points. Things like location, industry, employee count, etc. still matter.

And finally, create a tiering system. AI is your best friend here.

This can (and often, should) be 100% automated in the background. So that once you set it up, any new company added to your CRM gets enriched and tiered, and updated in the right field(s) in your CRM.

2/ AI-enabled Contact Sourcing + Categorization (Buyer Personas)

Build a list (with the help of AI) of titles that you want to get in front of. Each title should translate to a “Persona”. This is different than titles.

For example, for Cursor, you may have the following Personas (and want to run different messaging/automations for each) -

• Engineering Leaders

• Engineering ICs

• Product

• Founders

• Business users

Build an AI workflow so that every person at a company is found, with their title, and tagged with a ‘Persona’ that is written back to your downstream systems (eg: CRM and data warehouse). You’ll use this persona for messaging (eg: ai prompts) and to determine the level of automation for certain plays. Also you can/should use these persona buckets for ABM, reporting, and attribution.

3/ Signal-based sales plays (evergreen)

Come up with a stack-ranked list of signals that show buyer intent, for your product.

These are the companies/people who are most likely to say “yes” to a sales conversation if you reach out to them today.

Many of these signals/plays are the same as everyone else (website visitors, champion tracking, new hires, social/public listening, first-party data). And getting easier to build these with modern tools like Clay, Common Room, Pocus, Sumble, Unify, Warmly, etc. (and incumbents like Zoominfo and Apollo).

But the alpha is in the stuff that 99% of other companies aren’t doing (because it’s not relevant to them). When I’m consulting, I cannot come up with these ideas, because I don’t know the business well enough. I’ve noticed the best ideas usually come directly from the founder, or the head of sales, or the top rep. This is my “turing test” for a truly novel outbound experiment.

More on signal-based plays:

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

• The best automated GTM plays you’re not running

• “Micro-Campaigns”

• How to automate signal-based selling (+ 3 plays you can start using today)

4/ AI-generated drafts of emails

You have to customize the prompt to match your style (give it examples). And I recommend trying to get each unique message to generate ‘snippets’ within a message.

Think of these as modular blocks used within a template. Things like:

- Signal-based hook (relevance/timing)

- Persona-based pain + value prop

- Segment-based social proofing.

- Call to action (“offer”) that is not asking for time (give value instead).

Six months ago, I would have said AI is not good enough to write emails. Today, it’s ~basically there. Try it.

But just know: the output will only be as good as the prompt and examples you feed it (garbage in, garbage out).

Tools like Lavender.ai and Octave are great for a more fine-tuned version. Instantly, Apollo, etc. also have baked-in AI copy features baked in now. These are getting better each month.

Claude is my current go-to writing companion.

5/ Reporting/Attribution

Honestly, a nightmare with the current tool stack.

This requires a lot of manual, tedious work to make this happen. For now, try to make it work with your existing dashboards. It’ll be annoying, and won’t work great. But, hopefully MCPs solve this over time.

But it’s the necessary evil. The “ops challenges” are messy right now, but will be solved in-product over time (by the tools). Until then, you need someone who has deep revops chops to be able to truly systemetize this stuff.

This is the area I’m most excited about in 2026. Tangentially, evals, q/a (testing), and feedback loops are the other areas that are very early, but I expect to improve a lot in 2026.

6/ Data orchestration (system of intelligence)

I still believe the most important problem to solve in GTM is choosing the right company and person at the right now (message matters less if you nail timing/pain-point).

I did a dedicated post on this at the end of 2024: The “System of Intelligence”
(I should probably should revisit at some point; @grok remind me to do this in the new year).

Clay, Actively, and others are trying to become this layer. And other tools too, to a lesser degree (eg: Common Room, Pocus, Unify, etc.).

But you have to have a foundational data strategy if you’re going to build an AI-native GTM system. Otherwise, you’re just running the same 2019 Predictable Revenue Playbook with AI sprinkled on top, which won’t help move the needle.

That’s it!

Those are the 6 areas I’ve seen the most positive outcomes from this year when modernizing your GTM motion for the AI-era.

My favorite pieces of content I consumed this week:

• Executives need to roll up their sleeves and ship an agent themselves, or they’ll become obsolete in the age of AI GTM. If you do, you’ll be ahead of 98% of your colleagues (30-second clip by Jasn Lemkin on Kyle Norton’s podcast)

• TikTok US, AI GTM Summit, Salesforce Acquisitions, Zoominfo Lawsuit (Thanks to Pranav and Austin for having me on GTMN!)

• 2025 LLM Year in Review by Karpathy

• 2026 Predictions by Jason Lemkin, Harry Stebbings, and Rory O’Driscoll

• Adam Robinson’s 24 Predictions for 2026

• I’m still long (AI-enabled) SaaS

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

Happy holidays!

See you next time,
Brendan 🫡