The lean GTM stacks shared this week leave out the same layer: the record. Build, signals and delivery shrink into Claude Code, a few APIs and a sending tool. The layer every agent reads from and writes back to disappears with them.

The clearest example is Maja Voje's lean stack animation for the 2026 State of B2B GTM Report. It opens on a 2025 "bloated stack" of 15 tools, led by Zoho CRM. The Q4 2026 stack that replaces it has 5 layers: build and reasoning, signals, decisions, orchestration and delivery. Nothing in it is named as the record, and nothing replaced the CRM.

The operators on the GTM Vault record agree on half of this. Seats in build, enrichment and sending are collapsing into Claude Code, a few APIs and a sending tool. The record layer does not collapse. It is the one place every agent reads from and writes back to, and a stack without one is not lean. It is unanchored.

This is not an argument against fewer tools. It is an argument about which tools are allowed to disappear.

The Stack on the Table

The post rests on the 2026 State of B2B GTM Report by Kyle Poyar and Maja Voje: 300 B2B software and AI companies, surveyed in September 2026. Claude is the #1 most impactful GTM tool, up from #4, named by 110 respondents, more than 3 times the next vendor. The post's other figures, 71% on Claude Code, 80% building custom skills and 72% on MCPs, do not appear in the public write-ups of the report.

The stack itself:

1. Build and reasoning: Claude Code and Codex for research, messaging, builds and automation

2. Signals: Grok Bot for social intent, Common Room for intent, Granola for call insights

3. Decisions: Jev for scoring, triage and routing

4. Orchestration: Clay for lists, enrichment and messaging

5. Full-funnel delivery: Ploy for the website, LinkedIn, Instantly for outbound, Google Ads and LinkedIn Ads for paid

The seat rule is the strongest idea in the post. A tool keeps a seat if it owns data, plugs in through MCP, CLI or API, or brings intelligence the model does not have. Everything else becomes a skill or a team of agents.

Run the stack through its own rule and the gap shows. The first criterion is "owns data." No tool in the 5 layers is named as the owner of the customer record. There is no CRM, no context layer and no place where outcomes are written back. The rule keeps a seat for the system of record. The stack does not have one.

The GTM Vault record disagrees with the graphic. The Stack Index holds 23 operator stacks from the GTM Vault Podcast and Show Me Your Stack. 5 of those operators name a CRM as their system of record: Salesforce for 3, HubSpot for 2. Across all 23 stacks the index records 1 displacement, Clay losing the campaign build step to CLI orchestration (SMYS 6). No operator on the record has replaced their system of record. The report points the same way from the outside: the respondents who put Claude at #1 put HubSpot at #3 and Salesforce at #5.

Where the Record Agrees

The collapse is real, and it is concentrated in the layers that produce work. 7 operators on the record run Claude Code, and each one uses it to replace a workflow, not to sit beside one.

Tim Scheuer at Oxygen took campaign builds from 3 to 5 hours in Clay to 40 minutes in a terminal, shipping split tests across 220 inboxes by prompting an agent (SMYS 6). Clay was displaced by CLI orchestration in that stack. Jai Toor at DeepLine compressed a month of propensity work and nearly $2,000 of enrichment spend into 30 minutes and under $10 (SMYS 4). Garrett Wolfe at 1GTM replaced the CRM, Sales Navigator and Apollo shuffle with a single custom app built in Claude Code (SMYS 3).

The outside data agrees. In Poyar and Voje's April Claude Code for GTM pulse (200 operators), 55% said Claude had replaced a tool or vendor, and the first spend to go was services, then simple automation and enrichment.

The delivery layer is already lean. 4 operators in the Stack Index send through Instantly, and Charles Cormier runs it at $80 a month inside a stack he puts at about $200 a month (GTM 19).

Alex Bilmes at Endgame states the build rule directly: almost everything that was a SaaS purchase is now buildable on Claude, an MCP server and a forward-deployed engineer (GTM 46). That is the lean stack thesis, said 5 months earlier, from the vendor side.

One point of tension. The lean stack keeps Clay as its orchestration layer. The record shows Clay being displaced at the campaign build step and kept as a data layer. Vinayak Mishra at Slang AI runs Clay as 3 tables that function as the system of record (SMYS 1). Clay survives in lean stacks because it owns data, not because it orchestrates.

The Missing Layer Is the Record

Agents multiply writes. Every signal bot, scoring agent and outbound sequence produces a judgment about an account. Without one record to land on, those judgments fragment across tools, and each agent acts on the fragment it can see.

Gorish Aggarwal at Sybill gives the test. Count how many name variants each buyer has across the CRM, email, LinkedIn and Slack, then check whether any system collapses them into one record. Every unresolved variant is a place where an agent acts on partial information and reports it as complete (GTM 48).

Michael Bartimer at Clarify runs a long list of agents, most of them enabled, with almost none of the usual sprawl. The reason is placement: his Instantly outbound writes outcomes back to the CRM by persona, so every agent reads from the same record (SMYS 9). The agents are cheap because the record is not.

Angelo Quiambao at Intellistack runs his agents against Salesforce. Each run logs which sequence a contact is in and how many days since the last touch, and writes back to the CRM as it progresses. Deduplication is a gate enforced before work happens twice, not a cleanup job at the end (SMYS 7).

Even the tools in the lean stack assume a record exists. xAI's own Grok Bot for GTM guide lists Salesforce among its connections and has the bot write forecast notes back into it. The signal layer in the post depends on the layer the post leaves out.

The seat and the record are different things. Yoni Tserruya at Lusha describes a Salesforce instance the AEs have largely stopped opening. It still runs, feeding a custom dashboard (GTM 50). The interface lost its seat. The record kept its job.

A record that agents depend on also has to be maintained. Jelle van Geuns spent over a decade inside hundreds of Salesforce orgs and found accumulation, not breakage. Revenue AI money chases the agent that sells. Almost none of it funds keeping the system those agents read from in working order (GTM 54).

The people who build these systems for a living put the record first. Nil Rasmussen's 90-day plan for a new GTM engineer schedules nightly CRM cleanup in month 1, on the logic that every later workflow reads from those records.

The build rule from GTM 46 carries its own exception. What stays bought is infrastructure plus domain expertise compounded over years: databases and context graphs. Endgame's premise is to pull CRM, Gong, email, Slack, methodology and pricing into one place and run agent loops upstream of it (GTM 46). Olivier Roth pushes the same question further: when relationship data becomes its own layer that travels to every tool, what is left of the single system of record (GTM 51)?

This is not a CRM argument. It is a write-back argument. The record can be Salesforce, HubSpot, Clay tables or a context graph. What it cannot be is absent. A lean stack with 5 action layers and no record layer will feel fast for a quarter, then every agent will be scoring an account the others have already disqualified.

MCP Is How You Build, Not How You Run

The seat rule treats "plugs in through MCP, CLI or API" as one criterion. The record splits it in two. Alexander Shartsis at Skyp builds in an MCP-heavy Claude Code setup, then drops the production pipeline to direct APIs when volume and cost matter. At scale, direct APIs are cheaper and more efficient (SMYS 2).

MCP is the development interface. The API is the production interface. The pulse report cites a ScaleKit study that puts MCP at 10 to 32 times the cost of CLI for the same work. A tool that only offers MCP is fine for exploration and expensive at volume. The 72% MCP adoption number in the post measures how teams build. It says nothing yet about what they run in production.

Tokens Are Still Seats

"Per-seat pricing is almost obsolete. Tokens are the new currency of GTM." The second half is right. The first half moves the line item without removing it.

Mark van Oppen at SecureAuth describes a company that said it had bought no AI tools. His answer: everyone is using an individual seat in Claude, Gemini or ChatGPT, sanctioned or not, and every one of those can spawn agents (GTM 47). A founder who says they use no SaaS is often running model subscriptions, an API bill and a sending tool. That is a stack. It is just billed differently.

The budget is shifting, and the post is right about where it comes from: services and replaced tools. Alex Bilmes says some Endgame customers now spend headcount budget on agents instead of people (GTM 46). The control question is no longer how many seats. It is who owns the token spend, and whether anyone can tie it to pipeline.

The Corrected Stack and the Seat Test

Keep the 5 layers. Add the sixth underneath them.

The seat rule needs one change: "owns data" becomes "owns or writes back to the record," and the integration test separates building from running.

1. Does it own the record, or write outcomes back to it? It keeps a seat.

2. Is it the production API an agent calls at volume? It keeps a metered seat. MCP-only access is a build tool, not a production one.

3. Does it bring data or infrastructure the model cannot produce: proprietary signal, sending reputation, ad inventory? It keeps a seat.

4. Everything else becomes a skill.

Run the lean stack through the corrected test and most of it passes. Clay passes on criterion 1 if it holds the tables. Instantly and the ad platforms pass on criterion 3. The test does not cut the stack. It adds the layer that makes the rest of it safe to run with agents.

Common Questions

What does a lean AI GTM stack look like in 2026?

It runs build and reasoning on Claude Code, pulls signals and enrichment through a few direct APIs, and keeps a sending tool and ad platforms for delivery. Under all of it sits one record layer that every agent reads from and writes outcomes back to. The action layers shrink. The record layer does not.

Can Claude Code replace Clay?

At the campaign build step, it already has for some operators. Tim Scheuer moved campaign builds from 3 to 5 hours in Clay to 40 minutes in a terminal (SMYS 6). Clay keeps its place where it holds the tables that act as the system of record.

Should a GTM stack use MCP or direct APIs?

Both, at different stages. MCP is the faster way to build and explore inside Claude Code. Direct APIs are cheaper and more efficient once a pipeline runs at volume, which is why production enrichment drops to them (SMYS 2).

Do AI-native teams still need a CRM?

They need a record, and for most teams that is still a CRM. Agents multiply the number of judgments made about each account. Without one place where those judgments land, each agent acts on a partial view and reports it as complete (GTM 48).

Which GTM tools should keep a paid seat?

A tool keeps a seat if it owns or writes back to the record, if it is the production API an agent calls at volume, or if it brings data or infrastructure the model cannot produce. Everything else is a candidate to become a skill.

Is per-seat pricing dead for GTM tools?

The seat is moving, not disappearing. Spend shifts from per-user licenses to model subscriptions, API usage and tokens. A team that says it buys no SaaS is often still paying for individual model seats that nobody tracks against pipeline (GTM 47).

Related Reading

1. Clay Won the Layer, Not the Interface: Clay kept the enrichment layer while its interface moved to Claude Code and the CLI, the same split this essay makes for the CRM

2. The Context Layer Is Becoming the Operating System of AI-Native GTM: why agents without a shared context layer start every session cold

3. A Tool List Cannot Tell You What to Build First: the Stack Index, which places every tool in this essay on the layer it serves

4. GTM 54 | Salesforce Orgs Do Not Break, They Accumulate: what happens to the record layer once agents read from it at scale

Sources

1. Maja Voje's post and its lean stack animation

2. Nil Rasmussen's 90-day GTM engineer plan, LinkedIn

3. What's working in B2B GTM in 2026, Growth Unhinged, Oct 2026

4. 2026 State of B2B GTM Report, GTM Strategist, and the report landing page

5. The 2026 Claude Code for GTM pulse report, Growth Unhinged, Apr 2026

6. Grok Bot for GTM, xAI

7. Jev on Vercel AI Gateway

8. Ploy launch on Y Combinator

9. The Stack Index, GTM Vault, 23 operator stacks, Oct 2026

10. Episodes: SMYS 1, SMYS 2, SMYS 3, SMYS 4, SMYS 6, SMYS 7, SMYS 9, GTM 19, GTM 46, GTM 47, GTM 48, GTM 50, GTM 51, GTM 54

The GTM Vault MCP is live, and every GTM Vault subscriber can add it to Claude with one URL. Claude can then run the eight-layer revenue system audit on your company and build your stack from The Stack Index, and Pro members can also search every podcast and Show Me Your Stack episode to the timestamp from inside Claude. Every answer names the operator who ran the thing, the episode where they said it, and a link to check it. It is read-only, it stores nothing you ask, and it is free for every subscriber, with Pro unlocking all of it. Thirty-four playbooks ship with it at launch, from the audit to a tool comparison to a forecast reset.

Add the GTM Vault MCP to Claude

One click opens Claude with the MCP ready to add. Sign in with the email you subscribe with. The full setup guide covers adding it by hand and Claude Code.

The audit, the operator lookups and the full Build Your Stack output are free with a subscription. Pro, $99 a month or $999 a year, adds Library search inside Claude, every playbook, and a live office hours session with me on the first Wednesday of every month.

Open the Library · Browse The Stack Index · Add the GTM Vault MCP

Advice With No Operator Behind It

Ask Claude which enrichment tool to run and it gives you a category. Four vendor names, a sentence about your needs and budget, a suggestion to run a trial. Every name is plausible. None of it has been run by anyone you can check.

This is not a model problem. It is a sourcing problem. A model answers from the average of what has been written about a tool, and most of what is written about GTM tools is written by the people selling them. The operator who ran a tool for a year, hit its ceiling and replaced it said so once, in a conversation. That conversation is not in the average.

GTM Vault is where those conversations are. More than twenty operators have put their stacks on the record across the podcast and Show Me Your Stack, and every tool they named sits in The Stack Index on the layer it serves: more than 100 tools, about two thirds of them verified by an operator who ran them in a working system. The evidence was never the gap. The gap was that the evidence lived on a website, and the decisions get made in a chat window.

Reasoning in Claude, Evidence From the Vault

The MCP draws one line and keeps everything on the correct side of it. Claude does what it is good at: reading your situation, holding your context, reasoning across it and writing the answer. GTM Vault does the one thing Claude cannot do on its own, which is supply evidence with a name, an episode code and a link attached.

Three sources sit behind the MCP. The Library holds every podcast and Show Me Your Stack episode as a write-up and a transcript, searchable to the moment a phrase was said, and it is free to read on the web with no sign-in. The Stack Index holds every tool operators named, placed on the eight layers of revenue architecture, with the operator evidence behind each placement. The revenue system audit holds the eight questions, one per layer, in build order.

Claude reaches those sources through four tools. Each one returns evidence. None of them generates advice.

Three Sessions, Start to Finish

The Audit

The audit is where most sessions should start, because it answers the question every stack decision depends on: which layer is breaking first. You describe your company in plain language. Claude answers the eight questions from what you told it, asks you for anything it cannot infer, and runs the scoring The Stack Index uses on the site.

The output is a layer, not a tool. When four layers are breaking, the lowest one goes first, because every layer reads everything beneath it. A pipeline number rebuilt on a loose ICP inherits the looseness. Fixing Functional Coherence before Identity produces a reconciled dashboard of the wrong accounts.

In Claude, the answer arrives with the operators who have rebuilt that layer on the record, and the build order for your company already filled in.

The Build

Build Your Stack takes four answers: revenue band, motion, binding constraint and budget posture. Revenue band and motion set the base order, the constraint reorders it, and budget decides which tools are admissible inside each layer. The output is a sequence: what to install in the first six weeks, what waits for the second quarter, and what to deliberately not buy yet.

The "not yet" column is the most valuable part of the answer and the part generic advice never gives. Buying signal data, context layers and content channels before the source, enrichment and action surface hold is the most common way a stack stops compounding. Claude returns the same build the site does, down to the link, because both run the same engine. If the two ever disagreed, one of them would be wrong.

The Operator Lookup

The lookup answers the question buyers ask each other in private: who else runs this, and what do they run next to it. Ask about a tool and Claude returns every operator on the record who named it, what it did in their system, the tools that show up in the same stacks, and any displacement an operator stated.

Clay is the clearest example. Seven operators run it. Elliot O'Connor moved enrichment to it at Frontier and displaced ZoomInfo. Tim Scheuer ran his campaign build on it at Oxygen and later replaced it with CLI orchestration. Both facts are on the record, both come back in the answer, and neither is a vendor claim.

The Playbooks

The three sessions above are the four tools used one at a time. Playbooks chain them. Each one is a sequence of calls to the evidence tools for a job you already have, and every step either retrieves operator evidence or reasons over what came back. Thirty-four ship today, in six groups:

1. Diagnose. The revenue system audit, the fix-first layer, why pipeline stalled, whether your motion still fits your stage, whether your lower layers can carry AI agents, whether you are ready for signal data, a forecast reset, and the gap between the accounts you win and the ones you lose.

2. Build. Your stack, what not to buy yet, the same stack at another budget, the stack for your next revenue band, the first play to run, your enrichment waterfall, your CRM choice, every play on the record your build can run, whether to move a workflow from Clay into Claude Code, and the context layer your team and agents read from.

3. Distribute. How to get cited by AI answer engines, which channel your stage can carry, and the outbound sending stack operators run at your stage and budget.

4. Before you buy. Due diligence on one tool, two tools head to head, whether anyone has replaced a tool, a shortlist for one layer, a vendor claim checked against the record, and a teardown of the stack you pay for now.

5. Research. One operator's stack, two operators compared, the exact moment something was said, and a cited brief on any topic.

6. Decide. Whether to fill a GTM role with an agent, a person or both, a one-page decision memo with every claim cited, and whether your system is ready for its first GTM or RevOps hire.

Ask for one by name, for example Using the GTM Vault MCP, run the compare-tools playbook on Clay and Apollo, or type / in Claude Code. The gtm-audit, build-my-stack and tool-check playbooks are free; every playbook comes with Pro, including new ones as they ship. The full list with descriptions is on the MCP page.

Why I Did Not Build a GTM Plan Generator

The obvious version of this product exposes tools called build_icp, create_90_day_plan and generate_playbook. I scoped that version and threw it out. Claude already writes ICPs and ninety-day plans. Wrapping that capability in a GTM Vault label adds a server call and nothing a founder could not get for free. An MCP that generates GTM plans is a prompt with a logo.

What Claude cannot produce is a citation. So the MCP returns evidence and nothing else, and three decisions follow from that. It is read-only: Claude can look things up in GTM Vault and cannot change anything. It runs the same code as the site: the audit, the build and the operator pages compute one answer, so Claude and pro.gtmvault.co can never disagree. And it stores nothing you ask: what you tell Claude about your company is used to answer the request and discarded. The only thing logged is which tool ran and when, to enforce the daily limit, 50 requests on the free tier and 300 on Pro.

The same rule governs the playbooks that ship with it. A playbook such as tool-check or decision-memo is a sequence of calls to the evidence tools, not a template Claude fills in. Every step either retrieves evidence or reasons over what came back, and when nothing is on the record it says so. The full list is on the GTM Vault MCP page.

Setting It Up

Setup takes one click. The button below opens Claude with the GTM Vault MCP ready to add. Select Connect, enter the email you subscribe with and the six-digit code I send, and the tools and playbooks appear in Claude.

Add the GTM Vault MCP to Claude

To add it by hand, open Claude and go to Customize, then Connectors. Select +, then Add custom connector, name it GTM Vault MCP and paste https://pro.gtmvault.co/mcp. That address is for Claude, not a web page, so paste it rather than opening it. Once connected, set the tool permissions to Always allow so Claude uses the tools without asking each time. Add it once on the web and it works in Claude on desktop and mobile. In Claude Code, run claude mcp add --transport http gtm-vault https://pro.gtmvault.co/mcp.

The full guide, with prompts to start from, is at gtmvault.co/p/mcp.

Free, With Pro for the Rest

Every GTM Vault subscriber can add the MCP for free: the revenue system audit, operator and tool lookups, the full Build Your Stack output with every tool matched to budget, and three playbooks. GTM Vault Pro, $99 a month or $999 a year, adds Library search from inside Claude across every episode, every playbook including new ones as they ship, the Doctrine, the GTM Strategy Course, and a 30-minute live office hours session with me on the first Wednesday of every month. Annual members also get a 45-minute Blueprint Session with me that starts from their sequence.

If you subscribe to GTM Vault, add it to Claude today and start with one prompt: "Using the GTM Vault MCP, run the revenue system audit on my company."

One more thing. The Library is now free for everyone: every podcast, Show Me Your Stack and Coffee Walk episode as a searchable playbook, with the stack and the full transcript, and no sign-in. Open the Library.

Upgrade to Annual Pro

Common Questions

What is the GTM Vault MCP?

It is an MCP server that gives Claude read access to GTM Vault's operator evidence: the Library of podcast and Show Me Your Stack episodes, The Stack Index of tools placed on the eight layers of revenue architecture, and the revenue system audit. Claude reasons about your company and uses the MCP to cite named operators, episodes and timestamps. It is free for every subscriber, and Pro unlocks all of it.

Is the GTM Vault MCP free?

Yes, for every GTM Vault subscriber: the revenue system audit, operator and tool lookups, the full Build Your Stack output, and three playbooks, up to 50 requests a day. GTM Vault Pro, $99 a month or $999 a year, adds Library search from inside Claude across every episode and transcript, every playbook, monthly office hours and 300 requests a day.

What are GTM Vault playbooks?

Playbooks are multi-step workflows over the GTM Vault MCP's evidence tools, such as gtm-audit, compare-tools, agent-readiness and decision-memo. Ask Claude to run one by name, or type / in Claude Code. Every step retrieves operator evidence or reasons over it, so every answer stays cited, and when nothing is on the record the playbook says so.

How do I add the GTM Vault MCP to Claude?

Use the one-click install, or in Claude go to Customize, then Connectors, select +, then Add custom connector, and paste https://pro.gtmvault.co/mcp. Sign in with the email you subscribe with and the six-digit code sent to it. In Claude Code, run claude mcp add --transport http gtm-vault https://pro.gtmvault.co/mcp. The step-by-step guide is at gtmvault.co/p/mcp.

Does GTM Vault see or store my company's data?

No. What you tell Claude about your company is sent to the MCP only to answer the request, and it is not stored. GTM Vault logs which tool ran and when, to enforce the daily limit: 50 requests on the free tier and 300 on Pro. The MCP is read-only and cannot change anything in GTM Vault or in your accounts.

Will Claude recommend tools that no operator has run?

Through the MCP, no. Claude is instructed to recommend only tools The Stack Index returns, each with the operators who run it and the episode where they said so. If you ask about a tool no operator has named on GTM Vault, the MCP finds no operator on the record for it, and that absence is part of the answer: nobody on the record has run it in a working system.

What is a GTM MCP?

An MCP (Model Context Protocol) server connects an AI assistant like Claude to outside tools, data or expertise. A GTM MCP connects Claude to go-to-market systems or knowledge. Most GTM MCPs connect a single tool, such as a CRM or an enrichment platform. The GTM Vault MCP connects Claude to operator evidence: which tools operators run on each layer of revenue architecture, what those tools did in their systems, and the episodes where they said it.

How is the GTM Vault MCP different from the Clay MCP or the Salesforce MCP?

Tool MCPs like the Clay MCP and the Salesforce MCP let Claude read and act on your data inside one product. The GTM Vault MCP tells Claude which tools to run, in what order, and what happened when operators ran them. The two work together: tool MCPs for your data, the GTM Vault MCP to decide what to build and why. Both the Clay MCP and the Salesforce MCP are on the record in The Stack Index, named by operators who run them.

Does the GTM Vault MCP work with ChatGPT or other AI assistants?

Not today. MCP is an open standard, but this version signs in Claude clients only: claude.ai on the web, the desktop and mobile apps, and Claude Code.

Related Reading

A Tool List Cannot Tell You What to Build First: the launch of The Stack Index, the evidence base the MCP reads from, and why sequence comes before tools.

The 8 Layers of a Modern Revenue System: the architecture the audit scores and the build orders against.

GTM 50 | The Next Buyer of Your Data Is Not a Person: why evidence now has to be readable by agents, not only by people.

GTM 48 | The Transcript Is the Commodity, the Context Is the Asset: why transcripts searchable to the timestamp are worth more than the episodes they came from.

Subscribe

Every dollar in revenue AI is chasing the agent that sells. Almost nobody is funding the one that keeps the system those agents run on from rotting, which is strange, because the org they all read from is the thing quietly decaying underneath them. Jelle van Geuns spent over a decade inside hundreds of Salesforce orgs before he built anything, and what he saw was not breakage. It was accumulation. The founder and CEO of Cirra AI joins GTM Vault for episode 54 to explain why the admin layer is a company rather than a feature, where the guardrails on an AI that can touch Setup actually sit, and why an independent survives the platform vendor and the frontier labs on grounding and history rather than on model capability.

About Cirra AI

Cirra AI builds an AI admin for enterprise software, starting with Salesforce: someone describes a change in plain language, and Cirra reads the org, proposes an implementation, builds the metadata in a sandbox, and documents what it did and why. It was founded in 2024 by Jelle van Geuns, a Dutch-born engineer and decade-plus veteran of the Salesforce ecosystem, and runs out of San Francisco. It ships what it calls the first commercial Model Context Protocol server built for Salesforce administration, so an admin can change an org from Claude or another agent rather than logging into Setup. Cirra has raised no outside capital; before it, Jelle bootstrapped Decisions on Demand, a lead-routing AppExchange app, to seven-figure ARR without external funding.

Watch or listen now across YouTube, Apple Podcasts, and Spotify

Share

Episode highlights

(0:00) The Agent Nobody Is Funding
(3:30) Orgs Do Not Break, They Accumulate
(5:01) The Backlog At A 200 Person Company
(7:02) The Seven Figure ARR Correction And No Outside Capital
(8:22) One Change Request From Slack To Production
(10:27) Four Guardrails On An AI That Touches Setup
(14:57) Why Agentforce Does Not Absorb This
(16:42) What Stays Yours When The Models Improve
(22:19) The Day The Platform Turns Hostile
(25:47) The Autonomous AI Admin And What Early Autonomy Got Wrong

What you’ll learn:

• Why orgs do not break but accumulate, and why only about 2% of surveyed Salesforce orgs are described as clean and well maintained

• The norm at a 200-person company: one part-time admin, often the VP of sales, and 40 to 60 open requests that never shorten

• What the backlog costs where no line item shows it: a spreadsheet on the side, a shadow Asana instance, and reports that stop matching reality

• One change request end to end, from a Slack sentence to a confirmation gate, an admin approval, a sandbox build, and the customer’s own DevOps pipeline

• Four guardrails on an AI that touches Setup: the OAuth permission ceiling, role-based access, read before write, and the promotion flow

• Why Agentforce does not absorb the admin layer, and the tell: Salesforce’s own MCP servers read metadata but will not change it

• The headless bet, which is configuring Salesforce from the agent you already use rather than logging into the platform to do it

• What stays durable when the models improve: org-specific grounding, the accumulated record of why a change was made, and the approval trail

• The answer to “why not wait for Salesforce”, which is 2 or 3 releases, 9 months to a year, and a year and a half before it hardens

• The 18-month test: first-level admin traffic goes to the AI, and nothing gets reworked after it is approved

Key takeaways

1. Orgs do not break. They accumulate, because nobody is accountable for removal.

Every quarter somebody adds a field, a validation rule, a flow, or a permission change, and each one has a rationale at the time. Nothing comes back out, because removing it might break something and the reason it exists has been forgotten. After 5 years you have 3 fields that do the same thing and nobody knows which one is live, plus a flow nobody dares open. A Salesforce Ben survey Jelle cites puts orgs described as clean and well maintained at about 2%.

2. The backlog is not an admin staffing problem. It is a system of record problem.

The norm Jelle describes is 200 people with one part-time admin who grew into the role without choosing it, often revenue operations or the VP of sales, and a queue of 40, 60 or more open requests that never shortens because new ones arrive daily. Sales does not wait. They build a spreadsheet on the side, or stand up an Asana instance and run deal management there. The reports stop reflecting reality, because reality moved out of the CRM.

3. The guardrail is not the model. It is the permission ceiling and the read-before-write rule.

Cirra runs as a connected user through OAuth and can never do anything that user could not do by hand in Setup, so the blast radius is bounded before any model reasoning happens. Role-based access sits on top of that, fine-grained by individual, by role, even by object and field, so a team can start read-only in production and open it up incrementally. Then it reads before it writes and proposes a specific plan first, which is what stops it adding a fourth duplicate field. Promotion still runs through whatever the customer already has, DevOps Center, Flosum or Gearset.

4. Against the platform the bet is headless. Against the labs the bet is the history.

Agentforce builds agents that face customers and employees; changing how the org is built is a different job, and the tell is that Salesforce’s own MCP servers read and write records and read metadata but will not change metadata. So Cirra’s bet is that you configure Salesforce from the AI tools you already use rather than logging into the platform to do it. The frontier models know Salesforce in general but have no access to your specific org. What compounds is the record of what was there, what changed, and the reasoning behind it.

5. Bootstrapping is a timing instrument, not a badge.

To be precise, and Jelle corrected this on air, the seven-figure ARR belongs to Decisions on Demand, not to Cirra. The reason for no outside capital is that neither the models nor the standards around them were ready for a full AI admin when he started, so he iterated through product formats that did not work without burning a round to find out. That patience is also the sales answer to “why not wait for Salesforce”: 2 or 3 releases is 9 months to a year, and Salesforce has a history of taking a couple more releases to harden what it ships.

Jelle van Geuns

• LinkedIn: https://www.linkedin.com/in/jgeuns/

• Cirra AI: https://cirra.ai

Rick Koleta (Host)

• LinkedIn: https://www.linkedin.com/in/rickkoleta/

• Newsletter: https://gtmvault.co/

GTM Vault

• LinkedIn: https://www.linkedin.com/company/gtmvault

• YouTube: https://www.youtube.com/@gtmvault?sub_confirmation=1

• Website: https://gtmvault.co/

The GTM Vault Podcast - subscribe on your platform of choice

Subscribing on YouTube, Apple, or Spotify is what tells each platform to put the next episode in front of more operators, which is how the show keeps booking the guests worth an hour of your week.

Subscribe on YouTube

Subscribe on Apple

Subscribe on Spotify

Previous episodes include

See all previous episodes here: https://www.gtmvault.co/podcast

The GTM Vault Podcast is a breakdown of how high-growth companies design, test, and scale revenue architecture. Visit gtmvault.co for more episodes, the GTM Vault newsletter, Show Me Your Stack, and Coffee Walk, the on-location founder series that opens with Barbaros Ozbugutu in Istanbul.

Primer fixes the match rate that locks B2B teams out of the cheap channels.

LinkedIn CPMs keep climbing and every B2B team is bidding for the same shrinking pool of attention on the same two channels. Meta, YouTube and display cost a fraction, and most B2B teams cannot use them, because a standard contact list matches at single-digit rates and the audience that comes back is too small to learn from. Primer is built on the match rate. It turns your ICP, target accounts and net-new prospects into audiences matching at 45 to 85 percent across every major ad platform, and its 50 million person suppression list stops Meta and Google serving the people who will never buy. On Primer’s own site, Rippling says they would not have raised a $145M Series B without it.

GTM Vault readers: an extended 45 day trial and 15 percent off with the code GTMVAULT15.

Find your next efficient channel → sayprimer.com

Every growth team keeps a list it never writes down. The campaigns that were obviously right and never got built. The regulation your ICP is about to get hit by. Each one died the moment someone priced it and the number came back at ten thousand dollars and a month of calendar for a test nobody could promise would pay.

That price is what moved. Not the cost of a click. The cost of finding out.

In episode 10 of Show Me Your Stack, Riley Timmins, Growth Marketing Lead at Kintsugi, screen-shares what a growth function looks like once that number collapses. He takes a campaign from a standing start, a California use tax law landing on January 1, 2027, through brief, account list, angle, creative, launch and attribution in one sitting, with no engineer in the path. Ads are his biggest line item at roughly half the marketing budget, so this is the main motion.

The stack is Claude Code, Claude Design, a custom ad manager he built himself, Graft for the warehouse, HubSpot, Meta and Google Ads, and a knowledge base built from every sales call. The tool list is not the story. The build order is, along with the two things he refused to automate.

Listen on YouTube // Apple Podcasts // Spotify

Share

The full episode is on YouTube. Subscribe to the channel for the clips and cuts that never make the write-up.

The Gate: Nothing Gets Built Until the Campaign Survives Five Questions

The campaign starts as a brief, and the brief exists for the agents, not for the team. Goal, audience and channels, set before anything runs. A vague brief does not produce a vague campaign. It produces nine assets that each solved a slightly different problem.

The angle does not come from a whiteboard. Every sales call Kintsugi runs feeds an internal knowledge base, and the campaign queries it by topic. What comes back is quotes. One prospect told them every AI token they buy is effectively a software purchase now, and because AI spend is usage based, the tax moves with it. No brainstorm produces that. A buyer said it to a rep.

Then comes the part most teams skip. Before a single asset gets made, an agent runs the campaign against a five-question gate, and one of those questions carries a pipeline number rather than an opinion: two hundred thousand dollars of closed-lost traced to this reason in the previous month.

The Ad Manager: Ninety Percent of the Clicks Were the Same Every Time

The creative step is three images per ad, judged on whether the concept lands on v1 rather than whether it is finished, and he throws out the one he cannot follow himself on the grounds that his ICP will not either.

The custom software took about a week, and not a full week, since he was doing the job at the same time. The observation that started it is the kind most people have and discard: launching one ad in Meta takes at least five minutes, and ninety percent of the fields are identical every time. Only the copy, the headline, the landing page and the ad name vary, so he built an interface that asks for those four, keeps the rest, and routes an ad to Claude Design in one click when a concept needs a single change. A saved edit writes to the warehouse where the ads live, not into the tool, so the ad manager is a surface over the warehouse rather than the system of record.

The Pause Engine: You Have to Kill Ads as Fast as You Launch Them

Volume is what the build was for. The cadence moved from a new set of image ads every two to three weeks to one or two every day, which creates a problem nobody plans for, because you then have to pause at the same rate. So he built a pause engine that nominates the top three ads to kill each day, and its stated job is not saving money first. It is making room for the new ads.

The Attribution Layer: The Channel Your Dashboard Credits Is Often the Wrong One

Measurement runs on three things. UTMs for the direct path. Incremental lift read one to three months after launch, worth another twenty to thirty percent he says. And an agent, rather than a form, answering how people found them.

It reads every first sales call, finds the moment the prospect says how they found Kintsugi, and proposes the correction in HubSpot for a one-click approval. The example he pulls up is the argument for the whole build. The record says paid search. The call says the buyer asked Claude what to use for sales tax on Shopify, got told to search for a Nexus calculator rather than a brand, and landed on Kintsugi's own calculator through an ad. Paid search captured the click. AI search created the demand.

Where This Goes Next: Video Is the Piece That Does Not Work Yet

Riley is explicit about the part that does not work. Video creative still goes to human editors, because the AI output is not good enough to ship, and he names that limit rather than claiming the whole function is automated. Image is where this stack earns its keep, and video is the next thing it has to survive.

His stated rule for what comes next is to disrupt himself before another tool or another person does it for him, and to prove incremental results before expanding. That is also the warning he gives anyone copying this. Do not start with the automated launcher. Prove you can generate ads that convert, then build the thing that launches a lot of them.

The Pattern

AI did not make this team's ads cheaper. It made their wrong answers cheap, and a wrong answer you can afford is a test. The gate that kills campaigns before spend, the pause engine that clears space for the next batch, the reference libraries of good and bad ads: none of it exists to produce more ads. It exists to raise the number of things the team can be wrong about per month.

What it changes is the build order, and his is the opposite of the obvious one. Do not automate the launch first. Prove you can generate ads that convert, because launching ads that do not work faster is a faster way to spend the budget.

And do not automate what you cannot do yourself. An agent asked to do work you have never done returns the generic version, and you could have hired a cheap generic marketer for that. Asked what the growth marketer who cannot build in three years is, his answer is that they are no longer a growth marketer.

1. Put the gate in front of the creative, not after it. Five checks decide whether a campaign gets built, one of them carrying a pipeline number rather than an opinion. It is the cheapest step in the system and the only one that can stop the spend.

2. Count the clicks that never change. Launching one Meta ad takes five minutes and ninety percent of the fields are identical every time, so the four that vary are the interface worth building. Build the pause engine at the same time as the launcher.

3. Audit attribution against the call, not the dashboard. An agent reads every first call and proposes the CRM correction for approval. Paid search was taking credit for demand an answer engine created.

(0:00) The Campaigns That Get Priced and Then Quietly Killed
(1:23) The Brief, and Giving Each Agent One Job
(2:36) Querying Every Sales Call for the Angle
(4:11) The Worth-It Gate That Runs Before Any Asset Is Made
(6:01) The Ad Manager He Built in a Week
(8:48) The Ten Thousand Dollar Idea That Used to Get Killed
(12:51) The Attribution Agent That Reads Every First Call
(14:56) The Pause Engine, and Why Pausing Is the Constraint
(19:54) What a Two Person Team Should Copy First
(23:35) Ten Eighty Ten, and Not Automating What You Cannot Do Yourself

Follow Rick on LinkedIn - https://www.linkedin.com/in/rickkoleta/

Follow Riley on LinkedIn - https://www.linkedin.com/in/riley-timmins-4a264b96/

Try Kintsugi - https://trykintsugi.com/

GTM Vault on LinkedIn - https://www.linkedin.com/company/gtmvault

SMYS 9 | The First Thing a Signal Agent Does Is Throw Signal Away

SMYS 8 | The Browser Is the Interface Everyone Abandoned

SMYS 7 | Your Reps Should Never Meet Your Agents

If this was useful, hit like and restack.

This newsletter was written and edited by Rick Koleta.

Show Me Your Stack is a GTM Vault series. Each episode features one operator walking through the system behind their outbound, their prioritization, or their pipeline motion. No slides. Just the stack.

A GTM engineer is an operator who builds and runs the revenue system as software. Where a RevOps team maintains the CRM and a sales team runs plays by hand, a GTM engineer wires the signals, the enrichment, the routing and the outbound into one system, and then operates it. The output is pipeline per person, not tickets closed or sequences sent. The role exists because execution became cheap: when an agent can research, write and send, the scarce skill is designing what it should do, in what order, and with what data.

That is the definition. The rest of this essay covers where the title came from, how the role differs from RevOps, sales ops and a sales engineer, what the GTM engineers on the GTM Vault record have built, and how to tell whether a company needs one.

Where the Title Came From

The title spread from the Clay operator community in 2024 and 2025. Clay made it possible for one person to build enrichment waterfalls, scoring tables and personalised outbound without an engineering team, and the people doing that work needed a name. Michael Saruggia, who has trained more than 600 operators on Clay, described the shift on GTM Vault as automation eating RevOps: the work moved from maintaining systems to building them, and the people building them were measured on revenue per employee rather than on process health. By 2026 the first State of GTM Engineering report had surveyed more than 225 practitioners, and the title appears on job postings at companies from seed stage to public. The tools GTM engineers run, by operator count tracks what the role is built on now.

The name is new. The work is not entirely new. Growth engineers did a version of it for product-led companies a decade ago. What changed is the surface area: a GTM engineer today touches targeting, data, messaging, routing and the CRM, because the tools that used to sit in separate departments now sit in one table or one terminal.

What a GTM Engineer Is Not

A GTM engineer is not a RevOps hire. RevOps runs the revenue system that exists: data hygiene, routing rules, reporting, the process between functions. A GTM engineer builds the system that should exist and ships it. The two overlap in the CRM and diverge everywhere else. A company with strong RevOps and no GTM engineer has a clean system that does what it did last year. A company with a GTM engineer and no RevOps has a fast system that nobody can report on.

A GTM engineer is not a sales engineer. A sales engineer sits in the deal and proves the product works. A GTM engineer sits above the deal and decides which deals should exist.

A GTM engineer is not a marketing ops specialist with a new title. Marketing ops owns one function's tooling. The GTM engineer's defining property is that the build crosses functions: a signal from product usage routes to a rep through an agent that wrote the email from the CRM record. Three functions, one system, one owner.

What the Ones on the Record Build

Show Me Your Stack exists to record this work with the operator's screen shared, so the definition above can be checked against what GTM engineers do. Six builds from the record, in the order they published.

Vinayak Mishra built a review intelligence system for Slang AI, a voice reservation product for restaurants. Five tools, five layers: Serper to discover restaurants from Google Maps, Clay to hold the table, Apify to pull the reviews, n8n and Claude to classify every review that mentions phones or reservations, and a final Clay table of restaurants whose own customers had documented the problem Slang AI solves. The signal was designed, not bought.

Garrett Wolfe built the action layer for BDRs at Unify, then at his consultancy 1GTM. The account list, the signals and the intent data all existed. The rep still spent two hours a morning toggling between the CRM, Sales Navigator and Apollo to answer three questions: which accounts do I own, who should I call, why now. His diagnosis is the clearest statement of the role: the rep was the integration layer. He replaced the rep as integration layer with a Clay scoring pipeline and a web app built in Claude Code, and the program went from zero to more than $15M in pipeline in twelve months.

Tim Scheuer at Oxygen collapsed campaign setup from three to five hours in Clay to forty minutes in a terminal. Scraping, enrichment, personalisation and launch ran from three or four natural-language exchanges with Claude Code. The first 180 emails into the Y Combinator founder pool, one of the most over-targeted lists in B2B, produced eight positive opportunities. The point was not the tool. When campaign creation stops being the expensive step, the number of angles a team can test in a week changes by an order of magnitude.

Angelo Quiambao at Intellistack runs the opposite of the demo-driven build. His principle is that the best use of AI is the indirect use of AI: a rep checks a box in the CRM and never sees the agents that research the account, draft the sequence and load it. At his previous company the same architecture went from opt-in to mandatory, with every BDR required to send fifty agent-generated emails a day. The stack is Claude Code, Relevance AI, MCP, Databricks, Salesforce, Gong and Apollo. The reps never meet the agents.

Elliot O'Connor at Frontier rebuilt outbound around the browser as the interface, so the system acts where the data is rendered rather than where an API happens to exist.

Michael Bartimer at Clarify runs more than a hundred agents inside one CRM. His website visitor agent takes a de-anonymisation payload and, before classifying anything, throws signal away: employees, competitors and existing customers are suppressed first. His PQL agent passes seven signals out of a hundred. The first job of a signal agent is subtraction, and a GTM engineer is the person who decides what gets subtracted.

The Stack Pattern Behind Every Build

The six builds share a shape even though the tools differ. There is a signal source the company designed rather than bought: reviews, product usage, website visits, a scraped directory. There is an enrichment and scoring layer, Clay in three of the six. There is an agent or workflow runtime, which in 2026 is increasingly Claude Code with MCP connectors rather than a no-code canvas. There is a sequencer or the CRM as the point of send. And there is a deliberate choice about what the human sees: a single pane, a checkbox, a Slack message, never the whole machine.

The Stack Index records every tool these operators named, with the operator who named it, at pro.gtmvault.co/stack. As of October 2026 the index holds 100 tools across eleven instrumentation layers, with 23 operators on the record. Clay, Claude Code and Slack are each named by seven operators, Apollo by six, Salesforce by five.

Does the Company Need One

Three conditions, and a company that meets two of them is already paying for a GTM engineer in rep hours.

First, the data to decide who to contact and why already exists in three or more systems and a human joins it by hand. Garrett's two hours a morning is the symptom.

Second, campaign creation is the bottleneck, not sending capacity. If the team can test one or two angles a week because setup costs hours, the constraint is build time.

Third, there is a signal the company could design that no vendor sells: usage events, support tickets, public reviews, hiring pages, anything specific to the product's problem. Bought intent data is the same list everyone else is emailing.

A company that meets none of these does not need the role yet. It needs an ICP and a motion, which are sequencing decisions and come first. Automation amplifies the system it inherits, and a GTM engineer hired into an undefined ICP builds a faster way to reach the wrong accounts.

Common Questions

What does a GTM engineer do day to day?

Builds and operates the revenue system: designing signal sources, building enrichment and scoring tables, writing the prompts and workflows that research and draft, wiring routing into the CRM, and watching what the system produces. The measure is pipeline per person.

What is the difference between a GTM engineer and RevOps?

RevOps maintains the revenue system that exists and reports on it. A GTM engineer builds the system that should exist and ships it. The CRM is where they overlap.

What tools do GTM engineers use?

On the GTM Vault record: Clay for enrichment and scoring, Claude Code with MCP connectors for orchestration (named by seven operators on the record), Apollo or Sales Navigator for contacts, Instantly or the CRM for sending, n8n or Relevance AI as agent runtimes, and HubSpot or Salesforce as the system of record. The Stack Index lists every tool with the operator who named it.

Is GTM engineering a sales role or a marketing role?

Neither. It is a systems role that crosses both. The defining property is that one build touches targeting, data, messaging and the CRM.

How much does a GTM engineer cost compared with SDRs?

The companies on the record did not add the role to a full SDR team; they used it to avoid hiring one. Garrett's program reached $15M in pipeline with the rep count held flat. The comparison that matters is pipeline per person, not salary against salary.

Where can I see real GTM engineer systems?

Show Me Your Stack, every two weeks, at pro.gtmvault.co/shows/show-me-your-stack. Every episode is the operator's screen, written up with the stack and the full transcript.

Every tool and operator named above is on the record at pro.gtmvault.co/stack. The definition at the top of this essay is the one the Stack Index uses to decide whose evidence counts as operator grade.

Sequencing in go-to-market is the order in which the layers of a revenue system are built, and the rule that each layer depends on the one before it. Identity before motion, motion before distribution, distribution before metrics, and AI last, because AI amplifies whatever it inherits. The same tools installed in the wrong order produce fragmentation instead of compounding. Sequencing is the first decision in revenue architecture, not a planning detail, because every later layer inherits the one it was built on.

That is the definition. The rest of this essay covers why the word is used three different ways, the eight-layer order GTM Vault works from, what the operators on the record did in which order, and the four sequencing errors that produce most of the pipeline problems this publication gets asked about. AI-Native GTM Is a Sequencing Problem is where that order meets agents.

Three Uses of the Word

"Sequencing" circulates with three meanings and only one of them is the subject here.

In sales engagement tools it means a sequence: the cadence of emails and calls a rep sends to a contact. Outreach and Salesloft sold the word, and most people hearing it in a sales team mean this.

In fundraising and company building it means which market or segment to go after first, then second. Useful, and adjacent, but it is a strategy decision about where to point the machine, not about how the machine is assembled.

In revenue architecture it means the build order of the system itself: which structural layer is decided and installed before which. That is the meaning the GTM Architecture Laws use, and it is the one that decides whether the other two meanings ever matter. A perfect email sequence into an undefined ICP is activity. A sharp market sequence run through a fragmented stack is effort without compounding.

The Eight-Layer Order

GTM Vault's Revenue Architecture Map orders a revenue system in eight layers. The order is the point.

1. Identity. The ICP as the architectural definition every later decision is tested against. Not a targeting filter; the definition of who the system is for.

2. Sequencing. What scales first constrains everything after. This layer is the decision about the order of the remaining six, which is why it sits second: it is made once the ICP exists and before anything is built.

3. Pricing. Pricing restructures every layer it touches, so it is set before motion, because the motion that fits a $2,000 product is not the motion that fits a $200,000 one.

4. Functional coherence. One metric the functions share, before each function builds its own. Function-level optimisation is system-level debt.

5. Motion. The playbook for the current stage. Every playbook encodes the stage it was built for.

6. Distribution. Channels connected, not accumulated. Added channels increase activity; connected channels produce reach.

7. Metrics. Measurement that reports compounding rather than activity, built after there is a system to measure.

8. AI. Last, because it amplifies the architecture it inherits. On a coherent system it compounds. On a fragmented one it scales the fragmentation.

The law for layer two reads: expansion before architectural readiness is not growth, it is a structural violation that accelerates the distance between effort and output. The gap between a compounding curve and a plateauing one is rarely a performance difference. It is a sequencing decision made early and never revisited.

What the Record Shows About Order

Show Me Your Stack records systems with the operator's screen shared, and the order they built in is visible in every episode.

Michael Bartimer at Clarify runs more than a hundred agents inside one CRM, and his first step was none of them. Step one was visibility: a Slack channel where every agent posts what it did, so a human can read a run in ten to twenty seconds. Agents came after the surface that lets a person check them. The order was observe, then act.

Garrett Wolfe's BDR action layer began with the account list and the scoring table in Clay, and only then the web app in Claude Code that reps use. The app on top of an unscored list would have been a faster way to call the wrong accounts. Scoring before interface.

Vinayak Mishra's review intelligence system for Slang AI started with the signal definition, a negative review that mentions phones or reservations, before any discovery, enrichment or outreach was built. Signal definition before pipeline. The system narrows from thousands of restaurants to a qualified few because the narrowing rule was decided first.

Yoni Tserruya rebuilt Lusha for agents that query live because a third of a static list is wrong by the time the last rep touches it. The sequencing lesson sits underneath: a data layer built for a weekly export cannot be fixed by adding an agent on top. The data layer had to be rebuilt before the AI layer could be trusted.

The AI SDR category, 2023 to 2025, is the sequencing error at industry scale. The tools ran volume against the same broken qualification the human SDRs had been running, at machine speed, and early revenue walked once break clauses opened. Layer eight installed on top of an undefined layer one. The lesson was not that AI does not work. Automation amplifies the system it inherits.

The Four Sequencing Errors

Most of the pipeline problems this publication is asked about reduce to one of four orderings.

Motion before identity. The company hires SDRs and buys a sequencer before the ICP is an architectural definition. The symptom is a full calendar of meetings that do not close, reported as a sales execution problem. The cause is that every downstream decision inherited a blank.

Distribution before motion. Channels get added because each one is cheap to try: a LinkedIn program, a partner motion, paid, events. The symptom is a reporting deck with six channels and no compounding. The cause is channel accumulation with no motion to connect them.

Metrics before coherence. Each function builds a dashboard for its own metric. Marketing reports MQLs up, sales reports meetings up, customer success reports churn up, the CEO reports revenue flat. The dashboards are accurate. The system is measuring activity at every functional boundary because no shared metric was set first.

AI before everything. An agent is installed to generate pipeline on a system that has not decided who it is for. This is the most common error in 2026 because it is the cheapest to make: the agent costs less than the SDR it replaces and ships in a week. It produces the AI SDR result at company scale.

How to Read Your Own Order

The test is one question per layer, asked from the bottom up: is this layer decided, in writing, in a form the next layer can inherit? An ICP that lives in the founder's head is not decided. A motion that changes by rep is not decided. A metric each function defines differently is not shared. The first layer that fails the test is where the next build goes, regardless of what the team wants to build next.

The Stack Index runs this as a tool. Build Your Stack takes the revenue band, the motion, the binding constraint and the budget posture, and returns the sequence first: install first, install next, not yet. The plays come after the order, because the order is what the operators on the record got right before the tools.

Common Questions

What does sequencing mean in go-to-market?

The order in which the layers of a revenue system are built, with the rule that each layer depends on the one before it. In GTM Vault's framework: identity, sequencing, pricing, functional coherence, motion, distribution, metrics, AI.

Is sequencing the same as a sales sequence?

No. A sales sequence is a cadence of touches to one contact. Sequencing in revenue architecture is the build order of the whole system. The first only produces results inside a system that got the second right.

What should be built first in a GTM system?

The ICP, as an architectural definition rather than a targeting filter. Every later layer inherits it. Then the sequencing decision itself: which of the remaining layers is installed in which order for this stage.

Why does AI come last?

Because AI amplifies the architecture it inherits. On a coherent system it compounds output; on a fragmented one it scales fragmentation at machine speed. The AI SDR failures of 2023 to 2025 are the industry-scale example.

What happens when a company scales out of sequence?

Effort rises and output does not. The law for the sequencing layer calls expansion before architectural readiness a structural violation: the distance between effort and output accelerates, and the gap shows up later as a sales, marketing or tooling problem that is none of those.

Where is the full framework?

The GTM Architecture Laws at gtmvault.co/p/laws, one law per layer, and the Revenue Architecture Map in the What Is Revenue Architecture essay. The operator evidence for each layer is in the Library at pro.gtmvault.co/library.

The order above is the order the Stack Index uses to place every tool an operator names. A tool is recorded on the layer it served, and a build is read by which layer it started from.

Subscribe

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

Every vendor in your inbox is selling a signal, and most teams respond by picking the best one and wiring it to a sequence. The data says that is the wrong question. Accounts carrying more than eight signals generate nineteen times the opportunities of accounts carrying one or two, while the best single signal in B2B, champions on the move, tops out at about twelve percent of opportunities on its own. Christian Kletzl built UserGems on that one signal, in a one-week build in a cabin in the Austrian Alps that sold its first contract for $50,000. The co-founder and CEO joins GTM Vault for episode 53 to explain why he has spent the years since moving past it: how stacked signals get scored into one daily ranking, why if-this-then-that routing burns your best contacts, and why he gave up the dashboard to get there.

About UserGems

UserGems tracks when a company's past champions, users and buyers change jobs, then scores that against more than twenty other signal types to rank which accounts and people a revenue team should work on a given day. It was founded by the Austrian twin brothers Christian Kletzl, the CEO, and Stephan Kletzl, the CTO, and runs out of San Francisco, having started as SmartHires, their Y Combinator W15 company. Its customers are mid-market and enterprise B2B revenue teams, including Procore, Medallia, UserTesting and Sisense. UserGems has raised $22.4M, including a $20M Series A led by Craft Ventures with Battery Ventures, Tiger Global and Uncork Capital.

Watch or listen now across YouTube, Apple Podcasts, and Spotify

Share

Episode highlights

(0:00) Cold Open: Eight Signals, Nineteen Times the Opportunities
(4:01) A Cabin in the Austrian Alps and a One-Week Build
(5:38) Why Champions on the Move Tops Out at Twelve Percent
(10:53) The If-This-Then-That Mistake and What It Costs You
(13:25) Stacking Signals Into One Daily Ranking of Fifteen
(16:34) Twenty Million Accounts, Six Hundred Attributes, One ICP Score
(21:52) Where Gem-E Stops and the Rep Starts
(26:34) Going Headless Over MCP and Who Owns the Outcome
(34:41) Data Accuracy and the Ten Percent Trust Line
(37:14) Publishing Pricing and the Case for Self-Selecting Out

What you’ll learn:

• The finding that accounts carrying more than eight signals produce nineteen times the opportunities of accounts carrying one or two

• Why champions on the move generates about twelve percent of opportunities, why that share holds across organizations, and why it compounds on its own

• Why if-this-then-that routing spends your best information on whichever signal fires first, and burns the account for six months doing it

• How twenty million accounts and six hundred attributes become one ICP ranking, built by comparing your customers against everyone who never bought

• The two exceptions that should still fire instantly, and why everything else belongs in a daily ranked list of fifteen

• Why a ten percent error rate is where reps stop trusting a signal motion whatever its coverage, and the case against waterfall enrichment

• How UserGems doubled SDR-generated opportunities from nine to nineteen a month, hired more SDRs on the back of it, and kept calls human

• Which signals a competitor can buy, which ones only you can create, and why that line decides durability

• What changed in AI-written outbound around September 2025, and how the customer complaints flipped

• Why publishing a $40K entry price is a qualification mechanism rather than a pricing decision, and the math Kletzl expects a buyer to run

Key takeaways

1. The best signal in B2B has a ceiling, and the ceiling is the whole argument.

Champions on the move generates about twelve percent of opportunities, and Kletzl says that share holds across organizations. It compounds on its own, because a larger customer base produces more job changes. The mechanism underneath is durable: roughly eighty percent of people stay in the same industry and eighty percent stay at the same company size, so a champion carries the same problems into the next role. But twelve percent is not what a CMO wakes up thinking about, which left UserGems valuable and peripheral at once. Every product decision since has been an attempt to reach fifty.

2. If-this-then-that routing spends your best information on your first signal.

Kletzl names this as the most common mistake he sees, and says the easier the tooling makes it, the more it happens. A signal fires, a sequence launches, and that person is now off limits for six months. Better information arriving next week has nowhere to go. Two exceptions still fire instantly, a past champion and a pricing or comparison page visit. Everything else waits for the ranking.

3. Stacking signals beats picking signals, by a factor of nineteen.

Accounts carrying more than eight individual signals generate nineteen times the opportunities of accounts carrying one or two. That reframes the question most teams bring him. They want to know which signals to switch on, when the compounding sits in how many land on the same account and how they are scored together. It is also why he refuses to start a new customer on workflows, and starts on ICP definition instead. Kletzl will not name the signals behind his best customers’ motions, because at the top end it is no longer about any individual one.

4. Data accuracy is the foundation, and the tolerance is ten percent.

Above a ten percent error rate, Kletzl says people stop trusting the motion, and no amount of coverage recovers it. That applies to every signal and not just job changes, because a website visitor with a stale title is a dead signal the same way a nine-month-old job change is. It is also his case against waterfall enrichment, which buys quantity at the cost of knowing whether any of it is right. UserGems would rather return nothing than return something wrong.

5. Going headless gives up the interface and keeps the outcome.

UserGems exposed the whole platform over MCP, including campaign setup, audience building, list uploads and persona creation, not just data export. Kletzl puts that in the middle of three phases: humans clicking through a browser, then humans directing AI, then AI tuning campaigns against its own results. He is comfortable losing the dashboard because the end user was never in it. The buyer was always buying opportunities generated, and ownership of the outcome does not move when ownership of the interface does.

Christian Kletzl

LinkedIn: https://www.linkedin.com/in/christiankletzl/

UserGems: https://www.usergems.com/

Rick Koleta (Host)

LinkedIn: https://www.linkedin.com/in/rickkoleta/

Newsletter: https://gtmvault.co/

GTM Vault

LinkedIn: https://www.linkedin.com/company/gtmvault

YouTube: https://www.youtube.com/@gtmvault?sub_confirmation=1

Website: https://gtmvault.co/

The GTM Vault Podcast - subscribe on your platform of choice

Subscribing on YouTube, Apple, or Spotify is what tells each platform to put the next episode in front of more operators, which is how the show keeps booking the guests worth an hour of your week.

Subscribe on YouTube

Subscribe on Apple

Subscribe on Spotify

Previous episodes include

See all previous episodes here: https://www.gtmvault.co/podcast

The GTM Vault Podcast is a breakdown of how high-growth companies design, test, and scale revenue architecture. Visit gtmvault.co for more episodes, the GTM Vault newsletter, Show Me Your Stack, and Coffee Walk, the on-location founder series that opens with Barbaros Ozbugutu in Istanbul.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/gtm-53.

Subscribe

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

Most founders never see a hundred-million exit. Barbaros Ozbugutu closed one on December 17, 2019. What it taught him is that iyzico left a multibillion outcome on the table by operating in one country. Klarna’s first employee in Germany in 2010, he turned down a Deutsche Telekom contract to move his family to Istanbul in 2013 and built iyzico through the downturn years that followed. The co-founder of iyzico and now of Donnerstag.ai joins GTM Vault for the first ever Coffee Walk, from Galata down to Karakoy, to explain why the second company was global from day one, why it runs on rules rather than on an LLM, and what a co-founder’s diagnosis seventeen days after the exit did to how he spends his time.

About Donnerstag.ai

Donnerstag.ai is a system of action for enterprise finance: it connects ERP, service and banking data to reconcile transactions line by line, surface discrepancies, and run the workflow that follows, starting with accounts receivable for suppliers. It was founded in 2025 in Frankfurt by Barbaros Ozbugutu, co-founder of iyzico, and Volkan Ozkan, co-founder of Yolda. The team of thirteen works across Germany, Turkey, Spain, the UK and Dubai with no department heads. In November 2025 it raised a €4.3 million seed round led by Speedinvest, with QED Investors, Crestone VC and European angels.

Episode highlights

(0:00) One Country, And What It Cost
(2:21) Klarna’s First Employee In Germany
(12:24) The Deutsche Telekom Offer, And Moving The Family To Istanbul
(15:25) Hire People Better Than You, And Why There Is No Playbook
(20:46) Tahsin’s Diagnosis, Weeks After The Exit
(25:00) Why Donnerstag.ai, And Falling In Love With The Problem
(29:05) The Action Gap: The ERP Records, Excel Acts
(31:30) Three To Five Percent Leakage, 95 Percent Manual
(36:06) Never Send Financial Data Into An LLM To Match
(45:24) Global From Day One, And The Country Discount

What you’ll learn:

• Why a market-leading company in one country gets a country discount on valuation and fundraising, and why the second company was global from day one

• The action gap: why SAP, Oracle and Dynamics are systems of record, and why every real finance action still happens in Excel

• What a system of action is, and how it sits on top of the ERP instead of replacing it

• Three to five percent revenue leakage, 95 percent manual work, and a 10 to 15 day close: the three numbers driving enterprise finance automation

• Why you never send financial data into an LLM to match transactions, and what the LLM is for instead

• How a one-hour meeting with the people doing the work replaces ten consultants and a slide deck

• Why nobody in a large enterprise buys a horizontal AI orchestration project, and why the vertical problem wins

• Why there is no playbook in 2026, and what that changes about who you hire

• Why you hire people better than you, say expectations out loud, and fire fast when the gap does not close

• What a co-founder’s diagnosis seventeen days after the exit, and losing him eighteen months later, changed about how he gives, plans, and spends a day

Key takeaways

1. The country discount is real, and it is the one thing he refused to repeat.
iyzico led its market in Turkey, and Barbaros reads two or three more countries as the difference between a hundred-million exit and a multibillion one. One market meant a discount on valuation, a ceiling on fundraising, and a limit nobody set on purpose. Donnerstag.ai started global on day one, with people in Spain, Turkey, Germany, Dubai and the UK, because a finance team’s reconciliation problem is the same in every country.

2. The ERP is a system of record. Every real action still happens in Excel.
SAP, Oracle and Dynamics record everything, and the moment a finance team wants to act on it (cash flow, open positions, line-by-line reconciliation), the data leaves the ERP and lands in a spreadsheet run by a person. That round trip is the action gap. Donnerstag.ai is the system of action on top: it pulls the data, matches it, surfaces discrepancies, runs the workflow in autopilot or with an approval step, and writes the result back with an audit trail.

3. Three numbers make the case: three to five percent leakage, 95 percent manual, and a 10 to 15 day close.
Enterprise finance operations leak three to five percent of revenue because nobody can run them line by line. Ninety-five percent of the work is done by hand, and nobody wants that job anymore, which turns a cost problem into a talent problem. Month-end close takes 10 to 15 days, and until the books close the CEO does not know whether the quarter hit or whether there is cash to pay the invoices.

4. Never send financial data into an LLM and ask it to match. Use the LLM to write the rules.
A model is not deterministic, so three runs give three answers, and an auditor asking why a step was taken will not accept “the AI did that.” What the LLM does well is read the contracts and extract the rule set, so the matching runs deterministically and every decision is explainable. The moat is not the model. It is understanding the customer’s process, done in a one-hour meeting with the people doing the work rather than ten consultants and a slide deck.

5. There is no playbook, so hire people with opinions, hire people better than you, and fire fast.
Everything is at zero in 2026: nobody knows the right shape of a technology company or its go-to-market, so people who execute a playbook are the wrong hire and people who run experiments are the right one. Donnerstag.ai runs thirteen people with no department heads. Hire people better than you so you can take a day off, say the expectations out loud, and when the gap does not close, fire fast, because at ten people one person is the company.

Barbaros Ozbugutu

• LinkedIn: https://www.linkedin.com/in/barbaros-ozbugutu-34763619/

• Donnerstag.ai: https://www.donnerstag.ai

Rick Koleta (Host)

• LinkedIn: https://www.linkedin.com/in/rickkoleta/

• Newsletter: https://gtmvault.co/

GTM Vault

• LinkedIn: https://www.linkedin.com/company/gtmvault

• YouTube: https://www.youtube.com/@gtmvault?sub_confirmation=1

• Website: https://gtmvault.co/

The Library

Coffee Walk stays free. Every episode of the GTM Vault Podcast and every Show Me Your Stack lives as a written playbook in one searchable place, with the full transcripts searchable by phrase down to the timestamp. It is part of Pro. If you are a member, sign in at pro.gtmvault.co with your subscriber email. If you are not, this is the reason to upgrade.

Every tool operators name on GTM Vault is in The Stack Index, placed on the layer of revenue architecture it serves. Build your own stack at pro.gtmvault.co/stack.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/cw-01.

Across twenty-two GTM Vault episodes carrying operator evidence, Clay was named in seven, level with Claude Code and ahead of every other tool in its own layer. In none of them did it displace ZoomInfo: where both appear, Clay runs alongside it. In two of the seven the operator no longer opens Clay at all, reaching it through MCP or a command line with Claude Code holding the orchestration. Clay won the enrichment layer. The interface it won with is already being replaced, and that is the more useful finding.

Seven Stacks, One Table

The count comes from write-ups, not from a survey. Vinayak Mishra at Slang AI built three Clay tables as the master data layer for a review-scraping pipeline. Garrett Wolfe at 1GTM ran an enrichment waterfall inside it, with Lead Magic as the first call and Apollo and Sales Navigator behind. Umar Farooq Adam ran account research through it at Hitachi Vantara, wired to HubSpot, Salesforce and Outreach through the Microsoft Power Platform. Charles Cormier at TopLeads runs it beside a cold email sending stack he puts at about two hundred dollars a month. Michael Saruggia described it as the core of the GTM engineer’s stack. Tim Scheuer at Oxygen built campaigns in it. Elliot O’Connor at Frontier sells to RevOps teams who run it next to ZoomInfo or Apollo. Clay vs ZoomInfo on the Stack Index carries the per-operator detail behind the count.

Seven operators, seven companies, at seven different stages, from a sending stack of about two hundred dollars a month to an enterprise deployment. The same table in the middle of all of them. The full operator record, with every citation, sits on the Clay page of the GTM Vault Stack Index.

What the Waterfall Cost Before

The reason this happened is unglamorous. Enrichment was never one purchase. It was four or five, and the work was not the enrichment. The work was reconciliation.

A team bought a contact database, a second source for the records the first one missed, a scraping tool for the fields neither carried, and a spreadsheet to join them. Every step produced an export. Every export produced a different schema, a different match rate and a different set of duplicates. The operator’s time went into deciding which of three conflicting job titles was correct, not into deciding which account to work.

Clay did not invent better data. It absorbed the join. The fallback logic that used to live in a person’s head and a spreadsheet became a column rule, and the vendors that had priced themselves as the whole step became individual calls inside it. Once the waterfall was a configuration rather than a workflow, the seat-based contract for one participant in that waterfall stopped making sense.

This is not a story about data quality. It is a story about where the reconciliation work sits.

Why Nothing Was Displaced

No operator on the record describes Clay replacing ZoomInfo, and the reason is the interesting part.

Umar Farooq Adam at Hitachi Vantara runs Clay and still keeps ZoomInfo as the first source in his firmographic waterfall. Mark van Oppen at SecureAuth confirmed ZoomInfo in heavy use for account and contact data. Michele Shepard at Emburse runs Demandbase for account intelligence, alongside Gong, Nooks, Goldcast and HeyGen. In none of these stacks did a table displace the incumbent. At that size the contract is not paying for the waterfall, it is paying for procurement-approved coverage, security review, and a support relationship someone can escalate through. Those are real purchases and no amount of column logic replaces them.

So the honest version of the claim is narrower than the enthusiasm around it. Clay won the layer where the operator chose the tools, and it won it by sitting next to the incumbent, not by removing it. Elliot describes the split exactly: the reps live in ZoomInfo, RevOps lives in Clay. The count on its own is a poor guide to what any given company should do.

The Front Door Moved

Two of the seven stacks no longer touch the Clay interface.

Elliot O’Connor reaches it through Clay MCP, with Salesforce arriving the same way, and the rep works in a Chrome extension rather than in either system. Tim Scheuer went further and built a command line layer so that Claude Code executes the scrape, the enrichment, the personalisation and the launch from a prompt, replacing the campaign setup he used to do by hand in Clay.

Claude Code appears in seven stacks across the index, and in two of the seven that run Clay. Outside the Clay stacks the same move shows up. Angelo Quiambao at Intellistack runs his entire agent layer from it, over Databricks, Salesforce, Gong and Apollo. Jai Toor at DeepLine runs a signal discovery skill end to end in it. In none of these cases did the underlying layer change. The work still happens. The person stopped being the one clicking.

That is the pattern worth naming. The interface was Clay’s distribution advantage, the thing that made a GTM engineer productive in an afternoon. It was never the moat. When the orchestration moves to an agent, an interface optimised for a human operator becomes a cost, and the product that survives the transition is the one whose API and MCP server are as good as its tables.

The Layer Is the Durable Unit

The Eight Layers argument holds that tool categories are not architecture, and this is the cleanest evidence for it I have collected. Over eighteen months the enrichment layer stayed exactly where it was in the system. What changed was which vendor occupied it, and then how the occupant was reached. The layer persisted through both changes without moving.

Which means the question to ask about any tool in your stack is not whether it is the best in its category. It is whether the layer it occupies would survive its removal. If the layer would collapse, the tool is load-bearing and the switching cost is real. If another vendor would slot into the same position in a fortnight, the contract length is the only thing making the decision feel permanent.

For most teams reading this, the enrichment layer is load-bearing and the vendor inside it is not. Price the contract accordingly, and build the layer so the front door can move again, because on the evidence of the last eighteen months it will.

Common questions

Is Clay replacing ZoomInfo?

Not on the record. None of the seven Clay users documented on GTM Vault describes replacing ZoomInfo with it. Where both appear, they run side by side: Hitachi Vantara keeps ZoomInfo first in its firmographic waterfall, and Elliot O’Connor at Frontier describes reps working in ZoomInfo while RevOps builds in Clay. Clay absorbs the enrichment waterfall around the incumbent. In enterprise stacks, procurement, security review and support coverage keep ZoomInfo in place.

What does Clay do that a contact database does not?

It runs the fallback logic. A contact database returns what it has. Clay calls several sources in sequence, takes the first acceptable answer per field, and keeps the join rules as configuration rather than as a spreadsheet someone maintains. The value is in the reconciliation, not in the records.

Do I still need Clay if I am running agents?

The enrichment layer is still required, so something has to occupy it. What changes is how you reach it. Two operators documented here access Clay through MCP or a command line with Claude Code driving, and never open the interface. If you are heading that way, weigh a vendor’s API and MCP server more heavily than its user interface.

What is the cheapest working version of this stack?

Charles Cormier at TopLeads puts his core sending stack at about two hundred dollars a month: Namecheap for domains, SendGrid for delivery and Instantly for sending, with Clay and Persana for data on top. The constraint at that budget is not tooling, it is the quality of the account list going in.

How was this counted?

One citation per episode where a named operator described running the tool in a working system. Mentions in passing, sponsor reads and guest biographies were excluded, and products belonging to the guest’s own company were excluded from the counts entirely. The base is twenty-two GTM Vault and Show Me Your Stack episodes carrying operator evidence, plus one operator who confirmed his stack directly.

Related reading

The 8 Layers of a Modern Revenue Architecture sets out why tool categories are not architecture layers, which is the frame this essay tests against real stacks.

SMYS 8: The Browser Is the Interface Everyone Abandoned is the episode where the rep stops opening either system, because Clay’s data comes to the browser.

SMYS 6: From Clay to Claude Code is the clearest documented case of the orchestration moving out of the interface and into an agent.

You Are Building the Wrong Moat makes the distribution argument that explains how Clay took the layer in the first place.

Subscribe

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

This episode is now a free Claude skill: PQL scoring and routing agent, built from the system Michael Bartimer walks through here. See Michael’s full stack on the Stack Index.

Every GTM engineer runs the same quiet sprawl. An enrichment workflow here, a follow-up agent there, a Zapier chain nobody remembers building, each one solving a real problem and all of them together a second job. Michael Bartimer works inside a CRM workspace running a long list of agents, most of them enabled, and almost none of that sprawl, because they all live in the system of record. The GTM engineer at Clarify joins Show Me Your Stack for episode 9 to screen-share the two he is willing to open in public, a website visitor agent and a PQL scoring and routing pair, and to decline the premise the episode was booked on. He does not think the automation layer is being deleted.

About Clarify

Clarify is an AI-native CRM that connects to a team’s email, calendar and call data and uses a built-in agent to log interactions, summarise meetings, update pipeline and run workflows without being asked, which is what the company means by autonomous CRM. It was founded in 2024 in Seattle by Patrick Thompson, who previously co-founded the data tooling company Iteratively and sold it to Amplitude, alongside Ondrej Hrebicek, Iteratively’s former CTO, and Austin Hay, who had been an Iteratively customer. The company onboarded hundreds of teams through a pilot before opening the platform publicly, and employed roughly two dozen people at its Series A. Clarify has raised $22.5M, including a $15M Series A led by USVP and Gradient with Madrona, Recall, Ascend, Essence, New Normal Fund and Fika participating, and in 2026 it acquired the San Francisco startup Seam AI.

Download the transcript

GTM Vault SMYS 09 Michael Bartimer Transcript

75.5KB ∙ PDF file

Download

Download

Episode highlights

(0:00) Cold Open: An Experiment In Deletion
(0:40) The Sprawl Every GTM Engineer Is Quietly Running
(3:49) Inside The Agents Section: The Website Visitor Agent
(4:42) How He Briefs Rep: A Ramble, A Ticket, Or A PRD
(6:42) The Stale Data Problem And The LinkedIn Fix
(9:07) Reading A Live Run, And How Fast It Stood Up
(11:02) Start With Visibility: Why Slack Is Step One
(12:31) The PQL Agent: Seven Signals Out Of 100
(14:34) Four Routing Paths And The Ten To Twenty Second Review
(18:20) Why He Calls It Consolidation, Not Deletion

What you’ll learn:

• Why a website visitor agent spends its second step deleting people, before anything is classified or written anywhere

• Employees, competitors and existing customers: the three suppressions that run before any classification is allowed to happen

• How to treat a data vendor’s company field as a hypothesis, using the LinkedIn profile already in the payload

• Vendor data is often six or twelve months stale, and sometimes twenty-four or more, pointing at a previous role

• Why visibility in a Slack channel is the deployable version of this play and outbound is the upgrade

• How much less of your own site traffic sits inside your named personas than your model assumes

• Seven signals scoring a PLG signup out of 100, half of them tool calls out to the product analytics

• The four routing paths, and the ten to twenty second human review that nobody on the sales team wanted removed

• Why the workaround runs through an outside vendor and still has an end date

• Why he declines “deletion” and measures speed to deploy and iteration cycle time instead of tool count

Key takeaways

1. The first job of a signal agent is to throw signal away.

The website visitor agent takes a de-anonymization payload through a webhook and parses out name, title, LinkedIn and company. Its very next move is removal: employees browsing the site, named competitors, and existing customers are all suppressed before any classification runs. Only what survives gets sorted into an ICP, and only then does persona resolution happen at the person level.

2. Stale vendor data is a pipeline step, not a procurement decision.

Michael’s name for it is the stale data problem, and his numbers are blunt: provider data is often six or twelve months old and he has seen instances twenty-four months or more out of date, still pointing at the person’s previous employer. His fix does not involve a second vendor. The agent opens the LinkedIn profile already sitting in the payload, resolves the current company, and then re-runs the whole workflow against the corrected record.

3. The specification was the work. The build took minutes.

The PQL agent was one of the first things he built after joining four months ago. The build path is the interesting part: analysis in Claude Code, output into a Notion doc, a few rounds of team feedback on that doc, then the doc handed to Rep, Clarify’s built-in AI, which planned and drafted the working agent in minutes. Seven signals score a PLG signup out of 100, about half of them tool calls to the product analytics and the rest properties already in the CRM.

4. Nobody removed the human. They removed the hour around the human.

The routing agent splits into four paths. Path one is immediate sales outreach on firmographic criteria and it still passes through a person, because the sales team wants a ten to twenty second look before enrolling the account in a campaign with one click. Path two nurtures toward a PQL score of sixty or greater, the threshold at which an account is classified sales ready, which makes this a lightweight first version of a product-led sales motion.

5. He declines “deletion” and calls it consolidation, which is a claim about speed rather than tool count.

Clarify campaigns suit sales-led outbound and have gaps for marketing-led, so persona-specific enrollment runs through an outside sending tool with the outcomes written back for reporting. Michael treats that as two moves: build the workaround with outside tooling, then take the gap to product and engineering so the workaround expires. Six months ago the same work was spread across HubSpot, assorted automation tools and Claude Code, and what changed is that the pipes, the data and the reporting stopped living in different buildings.

Michael Bartimer

• LinkedIn: https://www.linkedin.com/in/michael-bartimer-9311b480/

• Clarify: https://www.clarify.ai/

Rick Koleta (Host)

• LinkedIn: https://www.linkedin.com/in/rickkoleta/

• Newsletter: https://gtmvault.co/

GTM Vault

• LinkedIn: https://www.linkedin.com/company/gtmvault

• YouTube: https://www.youtube.com/@gtmvault

• Website: https://gtmvault.co/

Show Me Your Stack - subscribe on YouTube

Show Me Your Stack lives on YouTube, because the screen is the episode. Subscribing is what tells the platform to put the next operator’s stack in front of more people who build these systems for a living.

Subscribe on YouTube

Previous episodes include

See all previous episodes here.

Show Me Your Stack is a GTM Vault series. Each episode features one operator walking through the system behind their outbound, their prioritization, or their pipeline motion. No slides. Just the stack.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/smys-09.

Subscribe now

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

Every vendor in revenue AI is pointed the same way. Automate the seller, draft the outbound, hand the follow-up to an agent. Which leaves a question nobody on that side of the market is funded to answer: what happens to the conversations an agent does not get to take, and who is responsible for making the humans in them better. Ariel Hitron has been running the other way since 2019, building AI that plays the buyer so the seller gets better. The co-founder and CEO of Second Nature joins GTM Vault for episode 52 to explain why an enterprise buyer signing off on a large number is not buying capability, where he draws the line between an agent conversation and a human one, and why the training product was only ever the wedge.

About Second Nature

Second Nature builds a data model of a company’s sales playbook out of its recorded calls, collateral, scripts and CRM stage criteria, then generates AI roleplays that let reps practice against it and scores them afterwards against that company’s own criteria, in more than twenty languages. It was founded in 2019 by Ariel Hitron, who helped scale Kaltura from startup to global business, and Alon Shalita, a former lead engineer at Facebook, and runs out of New York. Its customers include Zoom, Oracle, Adobe, Teleperformance and Check Point, and the company reports sales up more than twenty percent after an average of thirty minutes of practice per trainee, with onboarding at some accounts cut by three weeks off a nine week process. Second Nature has raised $38M in total, including a $22M Series B in October 2025 led by Sienna VC with Bright Pixel, StageOne Ventures, Cardumen, Signals VC and Zoom, which is also a customer.

Watch or listen now across YouTube, Apple Podcasts, and Spotify

Share

Download the transcript

GTM Vault Podcast 52: Ariel Hitron Transcript.pdf

105KB ∙ PDF file

Download

Download

Episode highlights

(0:00) Who Do You Hold Accountable When It Breaks
(1:38) The Category Automates the Seller. He Went the Other Way
(5:07) 2019, Before ChatGPT, and the Objection Every Enterprise Gave
(7:33) Digitizing the Playbook Into One Machine-Readable Model
(9:35) What the Scoring Layer Catches That a Manager Misses
(13:22) Which Conversations Should Go to an Agent, and Which Never
(19:18) Bundling, Unbundling, and Why Enterprises Unbundle Upward
(24:53) From Roleplay to Agentic Sales
(30:49) Demos Are Free. Maintenance Is the Moat
(38:24) The 2028 Revenue Org and the Test That Would Prove Him Wrong

What you’ll learn:

• Why an enterprise buyer approving fifty thousand or five hundred thousand dollars is buying accountability, which an agent has none of

• The two variables that draw the human line: size of the investment and how far the product sits from a commodity

• Why personality and preference is a third factor he names, and pointedly does not rank against the other two

• A playbook lives in four places at once, and none of them can be trained against until it is compiled into one model

• The machine does not beat a sales manager on judgment, it beats them on patience across a seven-parameter scorecard

• Building a hostile buyer is trivial, and the silent one is the hardest to sit across from

• Why enterprises are unbundling their enablement suite upward, buying the one capability the platform layer has not absorbed

• Demos are free and maintenance is the moat: what happens to every in-house roleplay build after the hackathon

• Why large competitors shipping roleplay as a feature made the sale easier rather than harder, and what he had to stop arguing

• The falsifiable test, on a clock: if the sales workforce shrinks, he was wrong

Key takeaways

1. Enterprise buyers are not buying capability. They are buying someone to answer the phone when it breaks.

Ariel gives away the whole capability argument without a fight. An agent can run discovery, ask the questions, solution, and put a proposal in front of you. What it cannot do is absorb the consequence, and a buyer signing off on fifty thousand or five hundred thousand dollars has put their own standing inside the company on the line to do it.

2. Two variables draw the human line, and a third one he names without ranking.

Size of the investment, and how far the product sits from a commodity. He puts the first threshold somewhere between ten and fifty thousand dollars, and the second at the gap between restocking something you have bought before and deploying a system nobody in the market can vouch for yet. Toilet paper goes to a bot and a new ERP does not, and the third factor he names is personality and preference, which he leaves unranked against the other two.

3. A playbook you have not compiled cannot be trained against, by an agent or a new hire.

The playbook is real and it is scattered across four surfaces: product marketing decks, tribal knowledge sitting in reps’ heads, recorded live calls, and the stage entry and exit criteria in the CRM. Second Nature’s job is to consolidate all of it into one machine-readable model of how that specific company sells. Every org runs its own mutation of MEDDPICC or SPIN, so the named methodology tells you almost nothing about the process that survives contact.

4. The scoring layer does not beat a manager on judgment. It beats them on patience.

Humans read the room, catch the nuance, and bring everything they have seen before into the call. What they do not do is walk a seven-parameter scorecard, call by call, rep by rep, and justify each score. Ariel’s framing is that sales leaders are not accountants, so the feedback that lands is that you were not convincing, not exciting, not bringing energy, which is true and unusable, and the machine advantage is consistency rather than insight.

5. Demos are free. Maintenance is the moat, and it is why the in-house build decays.

The pattern repeats across enterprises: a hackathon, an internal team, a working prototype, then decay. The builders return to their day jobs, the voices go stale, credits run out, access controls are wrong, and nothing consolidates the data. Every layer underneath moves fast enough, from the models to speech to text to the agent harnesses, that maintaining it becomes irrational for anyone whose job is not this.

Ariel Hitron

• LinkedIn: https://www.linkedin.com/in/arielhitron/

• Second Nature: https://www.secondnature.ai

Rick Koleta (Host)

• LinkedIn: https://www.linkedin.com/in/rickkoleta/

• Newsletter: https://gtmvault.co/

GTM Vault

• LinkedIn: https://www.linkedin.com/company/gtmvault

• YouTube: https://www.youtube.com/@gtmvault?sub_confirmation=1

• Website: https://gtmvault.co/

Previous episodes include

See all previous episodes here.

The GTM Vault Podcast is a breakdown of how high-growth companies design, test, and scale revenue architecture. Visit gtmvault.co for more episodes, the GTM Vault newsletter, and Show Me Your Stack.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/gtm-52.

Same tool. Four different jobs. One of them was retired.

A tool list would file all four under "enrichment" and move on. That is the failure of every GTM stack roundup I have read, including the ones I wrote. They tell you what exists. They cannot tell you what job a tool does inside a working system, which layer that job belongs to, or what has to be built before it.

The Short Version

The Stack Index is every GTM tool operators named on GTM Vault, placed on the layer of revenue architecture it serves. It draws on 13 podcast episodes, all 9 Show Me Your Stack episodes, and 8 essays, and it holds 100 tools today. 64 were described by a named operator running them in a working system. 36 rest on a GTM Vault essay alone, and the two grades are never blended. It opens with an eight-question audit that names the layer where your revenue system is breaking, and it ends with a build order for your company. It is free at pro.gtmvault.co/stack.

Tool Categories Are Not Architecture Layers

Vendors sort themselves by category: enrichment, intent, sequencing, conversation intelligence. Categories describe what a product claims to do. They say nothing about where it sits in the system or what it depends on.

The 8 Layers of a Modern Revenue System describes the decision structure of a revenue system in build order: Identity, Sequencing, Pricing, Functional Coherence, Motion, Distribution, Metrics, and the AI Layer. Each layer reads everything beneath it.

The Stack Index sits underneath that doctrine, not beside it. Every tool is placed by the function it performed in an operator's system, not by the category on its homepage. Clay at Slang AI is Identity work. Claude Code at Oxygen is AI Layer work. Salesforce at Intellistack is the system of record the agents read from and write back to. The placement follows the job.

Underneath the eight layers, tools group into eleven instrumentation layers by the job they do, such as Source, Signal and Orchestration. Each instrumentation layer reports up to exactly one doctrine layer.

How a Tool Gets In

A tool enters one of two ways: a named operator described running it in a working system, or a GTM Vault essay recommended it. The index shows both and never blends them. Placement is not for sale. There is no field in the data model for it, and a vendor gets in one way, a customer describing the product on Show Me Your Stack. Displacements go on the record too: Elliot O’Connor said Clay displaced ZoomInfo, Tim Scheuer said Claude Code displaced Clay, both because someone said so, neither inferred from usage or reviews. The full inclusion rules are on the Method page.

Start With the Layer That Is Breaking

Most readers do not arrive knowing which layer is theirs. So the index opens with an audit: eight questions, one per layer, in build order. Can your team disqualify an account in under a minute, from data, without a call? Was the order you built your GTM in a decision, or the order vendors reached you? Would you bet the forecast?

The answer is a layer, not a score. The audit names the lowest layer that is breaking, because every layer above it reads from it and inherits the break. Fix Metrics before Identity and the dashboard turns green while revenue stays flat. The result shows what operators run in that layer and hands the constraint straight into Build Your Stack.

Run the audit

From the Index to a Build Order

The index answers what operators run. Build Your Stack answers what you should build, and in what order.

It takes four inputs: revenue band, motion, binding constraint, and budget posture. From those it returns the layers in build order for your company, the plays for each one, and the tools operators run there at the depth your access opens.

A $2M to $20M sales-led company whose pipeline does not convert gets a different first layer than a $20M to $100M enterprise company whose forecast is wrong. The tools can overlap. The sequence does not.

Your four answers live in the link, so a build can be bookmarked, sent to whoever owns the number, or emailed to yourself from the page.

Every Operator Gets a Page

Every operator who has described a working system on GTM Vault has a page. Elliot O'Connor's stack shows the three tools he named, placed on the layers they served, with what each one did in his words and the episode beside it. There are 23 operator pages today.

You can compare any two layer by layer. Where they agree is the consensus. Where they differ is the argument. Elliot and Garrett Wolfe share Clay and Sales Navigator and disagree on everything above Identity, which is the more interesting half.

What Each Reader Gets

1. Anyone, with no sign-in: the audit, the full index, every tool, layer and operator page, compare, the method, and the complete build order from Build Your Stack.

2. Free subscribers (updated October 2026): every tool in every layer matched to your budget, with the operator evidence behind each one, plus the Library and each new operator stack by email as its Show Me Your Stack episode lands.

3. Annual Pro members: a printable build order for your Blueprint Session, and the session itself.

Where the Free Version Stops

The index tells you what operators run. It stops at the moment you have to choose. Motion holds 29 tools. A $5M sales-led company on a lean budget needs one of them, and the reason an operator picked one over another is buried in an episode. That is the gap between reading an index and installing a stack, and it is the gap Pro closes.

1. Every tool in every layer, matched to your revenue band, motion and budget, with the operator evidence behind each pick. The whole layer, so the second choice is there when the first does not fit your CRM. Free with your subscription since October 2026.

2. The Library, free with your subscription: every GTM Vault Podcast and Show Me Your Stack episode as a written playbook, with the full transcripts searchable by phrase down to the timestamp. When you remember that someone explained why they left Outreach but not who, this is where you find it in thirty seconds instead of three episodes.

3. A 45-minute Blueprint Session for annual members, where the build order gets locked against your numbers, not a generic company in your band.

Pro is $99 a month or $999 a year, and it is access and implementation: the full GTM Vault MCP and every playbook inside Claude, the Doctrine, the Course and monthly office hours with me. The audit, the full index, Build Your Stack and the Library are free with a subscription, and they will tell you whether you need any of this before you pay for it.

Upgrade to Annual Pro

How It Stays Current

Every Show Me Your Stack episode adds to the index. The operator walks through the system they built, every tool they run gets placed on its layer, they get a page, and the counts change. Show Me Your Stack publishes every two weeks, so the index moves every two weeks. The latest addition is SMYS 9, Michael Bartimer at Clarify, who put six tools on the record, three of them for the first time.

The counts in this post are a snapshot. The index is the current version.

Open The Stack Index

Common Questions

How do I find where my revenue system is breaking?

Run the audit at pro.gtmvault.co/stack/audit. Eight questions, one per layer of revenue architecture, answered as the system behaves today. The result names the lowest layer that is breaking, since every layer above it inherits the break, and shows which tools operators run there.

Can a vendor pay to be placed in The Stack Index?

No. Placement is not for sale, and sponsorship moves nothing into a layer or up a list. There is no field in the data model for paid placement. A vendor is added when a named operator describes running the tool on Show Me Your Stack. A guest's own product is excluded from recommendations and listed separately.

How do I get a recommended GTM stack for my company?

Use Build Your Stack at pro.gtmvault.co/stack/build. Enter your revenue band, sales motion, binding constraint, and budget posture, and it returns the layers in build order with the plays for each. Every subscriber sees every matched tool with the operator evidence behind it, free.

Related Reading

1. The 8 Layers of a Modern Revenue System: the doctrine the index is placed against, and why tool categories are not layers.

2. AI-Native GTM Is a Sequencing Problem: why the empty layer decides what every other layer produces.

3. Your Skills Are Not a Stack: the difference between owning tools and running a system.

4. What Is Revenue Architecture?: the full definition behind the eight layers.

Subscribe

Subscribe now

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

Your CRM knows the deal, the stage, and the contact's title. It does not know which person on your team can walk you into the account, or that the champion who changed jobs last quarter is now a warm door somewhere else. Olivier Roth built a company on that gap. The co-founder and Chief Growth Officer of The Swarm joins GTM Vault for episode 51 to explain why the relationship layer sits alongside the CRM rather than inside it, why it travels to wherever the work happens, and who ends up owning the relationship when it does.

About The Swarm

The Swarm turns a company’s extended network into a data layer its sales team can query. Founded in San Francisco in 2021 by David Connors, Michal Bil, and Olivier Roth, it grew out of Connors’ previous company, Automately.io, which Sequoia acquired, and the tools he then built so Sequoia’s portfolio could tap the firm’s network. The graph now covers 580M+ people and 100M+ company profiles, pipes into HubSpot, Attio, Clay, and any agent via MCP, and in 2026 the company acquired Commsor, the competitor that coined the go-to-network category. The Swarm has raised $8M in total, including a $4M seed led by 500 Global and a round backed by HubSpot Ventures, Motivate Ventures, and TRAC VC.

Watch or listen now across YouTube, Apple Podcasts, and Spotify

Share

Download the transcript

GTM Vault Podcast 51 Transcript: Olivier Roth

98.4KB ∙ PDF file

Download

Download

Episode highlights

(0:00) LinkedIn Is Your Audience, Not Your Network
(2:44) What A CRM Cannot Capture, And The Anti-CRM
(4:07) The Six Edges Of A Relationship Graph
(7:32) Where The Graph Lives: Inside, Beside, Or Under The CRM
(12:40) One Motion: LinkedIn Profile To Claude Prompt To Clay Workflow
(15:06) 500 Million Profiles, Freshness, And The Consent Architecture
(19:05) Potential, Likely, Confirmed: How The Graph Scores A Path
(23:39) The Commsor Acquisition And The Size Of The Category
(26:32) Swarm Send, 40 Percent Of Pipeline, And Three Intros Every Monday
(32:36) Rapid Fire

What you’ll learn:

• Why the CRM is a system of the past, and why the deals that could exist never appear in it

• LinkedIn is your audience, not your network: why a binary connection tells you nothing and most people know five to ten percent of theirs

• The six edges in a relationship graph: work overlaps, education overlaps, investor overlaps, LinkedIn connections, LinkedIn engagement, and email and calendar contact

• Potential, likely, confirmed: the scoring that says how sure the graph is that two people know each other

• Why the relationship layer is a building block that travels, and why the CRM stays the central nervous system anyway

• How a rep uses the graph from a LinkedIn profile, from a Claude prompt, and from a stalled-deals query inside HubSpot

• Freshness is what breaks at scale, and why The Swarm built its own 500-million-profile data layer instead of buying one

• The consent architecture: what is passive, what is user-permissioned, and why every company’s swarm is siloed

• Why orchestration, not data, is the next thing to build, and what three intros every Monday morning looks like in practice

• The test that would prove the bet: thirty percent of pipeline from warm intros, visible in the CRM’s own reports

Key takeaways

1. The CRM records the past. The deals that could exist live somewhere it cannot see.
   A CRM records interactions that already happened, tied to deals that already exist, and that is its job. It holds nothing on the other side: every potential deal reachable through someone attached to the company. The Swarm pools the networks of a company's investors, advisors, partners, employees and best customers, which Olivier calls an anti-CRM, peering forward at what the relationships make possible rather than backward at what closed.

   

2. LinkedIn is your audience, not your network, and a connection alone scores as "potential."
   A LinkedIn connection is binary, no context, and Olivier puts the share of connections people know at five to ten percent. So The Swarm stacks six edges instead: work overlaps, education overlaps, investor overlaps, LinkedIn connections, LinkedIn engagement, and email and calendar contact. Each relationship scores potential, likely, or confirmed: emailed, met and connected is confirmed; a single meeting or a short work overlap is likely; a LinkedIn connection and nothing else is potential.

   

3. The layer is a building block, and the CRM stays the central nervous system.
   Go-to-market engineers build agents on The Swarm's API; sellers use it inside HubSpot, Attio and Clarify, with Salesforce in progress, and in Clay workflows. With the HubSpot MCP a rep can take every deal stalled for ninety days and ask for a champion or investor in the swarm who can unstick it. Olivier still calls the CRM the central nervous system, because that is where revenue is recorded and reported, and the bet is that when every CRM ships a warm intro tab, the tab is built on The Swarm.

4. Freshness is what breaks at scale, so they built the data layer themselves, with the consent lines drawn in advance.
   No existing provider was fresh enough, so The Swarm built its own: roughly 500 million profiles, 100 million companies, job-change tracking, and a live enrichment endpoint that refreshes a profile on demand. Work, education and investor overlaps are computed passively from public history; LinkedIn connections, email and calendar are user-permissioned and visible only to the admins of that company's swarm. Every company's data sits in its own silo.

5. The data took five years. Orchestration is what comes next, and the proof is forty percent of their own pipeline.
   Olivier vibe-coded Swarm Send, which ranks the best-scored intro paths to target accounts and drafts the requests; roughly forty percent of The Swarm's pipeline now comes through intros. The pattern he wants to productize is one a customer's go-to-market engineer already built: three intros dripped to each seller every Monday morning. The test that proves the bet is a report, not a case study: thirty percent of pipeline from warm intros, visible as fields inside the CRM, next to paid ads on the same chart.

The Library

Every episode of this show, and every Show Me Your Stack, now lives as a written playbook in one searchable place. Fifty podcast episodes, eight stack breakdowns, and the tools behind each one indexed across all of them, so you can pull every episode where Clay or Claude Code shows up before you wire it yourself. It is part of Pro. If you are a member, sign in at pro.gtmvault.co with your subscriber email. If you are not, this is the reason to upgrade.

Olivier Roth

• LinkedIn: https://www.linkedin.com/in/olivier-roth/

• The Swarm: https://www.theswarm.com

Rick Koleta (Host)

• LinkedIn: https://www.linkedin.com/in/rickkoleta/

• Newsletter: https://gtmvault.co/

GTM Vault

• LinkedIn: https://www.linkedin.com/company/gtmvault

• YouTube: https://www.youtube.com/@gtmvault

• Website: https://gtmvault.co/

Previous episodes include

See all previous episodes here

The GTM Vault Podcast is a breakdown of how high-growth companies design, test, and scale revenue architecture. Visit gtmvault.co for more episodes, the GTM Vault newsletter, and Show Me Your Stack.

Every tool operators name on GTM Vault is in The Stack Index, placed on the layer of revenue architecture it serves. Build your own stack at pro.gtmvault.co/stack.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/gtm-51.

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

The list was exported, the sequence was loaded, and the reps worked it for three weeks. By the time the last contact was touched, a third of the data was already wrong. That decay rate was tolerable when humans worked lists over weeks, because a rep sees the bounced email and flags it. It is fatal when agents work signals in seconds, because the agent does not know the data is wrong. It acts on it.

The entire contact data industry was built for the tolerant version of that buyer: a person, in an interface, self-serving through a slick UI. Yoni Tserruya spent ten years winning that market. A few months ago he watched SDR and BDR agents go into production at customer accounts, doing certain work better than the humans they sit beside, and concluded the buyer of his data is about to stop being a person.

This is not a data quality story. Quality was always the product. The hard part is that the customer consuming the data is losing the ability to notice when it is wrong, which changes what a data company has to be.

Yoni Tserruya is the co-founder and CEO of Lusha, which he started as a side project in 2016 and bootstrapped for years before scaling it into one of the largest B2B contact data platforms in the market. Ten years in, he is rebuilding it as the layer AI agents query live: a verified provider in Clay’s ecosystem, waterfalls with Scale Stack, extensions inside Claude and ChatGPT, and a decision-makers API built for machine callers. He is explicit about the stakes: the agent is becoming the future persona of the data.

In GTM 50, Yoni breaks down why the buyer of contact data is stopping being a person, what survives of a ten-year-old product when the interface stops mattering, how waterfalls reset vendor economics, what an agent needs from a data vendor that a human never did, the two-layer retrofit forcing a ten-year-old company into the AI era, and how Lusha’s own GTM went headless.

This is not a conversation about data vendors. It is a conversation about which parts of your GTM system have to be true at the moment an agent acts.

Inside this episode

This episode maps what happens to the bottom layer of the GTM stack when the thing consuming it changes species.

Yoni opens with the inflection. It was not a keynote, it was production: a few months ago, early-adopter customers started running SDR and BDR agents live, trusting them with work they used to give reps, and seeing results. The majority of the market is not there, but enough early adopters are that he treats the next one to two years as the window in which agents become the real persona of his data.

We go deep on what breaks when the buyer is a machine. When a human worked the list, wrong data got caught: the rep knew it was wrong and flagged it. Put an agent on bad data and the damage is bigger and the detection is slower, because nothing in the loop knows to be suspicious. His conclusion runs against the commoditization story: inside a waterfall era, accuracy matters more, not less, and customers who need compliant, trusted data still pick their vendors carefully.

We cover the rebuild. Lusha won its first decade on two things, data quality and a self-serve UX simple enough that any user could log in, start free, and buy alone. The second thing is now irrelevant. If customers consume the data through Clay, Claude, or their own agents, they may never see Lusha’s interface again, so the product is being rebuilt as API and MCP based, integrated everywhere, chosen by machines on quality rather than by users on feel. He calls it a different way of thinking about the whole business, and it is still in progress.

We cover waterfall economics from the vendor’s side of the table. Waterfalls are the natural end state, one orchestrator stacking providers where customers used to buy three vendors and manage the mess themselves, and Yoni expects everyone to have one eventually. Lusha’s answer is to be agnostic and be everywhere: Clay, Claude, n8n, Make, Zapier. He is direct about the trade inside someone else’s waterfall: Lusha typically wins on quality and coverage, loses on price, and starts at forty-nine dollars a month, which he frames as quality any company can afford.

We go into agent-to-agent selling. When a buyer agent meets a vendor agent, both arrive having read everything public, so the discovery call dies and the conversation goes straight to pricing, integrations, and the needs that are not on the open web. The spam-to-spam worry gets the same answer: detection improves in parallel with generation, phones already screen callers, and the thing that passes the filter is a relevant reason for the contact. Laser-focused targeting stops being best practice and becomes the only thing that works.

We cover the retrofit, which he is honest about being harder than starting fresh. It runs on two layers, making the product AI-ready and making the organization AI-powered, and both are iterative and never finished. The mechanisms are concrete: every employee gets access to the AI tools they need, all-hands sessions share AI initiatives across divisions, and a team called Builders for Builders ships internal skills other teams adopt. The sharpest move is the constraint: where a team resists adoption, he shrinks the team while holding the workload constant, so AI becomes necessary rather than optional. There is no playbook and no expert to hire, because, as he puts it, eight months ago nobody was talking about Claude eating the world. The asset is a culture where trying and failing is cheap.

We go into how Lusha runs Lusha. Everything dogfoods: lead scoring, enrichment, prioritization, outbound, and churn risk all run on Lusha’s own data. The stack is going headless. The AEs almost never open Salesforce anymore, working instead from a custom dashboard that aggregates Salesforce, Lusha, outreach, and back office data into one view that says who to target and why, with engagement and call transcripts summarized and written back automatically. He expects go-to-market to go headless at more companies for the least glamorous reason available: it is a simpler operation.

We cover the pressure test. Operators are killing six-figure ZoomInfo contracts with Clay-native stacks, and Yoni’s answer is that Lusha was never the six-figure trap: it is usage-based, pay-as-you-go, bottom-up PLG. The position he claims against Apollo, Clay, and ZoomInfo simultaneously is the context layer feeding every agent in the market, including for SMBs. The LLM absorption question gets his most specific answer: a model can find five or ten contacts on the open web, it cannot return five thousand sorted, trusted results, because that requires a database designed for GTM. Claude and ChatGPT extensions already route those queries to Lusha. Compliance, he argues, is both moat and tax, and more moat, because very few companies can serve data compliantly at all.

We close on 2028 and the rapid-fire section. Reps today spend twenty to thirty percent of their time with customers; two years out he expects fifty to sixty, with agents absorbing the research, sequencing, and admin, quotas rising as manual work falls. Rapid fire lands API adoption as the underrated metric, transcripts and call recordings as the most overrated capability in revenue AI, company data as the next commodity, start small and iterate fast as the habit, and one sentence completed without hesitation: in three years the static lead list is irrelevant.

Watch or listen now across YouTube, Apple Podcasts, and Spotify

Discussed in this episode

(0:00) Cold Open: A Third of Your List Is Already Wrong
(2:58) The Moment the Buyer Stops Being a Person
(4:51) What Survives When the Interface Stops Mattering
(6:11) Waterfall Economics From the Vendor Side
(9:31) Agent to Agent Selling, Step by Step
(12:44) Spam to Spam, and the Relevance Filter
(14:24) The Two-Layer Retrofit of a Ten-Year-Old Company
(20:38) How Lusha Runs Lusha: Going Headless
(23:02) The Pressure Test: Apollo, Clay, ZoomInfo, and the LLMs
(26:10) The 2028 Revenue Team and Rapid Fire

Key takeaways

1. The buyer of GTM data is stopping being a person, and that is an architecture event, not a marketing one. The moment agents became the entity consuming contact data in production, the product requirements changed: API and MCP replace the interface, machine trust replaces user feel, and the vendor gets chosen by whatever the agent’s orchestrator ranks highest on quality. Everything downstream of that sentence is product strategy, which is why Yoni calls this the biggest evolution in Lusha’s history rather than a feature release.

2. Bad data compounds faster through a machine than through a rep. A human catches the wrong title and the dead number, flags it, and the damage stops. An agent executes on the bad record at full speed and the failure surfaces later and larger, because nothing in the loop knows to be suspicious. This inverts the commoditization story: as agents take over execution, accuracy gets more valuable, not less, and the waterfall makes the quality ranking explicit on every call.

3. Half of what won the last decade is now worthless, and knowing which half is the game. Lusha’s first decade ran on data quality plus a slick self-serve UX. The UX half is dead weight in a world where the customer may never open the interface. The discipline worth copying is the willingness to name which historic strength no longer matters and rebuild around the one that does, while the business still runs on both.

   

4. Everyone will have a waterfall, so position inside all of them. Fighting the orchestration layer is a losing move; being the highest-quality provider inside every orchestrator is a durable one. That means Clay, Claude, n8n, Make, and Zapier equally, winning on quality and coverage, losing on price, and saying both halves out loud. The honest trade is the position.

5. The retrofit is a forcing function, not a memo. Two layers, product and operations, both iterative and never finished. The mechanisms that make it real: universal tool access, all-hands AI show-and-tell across divisions, a Builders for Builders team shipping internal skills, and the constraint move of shrinking resistant teams while holding workload constant. Culture that makes failing cheap substitutes for the playbook that does not exist.

6. GTM is going headless, and the reason is boring: it is simpler. Lusha’s AEs stopped opening Salesforce because one custom view aggregating Salesforce, Lusha, outreach, and back office data answers the only question that matters, who to touch next and why, with context written back automatically. The suite interfaces become databases underneath an operator surface. Expect this at any company where reps cross more than three tools to answer that question.

Frameworks from the episode

1. The Two-Layer Retrofit. Yoni’s structure for moving an existing company into the AI era. Layer one is the product: make it AI-ready, API and MCP based, consumable by agents, or the market routes around you. Layer two is the operation: run the company itself on AI, or you carry too many humans to stay efficient. Both layers are iterative and neither is ever done. The output is a company whose product can be bought by machines and whose org can be run lean enough to keep shipping it.

2. Builders for Builders. The internal mechanism that makes layer two real: a dedicated team that builds skills and automations other teams adopt, paired with all-hands sessions where divisions demo their AI initiatives to each other. The output is horizontal adoption without a mandate, because every team is borrowing working examples instead of reading policy.

3. Headless GTM. The end state Lusha’s own stack is reaching: the CRM and the tools stay, but as data sources underneath a custom operator view that aggregates them into one prioritized surface, with context inserted back automatically. The output is reps who work one screen, and an org whose interface layer is designed around its own motion instead of its vendors’ products.

What to do this week

• Measure your data decay against your sequence length. Pull the last list your team worked and check what share had decayed by the final touch. That number decides whether your data layer is agent-ready or a liability you are about to automate on top of.

• Ask every data vendor for their machine interface. If the answer is an export button rather than an API or an MCP, you are buying static lists in a market whose static list is, on Yoni’s timeline, three years from irrelevant.

• Count the interfaces your reps cross to answer “who do I call next.” If it is more than three, pilot one aggregated view for the top workflow and watch whether your reps stop opening the CRM voluntarily.

• Run one ranked brainstorm. Yoni’s growth mechanism is a session where ideas arrive without pre-approval, get ranked by cost and impact, and the top few get run without knowing whether they will work. One session, this week, with the explicit rule that trying and failing is acceptable.

Why this matters

Every GTM team is wiring agents into a stack whose bottom layer was built for a different buyer. The lists, the forms, the interfaces, and the refresh cadences all assume a human is in the loop to notice what is wrong, and the agents being deployed on top of them assume nothing at all.

The uncomfortable part of Yoni’s argument is that it prices the mistake. Bad data used to cost a wasted dial. Through an agent it costs compounding, undetected error at execution speed, which is why the quality of what your automation consumes is becoming the ceiling on how much automation you can afford.

The vendor-side lesson generalizes inward. Lusha is deleting the half of its product that stopped mattering while the business still runs on it, and most revenue teams have not run that exercise on their own stack: which historic strength is now dead weight, and which quiet layer is now the whole game.

The orgs that act on this will audit the data layer before they scale the agent layer, and buy on machine interfaces rather than dashboards. The ones that wait will find out about decay the way agents find out about everything: not at all, until the pipeline shows it. This is GTM Vault.

Send this one to whoever owns your data vendors and whoever is building your first agent, because they are about to be the same problem.

Connect

Follow Yoni Tserruya // Lusha

Follow Rick Koleta // GTM Vault

Thanks for listening. See you in the next episode.

P.S. Annual paid subscribers get a Private GTM Blueprint Session.

Every tool operators name on GTM Vault is in The Stack Index, placed on the layer of revenue architecture it serves. Build your own stack at pro.gtmvault.co/stack.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/gtm-50.

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

Most sales teams still pay six figures for a contact database the reps do not trust. The data is stale, the exports are manual, the CRM update is a separate step, and somewhere between the research, the enrichment, and the send, hours of rep time disappear per account. The fashionable fix is to move the rep into a chat window and call it AI. This episode is a live argument against that: the rep stays in the browser, and the intelligence comes to them.

In episode eight of Show Me Your Stack, Elliot O’Connor runs the argument live. He is the founder and CEO of Frontier (formerly Exportly), which has raised thirteen million dollars from investors including operators at Cursor, EF, Pave, and Reddit, and counts Cursor and an 800-plus-rep Zoom deployment among its customers. In this episode he screen-shares the live product: a Chrome extension that puts Clay’s data and MCP-driven workflows one click away from the rep, on the pages where selling happens.

The stack on screen is a Chrome extension, Clay tables, Salesforce MCP, Clay MCP, and Sales Navigator. The tool list is not the story. The story is where the intelligence lives: in the browser, on the page the rep already has open, behind buttons the rep never has to prompt.

Watch now: Elliot O’Connor - Founder & CEO of Frontier

The full episode is on YouTube. Subscribe to the channel for the clips and cuts that never make the write-up.

The Wiring: Clay’s Data Under the Rep’s Surface

The build starts where reps start, on LinkedIn. A year ago Frontier was a deliberately simple extension: move contacts from LinkedIn and company sites, enrich them with contact data, push them into the CRM and the sales engagement platform. The difference was what sat underneath. Every email and phone number came from Clay tables, which meant the rep was pulling from the widest array of data vendors in the market without knowing Clay existed. Clay’s superpowers belonged to RevOps and marketing ops. The extension’s job was to extend them to the average rep, in the interface reps already trust.

The Gate: Why There Is No Install Button

There is no self-serve install, on purpose. A seller with one or two reps does not need the flexibility Frontier sells, and a self-serve user hits a wall the moment value depends on Clay-side build. The buyer is usually RevOps, someone who already owns and loves Clay, at a company where the ops team lives in Clay world while the reps live in a ZoomInfo world. Deployment closes that gap with generated templates, Frontier’s API can create Clay tables inside the customer’s workspace, plus a forward-deployed GTM engineer on every account to tune them. Elliot’s larger claim rides on this: sales used to be about labor, it is increasingly about orchestration and design, and the sales leader and the RevOps leader now set strategy as equals.

The Harness: Chat for Intent, Browser for State

The demo’s sharpest moment is an argument about interfaces. The industry’s default answer is to move selling into a chat window. Elliot’s counter: chat is great for expressing intent, but for managing state, for managing large lists of people, browser interfaces are still far better. A rep juggling fifty to five hundred accounts is managing state, and a chat thread loses it with every scroll. So Frontier built its own AI harness inside the browser: it pulls records from Salesforce through the Salesforce MCP, queries Clay’s MCP for who you sell to, and pushes the rep into Sales Navigator with a generated search no human would have assembled. The rep bounces between chat mode and browser mode without leaving the page.

The Buttons: Prompts the Rep Never Writes

Every workflow in the extension is a button, and every button is a prompt the rep never has to write. Frontier’s position is that prompting is a waste of time and tokens for salespeople. One click returns the buyer committee for the account, tuned to the ICP, with a Clay table running underneath. Another runs a company analysis before a meeting: Clay agents crunch the account and return partnerships, hiring acceleration in go-to-market, and the Chicago office that opened four weeks ago. RevOps builds the workflow once, and every rep at the company gets it as a click, pages of them in a single interface.

The Economics: Seats on Top of Credits

Pricing is old-fashioned SaaS seats, with usage-based AI credits arriving for the MCP features that cost inference. The dependency to see clearly: most actions run on Clay tables that consume the customer’s Clay credits, so the value ceiling is set by what RevOps has built in the workspace. Asked directly whether Frontier is a wrapper on Clay, Elliot takes the question head on: it started as one, and what it became is an AI harness, the same relationship Cursor has to the model providers. Customers and investors can decide how thick the wrapper is. The business he is in is making the best rep surface possible on top of it.

Where This Goes: More Products, Same Surface

Elliot’s forward claim is that the Chrome extension undersells the vision. Frontier’s bet is that reps still want to prospect in the browser, that GTM builders have forgotten and underinvested in it, and that the extension is one product of several they will release to bring AI to the pages where reps work, on Salesforce, on LinkedIn, wherever the buyer is.

The Pattern

Every SMYS episode is one operator showing where the work happens, and this one relocates the question. The industry is racing to move reps into chat windows, and Frontier is betting the opposite: the browser is the gateway to the buyer, and the winning move is bringing intelligence to the rep’s surface rather than moving the rep to the intelligence’s surface.

What it changes is who ships capability. RevOps stops being the team that runs enrichment requests and becomes the team that builds buttons. The gap between what ops can do and what reps can access, the gap ZoomInfo-plus-Clay companies live inside, closes to one click.

The rule: ship capability as buttons, not trainings.

Five Things Worth Stealing

1. Chat expresses intent, the browser manages state. A rep working hundreds of accounts is managing lists, stages, and follow-ups, and a chat thread forgets all of it. Put asking in chat and working in interfaces with persistent state.

2. Every button is a prompt the rep never writes. Prompting is overhead for salespeople. RevOps encodes the workflow once, and the whole floor gets it as a click with a Clay table underneath.

3. The gate is the onboarding, not the demo. No self-serve, because value depends on Clay-side build. Generated templates plus a forward-deployed GTM engineer per account is the distribution model.

4. RevOps is the buyer now. The extension sells to the team that owns Clay, and rep tooling decisions increasingly run through revenue operations, negotiated as equals with sales leadership.

5. The wrapper question has a harness answer. Frontier rides on Clay’s credits and data the way Cursor rides on model providers. The moat is the surface and the rep experience, and the market prices how thick that is.

Timestamps

(0:00) The hours that disappear per account
(2:05) Ground zero: the extension on LinkedIn
(3:52) Why there is no self-serve install
(6:30) RevOps as the buyer of rep tooling
(10:52) The AI harness: prospecting through Salesforce MCP
(13:19) Chat for intent, browser for state
(14:30) The buyer committee and company dossier buttons
(19:27) Templates and forward-deployed GTM engineers
(20:56) Seats on top of credits
(22:02) Wrapper or harness, the Cursor analogy

Links

Follow Rick on LinkedIn - https://www.linkedin.com/in/rickkoleta/

Follow Elliot on LinkedIn - https://www.linkedin.com/in/elliotoco/

Try Frontier - https://www.befrontier.com

Previous episodes include

• SMYS 7 | Your Reps Should Never Meet Your Agents

• SMYS 6 | From Five Hours in Clay to Forty Minutes in a Terminal: Outbound Run by Claude Code

• SMYS 5 | From Account List to Monitoring Universe: Building the Prioritization Layer

If this was useful, hit like and restack at the top of the post.

Show Me Your Stack is a GTM Vault series. Each episode features one operator walking through the system behind their outbound, their prioritization, or their pipeline motion. No slides. Just the stack.

Every tool operators name on GTM Vault is in The Stack Index, placed on the layer of revenue architecture it serves. Build your own stack at pro.gtmvault.co/stack.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/smys-08.

The short version

Search the role and you get two answers. Gong’s help centre defines a Revenue Architect as your strategic partner for getting value from Gong, and states plainly that it is the role you previously knew as your Customer Success Manager. A RevOps agency defines it as a director-level consultant who leads client engagements and hands over a phased roadmap. Both are real jobs. Neither can change your ICP, your pricing, or your motion, which are the decisions the title refers to. A revenue architect is defined by authority over the decisions that every other decision inherits. Advice about those decisions is a different job, and the gap between the two is why companies buy revenue architecture and do not get it.

The Two Definitions That Rank

Take them at their word, because both are explicit.

Gong’s help centre, published April 2026 and updated in June, says a Revenue Architect is “your primary strategic partner for getting business value from Gong,” and then adds the line that settles it: “You might previously have known this role as your Customer Success Manager (CSM).” The same page lists what the role does not handle: implementation, technical troubleshooting, pricing, contracts, and commercial negotiations. It is an adoption role, working on the vendor’s side of the relationship, and it is a good one. It is not architecture.

NewEdge Growth, a Kansas City RevOps agency, posts a Revenue Architect job that reads very differently. Director level, eight or more years, executive point of contact, leads internal delivery teams, defines the end-to-end revenue architecture including roles, processes, handoffs, and technology. That is a serious role and much closer to the discipline. But read the verbs. Evaluate, define, document, develop, communicate, advise. The output is a roadmap with Now, Near, and Far milestones, delivered to a client who then decides whether to follow it.

What the two share is the thing nobody says out loud. Both sit outside the company whose revenue system is being architected. One works for the vendor. One works for the agency. Neither can change the ICP, reprice the product, or redesign the motion, because those decisions belong to people who are not them.

That is not a criticism of either. It is a description of where the term currently lives, and it explains a pattern operators keep reporting: a company engages someone to architect its revenue system, receives a competent document, and eighteen months later has the same architecture it started with.

The Test Is Authority, Not Advice

A revenue architect is whoever can change the decisions that other decisions inherit.

That is the same boundary as the one between architecture and RevOps, applied to a person instead of a discipline. Architecture decisions are expensive to reverse and are inherited by everything below them. If a person can recommend a change to the ICP but cannot make it, they are advising the architect. They are not the architect.

The test is one question, asked about a specific human: when this person concludes that the pricing model is wrong, what happens next? If the answer is that the pricing changes, they hold the role. If the answer is that a deck gets presented and a decision gets scheduled, someone else holds it, and the useful next question is who.

Most companies cannot answer that question, which is the finding rather than a failure of the exercise.

What the Role Decides

Mapped onto the eight layers of a revenue system, the architect owns five and shares three.

Identity, who the system is for, defined tightly enough to disqualify in real time. Sequencing, what gets built and scaled in what order. Pricing, which is a structural decision rather than a number, because it reshapes qualification, motion, and margin at once. Functional coherence, meaning what each function is measured on and whether those measures compose. Motion, how the company sells and whether the playbook matches the stage it is in now.

Distribution, metrics, and the AI layer are shared. The architect decides which channels the company competes in, which number governs the forecast, and whether agents run inside the system of record. RevOps operates all three.

Notice what is absent from that list. No tooling decisions. No dashboard builds. No CRM administration. A revenue architect who is spending their week in the CRM has either been given the wrong job or taken it.

Not the GTM Engineer

The two roles get conflated constantly, and the distinction is clean.

The architect decides what the system should be and in what order it gets built. The GTM engineer builds and runs it: the workflows, the pipelines, the agents, the integrations. One is a design function. The other is an engineering function. Conflating them produces systems that are beautifully built to the wrong specification, which is the most expensive failure available because it looks like progress the whole way through.

The interesting evidence here comes from the agency job posting, which describes its Revenue Architect leading internal teams of Solutions Architects, Technical Solutions Architects, Developers, and GTM Engineers. Even the definition that treats the role as consulting puts the architect above the engineer in the order of operations. The disagreement in the market is about where the role sits relative to the company, not about where it sits relative to engineering.

Both roles are real and a company at scale needs both. A GTM engineer without an architect builds whatever was asked for. An architect without a GTM engineer produces documents.

Who Holds It at Each Stage

At seed, the founder is the revenue architect whether they accept the title or not. Every early decision about ICP, pricing, and motion is an architectural decision made under a different name, usually while doing four other jobs. This is fine, and formalising it early is overhead.

By Series B it needs to be a designed responsibility held by a named person, because the system has grown past what any single function can see. Marketing sees the top, sales sees the middle, CS sees the renewal, finance sees the model, and the interactions between those layers are visible to nobody. That is the specific condition the role exists to fix.

The failure mode in between is not that the wrong person holds it. It is that nobody does, and the decisions get made anyway, one at a time, by whoever owns the nearest function. Pricing gets set by whoever built the pricing page. The ICP drifts by accumulation as sales chases what closes. The motion changes because a new VP brought a playbook from their last company. Every one of those is an architecture decision made without an architect, and the result is a system nobody designed and nobody can explain.

Where This Framing Breaks

Below product-market fit the role does not apply. Architecture compounds a working motion; it cannot create one. A pre-PMF company needs a product people want, and anyone doing revenue architecture at that stage is building elegant systems for selling something nobody buys.

Authority is rarely total, and the test has to survive that. Almost nobody can unilaterally reprice a product. The realistic version of the test is not “can this person act alone” but “is this person in the room, with standing, when the decision is made.” A revenue architect who has to request a meeting to discuss pricing does not hold the layer.

The consultants are not doing nothing. An external architect who works with an executive who does hold the authority is a functioning arrangement, and often the only way a company gets the work done at all. The claim is narrower than it sounds: the consultant supplies the design, the executive supplies the authority, and the arrangement fails when everyone assumes the other party had both.

What This Decides

If you are hiring for this, the job description is a list of decisions, not a list of tools. If you are evaluating someone who calls themselves one, ask what they changed rather than what they recommended.

And if you are trying to work out who holds it at your company right now, ask who could change the ICP by the end of the quarter. The name that comes back, or the silence that comes back, is your answer.

Common questions

What is a revenue architect?

The person with authority over the decisions that every other revenue decision inherits: identity, sequencing, pricing, functional coherence, and motion. The test is not job title or seniority, it is what happens when they conclude a layer is wrong. If the layer changes, they hold the role. If a recommendation gets scheduled for discussion, someone else does.

What is the difference between a revenue architect and a GTM engineer?

The architect decides what the system should be and in what order it gets built. The GTM engineer builds and runs it: workflows, pipelines, agents, integrations. Design function against engineering function. A company at scale needs both, and conflating them produces systems built precisely to the wrong specification.

Is a revenue architect the same as a Customer Success Manager?

At Gong, yes, by their own definition. Their help centre states that the Revenue Architect is the role customers previously knew as their CSM, and that it does not handle implementation, technical work, or commercial terms. That is a vendor adoption role using the title. It is not the same thing as the person inside your company who owns architectural decisions.

Do you need to hire a revenue architect?

Usually not as a new headcount. At seed the founder already holds the role. By Series B it needs to be a named responsibility, which is more often an assignment to an existing executive than a hire. The question to answer first is who holds it today, because most companies find the honest answer is nobody, and that is a cheaper problem to fix than a hiring problem.

Can a consultant be your revenue architect?

A consultant can supply the design. They cannot supply the authority, because they do not hold the decisions. The arrangement works when an internal executive who does hold them is accountable for the outcome, and it fails when both sides assume the other had both the design and the power to enact it.

Who owns revenue architecture in a company?

Whoever can change ICP, pricing, and motion as a connected set. At early stage that is the founder or CEO. Past scale it is usually a CRO or a designated revenue architect. It is rarely the RevOps leader, which is why handing architectural defects to RevOps does not resolve them. If nobody can be named, that is the finding.

Related reading

What Is Revenue Architecture?
The discipline this role is named for, and the eight layers it decides across.

Revenue Architecture vs Revenue Operations
The same authority boundary drawn between two functions rather than around one person.

AI-Native GTM Is a Sequencing Problem
What happens to the build order when nobody owns the sequencing layer.

The Revenue Architecture Map
The layers as a diagnostic surface, with the reading order for each one.

The Stack Index Glossary
The role and the GTM engineer defined side by side, with the eight layers the role decides across.

The short version

Every page answering this question gives the same answer: revenue architecture is the design, RevOps is the execution, architecture is broader, RevOps sits inside it. That is correct and it decides nothing, because it gives an operator no way to classify the problem in front of them. The usable boundary is reversibility. Architecture decisions are the ones that are expensive to reverse and that every other decision inherits: who the customer is, how the product is priced, what the motion is, what gets built first. RevOps decisions are the ones you can change next quarter without redesigning anything above them. The practical consequence is a diagnostic: when a RevOps team is busy and revenue is not getting more predictable, the defect is almost always sitting on the architecture side of that line, where RevOps has no authority to fix it.

The Answer Everyone Gives

Search the comparison and the pages agree with each other almost word for word.

Revenue operations manages how revenue processes run. Revenue architecture designs how the revenue system is built. RevOps is operational, architecture is structural. RevOps improves execution, architecture defines the system that execution depends on. RevOps is one layer inside a larger model. You need both.

None of that is wrong. All of it is a hierarchy claim: architecture is the bigger box, RevOps is a smaller box inside it. A hierarchy claim tells you how to draw the diagram. It does not tell you which box your problem is in, which is the only reason anyone searches this comparison in the first place.

The tell is in who publishes these pages. Ca Design’s version lists five layers, of which revenue operations is one, and those five layers map one to one onto the five services the agency sells: demand generation, conversion, CRM infrastructure, RevOps, and automation. The page is accurate about the hierarchy and it is also a menu. When the boundary between two disciplines is drawn by someone who bills for both, the boundary tends to land wherever the engagement is largest.

So the comparison needs a test that does not depend on who is answering.

The Test Is Reversibility

An architecture decision is one that is expensive to reverse and that other decisions inherit. A RevOps decision is one you can change next quarter without redesigning anything above it.

Run it on real examples.

Changing your ICP is an architecture decision. Every qualification rule, every piece of messaging, every territory, every comp plan, and every dashboard downstream of it encodes the old definition. Reversing it means rebuilding all of them. Changing your lead scoring model is a RevOps decision. It is a rule set. You can rewrite it on a Tuesday and be back where you started by Friday if it is wrong.

Moving from seat-based to consumption pricing is an architecture decision. It reshapes qualification, changes what a good customer looks like, breaks the forecast model, and eventually rearranges who reports to whom. Changing the renewal reminder cadence is a RevOps decision.

Deciding that the company sells through a product-led motion with a sales assist is an architecture decision. Deciding which fields are required at opportunity creation is a RevOps decision.

The line is not about importance. RevOps decisions can be urgent, expensive, and highly visible. The line is about how many other decisions are downstream, because that determines the cost of being wrong and, more usefully, who has the authority to change it.

What Each One Owns

Mapped onto the eight layers of a revenue system, the split is clean and it is not a fifty-fifty split.

Identity, sequencing, pricing, functional coherence, and motion are architecture. They are decisions about what the system is. They are made once, revisited rarely, and inherited by everything above them. They are also, with the exception of sequencing, decisions no RevOps leader is typically authorized to make alone, because they belong to the founder, the CRO, or the pricing committee.

Distribution and metrics are shared, which is where most of the confusion lives. Choosing which channels the company competes in is architecture. Instrumenting those channels and reporting on them is RevOps. Deciding that pipeline coverage is the number that governs the forecast is architecture. Producing it accurately every week is RevOps.

The AI layer is shared in the same way, and it is the newest source of the confusion. Deciding that agents will run inside the system of record rather than as standalone tools is architecture. Configuring, monitoring, and maintaining them is RevOps.

RevOps owns the operation of every layer. Architecture owns the definition of five of them and half of three more.

The Failure Mode

The reason this comparison matters is not taxonomy. It is that the most common expensive mistake in a revenue org is assigning an architecture defect to the RevOps team.

The pattern is consistent. Pipeline is not converting. The CRO asks RevOps to fix conversion. RevOps does what RevOps can do: tightens the scoring model, rebuilds the stage definitions, cleans the data, adds a qualification field, ships a better dashboard. Every one of those is competent work. Conversion improves for a quarter and then returns to where it was, because the defect was in the ICP, and no scoring model can be tighter than the definition it scores against.

From the outside this looks like a RevOps performance problem. It is a scoping error. The team was handed a problem from the layer above the one it has authority over, and the only tools available to it operate below the defect.

This is what the phrase “our RevOps team is busy and revenue is not more predictable” almost always means. Busy is the symptom of working hard at the wrong layer.

The diagnostic that comes out of it is short. Before assigning a revenue problem, ask whether the fix would require changing a decision that other decisions inherit. If yes, it is architecture, and it needs whoever owns that decision in the room. If no, it is RevOps, and RevOps can own it end to end.

The Boundary Moves, and 2026 Is Moving It

The split above is not permanent, and there is now outside evidence of it shifting in a specific direction.

ICONIQ’s 2026 study of GTM org structure, drawing on more than 150 B2B software GTM leaders, found that under consumption and outcome-based pricing it becomes relatively common for RevOps to report into Finance rather than Sales, because revenue is no longer locked in at signature and forecasting gets materially harder. In the same conditions, data and reporting swells to roughly 30% of RevOps time.

Read that through the reversibility test and it is a clean demonstration. Nobody set out to reorganize RevOps. A pricing decision changed, which is architecture, and the reporting line and the time allocation of an entire function reorganized themselves downstream of it. RevOps did not choose either outcome. It inherited both.

That is what “architecture decisions are inherited” means in practice, and it is the strongest available argument that the boundary is real rather than a consultant’s diagram.

Two caveats worth stating, because the pages competing on this query do not state theirs. ICONIQ is an investor publishing on a portfolio-adjacent dataset, and the respondent set is self-selected. The org-structure findings are the durable part; treat the performance comparisons in the same report as correlational.

Where This Framing Breaks

In small companies the two roles are one person. Below roughly Series A the same operator is making the ICP call and building the dashboard. The boundary is still real, because the decisions still have different reversibility costs, but the org chart implication disappears and insisting on the distinction is overhead.

Sequencing is contested, and reasonably so. It is listed above as architecture, and a reasonable person could put it on the RevOps side, since the person who knows what can be built next quarter is usually the person operating the system. The defensible version is that sequencing is an architecture decision that requires RevOps input to make well, and treating it as either one alone produces a bad answer.

The test fails on decisions that are cheap to reverse and still inherited. Field naming conventions are a small example: easy to change, and everything downstream references them. The reversibility test handles most cases and it is not a law. Where it gives an ambiguous answer, fall back to asking how many other decisions would have to change with it.

What This Decides

The next time revenue is not compounding, the question is not whether to invest in RevOps. It is whether the defect sits above the line where RevOps has authority.

If it does, more RevOps capacity produces more competent work at the wrong layer, and the improvement decays on schedule.

Common questions

What is the difference between revenue architecture and revenue operations?

Revenue architecture designs the revenue system and its build order. RevOps operates the system that architecture defined. The usable test is reversibility: architecture decisions are expensive to reverse and are inherited by every decision below them, like ICP, pricing, and motion. RevOps decisions can be changed next quarter without redesigning anything above them, like scoring rules, stage definitions, and reporting.

Is RevOps part of revenue architecture?

Yes, and stating only that is the reason most answers to this question are unhelpful. RevOps is one layer of the architecture and it also operates all the others. The useful question is not whether one contains the other but which decisions each is authorized to change, because that determines who can fix a given problem.

Do you need a revenue architect if you already have RevOps?

Below roughly Series A, no: the same person makes both kinds of decision and the distinction is organizational overhead. Past that point the question is whether anyone is authorized to change ICP, pricing, and motion as a connected set. If those decisions are being made separately by different owners, RevOps will keep inheriting an incoherent system and being measured on the result.

Why is our RevOps team busy without making revenue more predictable?

Usually because the defect sits above the layer RevOps has authority over. If conversion is broken because the ICP is loose, every fix available to RevOps operates below the defect: tighter scoring against a vague definition, cleaner data about the wrong accounts. The work is competent, the improvement decays within a quarter, and it reads from the outside as a performance problem rather than a scoping error.

Who owns revenue architecture in a company?

Whoever can change ICP, pricing, and motion together. In practice that is the founder or CEO at early stage, and a CRO or a dedicated revenue architect past scale. It is rarely the RevOps leader, which is precisely why handing architecture defects to RevOps does not work. If nobody can name the owner, that is the finding.

Is revenue architecture just a rebrand of RevOps?

No, though the volume of agency content on this query makes the suspicion reasonable. The distinction is testable rather than positional: the two categories of decision have measurably different reversal costs and different authority requirements. A rebrand would not produce a different answer to “who has to be in the room to change this.”

Related reading

What Is Revenue Architecture?
The full definition and the eight layers this comparison maps onto.

AI-Native GTM Is a Sequencing Problem
What happens when the build order is treated as an operational choice rather than an architectural one.

GTM Vault 2: The Evolution of RevOps
How the RevOps function got to its current scope, and what it absorbed on the way.

The Revenue Architecture Map
The layers as a diagnostic surface, with the reading order for each one.

What Is a Revenue Architect?
The role the layers imply, and the test that separates holding it from advising on it.

The Stack Index Glossary
Both terms defined in one sentence each, alongside the eight layers and the tools operators run on every layer.

The short version

Published revenue architecture models range from three layers to six, and none of them agrees with another. They disagree because they are counting different things: maturity phases, tool categories, service lines, pipeline stages. A revenue system decomposes into eight layers (identity, sequencing, pricing, functional coherence, motion, distribution, metrics, and the AI layer), and the number is the least interesting part of the model. The property that matters is that the layers are a build order with dependencies. Each layer reads the state of every layer beneath it, which is why a defect low in the stack surfaces as noise everywhere above it, and why fixing the layer where the symptom appears never holds.

Five Models, No Agreement

Search for the layers of a revenue system and you get a number. The number is different every time.

Revenue Architects publishes a three-layer method. Mike Allton’s D.E.A.L. framework has four: Data, Execution, Augmentation, Leadership. PILLAR GTM publishes a four-layer Revenue Operating System: Signal Infrastructure, Scoring Engine, Decision Engine, Operating Cadences. Ca Design has five: Demand, Conversion, CRM Infrastructure, Revenue Operations, Automation and Intelligence. Revenue Engineered has five with a sixth proposed. Step outside revenue architecture into RevOps tooling guides and the decompositions multiply again, into four-layer stacks, six-zone maps, and seven-category checklists.

Five models, a range from three to six, and no overlap in the terms. Nobody on the first page of results acknowledges that the disagreement exists.

The disagreement is not a disagreement about revenue systems. It is a disagreement about what a layer is. The AI Hat is counting organizational maturity phases. Revenue Engineered is counting tool categories in an outbound stack, which is why its layers have names like CRM. PILLAR is counting stages in a data pipeline: signal comes in, gets scored, produces a decision, gets reviewed on a cadence. Ca Design’s five layers map one to one onto the five services a HubSpot agency sells, which is the tell that recurs across the category. When the layer count matches the service catalog, the model is a price list with a diagram on it.

PILLAR is the useful case here, because it is the strongest of them and it demonstrates the problem inside a single publisher. Its canonical thesis is four layers. Its own Revenue Architecture Framework, same author, same library, is a five-pillar diagnostic: Strategy, People, Process, Systems, Metrics. Two decompositions, no reconciliation offered on either page. That is not carelessness. It is what happens when the layers are chosen to fit the argument being made rather than derived from the system being described.

So the count is the wrong argument to have. Eight is not more rigorous than four. The question worth answering is what the layers are ordered by, and whether the order is load-bearing.

What a Layer Is

A layer governs a class of decisions and reads the state of every layer beneath it.

Both halves of that do work. The first half is why the count comes out where it does: identity and pricing are different layers because they answer different questions and fail differently, not because a consultancy sells two services. The second half is the part no competing model commits to, and it is the part that makes the model falsifiable.

Reading the state of the layers beneath means a layer inherits their condition whether or not anyone intended it to. Qualification reads identity. If identity is defined loosely, qualification cannot be tight, no matter how the scoring model is built, because there is nothing precise for it to be tight against. Metrics read motion. If the motion changed and the dashboard did not, the numbers keep reporting on a system that no longer exists. None of this requires a mistake by the team operating the upper layer. The inheritance is structural.

This is where the model separates from PILLAR’s, and the distinction is worth stating plainly because both models are defensible. PILLAR’s four layers order a data pipeline running inside a business that already sells something: a signal arrives, it gets scored, a decision comes out, a cadence reviews it. Everything upstream of that pipeline is assumed. Someone already decided who the customer is, how the product is priced, and what the motion is. Those decisions are exactly the region the eight layers start in. PILLAR orders the pipeline that runs a motion. The eight layers order the decisions that create the motion.

Both can be right about dependency and be about different things. A pipeline model is not a rival to a decision model, and an essay that pretends otherwise is doing the same thing the category already does too much of.

The Eight Layers in Build Order

Each layer below carries its governing question, its failure signature, and what it reads from the layers underneath. The build order runs bottom-up.

Layer 1. Identity. Who the system is for, defined tangibly enough to disqualify in real time. It reads nothing, which is why it comes first, and everything downstream inherits it. The failure signature is a pipeline that fills and does not convert, because the filter admits accounts the product was never built for. Teams misread this as a conversion problem and hire closers.

Layer 2. Sequencing. What gets built and scaled in what order. It reads identity, because what you scale first depends on who you are scaling to. The failure signature is a company that installed every tool at once and cannot say which one is producing anything. This is the layer most teams skip entirely, which is why it is the one this model keeps returning to.

Layer 3. Pricing. Not a number. A structural decision that reshapes qualification, motion, and margin at the same time. It reads identity and sequencing. The failure signature is a motion that fights the price: enterprise pricing on a self-serve motion, or usage pricing with a sales team compensated on contract value. Pricing changes propagate upward harder than any other layer, which is the mechanism the ICONIQ data below makes visible.

Layer 4. Functional coherence. Whether the functions optimize the system or their own dashboards. It reads pricing, because compensation and targets follow the pricing model. The failure signature is the familiar one: marketing hits MQL targets, sales hits meeting targets, and pipeline is flat, because every function is winning its own game.

Layer 5. Motion. How the company sells, and whether the playbook matches the stage it is in now rather than the stage it was written for. It reads everything below. The failure signature is a playbook that worked at the last stage and is quietly failing at this one, usually blamed on execution.

Layer 6. Distribution. Whether channels compose into a system or accumulate into a pile. It reads motion. The failure signature is six to eight channels, none of which can be removed because nobody can say what any of them contributes.

Layer 7. Metrics. Whether the numbers compound understanding or conceal decay. It reads all six layers beneath it, which is why it is the most common place to misdiagnose. A metric that has aged out of structural relevance keeps reporting confidently. Nobody retires it.

Layer 8. The AI layer. Last on purpose. Agents installed on top of the seven layers below inherit whatever state those layers are in. The failure signature is the most expensive one in the category: a system that produces more activity than the company has ever generated while pipeline stays flat, because the agents are reasoning over stale data, against an ICP from two stages ago, inside functions that are each optimizing something different.

Why Diagnosis Runs Bottom-Up

The dependency claim has a practical consequence: symptoms appear at the top, causes sit at the bottom, and the two are rarely the same layer.

A team sees flat pipeline against rising activity. Activity is a layer seven and eight observation. The cause is usually layer one or two. The team responds where the symptom is visible, because that is where the dashboard is, and buys another tool or rewrites the sequences. The fix decays within a quarter, because the defect underneath it never moved.

This is why the ordering claim is worth more than the count. It generates a diagnostic procedure. Start at identity and walk up until you find the first layer whose state is wrong, then repair from there rather than from where it hurts.

The best outside evidence for the mechanic comes from a report that was not trying to make this argument. ICONIQ surveyed more than 150 B2B software GTM leaders for its 2026 study of GTM org structure, and the structural findings read as a pricing-layer change propagating upward through functional coherence and into metrics. Under consumption and outcome-based pricing, customer success managers increasingly report into Sales rather than CS, because retention and expansion stop being post-sale concerns. Under the same models it becomes common for RevOps to report into Finance rather than Sales, because revenue is no longer locked in at signature. Data and reporting swells to roughly 30% of RevOps time. Account executive compensation moves toward net new recurring revenue and net dollar retention rather than initial contract value.

Nobody redesigned the org chart because org charts were due for a redesign. A pricing decision changed, and reporting lines and compensation reorganized themselves around it two layers up. That is the dependency running in public across 150 companies.

Two caveats, because the category does not state them and should. ICONIQ is an investor publishing on a portfolio-adjacent dataset, the respondent set is self-selected, and the AI-adoption comparisons in the same report are correlational rather than causal. The org-structure findings are the durable part. The performance deltas are the part to hold loosely.

The AI Layer Reads Everything and Repairs Nothing

The eighth layer deserves its own statement because it is where the ordering claim gets tested most expensively and most often.

An agent reasons over whatever structure sits beneath it. Install one on a coherent system and it compounds. Install one on a fragmented system and it automates the fragmentation at machine speed, which looks like progress for about a quarter. The agent carries seven dependencies and can repair none of them. It cannot tighten an ICP. It cannot resolve two functions optimizing against each other. It inherits all of it and runs faster.

This is the same argument as AI-Native GTM Is a Sequencing Problem, generalized. That essay made the case for one layer. The model makes it for all eight: every layer amplifies the state of the layers beneath it. The AI layer is the most visible case because it amplifies hardest and costs most, not because it is a special exception.

Where This Framing Breaks

Three conditions, stated so the model can be argued with.

Before product-market fit, the layers collapse. A repeatable motion is what the layers decompose. Without one there is nothing to decompose, and sequencing decisions are premature abstraction. Pre-PMF companies need a product, not an architecture. Anyone applying this model at that stage is using it to feel organized.

The ordering claim is falsifiable, and here is what would falsify it. If teams that repair upper layers first, metrics before motion, or agents before identity, showed durable gains rather than gains that decay within two to three quarters, the dependency argument would be wrong. Not weakened, wrong. The model predicts that out-of-order repair produces a temporary improvement that reverts once the underlying defect reasserts itself. If that pattern does not hold, the layers are a taxonomy and not a build order, and the taxonomy is worth much less.

Eight is a decomposition choice. Merging pricing into identity gives seven. Splitting distribution by channel class gives nine. Neither breaks the argument, because the argument was never the number. Anyone treating eight as doctrine has taken the least defensible part of the model and made it the point, which is the mistake the rest of the category has already made five different ways.

What This Decides

The next time pipeline is flat against rising activity, the question is not which tool to add. It is which layer is the lowest one whose state is wrong, and whether anything above it can be trusted until that is fixed.

Most teams will find the answer further down than the dashboard suggested.

Common questions

What are the layers of a modern revenue system?

Eight, in build order: identity, sequencing, pricing, functional coherence, motion, distribution, metrics, and the AI layer. Identity comes first because every other layer inherits it. The AI layer comes last because it reads all seven beneath it and can repair none of them. The order is the argument; the count is a decomposition choice.

How many layers does a revenue architecture have?

Published models range from three to six, and they disagree because they count different things. Revenue Architects counts three method tiers, D.E.A.L. counts four maturity phases, PILLAR counts four pipeline stages, and Ca Design and Revenue Engineered count five service lines and five tool categories respectively. Counting decision classes yields eight. The useful question is not how many layers a model has but what its layers are ordered by.

Do revenue architecture layers have to be built in order?

Yes, and the mechanic is specific: each layer reads the state of the layers beneath it, so a defect below surfaces as noise above, and a fix applied above the defect decays. Repair runs in build order and diagnosis runs bottom-up. This is a testable claim, not a preference, and it predicts that out-of-order fixes revert within two to three quarters.

What is the difference between the 4-layer revenue operating system and the 8-layer revenue architecture?

Scope. PILLAR’s four layers (Signal Infrastructure, Scoring Engine, Decision Engine, Operating Cadences) order a data pipeline running inside a business that already sells something. The eight layers order the decisions that create the motion that pipeline runs on: who the customer is, what the price is, how the company sells. One assumes the upstream decisions; the other is about them. They are not rival answers to the same question.

Where does AI sit in revenue architecture?

Eighth and last, on top of the other seven. An agent reasons over whatever structure sits beneath it, so it amplifies the state of the system it inherits in either direction. It carries seven dependencies and can repair none of them, which is why installing agents before fixing data and qualification produces fragmentation at machine speed rather than intelligence.

Why do revenue architecture frameworks disagree with each other?

Because most layer counts mirror the author’s service catalog. Ca Design’s five layers map one to one onto the five services a HubSpot agency sells. PILLAR publishes two different counts in the same library without reconciling them. The models are not describing the same object and then disagreeing; they are describing maturity phases, tool categories, service lines, and pipeline stages, and calling all four “layers.”

Related reading

Revenue Architecture vs Revenue Operations
Where the architecture layers end and RevOps begins, and why the boundary is reversibility rather than scope.

What Is Revenue Architecture?

The definition the eight layers sit inside, and why architecture is the layer of decisions above RevOps.

AI-Native GTM Is a Sequencing Problem

The dependency argument applied to one layer, with the seven-step build order underneath it.

What Is AI-Native GTM?

Where the eighth layer belongs, and why adoption burden is the test rather than the tooling.

The Revenue Architecture Map

The layers as a diagnostic surface, with the reading order for each one.

What Is a Revenue Architect?
The role the layers imply, and the test that separates holding it from advising on it.

The Stack Index Glossary

Every layer defined in one sentence, with the tools operators named on each one.

Subscribe now

Ad click-through rates are going up. On-site conversion is going down. Hao Sheng watches both sides of that scissor across roughly 80 million clicks a month, and his diagnosis is uncomfortable: part of the traffic you are paying for is agents clicking your ads, and an agent never fills out a form. Your 1 percent conversion rate is measuring the wrong population.

The standard response is to buy more traffic, feeding a number that does not move, while the visitors who matter decide whether to stay in the first 10 to 15 seconds. That gap is not a traffic problem. The hard part is the surface: a website built for reading, asked to do the work of buying.

Hao Sheng is co-founder and CEO of expertise.ai, repositioned from Chat Simple, which he founded in 2023 and scaled to 25,000 companies, profitably. He spent years building the decision-tree generation of agents at Google and Cresta, and is now replacing it with expertise installed onto agents rather than trained into people.

In GTM 49, Hao breaks down why falling intent is partly a bot problem, why organic converts at nearly twice the rate of paid, the operational difference between a chatbot and an agent, and the commit rule he applies to GTM automation.

This is not a conversation about chatbots. It is a conversation about what your website is for when most of its visitors stop being human.

This episode in the Library: the written playbook, the stack and the full transcript, free and open. Open it at pro.gtmvault.co.

Inside this episode

Hao opens with the diagnosis. Ad click-through is rising while conversion falls, because agents are clicking ads without ever leaving an email. Your 1 percent is measuring a population that is less human than you think.

We go deep on why buying more traffic fails: VC-subsidized bidders inflate the auction while organic converts at nearly twice the rate of paid. And on the most clicked button on a B2B website: pricing, not book a demo, in the 15 seconds almost every site leaves unstaffed.

Hao draws the line between chatbot and agent. A chatbot answers questions. An agent installs expertise as modules, and generates the page in real time instead of fetching one that already exists.

We cover the Amazon commit rule, automate only what you have done manually, and the failure case: the hundredth email reveals the template, addressed to Shuama King.

We close on 2028, when agent visitors outnumber humans, and the human-to-bot ratio becomes the metric that tests the whole bet.

Watch or listen now across YouTube, Apple Podcasts, and Spotify

Discussed in this episode

Key takeaways

1. Your conversion rate is measuring a population that is less human than you think. Rising ad click-through with falling on-site conversion is the signature of agents in the traffic. An agent clicks, browses, and leaves no email, which means the denominator of your conversion math includes sessions that were never convertible. Before concluding the website is failing, split the traffic. The human-to-bot ratio is becoming a first-class GTM metric, and Hao tracks it as the signal that tests his entire bet.

2. Buying more traffic means outbidding people who are not playing your game. VC-subsidized AI companies drive ad auctions without caring about cost per conversion, winning campaigns saturate fast, and cost per click inflates the moment you scale budget into them. Organic converts at nearly twice the rate of paid across the roughly 80 million monthly clicks Hao observes, because trust arrives with the visitor or it does not. The next dollar belongs in the channels that build trust before the click.

3. The first 15 seconds of a visit are the highest-leverage unstaffed moment in B2B. The most clicked element on a B2B site is pricing or get a quote, which means visitors are self-qualifying before they will speak to anyone. A static page answers that moment with reading material, and live chat that connects in four minutes answers it after the visitor has left. Whatever engages inside that window, and can answer is this for me, owns the conversion.

   

4. A chatbot answers questions, an agent installs expertise. The operational difference is not response quality. It is that qualification, objection handling, and follow-up become modules built by experts and installed onto agents, so the agent performs like the person who spent decades learning the workflow. Humans learn expertise, agents install it. That moves GTM knowledge out of heads and playbooks and into components, which is the entire logic of the Chat Simple to expertise.ai repositioning.

5. The commit rule is the automation governor GTM needed. Automate only what you have done manually and can supervise, because having done the work is what qualifies you to evaluate the agent doing it. Inside that boundary, automate aggressively, and Hao argues RevOps could automate more than 90 percent of its current work. Outside it, automation produces output nobody on the team can audit, which is where templated, Shuama King outreach comes from.

6. Agent output breaks at the hundredth repetition, and creativity is the remaining human job. Models distilling each other produce homogeneous responses, so the same tool writing your outreach converges on the same email. The first draft impresses, the pattern emerges at scale, and buyers see the pattern across every vendor mailing them. The teams that win with agent-written outreach are the ones with a human breaking the template on purpose, not the ones generating more volume from the same prompt.

Frameworks from the episode

1. Install, Don’t Train. Hao’s model for where GTM expertise lives in the agent era. Expert workflows, how to qualify, how to handle objections, how to run follow-up, are packaged as modules by people with decades of experience and installed onto agents in minutes. A human acquires expertise through years of learning. An agent acquires it through installation. The output is a GTM motion whose capability ceiling is set by the best available module, not the most experienced person on payroll.

2. Generative UI. The difference between fetching and generating. A normal website fetches pages that already exist and shows every visitor the same thing. A generative surface produces the UI component and the engagement line in real time, keyed to the arriving keyword and observed behavior. The output is a page assembled per visitor, which is what makes the first 15 seconds answerable at all.

3. The Commit Rule for GTM Automation. Borrowed from Amazon’s engineering rule that you cannot commit code you could not have written. Translated: you may automate a workflow only if you have done it manually and can supervise the agent doing it. The output is a clean partition of your GTM motion into work you hand to agents now, work you run manually first to earn the right, and judgment that stays human.

What to do this week

• Split your conversion rate by source and by humanity. Pull 90 days of data, separate organic from paid, and estimate the bot share of your sessions. If organic converts at anything close to two to one, the next dollar goes to trust channels, and if bot share is material, your 1 percent was never 1 percent.

• Cut your demo form to two fields. Name and business email. Everything else moves to enrichment after the click. Each field you keep is friction spent collecting what an agent can research in seconds.

• Staff the first 15 seconds. Watch ten real sessions and note what a visitor sees in the window where they decide to stay. If the answer to is this for me is buried in a pricing page and a form, that window is where your pipeline leaks.

• Run the commit rule audit. List everything your team automated in the last year and flag anything nobody on the team has done manually. Those automations are unsupervisable by definition, and they are where the templated output is coming from.

Why this matters

Every B2B company is about to run its funnel through two simultaneous shifts: the visitors are becoming less human, and the surface they land on is becoming capable of conversation. Most teams are responding to the first shift with more spend and ignoring the second entirely.

The uncomfortable arithmetic is that the cheapest pipeline you will add this year is already on your website, leaving. At 1 to 2 percent conversion, a surface that qualifies in the first 15 seconds does more for revenue than any realistic increase in traffic, and it compounds instead of saturating.

The automation question underneath it has a governor now. The commit rule separates the teams that automate what they understand from the teams that generate Shuama King emails at scale. The difference between those two outcomes is not the model. It is whether an operator who has done the work is supervising it.

The orgs that act on this will treat the website as a qualifying surface and automation as an earned privilege. The ones that wait will keep buying traffic into an auction their competitors are happy to lose money in. This is GTM Vault.

Send this one to whoever owns your website and your paid budget, ideally in the same thread.

Connect

Follow Hao Sheng // expertise.ai

Follow Rick Koleta // GTM Vault

Make Better Decisions With AI

AI is changing how companies operate, but the real advantage comes from making better decisions with it. The Decision Intelligence Newsletter by DecideWise breaks down enterprise AI, decision automation, and how leading organizations turn data into decisions that drive business outcomes.

Join the Decision Intelligence Newsletter →

Every tool operators name on GTM Vault is in The Stack Index, placed on the layer of revenue architecture it serves. Build your own stack at pro.gtmvault.co/stack.

Full transcript, searchable to the timestamp: pro.gtmvault.co/episodes/gtm-49.

A revenue system is AI-native when the work happens behind a trigger the rep already touches, rather than inside a tool the rep has to open, learn, and choose to use. AI-assisted GTM puts the model in front of the human and inherits every adoption problem software has ever had. AI-native puts it behind the system, where the architecture runs whether or not anyone changes their behavior.

Hi, it’s Rick Koleta. Welcome to GTM Vault, a breakdown of how high-growth companies design, test, and scale revenue architecture. Read inside OpenAI, Anthropic, Meta, and Google, and by 27,000+ operators across 150+ countries building GTM systems that compound.

The short version

Every page-one result I checked defines AI-native GTM by the same test: is AI in the core of the product or bolted on the side. That test describes software. It does not predict outcomes, because a product can be AI at the core and still sit unopened on a rep’s second monitor. The test that predicts outcomes is adoption burden. Ask who has to change their behavior for the system to run. If the answer is the rep, the system is AI-assisted no matter what is under the hood.

The Term Means Two Things and Nobody Has Said So

Search the phrase and page one returns two incompatible definitions sitting next to each other.

One group means a way of running revenue: a system that researches accounts, scores them, drafts outreach, and writes back to the CRM. The other means a way of selling AI: how a company with a model and a usage-based price gets to its first thousand customers. Both call it AI-native GTM. Both rank for the same query. Not one of the pages I read acknowledges the other meaning exists.

That collision is why the answers are useless. A founder who asks an engine what AI-native GTM is gets a blend of two subjects, delivered with confidence, resolving to a demo request. This essay means the first thing. How revenue work gets done when agents do most of it.

The Test Is Adoption Burden

The incumbent definitions I read all run the same architectural test. Is intelligence woven into the core, or is it an add-on. It is a real distinction and it is the wrong one to lead with, because it describes how a vendor built their product rather than what happens inside your company on Tuesday.

Run the adoption test instead. For each piece of AI in your revenue motion, ask what a rep has to do differently for it to produce anything. If the answer involves opening something, learning something, or remembering to use something, the AI is in front of the human. Every gain it produces is now gated behind behavior change, which is the thing revenue orgs are worst at.

This is not a tooling distinction. It is a placement distinction.

Most writing on this collapses the field into two boxes, which is why the copilot question keeps escaping. There are three placements, and the middle one is where most revenue orgs are sitting right now.

AI featureAI copilotAI-nativeWhere the model sitsInside a tool the rep already opensIn a surface built for the rep to consultBehind the systemWhat the rep doesClicks a suggestionOpens it, prompts it, judges the outputTouches a trigger they already touchWhat has to change for it to workAlmost nothing, and it does almost nothingRep behavior, dailyNothing the rep was not already doingWhat breaks itNothing, the ceiling is just lowAdoption stalls at the tinkerersThe layer underneath, data or definitionsHow it is measuredFeature usageSeats, prompts sent, weekly activesPipeline per seller, cost per opportunityFailure modeInvisible, because expectations were lowQuiet non-useTraceable, if the logging layer was built

The middle column is the expensive one. A copilot carries the full cost of a real deployment, the integration work, the security review, the seat spend, and then routes every gain through the one variable the org controls least. That is why copilot rollouts produce a strong pilot and a flat quarter. The pilot self-selects the people who like tools. The quarter includes everyone else.

Two rows deserve a caveat, because the honest version of this argument is more useful than the clean one.

The third row does not say nothing changes. It says nothing changes that was not already the job. A rep in an AI-native system still reads a draft, judges it, edits it, and sends it. That is a real burden and it carries a real training cost, because trusting a draft is a learned behavior and so is knowing what the gates did not catch. The reason this survives where tool adoption fails is narrow and worth stating plainly: reading and sending an email was already in the job description. Opening a new interface never was.

The last row is conditional, and the condition is the whole design. An AI-assisted deployment fails silently by default. Usage drifts down, nobody escalates, and the renewal conversation is the first time anyone says it out loud. An AI-native system can fail either way. Built with error logs and gates that block and record, it fails where you can see it. Built without them, it fails quietly and expensively, which is the state described further down.

What the Benchmark Measures

ICONIQ’s State of Go-to-Market in 2026, a January 2026 survey of GTM executives at more than 150 B2B software companies, splits its sample on a variable worth reading twice. Not tool count, not spend. Their two cohorts are companies with AI “fully embedded into GTM processes” and companies where it is not.

Be careful about what that measures. Embeddedness is depth of adoption, not placement, and a company where every rep diligently opens three AI tools a day counts as fully embedded while being textbook AI-assisted. So the benchmark does not prove the distinction this essay is drawing. It is the closest instrument in the field, its cohort language is suggestive, and the direction of its findings is worth having.

In the $25M to $100M revenue band, companies with AI fully embedded averaged 45 GTM full-time employees in 2025 against 65 for their peers, counting sales, post-sales, marketing, and RevOps, with services and support excluded. That exclusion matters, because it rules out the obvious objection that the leaner cohort simply moved the work to a support team. Ramped account executives hit quota at 67% against 59%.

Hold those ratios loosely. The high-adoption cell runs between three and eleven companies in every revenue band, and ICONIQ publishes no sample size at all for the productivity scorecard the quota and cost figures come from.

The number that matters most is the one no vendor page I read quotes. Companies with AI fully embedded pay more per lead, $670 against $600, and less per opportunity, $8.5K against $8.9K. The most natural reading of that inversion is that the embedded cohort spends more to produce each lead and converts more of them, so the system is not a volume machine but a filter, and the filtering costs money at the top and saves more of it downstream. ICONIQ reports the two figures as independent averages rather than as stages of one funnel, so treat that as my reading of the data rather than their finding.

There is a limit in the same report, stated plainly, and any honest definition has to carry it. Comparing companies with more than half their pipeline AI-influenced against those below that line, conversion improves 11 percentage points from lead to MQL and 8 from MQL to SQL, then 1 point from SQL to closed-won and 3 from demo to closed-won. Their conclusion: AI-driven pipeline generation “currently does not materially change outcomes once deals are in an active cycle.”

That is not a disappointing result. It marks where the boundary currently sits. AI-native describes the preparation half of the revenue motion, the part that is research, matching, gating, drafting, and logging. The judgment half stays human, and a system designed as though it does not will produce the failure documented in why AI SDRs failed.

One Checkbox, Seven Layers

The clearest production example I have seen came from Angelo Quiambao, a GTM engineer at Intellistack, who ran his live system on screen for twenty minutes in Show Me Your Stack 7.

His architecture is Claude Code as the terminal, Relevance AI hosting the agents, and MCP as the connective tissue, sitting over Databricks, Salesforce, Gong, and Apollo. One orchestrator sits in front of four single-job agents covering prospecting, account research, contact research, and emailing. No agent makes two decisions, because an agent that makes multiple decisions creates too many places to fail.

The design choice worth copying is what the research agent does first. It checks internal data before it touches anything external. Is there an open opportunity. Is there closed-lost history worth re-engaging. Is there first-party intent. Are there MQL or MQA personas on the account. Third-party signal comes last, after the company’s own knowledge has already narrowed the field. Then the gates run: ICP, duplicate check, and a pre-check for accounts already in a deal cycle. Anything that fails is blocked and logged rather than emailed. Deduplication is not cleanup at the end. It is a gate enforced before work happens twice.

The rep never sees the machinery. Their entire interface is a checkbox in Salesforce, or a message in Slack where the team already lives. They are never told that seven layers fired. They are told a draft will be in their inbox, and reading that draft is the one thing the architecture asks of them, which was already the job.

Two things about that are worth stating directly. First, it is the ICONIQ inversion in a single system. The architecture’s main job, as the episode frames it, is deciding who not to contact, which is what paying more per lead and less per opportunity looks like from the inside. Second, rep adoption is the number one thing he measures, ahead of any measure of agent capability, and his test for whether a build is sound is whether he can describe what an agent does to leadership in five to ten words.

A vendor cannot write this section. It requires an operator who built the thing and is willing to say what breaks.

Subscribe now

Why the Order Still Decides This

Nothing above changes the sequence. An agent reasons over whatever structure sits beneath it, so an AI-native architecture installed on fragmented data produces that fragmentation at machine speed, quietly and expensively. Angelo’s first move on any build is not a build. Before a single agent exists he maps account tiering, ICP definitions, product information, and buying teams, then takes them to RevOps, marketing, and sales until the definitions match across all three.

His read on the market condition is the sharpest line in the episode. Companies are very data rich, because AI can pull data from anywhere, but nobody is context rich. The data is available to anyone now. The definitions are not, and the definitions are what an agent reasons against.

The full build order is in AI-native GTM is a sequencing problem: data, then intelligence, then agents. This essay defines the destination. That one is the route.

The AI Layer Is the Eighth

Revenue architecture has eight layers, and they are a build order rather than a checklist. Identity, sequencing, pricing, functional coherence, motion, distribution, metrics, and then the AI layer on top. Each one governs a class of decisions and reads the state of everything beneath it, which leaves the AI layer as the only layer in the stack carrying seven dependencies and no ability to repair a single one of them. Agents installed on top of the seven layers below inherit whatever state those layers are in.

That is why placement alone is not protective. Putting the model behind the system is the correct move and it does nothing for the layers underneath. An AI-native architecture sitting on an unresolved identity layer will disqualify the wrong accounts faster and more consistently than any human could, and it will do it quietly, because the ICP gate is working exactly as specified against a specification nobody agreed on.

This is not an argument for holding the AI layer until the other seven are finished, which is a state no company has reached. It is an argument for knowing which layer you are failing at when the output is wrong. Teams reliably diagnose a layer-one problem as a layer-eight problem, because layer eight is the one that produced the artifact they can see.

What a Half-Built System Looks Like

None of the pages defining this term describe the middle state, which is where most teams reading this will be.

It looks like an orchestrator wired to agents whose definitions came from three different documents, so the ICP gate passes accounts the AE team would never work. It looks like a dedupe check that runs on email address while the CRM keys on domain, so the same account gets touched twice a quarter and nobody can reproduce it. It looks like an agent with write access to the CRM and no error log, which means the first sign of a problem is a rep asking why the account owner changed.

The pattern in each case is the same. The placement is right and the layer underneath is not finished. Note that none of those three failures announce themselves, which is the condition attached to the last row of the table earlier. Placement alone does not buy you visibility. Gates that block and record, and agents that log their errors, are what turn a silent failure into a traceable one, and they are the part teams skip because they look like plumbing rather than capability.

The fix is never a better agent. It is going back one layer.

The Audit

Five questions, in order. Run them against one motion rather than the whole revenue org, because the answers differ by motion and an average across all of them tells you nothing.

1. What does the rep have to do that they were not doing before? If the honest answer includes opening, prompting, or remembering, you are running a copilot and every projected gain is multiplied by an adoption rate you have not measured. Measure it before you plan against it.

2. Where does the trigger live? Name the specific object the rep touches. A field on a record, a message in the channel they already sit in. If the trigger lives anywhere the rep does not already go daily, the placement is wrong regardless of what the architecture does after the trigger fires.

3. What does the system decide not to do? An architecture that only produces is a volume machine, and volume against a weak filter is the AI SDR failure with better branding. Count the gates. If there is no ICP gate, no duplicate gate, and no check for accounts already in a deal cycle, the system has no opinion about who to leave alone.

4. When it is wrong, how do you find out? Trace one bad output backward. If the path from a rep noticing something odd to a logged, reproducible cause takes more than a few minutes, you do not have an observable system, you have an unobservable one that happens to be behind the rep instead of in front of them.

5. Which layer produced the defect? Take the last three things the system got wrong and assign each to one of the eight layers. If all three land on the AI layer, the assignment is wrong. Almost nothing originates there.

The output of that audit is not a score. It is a single sentence naming the lowest layer with a real defect, and that sentence is your next quarter.

Where This Framing Breaks

Three limits, because a definition that survives only in the cases it was built for is a slogan.

The first is stage. Adoption burden is the right test once a motion is repeatable and the rep’s job is defined well enough to say what was already in it. Before that, in founder-led sales and the first complex enterprise deals, the research is the selling. Hiding the preparation from the person having the conversation removes the thing they were supposed to learn. Early on, put the human in front on purpose and accept the ceiling.

The second is opacity. Hiding seven layers behind a checkbox buys adoption and spends something to get it. A rep who cannot see the system cannot debug it, cannot tell you the drafts got worse in the last two weeks, and cannot distinguish an agent error from a data error. The mitigation is the translation layer, which is why Angelo weights enablement equal to the build and tests every agent against a five-to-ten-word explanation. Skip that and you have traded an adoption problem for a trust problem, which is slower to detect and harder to reverse.

The third is that adoption burden says nothing about ownership. A system nobody has to adopt is also a system nobody obviously owns, and agents with CRM write access and no named owner are a governance problem waiting for a quarter-end. The test tells you where to put the model. It does not tell you who answers for it.

What This Decides

The practical consequence is a reallocation, not a purchase.

Most GTM AI budget currently buys surfaces that reps have to choose to open, and most GTM AI disappointment traces to the gap between the pilot group who chose to and the org that did not. Moving that spend behind the system does not require a platform migration. It requires deciding that the interface is a design constraint rather than a feature, and that every new capability gets placed before it gets built.

The question to take into the next planning cycle is not which AI to buy. It is which triggers your reps already touch, and what could run behind them.

Common Questions

What is AI-native GTM?

A revenue system is AI-native when the work happens behind a trigger the rep already touches, rather than inside a tool the rep has to open, learn, and choose to use. The test is adoption burden, not whether AI is in the core of a product. If the system requires rep behavior change to produce anything, it is AI-assisted regardless of the architecture underneath.

What is the difference between AI-native and AI-assisted GTM?

Placement. AI-assisted puts the model in front of the human, which means every gain is gated behind adoption. AI-native puts it behind the system, so the architecture runs whether or not anyone learns a new interface. The practical tell is what the rep has to do differently, and in an AI-native system the answer is nothing that was not already the job. Reading and sending a draft was already the job. Opening a new tool was not.

Is an AI copilot the same as AI-native GTM?

No, and the copilot is the more expensive of the two to get wrong. A copilot is a surface built for the rep to consult, so it carries the full cost of a deployment, the integration, the security review, and the seat spend, then routes every gain through whether people open it. AI-native puts the same capability behind a trigger the rep already touches, which is why copilot pilots look strong and copilot quarters look flat. The pilot self-selects for people who like tools.

Is AI-native GTM a platform you buy?

No. It is a property of how your revenue system is arranged, and you can build it on tools you already own or fail to build it on the most AI-native platform on the market. Vendors define the term as a product category because that is the version they can sell. The arrangement is the part that decides whether it works.

Does AI-native GTM mean replacing sales reps?

No, and the benchmark data argues against it. ICONIQ’s 2026 survey shows AI-influenced pipeline improving lead-to-MQL conversion by 11 percentage points and MQL-to-SQL by 8, then 1 point and 3 once a deal is in an active cycle. AI-native describes the preparation half of the motion. The judgment half stays human, and systems built as though it does not are the ones that failed publicly in the AI SDR wave.

How do you know if your GTM is AI-native?

Ask what a rep has to do differently for the system to produce output, and ask where a failure shows up. In an AI-native system the rep does nothing that was not already part of their job, and failures surface as blocked records and error logs if the logging layer was built. In an AI-assisted system the rep has to open something, and failure looks like usage quietly declining until someone notices at renewal.

Where does AI-native GTM improve the numbers?

At the top of the funnel and in headcount leverage. Companies with AI fully embedded in GTM processes averaged 45 GTM full-time employees in 2025 against 65 for peers in the $25M to $100M band, with 67% of ramped AEs hitting quota against 59%. They also pay more per lead and less per opportunity, which is the signature of a system built to filter rather than to produce volume. Sample sizes on the high-adoption side are small, so read the direction rather than the ratio.

Related Reading

AI-Native GTM Is a Sequencing Problem. This essay defines the destination, that one gives the build order: data, then intelligence, then agents.

Your Reps Should Never Meet Your Agents. Angelo Quiambao’s full stack on screen, the seven layers behind the checkbox, and the gates that run before any work happens.

Why AI SDRs Failed. What happens when a system is built as though the judgment half of the motion can be automated too.

What Is Revenue Architecture. The eight layers in build order, and why the AI layer is last on purpose.

What Is a Revenue Architect? Who owns the layer order, and the test that separates holding that role from advising on it.

The Stack Index Glossary. AI-native GTM defined in one sentence, next to the eight layers and the tools operators run on each one.

This is for teams where CAC is rising, win rates are softening, or headcount is scaling faster than system coherence. If your product works and your pipeline does not, the constraint is structural.

Subscribe for the architecture behind what the best operators are building.