Hi, it’s Rick Koleta. Welcome to GTM Vault, a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

Eight days ago, GTM Vault ran on my hours. Every swap pitch, every guest booking, every sponsor draft, every post went out by hand or it did not go out. Today the entire go-to-market motion runs on twenty-one automated systems, and I run them alone.

I did not build this to save time, though it returns about thirty hours a week. I built it to test a claim I have been making in this publication for months: that revenue problems at working companies are structural, not effort problems, and that the same intelligence applied to a coherent system compounds, while applied to a fragmented one it only produces noise at scale.

The Distinction Most GTM Automation Misses

AI collapsed the cost of execution. That is the whole event. When drafting an email, researching a prospect, or assembling a report costs almost nothing, the scarce skill is no longer doing the work. It is deciding what the work should be, and in what order it runs.

This is what GTM engineering actually means. GTM engineering is the practice of building go-to-market as a system instead of a headcount plan: workflows, data pipelines, enrichment layers, and AI agents that execute the motion, designed and maintained the way software is. A GTM engineer replaces repetitive execution with orchestrated systems and spends their judgment on what the system should do, not on doing it manually. The discipline emerged when AI collapsed the cost of execution and moved the constraint to design: the scarce skill is no longer doing the work, it is architecting the system that does.

Most teams get the sequence backwards. They bolt agents onto a stack that was accumulated, not designed, six to eight tools stitched together by whoever set them up, and the AI faithfully executes the incoherence faster. The output looks like productivity. It is noise at scale. Automation on a fragmented system does not fix the fragmentation. It industrializes it.

What I Built

The motion is not a pile of automations. It is a funnel with four stages, each with one job, sequenced so the output of one becomes the input of the next. Top of funnel turns strangers into subscribers. Middle turns anonymous readers into named relationships. Bottom turns relationships into commitments, booked guests and sponsor conversations. Retention holds what converted and measures the one leak that matters, the gap between free readers and paid.

Every rail is capped, deduped, and gated. Caps so the platform accounts survive the volume. A shared record so no asset and no prospect ever gets hit twice. Gates so anything that speaks to a human in my name waits for my judgment before it sends. The machine runs the repeatable work at full capacity whether I slept or not. I spend my hours on the only thing that does not automate: which relationship to close, which sponsor to take, which architecture decision to make next.

The Team Became a System

The version of this motion that runs on people looks like an org chart: a founder still closing, an SDR or two, someone on marketing, someone on RevOps, a contractor on content, all coordinating by hand across a stack of tools nobody fully owns. The version that runs on architecture looks like one operator sitting on top of a system that does the repeatable work.

The roles did not get automated away one at a time. What got replaced was the coordination between them, the meetings, the handoffs, the status checks, the coordination that actually consumed the hours. That is the quiet claim of this whole build. The expensive thing was never the work. It was the coordination, and coordination is a design problem.

What a System Knows That an Automation Does Not

The difference between a pile of automations and a system shows up the first time something tries to go wrong.

On its first live run, the rail that publishes to social came within one action of posting the same essay to the same account twice. It did not, because a shared record of what had already gone out stopped it. That is the line. An automation repeats. A system knows what it has already done, and refuses to do it again.

A day later, the layer that audits the whole operation each night caught something worse. The records claimed outreach had been sent that the mail log could not confirm, and two addresses marked as delivered had in fact bounced into nothing. The dashboard was confidently reporting fiction. This is the part most teams skip when they automate. Instrumentation is not a chart you read on Monday. It is the mechanism that keeps the machine honest about what it actually did, because a system that cannot audit itself will scale its own errors and present them as progress.

And one rule governs every send. The machine publishes freely to my own channels, where a mistake is reversible, and never messages a human in my name without my judgment first, because that is not. Automate the reversible. Gate the irreversible. The sequencing of trust is itself an architecture decision, and getting it backwards is how automated go-to-market turns into a public apology.

The Number That Matters, and the One That Does Not

The thirty hours are real, but they are the byproduct, not the point. The point is that one person now runs a full-funnel revenue motion that used to require a team, and the freed hours convert into judgment instead of execution.

I am not going to show you a growth chart. The system is eight days old, and the honest state is that it runs clean while the outcomes it exists to produce are still compounding. That is the truth, and this audience can handle it. What I can show you is that the architecture holds: the machine executes at cap, catches its own errors, reconciles its own records, and reports against the number that grades it. Results follow structure. They do not precede it.

Everything above is the doctrine I write about, installed on GTM Vault itself. It is not a case study I am describing from the outside. It is the argument, running. For what it is worth on the question of who reads this kind of work, GTM Vault is 26,000+ subscribers with 6,683 highly engaged readers, and it is read inside OpenAI, Anthropic, Meta, and Google. The audience is operators, not spectators.

Automate the reversible. Gate the irreversible.

Why This Installs in a Company That Sells Differently Than Mine

My motion is a publication’s. Yours may be sales-led, enterprise, six-figure deals with a human in every loop. The substrate changes. The principle does not. A sales-led revenue system has the same four stages and the same failure mode: signal, positioning, motion, and RevOps, assembled in whatever order the tools arrived rather than the order the system needs. The enrichment tool bought before the ICP was defined. The sequencer running before the positioning was clear. The AI agent layered on last, executing all of it faster.

The headcount you are about to add to fix a pipeline that will not compound is a bet that the constraint is capacity. In a working company it almost never is. You will scale the fragmentation, and call the higher burn growth.

The Diagnosis

If your product works and your pipeline does not, the constraint is architecture, not activity. Your team is working. The channels are running. The pipeline still does not compound. No amount of added headcount closes a structural problem, it only makes the incoherence more expensive to run.

I install the same sequencing and coherence on a company’s revenue system that I installed on mine, with a small number of teams each quarter. Not advice layered on top of the existing motion. The system underneath it, rebuilt in the right order. That work runs through GTM Vault Pro. An annual membership is the qualifier, and it opens the Blueprint Intake Form, which arrives by email automatically when you upgrade. It is deliberately not for everyone. It is for teams where CAC is rising, win rates are softening, or headcount is scaling faster than system coherence.

If you are earlier than that, the frameworks behind every rail above live in GTM Vault Pro, and the free publication is one click at gtmvault.co

Reading the argument is not the same as installing the system. That is the line Pro crosses.

Free readers get the doctrine. Pro members get the frameworks, the configs, the diagrams, and the sequencing behind it, the actual instructions for building the motion instead of the description of why it works. If the essays have told you what is broken, Pro is where you fix it.

“A must-read for anyone driving growth, this newsletter offers sharp insights on GTM strategy, covering inbound/outbound tactics, ideal customer profiles, and key growth metrics.”

— Sean Ellis, Founder of GrowthHackers

Read inside OpenAI, Anthropic, Meta, and Google, alongside more than 26,000 founders and revenue leaders running GTM systems inside their own companies.

The Doctrine, in full

Pro opens the complete archive. Every Foundational Law, every Architecture piece, and the working artifacts underneath them: the frameworks I run, the RevOps instrumentation maps, the sequencing logic, and the diagrams that show what gets built in what order. The free essays state the principle. The Doctrine gives you the version you can install, including the parts I hold back from public posts because they only make sense with the full system around them.

The GTM Strategy Course

Ten chapters, sequenced the way the build actually happens. Not a library of tactics to pick from, a path. It starts at positioning and pricing, moves through motion design and RevOps, and ends at the AI-native workflows that execute the motion. The order is the point. The same tools installed in the wrong sequence produce fragmentation instead of compounding, and the course is built so you install them in the order that compounds.

The Blueprint Session

This is the reason most members upgrade. The Blueprint Session is a direct diagnostic of your own revenue architecture: where the layers are misaligned, which metric you are measuring at the wrong stage, and what to build next. Upgrading to annual opens it. You will get an email with the intake form the moment your membership starts, and the form itself is the qualifier. Completing it is how the session gets scoped to your system rather than a generic call.

Who this is for

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, and Pro is built to work that constraint.

It is not for awareness-stage reading, and it is not for companies still searching for product-market fit. If you are earlier than that, the free publication is the right place to stay, and it is one click.

What upgrading does

Annual membership unlocks the Doctrine and the Course immediately, and triggers the Blueprint intake in your inbox. There is no call to book and no form to chase down. You upgrade, the system opens, and the intake finds you.

If your pipeline has stopped compounding and you already know the problem is not effort, this is the step that turns the reading into a build.

Upgrade to Annual Pro

Common questions

What is revenue architecture?

Revenue architecture is the structural design of a company’s revenue system: how positioning, pricing, motion design, RevOps, and AI-native workflows fit together, and in what order they get built. It is not a tool choice and not a growth tactic. The core claim is that revenue problems at working companies are usually structural, not effort problems: when the product works and the pipeline does not, the constraint is the architecture, not the activity. Revenue architecture treats sequencing as the first decision, because the same tools installed in the wrong order produce fragmentation instead of compounding.

What does GTM Vault Pro include?

Pro is an annual membership. It unlocks three things: the full Doctrine archive, including every Foundational Law and Architecture piece plus the frameworks, configs, and diagrams underneath them; the ten-chapter GTM Strategy Course, sequenced in build order; and the Blueprint Session, a direct diagnostic of your own revenue architecture.

What is the Blueprint Session?

The Blueprint Session is a scoped diagnostic of your company’s revenue architecture. It identifies where your layers are misaligned, which metric you are measuring at the wrong stage, and the single next thing to build. It is scoped to your system through an intake form rather than run as a generic call.

How do I get the Blueprint intake form?

Upgrading to annual Pro triggers it automatically. You receive an email with the intake form the moment your membership starts. The form is the qualifier, completing it is how the session gets scoped to your architecture. There is no separate call to book.

Is Pro monthly or annual?

Pro is annual. The annual commitment is what opens the Blueprint intake, since the session is built for members installing the system over a full cycle, not sampling it.

What is the difference between the free publication and Pro?

The free publication is the argument: the weekly case that revenue problems are structural, not effort problems. Pro is the install: the frameworks, sequencing, and diagnostic that turn the argument into a system you build inside your own company. Free explains the architecture. Pro hands you the parts and the order.

Who should not upgrade?

Pro is not for awareness-stage reading and not for companies still searching for product-market fit. If your product does not yet work, the constraint is not architecture, and the free publication is the right place to stay.

Upgrade to Annual Pro

Explore GTM Vault

The free publication runs across five sections. Start wherever your problem lives.

GTM Vault Podcast · operators on how they built the motion.

Show Me Your Stack · the real tools and configs behind working GTM systems.

Foundational Laws · the structural principles under every AI-native GTM motion.

GTM Architecture · how the layers fit together, and in what order they get built.

GTM Playbooks · the applied builds, end to end.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

Why did AI SDRs fail? The first wave optimized volume instead of reasoning: more sends against the same broken qualification, which produced spam at machine speed and churn to match, with the category’s early leaders losing most of their early revenue once break clauses opened. What replaces them is not a better SDR imitation. It is a different architecture: signal-based prioritization, human-in-the-loop copilots, and context layers that give agents something real to reason over. The lesson is structural: automation amplifies the system it inherits.

That is the answer. The rest of this essay is the evidence, the mechanism, and the taxonomy that predicts which of today’s agentic sales products live or die.

The Promise, Stated Fairly

The 2023 pitch deserves an honest reconstruction, because the diagnosis only means something if the pitch was reasonable. It was. SDR labor is expensive, repetitive, and churns faster than almost any role in the building. The work is structured: find accounts, find contacts, write a relevant message, send, follow up, book. Large language models had just demonstrated they could do the writing. The syllogism assembled itself: an agent that prospects, personalizes, and books meetings replaces the function at a tenth of the cost, and every company with an outbound motion is a customer.

Hundreds of millions in venture funding followed that logic into the category. The logic was not stupid. It was architecturally naive, and the gap between those two things took about eighteen months to price.

Eighteen Months From Category to Cautionary Tale

The dates matter, because the collapse was fast and public.

Through 2023 and 2024 the category scaled on the replacement narrative. The first structural warning came from inside the vendor pool: in December 2024, Amplemarket’s CEO João Batalha published a prediction that “AI SDR companies will pivot away from what they were offering in 2024. The narrative that sales reps will be replaced by AI will die down.” A vendor whose product line sat next door to the category was calling the pivot before the press did.

The press caught up in the spring. In March 2025, TechCrunch reported that 11x, the category’s most visible company, had displayed logos of companies that were not customers, and that trial contracts with three-month break clauses had been counted as full-year ARR while early-cohort churn ran 70 to 80 percent. Sifted’s reporting the same week put the figure at roughly 70 percent of customers closed or paused by mid-2024. Six weeks later, the founder stepped down to non-executive chairman and the company’s CTO took the CEO seat. Whatever else that sequence was, it was the company accepting the diagnosis and starting the rebuild.

The channels pushed back on the category too. Google and Yahoo’s bulk-sender requirements, effective February 2024, put authenticated sending, one-click unsubscribe, and an enforced spam-rate ceiling under every high-volume outbound motion. And in late 2025, LinkedIn banned Artisan, one of the category’s loudest brands, for roughly two weeks before reinstating it. The specifics were about naming and data vendors rather than agent spam, but the structural message was legible to everyone building on the platform: the landlord was watching, and the category was the tenant it watched most.

The strangest marker came from the category’s own sellers. In April 2025, Actively AI raised $22.5 million with a pitch TechCrunch headlined as, verbatim, “says AI SDRs failed”, its co-founder arguing the first wave chased pure volume instead of reasoning about high-value opportunities. A year later the same company raised $45 million selling per-account reasoning to the same buyers. When a category’s fastest-growing vendors lead with its obituary, the failure is not a contrarian take. It is consensus with a marketing budget.

The Mechanism: Four Structural Failures

The failure was not model quality. The models wrote competent emails in 2023 and write better ones now. The failure happened in the layers the models were installed on top of, and it happened four ways.

Failure 1: Volume inherited a broken qualification layer. An agent amplifies whatever ICP definition it is given, and at most buyers that definition was a category, not an ICP. “Series B SaaS, 50 to 500 employees” is a filter, not a qualification layer. Machine-speed outreach pointed at a human-speed targeting error produces spam with perfect grammar, and the recipient can tell. Every downstream decision inherits the ICP, and the agents inherited it at a thousand sends a day.

Failure 2: The data underneath was stale. The agents reasoned over CRMs that were hand-updated, late, and wrong, because almost nobody had eliminated the manual hops between signal and record before installing automation on top of them. The sequencing essay calls this Step 1 for a reason. Skipped, the automation automates the staleness. AI amplifies the architecture it inherits, and what it inherited was six to ten manual hops and a database describing last quarter.

Failure 3: Rented channels punished machine volume. Deliverability is a commons. Every AI SDR degraded the inbox for all of them, and the platform owners responded exactly as landlords do: authentication requirements, spam-rate ceilings, enforcement actions. A category whose unit economics required volume built itself on channels whose owners profit from punishing volume. That is not bad luck. It is a structural contradiction that was visible in the pitch deck.

Failure 4: The economics never survived the break clause. The category sold on booked meetings, a demo metric. Renewal happens on pipeline that closes, a system metric, and the two diverge exactly as far as the qualification layer is broken. The three-month break clause became the category’s actuarial table: per the public reporting, most early revenue did not survive its first exit window. There is no independent dataset on AI SDR renewal rates, which is itself telling, but the reported cohort numbers and the leadership resets that followed them tell a consistent story.

What Actually Failed, and What Didn’t

The category’s deepest problem was taxonomic. Three different architectures shipped under one label, and the label failed while two of the architectures did fine.

Autopilot. The agent replaces the rep end to end: finds the account, writes the message, owns the send, books the meeting. This is the architecture that failed, for the four reasons above. It concentrated every structural weakness of the buyer’s revenue system into an unsupervised loop running at machine speed.

Copilot. The agent does the execution, the human owns judgment and the send button. This is the architecture that survived and grew, and its vendors are the ones who called the collapse in advance. Amplemarket’s own framing of the distinction is explicit, and Regie.ai’s public position that AI belongs in “enhancing, rather than replacing, human sellers” is the category’s surviving wing saying the quiet part early.

Reasoning layer. The agent decides who and when, not what to say: signal-based prioritization over generation. This is where the survivors repositioned, and where the new money went. Actively’s per-account reasoning, the context-graph vendors, the warm-signal orchestrators. The generation that the first wave sold became a commodity; the deciding that the first wave skipped became the product.

The claim, stated flatly: AI did not fail at sales. Full autonomy failed at the qualification and context layers it was never given. The taxonomy is not academic. It predicts which current products live, because any agentic sales tool you evaluate today is one of these three architectures wearing a new name.

Where the Value Settled

When generation commoditized, value moved to what generation needs: clean data, unified context, real signals. The vendors thriving in 2026 sell exactly that layer. Context graphs built from call and deal data. Per-account reasoning over live signals. Orchestration that treats the send as the last step of a system rather than the product itself.

This is the same migration this publication has been documenting from other angles: episode 46 argued context is GTM infrastructure, not a tool connector, and the argument runs through the AI SDR story in reverse. The category that owned the send but not the context is gone. The layer that owns the context is where the premium settled. The full architecture of that claim, and where it sits among the eight layers, is in What Is Revenue Architecture.

How to Evaluate Agentic Sales Tools Now

The practical residue of eighteen months of category tuition is four questions, each of which resolves to architecture rather than demo quality.

What data does the agent reason over, and who keeps it current? If the answer is your CRM as it exists today, the agent inherits your data debt at machine speed.

Where does the human sit in the loop, and is that placement designed or residual? A copilot with a deliberate judgment gate is an architecture. A copilot that is an autopilot with a checkbox is a liability with better positioning.

What happens to your domain and your brand when the agent is wrong at scale? Deliverability and platform standing are shared assets that burn faster than they rebuild, and the vendor does not carry that risk. You do.

Is the vendor selling replacement or leverage, and does the contract structure match the claim? Replacement claims with quarterly break clauses are a pricing model for churn.

And underneath all four, the sequencing rule this publication keeps returning to: repair the data hops and the qualification layer first, because an agent installed on top of them amplifies whichever state they are in. The tools are not the problem. The order is.

The Falsifiable Version

A diagnosis that cannot be wrong is a slogan, so here is the test that would break this one. If a full-autonomy product sustains renewal-grade pipeline, not booked meetings, across two years, without human judgment in the loop and without degrading the channels it runs on, then the autopilot architecture works and this essay becomes a period piece about early implementations. As of 2026, no vendor has published numbers that meet that test, and the category’s own capital is betting on the other two architectures. The test stands open.

Questions Operators Ask

Why did AI SDRs fail? The first wave optimized volume instead of reasoning, ran it against broken qualification layers and stale data, and burned rented channels doing it. Churn followed the architecture, not the model quality.

Did AI SDRs fail because the AI wasn’t good enough? No. Generation quality was never the constraint. The failures were the qualification layer, the data layer, and the channel economics underneath the generation.

What is the difference between an AI SDR and an AI sales copilot? An autopilot replaces the rep and owns the send. A copilot executes while a human owns judgment and the send. The first architecture failed. The second survived and grew.

Are AI SDRs dead? The autopilot architecture is. The category repositioned toward copilots and reasoning layers, often under the same brand names, and the recent funding follows the repositioning.

What should replace an AI SDR? A sequence, not a substitute: repair the data hops, fix qualification, then install agents as leverage on clean structure. The order is the product.

The First Casualty Report

The AI SDR wave was the execution shock’s first casualty report, and its lesson is the architecture era’s founding lesson. Execution collapsed toward free, everyone bought it, and the companies that bolted it onto fragmented structure paid to discover what the structure was worth. Automation amplifies the system it inherits. The category learned it at venture scale so that operators reading this can learn it at the price of an essay.

The map of what to build instead is in What Is Revenue Architecture, and the build order starts at Law 01.

Subscribe now

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

Revenue architecture is the structural design of a company’s revenue system: how positioning, pricing, motion design, RevOps, and AI-native workflows fit together, and in what order they get built. It is not a tool choice and not a growth tactic. The core claim is that revenue problems at working companies are usually structural, not effort problems: when the product works and the pipeline does not, the constraint is the architecture, not the activity. Revenue architecture treats sequencing as the first decision, because the same tools installed in the wrong order produce fragmentation instead of compounding.

That is the definition. This essay covers the rest: where the discipline came from, what is propelling it now, the eight layers it consists of, and why lean organizations that install it are pulling away from larger ones that accumulate instead.

Why the Term Needs Defining

“Revenue architecture” is currently used three ways. In the SaaS metrics world it circulated as a sales methodology, a system of models for measuring recurring revenue. In the consulting world it shows up as a rebrand for RevOps services. In vendor copy it means whatever stack the vendor sells. All three usages share the word. None of them carry the claim this essay makes: that architecture is the design and build order of the entire revenue system, and that in the AI era it has become the primary constraint on growth.

Loose terms produce loose decisions. A founder who thinks revenue architecture means a metrics model will buy dashboards. A founder who thinks it means a stack will buy tools. Both will wonder, eight months later, why the pipeline still does not compound. The definition matters because the diagnosis depends on it.

What Revenue Architecture Is Not

It is not RevOps. RevOps runs the revenue system that exists: the data hygiene, the routing, the reporting, the process. Architecture decides what system should exist and in what order it gets built. RevOps is a function. Architecture is the layer of decisions above it. A company can have an excellent RevOps team operating a badly architected system, and most do.

It is not a tool stack. The same eight tools produce compounding growth in one company and expensive chaos in another. The difference is not vendor selection. It is the structure the tools were installed into and the order they arrived in. Anyone selling architecture as a shopping list is selling the stack, not the structure.

It is not strategy in the slide-deck sense. Strategy says which market to win and why. Architecture says how the machine that wins gets assembled. Between the strategy offsite and the SDR hitting send, there is a layer of structural decisions that most companies never make deliberately. That layer is the subject of this essay.

The Five Eras of the Revenue System

The discipline did not appear from nowhere. It is the fifth era of a system that has been rebuilt four times, and each era is defined by what was scarce in it.

The System of Record, 1999 to 2010. Salesforce moved the pipeline out of spreadsheets and into the cloud. The scarce thing was visibility. For a decade, answering “what is happening in the pipeline” was the frontier, and the CRM answered it. Companies mistook record-keeping for architecture because the record was the most structured thing they owned. The era’s legacy is still with us: revenue data organized around what happened, not around what should happen next.

The Automation Wave, 2010 to 2016. Marketing automation arrived first, then sales engagement. Eloqua, Marketo, Outreach, Salesloft. The scarce thing was volume: more emails per rep, more sequences per campaign, more touches per account. The pipeline industrialized. Almost nobody asked whether the assembly line was pointed at the right buyers, because the line itself was new and the throughput gains were real. The era ended with every competitor running the same sequences into the same inboxes.

The Intelligence Layer, 2016 to 2022. Conversation intelligence, intent data, ABM platforms, and the rise of RevOps as a titled function. The scarce thing was insight: recording, scoring, and interpreting what the volume era produced. This is also the era of stack sprawl. A mid-market GTM org accumulated six to eight distribution channels running through fifteen to twenty tools, each optimizing one function’s metric. Each function improved in isolation. The system as a whole degraded at every functional boundary. The diagnosis has its own law: function-level optimization is system-level debt.

The AI Execution Shock, 2022 to 2025. ChatGPT shipped in November 2022. Within eighteen months, a category of AI SDR companies promised to replace the humans running the automation era’s playbooks. The first wave largely failed, and the failure was instructive: the tools ran volume against the same broken qualification the humans had been running, at machine speed, and the category’s early leaders watched most of their early revenue walk once break clauses opened. The lesson was not that AI does not work. The lesson was structural: automation amplifies the system it inherits. Execution collapsed toward free, and for the first time in five eras, the constraint moved to design.

The Architecture Era, 2025 to now. Context layers, MCP connectors, copilots over autopilots, GTM engineering as a named discipline, agents that reason over unified data instead of spraying from fragmented data. As of 2026, every company can afford every play. When execution is abundant, the differentiator is the order and structure of assembly. This is the era the definition at the top of this essay belongs to.

The Four Forces Behind the Architecture Era

Eras do not change because analysts announce them. They change because underlying costs move. Four moved at once.

Execution became software, then became nearly free. Work that consumed SDR teams, ops analysts, and content teams now runs through agents. Account research that took ninety minutes takes four. Sequence drafts that took an afternoon take a prompt. When doing costs almost nothing, deciding what to do is the entire game, and deciding-what-to-do is architecture.

The integration substrate matured. First APIs everywhere, then MCP in late 2024, which turned tools from destinations into layers an agent reasons across. A stack that could not talk to itself in 2020 is a queryable system in 2026. The technical precondition for architecture, connective tissue between layers, went from custom engineering project to configuration.

The context layer became a product category. Call data, CRM state, and intent signals are converging into graphs that agents act on directly. The vendor landscape is reorganizing around architecture’s raw material. When the market starts selling you the connective layer, the structure it connects becomes the differentiating asset.

Services flipped from staffing to systems. Agencies sold hands. The new wave, GTM engineers, fractional architects, systems consultancies, sells installed and documented systems that run without the vendor in the room. The services market is repricing execution toward zero and judgment toward premium, which is the same migration the software market made, one layer up.

The Eight Layers

Revenue architecture is not a metaphor. It has layers, each governs a specific class of decisions, and each has a law that names its failure mode. The eight layers, in build order:

1. Identity. Who the system is for, defined tangibly enough to disqualify in real time. Everything downstream inherits this decision, which is why it comes first. Every downstream decision inherits the ICP.

2. Sequencing. What gets built and scaled in what order. The layer this essay keeps returning to, because it is the one most teams skip. What scales first constrains everything after.

3. Pricing. Not a number, a structural decision that reshapes qualification, motion, and margin at once. Pricing restructures every layer it touches.

4. Functional coherence. Whether the functions optimize the system or their own dashboards. Function-level optimization is system-level debt.

5. Motion. How the company actually sells, and whether the playbook matches the stage the company is in now rather than the stage it was written for. Every playbook encodes the stage it was built for.

6. Distribution. Whether channels compose into a system or accumulate into a pile. Channel accumulation is not distribution architecture.

7. Metrics. Whether the numbers compound understanding or conceal decay. Every metric compounds or conceals.

8. The AI layer. Last on purpose. Agents installed on top of the seven layers below inherit whatever state those layers are in. AI amplifies the architecture it inherits.

Sequencing Is the First Decision

The layers are not a checklist to run in parallel. They are a build order, and violating the order is the single most common architectural failure in AI-native GTM.

The pattern is familiar to anyone who has watched a funded team tool up. The company buys the full stack at once: enrichment, engagement, intent, conversation intelligence, and an agent layer on top. Every tool works as advertised. The system produces more activity than the company has ever generated, and the pipeline does not move, because the agents are reasoning over stale CRM data, the qualification layer still encodes an ICP from two stages ago, and every function is optimizing its own metric. The company did not install an architecture. It automated its existing fragmentation at higher speed.

The corrective sequence is unglamorous. Eliminate the manual data hops first, starting with the CRM update, because every agent downstream reasons over that data. Fix qualification before scaling volume, because volume against a broken filter produces expensive noise. Install agents on clean structure, not instead of it. The full argument is in AI-Native GTM Is a Sequencing Problem, and its one-line version is the closest thing this publication has to a motto: the tools are not the problem. The order is.

The Leverage Repricing

Here is why this matters more than the usual category essay, and why the stakes are organizational rather than technical.

The architecture era is a one-time repricing of organizational leverage. A five-person team with the right architecture now outperforms a fifteen-person team running automation-era playbooks at intelligence-era costs. This is not a productivity-tool claim. It is a structural claim: the small team’s system compounds, every signal accelerating the next action, while the large team’s accumulation produces increasing activity and decreasing leverage. The gap between them is structural, which means it does not close with effort. The fifteen-person team cannot outwork a compounding system. It can only out-spend its own noise for a while.

The comfortable framing of this moment is “companies that fall behind on AI will lose.” That framing is wrong, and the wrongness matters. Every laggard will buy the same AI. The models are available to everyone, the agents are subscription products, and the stack is a credit card away. The actual risk is bolting abundant execution onto fragmented structure, funding your own noise at machine speed while a leaner competitor funds compounding. Two companies will run the same tools next year. One of them architected the system underneath. That difference, not AI access, is what the next several years will price.

If your product works and your pipeline does not, the constraint is structural.

The Revenue Architect

Someone has to do this work, and at most companies nobody formally does. 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. By Series B, architecture needs to be a designed responsibility, held by a specific person, because the system has grown past what any one function sees.

The revenue architect is not the GTM engineer. 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. One is a design function, the other an engineering function, and conflating them produces systems that are beautifully built to the wrong spec.

The honest boundary: companies without product-market fit do not need revenue architecture. They need a product people want. Architecture compounds a working motion. It cannot create one, and installing it early is how teams end up with elegant systems for selling something nobody buys.

Questions Operators Ask

What is the difference between revenue architecture and RevOps? RevOps operates the existing revenue system. Revenue architecture designs the system and its build sequence. RevOps is a function. Architecture is the layer of decisions above it.

Who needs revenue architecture? Companies past product-market fit where the pipeline has stopped compounding: rising CAC, softening win rates, headcount scaling faster than system coherence. Pre-product-market-fit companies need a product, not an architecture.

When did revenue architecture emerge? The term predates the AI era, but revenue architecture as a discipline emerged between 2022 and 2025, when AI collapsed the cost of execution and moved the constraint to design.

Is revenue architecture only for AI-native companies? No, but AI raised the stakes. When execution is abundant, structure becomes the only durable differentiator, because everyone can afford the same activity.

What replaces the traditional GTM org? Smaller teams running architected systems: humans on judgment and relationships, agents on execution, and the structure between them doing the compounding.

Where the Eras Leave Us

Four eras ended the same way. The scarce thing became abundant, the constraint moved, and the companies that noticed first spent a few years compounding while everyone else optimized the previous era’s bottleneck. Visibility, volume, insight, execution. Each was the frontier until it was table stakes.

Design is the constraint now. It will not stay scarce forever either, but the repricing window is open, and windows like this one do not announce their closing. The eight layers above are the map. Start Here is the reading path, and Law 01 is where the build order begins.

Subscribe now

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

The short version. How should an AI-native B2B company structure its GTM stack? In sequence, not in bulk. Step 1: eliminate the manual data hops, starting with the CRM update, because every agent downstream reasons over that data. Step 2: fix qualification before scaling volume. Step 3: install agents on top of clean structure, not instead of it. The failure mode this essay documents: companies that buy the full AI stack at once and automate their existing fragmentation at higher speed. The tools are not the problem. The order is.

Ramp’s June 2026 study tracked AI spending and workforce outcomes across 21,599 U.S. firms. The companies in the top tier of AI spend grew headcount by 10.2% over two years, with hiring gains extending into sales, administration, and customer success. The companies at the bottom of that distribution, averaging under $3 per employee per month, are mostly running chat seats with nothing to show for it.

Same tool category. Opposite results.

The gap is not technology. It is sequence. The companies compounding on AI made infrastructure decisions before they made procurement decisions. The companies stalling made procurement decisions and then tried to retrofit an infrastructure around them. That sequence does not work, and the data from the first half of 2026 is definitive on the point.

This playbook is the build sequence.

Step 1: Map the Revenue Motion Before You Touch the Stack

Before you evaluate a single tool, map the revenue motion end to end and identify every place where a human is moving information from one system to another.

This step is almost always skipped. Teams go straight from “we need AI” to “let’s evaluate vendors.” The vendor evaluation answers the wrong question. The right question is: where does latency exist in the current system, and what data needs to flow between which systems for an agent to eliminate it?

A typical mid-market GTM motion has six to ten manual handoff points between signal identification and rep action. A signal is identified in one tool. A human researches it in another. A human drafts an outreach in a third. A human logs the activity in the CRM. A manager reviews the CRM and decides on next steps. Each hop introduces latency. Each hop is also a place where context is lost and quality degrades.

Document those hops before you buy anything. The infrastructure you build will exist to collapse them. If you do not know where they are, you will buy tools that solve local problems but do not connect into a system, which is exactly how teams end up with six tools that each do something and none of which compound.

The output of this step is a written map of the revenue motion with every manual hop identified and labeled. That map becomes the specification for the infrastructure you are about to build.

Step 2: Hire the GTM Engineer Before You Buy the Stack

The single most common infrastructure error is buying tools before hiring the person whose job is to architect them into a system.

Fifty-four percent of the fastest-growing private B2B SaaS companies have a GTM Engineer on staff, per GTM Vault’s in-house research, with job postings up more than 200% year over year. The role exists because infrastructure decisions require someone capable of executing them. A RevOps hire optimizes the existing system. A GTM Engineer designs a new one.

The GTM Engineer takes the revenue motion map from Step 1 and specifies the agent architecture that will collapse the manual hops. They decide which systems need to communicate, what data the agents need to reason against, where humans stay in the loop and where they do not, and how the output of each agent feeds into the next step. SQL and Python appear in 38% of job postings for the role, but the core capability is systems thinking applied to revenue motion.

If you are not ready to hire a GTM Engineer, designate someone in the existing org to own the infrastructure decision before the procurement decision. That person needs enough technical fluency to evaluate vendor integrations and enough GTM context to understand what the system is supposed to produce. Running this decision through a committee of tool owners will not work. It needs a single accountable owner.

The GTM Engineer should sit close to the CEO or CRO, not inside RevOps. Infrastructure decisions constrain everything below them. The person making them needs the authority to make them.

Step 3: Choose Your System of Record First, Then Build Outward

The point-solution layer in GTM intelligence collapsed in the first half of 2026 for a specific reason: agents need data to be useful, and the data lives in the CRM.

HubSpot acquired Warmly in June 2026, absorbing person-level buyer intent natively into its customer platform. Zoom announced the acquisition of Common Room two days later, pulling buyer intelligence into its revenue platform. Clari and Salesloft had already merged. Apollo had acquired Pocus. The best-funded standalone GTM intelligence tools in the market were absorbed into systems of record inside twelve months.

The architecture implication is direct. The agent layer you build should live inside or natively connect to your system of record, not beside it. A standalone tool that sits outside the CRM requires a human to carry the insight from the tool to wherever the action happens. That human-in-the-middle step is the latency the agent was supposed to eliminate. When the agent lives outside the data, it does not eliminate the step. It generates output that still needs to be carried somewhere.

When evaluating your stack, start with the CRM and ask what agent capabilities exist natively or through direct integration. Build outward from there. Tools that require human handoffs to connect their output to the system of record are either transitional or wrong for the architecture.

Step 4: Design the Copilot Layer, Not the Autopilot Layer

The autonomous AI SDR was the most visible infrastructure mistake of the past eighteen months. The failure was architectural, not technological.

Benchmark and a16z deployed $74 million into 11x, the most-funded autonomous AI SDR in the category. By May 2025, 11x had lost roughly 78% of early ARR past the 90-day break clause. Teams that removed the human layer from outbound were reverting to hybrid models across the category. Reply rates on fully autonomous outbound run 1 to 3%. Reply rates on copilot-assisted outbound, where a human reviews, edits, and approves before the send, run 5 to 12%. A hybrid model delivers cost per opportunity of $847 versus $2,214 for AI-only deployment.

The autonomous SDR failed because it placed the human in the wrong part of the workflow. The assumption was: remove the human entirely. The correct architecture is: move the human to the decision point and remove the human from the preparation steps.

Design the agent layer to own preparation: signal research, account intelligence, first-draft outreach, CRM logging. Design the human layer to own judgment: reviewing agent output, approving or editing, managing the relationship through the sales cycle. The rep’s output per hour increases because preparation time drops. The agent’s output quality improves because a human is catching errors and the feedback loop closes.

Apply this architecture to every agent you deploy, not just outbound. Every agent should have a defined handoff point where a human reviews before the output moves to the next step. When that handoff point does not exist, quality degrades and buyers notice.

Step 5: Restructure What Humans Do, Not Whether to Keep Them

The companies spending the most on AI in the Ramp study grew headcount 10.2% and increased entry-level hiring by 12%, while the share of managers per rep shrank. These numbers are the output of a specific org design decision.

The traditional sales management layer existed because the system was opaque. Managers reviewed pipeline, listened to calls, coached on objections, and made prioritization decisions the system could not make on its own. Pipeline review runs off CRM data now. Call coaching is automated. Signal prioritization is agent-driven. The mechanical oversight functions that justified the management layer are being absorbed into the infrastructure.

What remains is the judgment layer: decisions that require relationship context, organizational knowledge, and the ability to read a situation no data set can read. That is a much smaller function than what most management layers currently contain.

The org design that follows is an AI-fluent junior rep layer operating with leverage that did not exist three years ago, supervised by a thinner management band accountable for outcomes rather than activity. The GTM Engineer and the agent layer absorb the activity monitoring function. The managers who remain manage the result.

Prioritize AI fluency in entry-level rep hiring above almost every other criterion. An AI-fluent rep inside a well-designed infrastructure runs at leverage a non-fluent rep cannot match regardless of experience. The leverage multiplier is the system. The human needs to be capable of operating it.

Step 6: Commit to a 12-Month Timeline, Not a 90-Day Pilot

Meaningful output gains from AI adoption appear 6 to 12 months after implementation begins. The curve does not bend in the first quarter.

The first 90 days are tooling and integration: getting systems to communicate, getting agents to reason against the right data, getting the stack to function as a system rather than a collection of separate tools. The next 90 days are calibration: adjusting workflows, correcting agent errors, building the habit layer on top of the tooling layer. The compounding begins around month six, once the team has refined the system enough that it runs with less correction and the feedback loop has produced measurable agent improvement.

A one-quarter pilot exits at month three, before the curve turns. The team sees marginal output improvement, concludes the investment is not working, and either abandons it or continues paying without scaling. This is the structural error of the pilot model: it evaluates a six-month investment on a three-month timeline and almost always reaches the wrong conclusion.

Budget and staff for 12 months from the start. Set internal expectations that output measurement begins at month six, not month three. Define what “working” means in outcome metrics before implementation begins, so the evaluation at month six is against a predetermined standard rather than a feeling. The teams that exit early almost always do so because no one defined success before they started.

Step 7: Measure Outcomes, Not Activity

The most common measurement failure in AI GTM implementations is tracking the wrong layer.

Activity metrics are what procurement decisions produce: prompts sent, emails drafted by AI, percentage of outreach that was AI-assisted, time saved per rep per week. These numbers are measurable and they trend upward quickly, which is why teams report them. None of them connect to revenue. They tell you the tools were used. They do not tell you whether the system produced a commercial return.

Outcome metrics are what infrastructure decisions produce: pipeline generated per seller, conversion rate change at each funnel stage, cost per meeting booked, revenue per head. These connect directly to whether the architecture is working. They are harder to isolate in the short term, which is why teams avoid them. They are the only numbers that answer the CFO’s question about tokenspend.

Design the measurement system in Step 1, not after implementation. Define the baseline for each outcome metric before the infrastructure goes live. Measure the same metrics at month six and month twelve. The delta against baseline is the only clean way to attribute the AI investment to a commercial outcome.

Teams that did not build the measurement baseline before implementation have no clean way to isolate the AI’s contribution after the fact. Every gain looks like it might have happened anyway. This is not a data problem. It is a design problem that was created in month one and cannot be fully fixed later.

What This Looks Like at 12 Months

A GTM org that ran this sequence correctly at the start of 2025 looks like this at the midpoint of 2026.

The agent layer handles signal identification, account research, outreach drafts, and CRM logging. Reps review and approve agent output at a defined handoff point before anything goes to a buyer. The management layer is thinner, with pipeline reviews running off CRM data rather than rep self-reporting. The GTM Engineer owns the infrastructure and iterates the agent pipelines based on outcome metrics. AI spending runs at $30 to $40 per employee per month across multiple models and agents, not a single chat seat.

The org is younger and more AI-fluent than it was twelve months ago. It is flatter, with fewer managers per rep, because the oversight function that justified the management layer has been absorbed by the system. Pipeline per seller has improved measurably since month six. The CFO can answer the tokenspend question because the measurement system was built before the infrastructure was deployed.

This is the pattern across the operators running the winning architecture right now. The inputs that produced it are the seven steps above, in that sequence.

The Failure Mode to Avoid

Every team that stalled on AI GTM made the same mistake: they started at Step 3 or Step 4 and never went back to do Steps 1 and 2.

They bought a tool that looked compelling. The tool worked in isolation. It did not connect cleanly to adjacent systems because no one had mapped the revenue motion or specified what the connection needed to do. They bought another tool to fill the gap. The gap did not close because the gap was architectural, not technological. They are now running six tools that each do something and none of which compound.

The fix is not buying better tools. It is stopping the procurement cycle, going back to Step 1, and designing the system the tools are supposed to serve. That requires the GTM Engineer in Step 2 to lead the redesign, which often means the first GTM infrastructure hire is also the person who audits and rationalizes the existing stack before adding anything new.

Infrastructure decisions made late are more expensive than infrastructure decisions made first. But they are less expensive than continuing to stack procurement decisions on top of a system that was never designed.

GTM Vault publishes the architecture behind what the best operators are building. More at gtmvault.co.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

Fourteen percent of AI agents go live with full approval. The rest are running anyway. They were never registered. Never audited. Never governed. They are chaining tasks, spawning sub-agents, and crossing system boundaries at machine speed inside enterprise environments with more access than any human employee would be granted. The identity stack can tell you who logged in. It cannot tell you whether the agent spawned from that login should be querying that database right now, to that resource, in that context.

That gap is not an authentication problem. Authentication solved itself. The hard part is what happens after the door opens.

Mark van Oppen is CRO at SecureAuth. SecureAuth has been in identity infrastructure for twenty years, trusted by some of the largest banks and enterprise organizations in the world, with user populations at a scale that makes their uptime stakes materially career-defining for the security teams running on them. Mark spent fifteen years in core infrastructure and four years in customer identity before joining two months ago to run the GTM motion for what he sees as the most structurally important category emerging in enterprise security right now. SecureAuth is building what they call continuous authority: a unified platform that governs every identity type (workforce, customer, partner, and non-human agent) with real-time action-level control enforced at every session and every interaction, not just login.

In GTM 47, Mark breaks down why CISOs who believe they have identity covered are right about the old definition and completely exposed to the new one, how a fintech executive who vibe-coded a capacity planning app accidentally started querying HR data to forecast which employees might become pregnant, why unique monthly active users is the wrong metric in a world where one human can spawn a hundred agents overnight, and how SecureAuth creates urgency with buyers who believe agentic AI is still eighteen months away from their organization. He explains the 50:1 ratio and why it is the number that opens the conversation, why IT buyers need the blindfold removed before CISOs can apply policy, and why the AI deployment decision most enterprises will regret is betting on a single LLM provider to underwrite their risk posture.

This is not a conversation about authentication. It is a conversation about what identity governance has to become when agents have more access than humans, operate without human friction, and cannot exercise the contextual judgment that the old identity model assumed.

Inside this episode

This episode maps the structural gap between what enterprise identity stacks were built to do and what they need to do the moment an agent steps through the login they verified.

Mark opens with the definitional problem. CISOs are not wrong that they have identity covered. Identity verification works. The problem is that identity changed. The old model assumed a human on the other side of the login, a person with judgment, context, and friction. Rick types at a human rate. Rick knows that querying an HR database for pregnancy data is a PII violation. The agent Rick spawned to run a capacity forecast does not. It was given an objective and it pursued it, all the way to a liability. SecureAuth’s fintech customer caught it before anything was disclosed. The identity stack did not catch it at all, because the agent had cleared authentication and everything downstream was ungoverned.

We go deep on the architectural difference between authentication and continuous authority. Authentication is the front door. It confirms that Mark is Mark at the point of entry. Continuous authority is everything downstream. Does this agent, spawned from Mark’s session, have the right to make this specific read request to this specific database at this specific moment? The answer most enterprise stacks can give is: we verified Mark at login. The answer continuous authority requires is: we verify this action now. Every action. Every session. Downscoping where the agent’s access exceeds its required scope. Step-up verification where the action exceeds the standing permission level.

We cover the 50:1 ratio and what it actually means in practice. Fifty non-human identities for every human one. The number sounds dramatic until Mark explains the mechanism. Mark runs an automated report. That report queries Salesforce, publishes a summary to Slack, and writes a line into a Confluence page. Three sub-agents. Three separate access events. All using Mark’s credentials. All invisible to the identity stack. Most enterprises have no inventory of what is running inside their environment right now, which systems those agents are crossing, or what access they have inherited from the human sessions that spawned them. The IT buyer’s first interaction with SecureAuth’s agent authority product is described as removing the blindfold. The reaction, consistently, is: I did not know any of this was already in here.

We go into how Mark creates urgency with buyers who believe they are not yet in scope. The most common deal-stalling belief is that agentic AI is still months away for their organization. Mark’s approach is not to push. It is to present back the buyer’s own information. How many engineers do you have? What percentage of them are using any AI tool? What percentage of those engineers have access to critical-path systems? If the answers are A, B, and C, then D is unavoidable: the risk surface is already active, already sized, and the cost of a single incident against it vastly exceeds the cost of addressing it now. Mark is explicit that this is not a sales tactic. It is a structural argument. The buyer concludes D on their own. The question is just whether they get there before something bites them.

We cover where deals stall. The most common failure mode is a buyer who insists AI is not yet happening in their organization and that they have not sanctioned it. Mark presses. What about individual Claude or ChatGPT seats? The answer is usually some version of they should not have access or they do not have access. The reality is that this has not been true in a single customer interaction SecureAuth has had. The question is not whether AI workloads are running. It is how many, how far along, and how much of the access risk is already realized.

We go into buyer segmentation by maturity. The IT buyer’s moment is removing the blindfold. Once they see what is running, they know they have a problem. The CISO comes in one step further along: they know what is running, they need to apply policy, constrain blast radius, and move toward a least privilege model where each agent only has access to the specific systems required for its specific task. The framing Mark uses for the CISO is the department of yes. Security teams are almost always in the position of blocking new tools to maintain risk posture. Continuous authority governance is the architecture that lets the CISO say yes. Yes, use that AI tool. Yes, deploy that agent. Because the governance layer underneath it is already enforcing the constraints.

We cover the pipeline motion. Majority inbound, augmented with high-propensity outbound using intent data. No core partnership motion, but partner-friendly where customers bring partners into the evaluation. The structural constraint on deal motion is that identity is high risk, low reward from the buyer’s perspective. Best case, no one notices anything changed. Worst case, employees and customers lose access and it is very visible. That asymmetry means there has to be either acute pain in the current approach or a recognized looming iceberg to pull a deal forward. The iceberg narrative is the AI agent security question. Most buyers have not been bitten yet. The ones moving are the ones whose leadership has done the math.

We close on the rapid-fire section. The biggest misconception enterprises have about AI agent risk: that it is static. A train accelerates and stops but stays on the rails. An AI agent can reverse backward up the sidewalk. Most enterprises are preparing for a train. They are getting a taxi. The AI deployment decision most enterprises will regret: betting that they can govern their risk posture by standardizing on one LLM provider. Every organization already has employees using Claude, Gemini, ChatGPT, and some home-built variant. The governance layer has to be Switzerland. It cannot be anchored to one provider’s architecture. The metric every security team tracks that measures the wrong thing: unique monthly active users. One user. One hundred agents overnight. The metric is no longer correlated to the actual risk surface.

Listen & subscribe now across:

Apple // Spotify

Discussed in this episode

00:00 Intro

01:45 Why Mark joined SecureAuth and what the first two months revealed

04:23 The snapshot problem: customers who do not know what SecureAuth can do

05:57 What CISOs think they have covered and what actually changed

07:30 The fintech executive, the capacity report, and the pregnancy forecast

10:07 Continuous authority versus authentication in practice

11:28 Where other identity vendors' coverage ends

12:27 Buyer segmentation: IT buyers, CISOs, and how company size shapes the motion

13:56 What a qualified deal looks like right now

15:26 Where deals stall and the resistance to admitting AI is already running

17:56 How to create urgency with buyers who think they are not yet in scope

20:21 Building the category with enterprises who think agentic AI is 18 months out

22:07 Rapid fire: the train versus the taxi, the wrong metric, the deployment regret, and what CROs get wrong selling into security

Key takeaways

1. Authentication and authority are different problems. Only one of them is solved. Most enterprise identity stacks can verify that a user is who they say they are at login. They cannot verify whether an action taken three steps downstream, by an agent spawned from that session, is within scope. That gap is not a configuration problem or a policy gap. It is an architectural gap. The model was built for human users with human friction and inherited those assumptions into the agent era without modification. Closing it requires a different layer: real-time, action-level authority verification operating at machine speed, not at the cadence of a human login event.

2. The 50:1 ratio is not a statistic. It is the shape of the exposure. Fifty non-human identities for every human one. The number is the direct output of agents spawning sub-agents, each of which inherits the credentials of the session that spawned it. One automated report becomes three agents, three access events, and three ungoverned actions, all attributed to one human identity. Most enterprises have no inventory of what is running. The IT buyer’s reaction when they first see the map is consistent: I did not know any of this was already in here. The inventory does not exist until someone builds it, and building it is the first conversation.

3. Urgency is not something you create. It is something you help buyers recognize. The most effective motion for an identity security vendor is not a compelling reason to act. It is structured discovery that helps the buyer construct the argument themselves. How many engineers? What percentage using AI tools? What percentage with critical-path access? The inference chain from those inputs arrives at a risk magnitude the buyer computed from their own numbers. The vendor does not assert that there is a problem. The buyer concludes it. The deal motion starts when the buyer owns the conclusion.

4. Agentic AI is already inside every enterprise. The governance gap is already active. Every deal that stalls on “we are not yet using agentic AI” has not survived a conversation about individual seat usage. Claude. Gemini. ChatGPT. Every organization has employees using at least one of these tools, sanctioned or not. Every one of those tools is capable of spawning agents. The question is not whether AI workloads are running. It is how many, and how much of the access risk is already realized. SecureAuth has not yet encountered a customer where the answer to that question is zero.

5. Governance architecture has to be LLM-agnostic. The AI deployment decision most enterprises will regret is building risk posture on top of a single provider’s tooling. Standardizing on Claude does not mean every employee uses Claude. It means every employee using something else is operating outside the governance layer. The identity and authority infrastructure has to function as Switzerland: agnostic to provider, consistent across model types, and stable across the provider switching that will happen continuously as new models ship. Any architecture that assumes one LLM provider is already incomplete.

6. Unique monthly active users is the wrong metric in an agent-native environment. One user. One hundred agents. One overnight session. The volume of queries hitting a system is no longer correlated to the number of humans behind them. SecureAuth’s CTO ran over a hundred agents in a single overnight build session. One human. One session. One hundred independent access events. The metric that has historically anchored security posture has already decoupled from the actual risk surface. What replaces it is not yet standardized, but it has to track actions and authority, not users and logins.

Frameworks from the episode

1. Continuous authority as the operating layer for AI identity governance

The architectural premise of SecureAuth’s platform. Authentication confirms identity once at login. Continuous authority verifies the right to act at every subsequent action within that session and downstream from it. Downscoping where the agent’s access exceeds its required scope. Step-up verification where the action exceeds the standing permission level. Perpetual audit log across every action taken by every identity type, human and non-human. The practical output is a CISO who can say yes to new AI tools because the governance layer enforces least privilege at execution time, not at provisioning time. The org moves faster because the guardrails are structural, not behavioral.

2. The A, B, C to D urgency framework

Mark’s structured discovery approach for helping buyers recognize risk they already carry. The framework works by surfacing the buyer’s own data and walking them through a structured inference. How many engineers do you have? What percentage are using any AI tool? What percentage have access to critical-path systems? If A and B and C, then D. D is the risk magnitude computed from their own numbers. The vendor does not assert a problem. The buyer concludes one. The approach works because it is accurate: the risk is already there, and the discovery is just helping the buyer see it before an incident makes it visible.

3. The train versus the taxi

The CEO of SecureAuth’s metaphor for the core architectural difference between static automation and AI agents. A train has more power than a taxi. It is faster and it can carry more. But it stays on the rails. A taxi can reverse backward up the sidewalk. Enterprise identity governance was built for trains: scripted processes, predictable paths, bounded access. AI agents operate differently. They can change direction, query unexpected systems, and pursue an objective through paths no one anticipated. The governance architecture that works for trains fails the moment the taxi shows up, and every enterprise with AI tooling deployed already has taxis running.

What to do this week

• Map what is actually running

  Before evaluating any identity governance vendor, run a discovery pass on your own environment. Ask IT to pull every active service account, API key, and OAuth token from the last thirty days. The list will be longer than expected. The question is not whether agents are running. It is how many and what they have access to. If there is no inventory, that is the first problem. The inventory gap is the governance gap.

• Run the A, B, C to D exercise on your own org

  Take the inputs Mark uses in sales conversations and apply them internally. How many employees in engineering, sales, and operations? What percentage are actively using AI tools, sanctioned or not? What systems does that population have access to? The output is a rough map of the ungoverned surface area. Most organizations that complete this exercise come out with a number significantly larger than the risk posture they believed they were carrying.

• Identify who owns agent governance today

  Not formally. In practice. If a rep’s AI assistant starts querying a system it was not explicitly intended to access, who finds out? How quickly? Is there a response policy? If the answer to any of those is unclear or nobody, the governance gap is active right now. Naming the gap is the precondition for closing it.

• Audit your LLM standardization assumption

  If the org has standardized on one AI provider for governance purposes, survey actual usage. Ask ten engineers and ten salespeople what AI tools they used in the last week. The number of providers will be higher than the standardization policy assumes. Governance architecture that does not account for the actual distribution of tool usage is producing a false sense of coverage, not coverage.

Why this matters

The first generation of enterprise AI deployment was access. Give the team Claude. Give them ChatGPT. Connect a few systems. See what they build. The implicit security posture was: we already govern identity, we are covered. Authentication is solved. We know who is logging in.

The problem is that knowing who logged in is no longer the hard part. The hard part is what happens in the session after the login, when an agent spawns three sub-agents, each of which inherits the credentials of the original session and proceeds to query systems the human user would have known not to touch. The fintech executive building a capacity planning tool did not intend to surface pregnancy forecast data. The agent did not know it was not supposed to. The identity stack did not flag it because the agent cleared authentication and everything downstream was ungoverned. Every enterprise running agents on top of a traditional identity architecture has this gap. Most have not been bitten yet.

The category Mark is running GTM for is not identity security in the conventional sense. It is the governance architecture for the AI era. The question it is answering is not who are you. It is should you be doing this right now, to this resource, in this context. That question cannot be answered at login time. It can only be answered at execution time, for every action, at machine speed.

The orgs that build continuous authority governance before an incident forces the conversation are the ones where the CISO gets to say yes. Yes to the new AI tool. Yes to the new agent deployment. Yes to moving faster than the security posture previously allowed. The orgs that wait are the ones that discover the gap through an incident that was already inside before anyone saw it coming.

This is GTM Vault.

If this episode changed how you think about the governance layer underneath your AI deployments, share it with the CISO or head of IT at your organization. The question is not if the gap exists. It is whether you find it or it finds you.

Connect

Follow Mark van Oppen // SecureAuth

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. One working session to identify your primary GTM constraint and design the 90-day architecture to resolve it.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

The bottleneck in outbound moved. It is no longer sending capacity, and it is no longer data access. It is the three to five hours a GTM engineer spends in Clay setting up a single campaign: building the table, configuring the waterfall, writing the AI prompt columns, wiring the export, loading the sequencer. At that cost per campaign, you ship one or two tests a week. The winning angle exists somewhere in the space of messages you never had time to test.

In episode six of Show Me Your Stack, Tim Scheuer walks through how he collapsed that setup time to forty minutes. Tim is the co-founder of Oxygen, a CLI and MCP for go-to-market that lets Claude Code orchestrate the entire GTM stack. The campaign he demos was scraped, enriched, personalized, and launched by prompting an agent in natural language. Three to four exchanges back and forth. No table building. The result from the first 180 emails: eight positive sales opportunities in one of the most over-targeted prospect pools in B2B.

Tim ran a GTM engineering service company before building Oxygen, so the comparison is not theoretical. He has done this work the manual way, at billable rates, inside Clay. His current stack is Oxygen, Claude Code, Instantly, and Zapmail. The interesting part is not the tool list. It is what becomes economically possible when campaign creation stops being the expensive step.

The Target Problem: 1,900 Founders Everyone Else Is Also Emailing

Oxygen sells to technical, fast-growing SaaS companies. The densest pool of those is the Y Combinator directory, which makes it a goldmine and a minefield at the same time. Every outbound vendor, agency, and tool company is emailing YC founders. The accounts are high value and the inboxes are saturated. Reaching them is not the hard part. Differentiating in the inbox is.

Tim’s first move was to tell Claude Code to scrape the YC directory. It returned more than 1,900 SaaS founders from recent batches, with names, LinkedIn profiles, and batch data. That is the raw list. On its own it is worth nothing, because everyone targeting YC has the same list. The campaign’s edge had to come from what happened to the list next.

Read more

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

At $0-1M ARR, you need 5 GTM rules to stay alive. At $25M+ ARR, you are running 62.

That number is the diagnosis. Not a benchmark or an aspiration. A failure mode in the making.

At 5 rules, a founder can manage the list manually. Post on LinkedIn, close the first deals personally, do not hire an SDR until the playbook is proven. Five rules fit in your head. They do not require infrastructure. They require discipline.

At 62 rules, the list has become the coordination problem. Somebody owns the LinkedIn ads. Somebody owns the Clay sequences. Somebody owns the ABM motion. Somebody owns the ICP scoring refresh. Each rule is a project. Each project is a queue. The plays are real. The problem is that 62 real plays, managed as 62 separate initiatives, compound overhead faster than they compound pipeline.

The best GTM teams are not running more plays. They are running fewer, better-connected ones.

Subscribe now

Why the Play Mental Model Breaks

The play is a useful unit for explaining what should happen. It is a poor unit for building what actually runs.

A play requires someone to own it. Someone to update the list, pull the accounts, write the copy, QA the sequence, and push the button. At $1-5M ARR, ten rules are manageable. The founder documents the playbook, the first AE closes most deals, the first inbound motion starts to compound. The coordination cost is friction, not failure.

At $5-10M ARR, the rules double. The five-tool stack arrives: CRM, Clay, Instantly, Common Room, n8n. Per-account AI research before every cold email, sub-$0.10 per account. Multi-touch attribution replaces last-touch. Each of these is a real capability. Each requires ownership. What kills teams at this stage is treating $5M like $1M: keeping the founder in every deal, running plays without the system underneath them.

At $10-25M ARR, 50% or more of GTM research, scoring, and drafting is supposed to be automated. Dedicated demand gen, performance marketing, product marketing, and ABM as separate functions, not generalist roles. CAC payback under 18 months. What kills teams here is ABM without RevOps support. The motion is right. The infrastructure to run it is not there.

The deeper issue is that plays do not share infrastructure. A closed-lost re-engagement play and a champion tracking play might draw from the same CRM data, the same enrichment layer, and the same outbound tooling, but if they were built separately, they operate separately. The signal that would trigger one play has no visibility into whether the other play already contacted the same account last week. Overlap, contradiction, and redundancy accumulate invisibly.

The GTM teams that have solved this noticed that most plays draw from the same four or five signal types and built a single infrastructure layer that monitors all of them continuously, routes outputs to the right workflow, and enforces the rules that prevent plays from contradicting each other.

When you build that layer, the play count becomes irrelevant. The system decides what runs and when.

The Five Signal Types That Drive Most of It

The plays that produce pipeline in B2B compress into five underlying signal categories. Every play is a response to one of them. Building the system means building infrastructure around the signal, not around the play.

1. Account motion

   Companies changing their infrastructure, headcount, or technology stack in ways that indicate budget, urgency, or displacement opportunity. Job postings, tech stack changes, funding events, and leadership transitions all belong here. The system version monitors all of these simultaneously, scores the account against your ICP in real time, and initiates the sequence without a human reviewing a list. The manual version surfaces the same signal three weeks later when someone runs a Bombora export.

2. Relationship change

   Champions leaving, former customers changing roles, mutual connections arriving at target accounts. A champion who moved to a new company six months ago has already formed a vendor preference. The one who moved last week has not. The window is 48 hours, not 48 days. The manual version runs a monthly Salesforce report and gets to it when someone has bandwidth. At that point, the window is gone.

3. Buying intent

   Product behavior, high-value page visits, G2 reviews, competitor evaluation signals. Intent decays in hours, not weeks. By the time a rep sees the alert in their inbox, reviews it, pulls the account, and decides whether to reach out, most windows have already closed. The system that acts on the signal automatically is not a luxury. It is the only version that works at the speed the signal requires.

4. Expansion surface

   Accounts approaching usage limits, multiple users from the same domain on a free tier, admin behavior that indicates enterprise readiness. The system version connects product data directly to the outbound motion, triggering a sales touch when the behavioral threshold is crossed. The manual version catches it in the next QBR.

5. Competitive displacement

   Accounts visibly dissatisfied with a competitor, evaluating alternatives, or entering a renewal cycle. The signal is harder to source and easier to misread, but the accounts it surfaces are the highest-intent pipeline in your TAM. The system version monitors review platforms, job postings, and LinkedIn activity continuously. The manual version checks quarterly.

The rest of this post is for paid subscribers: the architecture underneath these signals, and what it looks like when a GTM engineer actually builds it.

Read more

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

The product is no longer the moat. For most founders reading this, that sentence either lands as obvious or alarming. If it feels obvious, the question is whether your GTM motion reflects it. If it feels alarming, this piece is for you.

Every era of B2B software is defined by a single binding constraint. The companies that win each era are not necessarily the ones with the best product. They are the ones that identify what the binding constraint is, build their entire motion around collapsing it, and move before the previous generation realizes the game changed.

The constraint that defined the last decade was building. Shipping enterprise-grade software required two to four years of runway, ten to thirty engineers, and infrastructure spend that only institutional capital could absorb. The product was hard to copy, so the moat lived inside it.

AI collapsed that constraint. The cost to build is approaching zero. The cost to copy is even lower. A category leader that once had six months to compound a product advantage before a well-funded competitor matched it now has weeks. The product is still necessary. It is no longer sufficient.

The moat moved. It is sitting in distribution now.

Subscribe now

The Historical Record

The relationship between distribution and product outcome is not new. It shows up across the last fifteen years of B2B software in the same pattern: the company that builds the audience first wins, even when it has the weaker product. The examples closest to this audience make the point most clearly.

ZoomInfo had the deeper data asset, the larger enterprise contracts, and the sales machine to match. Apollo entered the market with a thinner database and a fraction of the budget. What Apollo had was distribution: a freemium motion that put the product directly in the hands of SDRs and revenue operators who couldn’t afford ZoomInfo’s six-figure contracts. Those users became evangelists. They brought Apollo into new companies when they changed jobs. They built sequences, shared templates, and talked about it in Slack communities that ZoomInfo’s field team had never set foot in. Apollo reached a $1.6 billion valuation not by out-featuring ZoomInfo but by owning the distribution layer ZoomInfo had ignored.

Gong did not win the conversation intelligence category by building a better recorder. Clari, Chorus, and a half-dozen other tools were competing on features at the same time. Gong won by creating the category itself. The “revenue intelligence” framing, the state of remote selling reports, the relentless content engine that owned every search term a revenue leader would type on a bad pipeline quarter. By the time enterprise buyers were ready to evaluate, Gong was already the default answer. Chorus sold to ZoomInfo for $575 million. Gong’s last valuation was $7.25 billion.

Clay became the operating system for GTM engineers before most companies knew what a GTM engineer was. The product was technically sophisticated and genuinely hard to copy. But the moat was not the product. It was the community of operators who had built their entire outbound infrastructure on Clay, documented it publicly, and evangelized it in every GTM Slack, newsletter, and conference session they could find. When competitors with similar feature sets entered the market, they were not competing against Clay’s product. They were competing against Clay’s distribution, which had already saturated the audience that mattered.

What is different now is not the pattern. It is the stakes. In each of those examples, distribution beating product was still somewhat exceptional, the result of a founder who saw an angle. In the current era, it is the only durable path. The window to build a product moat is gone. Distribution is what remains.

If you want to see distribution-first operators break down the exact systems they built, that's Show Me Your Stack. Every episode is here.

The Sequence Changed

Founders have been given the same playbook for two decades. Build the product. Find product-market fit. Then figure out go-to-market.

That sequence was designed for a world where the product was hard to copy and distribution was something you bolted on after you had proof. That world is gone.

Go-to-market is not what you do after product-market fit. It is how you get product-market fit. The audience you build before launch is the population you test with. The trust you earn before the product is finished is the credibility that converts skeptics into early customers. The brand you establish in a category before anyone else arrives is the default that compounds for years after the market matures.

Ironclad became the default contract lifecycle management platform for in-house legal teams before its product could match what DocuSign or legacy CLM tools offered on paper. The feature gap was real. The distribution gap was larger. Ironclad showed up inside legal operations communities, built trust with general counsels before they had budget to evaluate vendors, and established the category name before the category had a formal RFP process. By the time procurement got involved, the decision was already made. Replit ran the same play with a different audience. It built distribution through students and early-career developers who had no purchasing authority. When those developers moved into engineering roles at companies with real budgets, they did not run a vendor evaluation. They installed what they already trusted. Replit’s enterprise motion did not start with enterprise sales. It started with a free tier that its competitors dismissed as a hobbyist product.

The founders who deferred distribution are learning this at Series A, when a competitor with a comparable product and an established audience is converting faster without a better product. By then, catching up costs more than starting right would have.

The Benchmarks Confirm It

The pace at which this is playing out is structurally different from any previous software cycle.

Source: a16z, “What ‘Working’ Means in the Era of AI Apps” (June 2025)

The median enterprise AI startup reaches $2.1 million ARR by month twelve. The top quartile reaches $5.3 million. What was best-in-class for SaaS companies a decade ago, $1 million ARR in year one, now sits below the median for AI-native companies. Series A rounds are happening at nine months post-revenue.

Markets are getting called earlier, with less data and higher conviction, because the investors who wait for traditional proof points are being priced out. The companies that establish default-brand status in a new category before the market decides do not need to maintain it aggressively. They need to establish it once. After that, the compounding does the work.

The implication for founders is not that they should move faster on product. They should move faster on audience. The window between category creation and category lockout is compressing in direct proportion to how fast the product can be copied.

The Anthropic Signal

The fastest-growing software company in history is concentrating its hiring around how to sell, not just how to build.

Source: boards.greenhouse.io/anthropic · as of May 27, 2026 · figures approximate

Sales is Anthropic’s single largest open department. It accounts for one in five open roles, ahead of AI research, product engineering, and every other function. The company with arguably the strongest model position in the world is betting more on distribution than on product right now.

This is not a coincidence. It is the logical conclusion of the constraint shift. When the product can be matched, the durable advantage lives in the relationships, the brand presence, and the market access that a well-built GTM motion produces. Anthropic knows this. The companies that survive the next decade will build accordingly.

Distribution Is a System, Not a Channel

The mistake most founders make when they accept the distribution-first thesis is treating distribution as a single channel decision. They pick LinkedIn, or a podcast, or a newsletter, and optimize it in isolation. That is not distribution. That is a channel experiment.

Distribution is a system with inputs, outputs, and feedback loops. The audience you build in one channel becomes the distribution mechanism for every channel that follows. The trust you earn through one piece of content becomes the conversion layer for the next product you ship. The ICP you identify through early distribution informs the product roadmap that deepens the moat.

The founders winning the Distribution Era are not the ones with the largest followings. They are the ones who built the tightest feedback loop between distribution and product, so that audience growth and product-market fit converge instead of developing in parallel.

That convergence is the compound return that distribution provides when it is treated as a system. A channel is a tactic. A distribution system is what makes the next product launch, the next category expansion, and the next pricing increase easier than the last one. The audience you built absorbs each of them before the market has time to generate friction.

The Structural Implication for GTM Teams

If you are running GTM at a company where distribution is still treated as a downstream activity, the constraint is not budget or headcount. It is sequencing.

The GTM teams that are winning are not running larger programs. They are running earlier ones. They are building the audience before the product is finished, establishing the brand before the category is defined, and converting the trust they earned in distribution into pipeline at a rate that outbound programs cannot match on a comparable cost basis.

The product still has to be exceptional. That requirement did not change. The order changed. Build the audience first. Ship the product into a market that already believes in you.

The moat is not inside the product anymore. It is in the relationship between the product and the people who were already waiting for it.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

Enterprise account lists are too long to work and too short to ignore. The TAM is mapped. The named accounts are assigned. Reps still spend their week researching the wrong 50 companies because nothing in the system tells them which five to actually open today. This is not a coverage problem. It is a prioritization problem masquerading as one.

In episode five of Show Me Your Stack, Umar Farooq Adam walks through how he solves it at a Global Systems Integrator pushing hard into EMEA on the back of sovereign cloud trends and cloud repatriation. The client has a TAM of more than 150,000 enterprise accounts. They reach out to 300 of them every month. The system Umar built is what decides which 300.

Umar started as an inside sales rep for APAC at Hitachi. He did not wait for someone to build better tooling. He built account research automations to improve his own selling, got pulled into a global pilot, increased lead quality by 60%, and compressed weeks of manual research into two days. He now runs GTM programs globally at Hitachi Vantara and consults IT MSPs and ISVs on automating GTM at gtmstudio.xyz. His stack is Clay, HubSpot, Chili Piper, Outreach, and the Power Platform with the rest of the M365 suite. The unusual part is not the tools. It is how he wires them together inside an enterprise where the data lives in Salesforce, the workflows live in Microsoft, and the motion has to land in both without breaking either.

Subscribe now

The Client Problem: Project-Based Selling Into a Commodity Signal Window

Systems integrators do not sell on subscription. Every deal is a project. There is no recurring revenue base to expand against, no predictable renewal motion to anchor outbound timing. The buying window opens when a customer’s infrastructure is aging, their vendors are consolidating, or their cloud workloads are ready to move. The GSI’s job is to be present the moment that window opens, not six months after the deal was already decided.

The sovereign cloud trend and the cloud repatriation window in EMEA created a specific version of this problem. A large cohort of enterprise accounts are evaluating moves from cloud-heavy infrastructure back toward on-premises solutions, driven by data sovereignty regulation, cost repatriation, and one specific structural event: a major mainframe supplier is going end of life. There were three players providing mainframe systems. One is closing that business. The accounts still running those systems need to move, and they need a systems integrator to help them do it.

The window is real. The signal is public. The problem is that 150,000 enterprise accounts fit the rough profile, and the GSI does not have 40 sales reps making 200 dials a day. They have a tight outbound function and a need to be surgically right about which 300 accounts deserve time this month.

Before this system, they were spending £300,000 a year with a specialized research firm in London to answer that question manually.

Read more

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

I built my first four GTM Vault skills over a quarter. A writing skill that encoded my voice and structural rules. A thumbnail generator wired to the brand templates. An engaged-subscriber outreach workflow. A sponsor outreach pipeline. Each one worked. Each one saved real time on the recurring task it was built for. I was running all four every week.

Two months in, I noticed something. The leverage had stopped growing. The fourth skill produced roughly the same incremental gain as the second one had. Each skill kept saving time on its specific task. The team and I were operating better than before, but not differently. The compounding curve I expected had not shown up.

The diagnosis was structural and I had not noticed it. The four skills were not a stack. They were four tools sitting next to each other. Each one had been designed to be run alone. The thumbnail skill had no idea what the writing skill had produced. The sponsor outreach pipeline did not reference the same brand context as the subscriber outreach. Each skill was carrying its own snapshot of voice, ICP, and format. When I updated one, I had to remember to update the others. The skills were running. They were not composing.

The constraint is not the number of skills. It is whether the skills compose. A skill is a tool. A stack is a system. The math between the two is not similar.

Subscribe now

The Skill Stack

The Skill Stack is a coordinated set of skills designed to compose, where the output of one skill is structured to be the input of the next. The skills share context. They reference each other. They participate in workflows that fire them in sequence. The leverage produced by a stack is multiplicative, not additive, because every skill operating on the output of an earlier skill is operating on work that has already been leveraged.

The math is non-linear, not multiplicative.

Five isolated skills, each saving 30 minutes on a single task, produce five separate 30-minute savings. Real productivity. The operator still has to run each skill, copy outputs into inputs, switch tabs, and reformat data between them. The savings cap at the time each individual task takes to manually run, plus the orchestration overhead between them.

Five stacked skills produce a different kind of leverage. The skills do not just save time on individual tasks. They run as a single workflow that the operator no longer has to orchestrate. The cycle time of the entire workflow collapses, because the manual handoffs between skills disappear. An isolated skill saves time within a task. A stack saves the operator entirely from the workflow.

The arithmetic difference is not 5 × 30 minutes versus 32 × 30 minutes. It is 5 × 30 minutes of operator-attended task work versus a workflow that runs ambient and produces a finished output the operator only has to review. The chain that took an hour and a half to manually run on isolated skills runs in under ten minutes on a stack, and most of that time is the operator reading the output. The leverage is not in the multiplication. It is in the disappearance of the operator from the loop.

This is the math most operators have not seen because the question of whether their skills compose has never been asked.

Why most operators build isolated skills

The default mode of skill-building is the worst possible mode for composition. The operator notices a recurring task that takes too long, builds a skill that does that task, ships it, and moves on. Every skill is built in the context of the single task that prompted it. The output format is whatever was convenient for the operator to read. The context the skill loads is whatever the operator typed into the SKILL.md file in that session. The skill never imagines being called by another skill. It is a tool built to be run alone, and the tools you build to be run alone do not compose.

The pattern is sticky for three reasons.

First, building a skill feels like the unit of progress. The operator can demo “I built a skill” but cannot demo “I designed a stack.” The visible output of building maps to one skill at a time, so the operator’s instinct to ship pushes toward isolated artifacts.

Second, composition requires upfront architecture. To build a stack, the operator has to decide in advance what the output schema of each skill should be, what shared context will be referenced across the stack, what workflows will fire the skills in sequence. This work has no immediate payoff. The first skill in a stack costs more to build than the first isolated skill, because the architecture has to be designed before the implementation. Most operators do not pay this cost because they do not see the payoff yet.

Third, the team usually does not have the discipline to enforce composability across multiple operators’ skills. One operator builds the research skill. A different operator builds the outreach drafter. They do not coordinate. The two skills cannot consume each other’s output because nobody designed them to. Building stacks requires either a single architect or a team-level convention, and most teams have neither.

The four design principles for stacks

Stacks are not built. They are designed. Four principles separate a designed stack from a pile of co-located skills.

1. The first is output schemas. Every skill in a stack has a defined, structured, predictable output. Not a paragraph. A specified format that downstream skills can consume without parsing. An account research skill that outputs an unstructured page is a research skill. An account research skill that outputs {company, signal, buying_committee[], hook_angles[], next_step} is a stack-ready research skill. The schema is the contract that makes composition possible.

2. The second is shared context. Stacks reference a single set of context files (icp-definition.md, positioning.md, competitor-radar.md, anti-positioning.md) that every skill in the stack pulls from. Skills that each maintain their own context fragment the team’s knowledge into N copies and guarantee drift. Stacks share context the way well-designed software shares dependencies: one source of truth, referenced by everything that needs it. This is the structural shift I named in the context layer becoming the operating system, now applied at the skill layer.

3. The third is composability by default. Every skill is designed assuming it will be called by another skill. The skill receives structured input and emits structured output. It does not require the operator to manually copy/paste between skills. It does not assume a human reads the result before the next skill runs. The composition test is whether two skills can be chained without manual intervention. If not, they are not a stack.

4. The fourth is workflow orchestration. Stacks are fired by workflows, not by individual skill invocations. The workflow defines when the stack runs (a new account is added, a call is completed, a deal closes) and which skills participate. The operator does not pick which skill to run next. The workflow does. This is the difference between owning five skills and operating a system.

The four failure modes

Stacks fail in predictable ways. The four failure modes are recognizable from the outside, and each one points to which design principle is missing.

1. The first failure is skill silo. The operator who built the skill is the only person using it. No other operator on the team has adopted it. The skill has a Build Reach of one. By the Build Reach test, the skill is producing personal leverage and zero team leverage. Silos are the precondition for stacks failing because composition requires multiple skills sitting in the same workflow, and skills that nobody else uses are not in any workflow.

2. The second is output mismatch. Skill A emits text. Skill B expects structured fields. The chain breaks at the seam. The operator works around it by manually translating between formats, which means the stack runs only when the operator is in the loop, which means the leverage caps at the operator’s calendar. Output mismatch is the single most common reason stacks designed on a whiteboard never run in production.

3. The third is context fragmentation. Each skill maintains its own version of the ICP, the positioning, or the competitor list. When the team updates the canonical ICP, half the skills get updated and half do not. The outputs drift apart. The operator running the stack gets contradictory positioning recommendations from two skills that should have produced consistent output. This is not a new failure mode. It is the Reference-Feedback Split appearing at a different layer of the system. Context that lives in N places drifts. Context that lives in one place can be kept current. The pattern recurs because the structural claim is the same: reference material that is not paired with a feedback loop decays, regardless of which layer of the system it sits in.

4. The fourth is no orchestration. The skills exist. The composability is technically there. But nothing fires the chain. The operator has to remember which skill to run next, copy the output into the input of the next skill, and so on. The stack only runs when the operator is doing the orchestration manually. The leverage is real but capped by the operator’s bandwidth. Without orchestration, a stack is a sequence of well-designed skills that almost never run together.

A working example

A stack-ready outbound sequence inside a GTM org looks like this.

Trigger. A new account is added to the prospecting list, fitting the ICP definition stored in /context/icp-definition.md.

The stack composes. The output of skill 1 is the input of skill 2. The output of skill 2 is the input of skill 3. The shared context files are referenced by every skill that needs them. The orchestration fires when the trigger conditions are met. The retrospective at the end of the chain updates the same files that skill 1 reads from at the beginning of the next chain.

This is what compounding looks like in operator terms. Every cycle of the stack improves the inputs of the next cycle. The signal-performance log gets sharper after every deal. The ICP evolution log updates from outcomes. The positioning file gets refined when post-call summaries surface drift. The system is not just running the stack. It is improving the stack.

Channel Drag applies to stacks too

A stack designed for last quarter’s workflow is the same kind of decay artifact a channel mix from two stages ago is. The signals the stack scores against were the signals that worked in Q1; by Q3 they have aged out. The positioning the outreach drafter references was the positioning that landed in Q2; by Q4 the buyer has stopped responding. The ICP evolution log has been updating, but the skills have not been re-pointed at the new segments.

This is Channel Drag at the skill layer. The stack that collapsed a 90-minute workflow to 10 minutes three quarters ago is now producing outputs the team has to manually rework, which restores the operator to the loop and erases the leverage. The operator does not notice because the stack is still running smoothly, the outputs are still landing in the inbox, and the failure mode is silent.

The maintenance discipline at the stack layer is the same as at every other layer. A feedback file that tracks the actual conversion rate of the stack’s outputs over time. A quarterly review that compares the stack’s current performance to its peak performance. A set of triggers (drop in reply rate, drop in qualified meetings) that kick off a stack audit. Stacks that are not maintained are reference artifacts. Stacks paired with feedback files compound.

What this changes for an operator

Pull the skills you have built. List them. For each one, ask three questions.

What is the output schema? If you cannot describe it precisely, the skill is not stack-ready. The first move is to define the output format and refactor the skill to produce it.

Which other skill could consume this output? If the answer is none, the skill is a tool, not a stack member. The next move is either to build the consumer skill or to redesign the existing skill to produce output that the rest of the team’s skills can use.

What workflow fires this skill? If the answer is “I run it manually when I remember,” the orchestration is missing. The next move is to define the trigger condition and either build the workflow file that fires it or wire the trigger into an existing workflow.

The audit usually surfaces that the operator has been building skills the way you would build a Swiss Army knife. Many tools, all separate, each useful, none composing. The shift is from accumulating tools to designing systems, and that shift is structural before it is technical.

What this changes for a leader

Stop counting skills. Start counting compositions.

The right metric is not how many skills the team has built. It is how many skills are in workflows that fire automatically and produce structured output that downstream skills consume. A team with twelve isolated skills is a team that built twelve tools. A team with five stacked skills connected by two workflows and three shared context files is a team that built a system. The second team produces compounding leverage. The first team produces twelve separate productivity bumps.

The leadership move is to enforce a stack-design convention before the team has finished building the first stack. Output schemas in every SKILL.md. Shared context files referenced by everything. Workflows that orchestrate skill chains. The convention costs upfront speed and pays it back the first time two skills compose without manual intervention.

The teams that figure this out first will look like they are operating at a different multiplier than their peers. They are. The multiplier is the stack.

The constraint reframed

The operator with five isolated skills is saving time inside five separate tasks. The operator with five stacked skills has removed themselves from the workflow that strings those tasks together. The same person, the same model, the same prompts, a non-linear difference in cycle time, all of it produced by a design choice the operator made before they wrote the first SKILL.md. The architecture you build is what AI amplifies. Isolated skills get amplified into isolated leverage. Stacked skills get amplified into compounding workflow gains.

The constraint is not the skill. It is whether the skills compose into a system that runs without the operator in the loop and improves itself with every cycle.

The skills you have are the inventory. This is not a quantity problem. It is a composition problem. The system is what you have not built yet.

Someone gave every rep a Claude license. Every team built its own ChatGPT project. Now the same question gets two different answers depending on who you ask. One customer had a rep pitch a product line that did not exist because ChatGPT made up SKUs the company had never sold. The model was not the problem. The agent was not the problem. The architecture underneath was.

Alex Bilmes built Endgame to fix that architecture. Alex was the first hire at CloudAbility (acquired), founded Reflect (acquired), and ran one of the early product-led sales CRMs with customers like Figma, Loom, Calendly, and LaunchDarkly. He has raised over $47M for Endgame, with customers including Braze, Scale AI, BetterUp, and Monte Carlo. Monte Carlo reached 80% AI adoption across its GTM team running on the platform.

Endgame is a context graph for go-to-market. It pulls everything (CRM, Gong, email, Slack, methodology, enablement, policy docs) into one source of truth and pre-processes that data upstream of any agent or human asking a question. It runs fact extraction and compression, builds dense one-pagers per account, and serves the graph through a single MCP server that any tool can plug into. The architectural premise is direct. Most AI GTM stacks fail because every agent makes a different set of tool calls at read time. Accuracy is low, cost is high, answers are inconsistent. The fix is not better agents. It is a unified context layer underneath them that does the synthesis once and serves it to everyone.

In GTM 46, Alex breaks down why revenue is the GTM function furthest behind on AI despite being the function that makes the money, why the investment mix on what to do versus doing it is 80-20 in favor of knowing what to do, and the new function that controls how every rep sells. He explains why agentic hellscape is the default state of most enterprises right now, why revenue per employee is the metric every CRO is laddering to, and why the best leaders are now the ones spending nights and weekends building with AI on their own accounts.

This is not a conversation about better AI tools. It is a conversation about the architecture that determines whether every tool you bought produces leverage or sprawl.

Subscribe now

Inside this episode

This episode maps the structural gap between how most enterprises adopted AI in GTM and what the architecture has to become when every team is shipping agents, every rep is using ChatGPT and Claude, and the same question is producing different answers across the org.

Alex starts with the pattern he keeps seeing inside enterprise customers. Someone gave every rep a Claude license. Every team built its own ChatGPT project. Marketing has its own context, sales has its own, customer success has its own, and none of them share. The result is what he calls agentic hellscape. The same question gets two different answers depending on which department you ask. One of his customers had a rep pitch a product line the company did not sell because ChatGPT, working with nothing connected to it, fabricated SKUs the rep then pitched to a real customer. The fabrication is not a model bug. It is the predictable output of an agent with no context.

We go deep on why revenue is structurally the hardest GTM function to automate. Engineering is the furthest ahead. Teams are running Cursor and Claude Code with agents writing most of the code. Legal moved fast through Harvey and Legora. Support has Sierra and Decagon running autonomous workflows. Revenue lags every other function because the context to sell to a single account lives in Salesforce, Gong, email, Slack, methodology playbooks, pricing rules, packaging, and policy contradictions all at once. The data is not just fragmented. It is also messy, contradictory, and updated by different people at different cadences. No model can reason its way through that without a synthesis layer underneath it.

We cover why connecting Claude directly to MCP servers does not solve the problem. If the agent has to query Salesforce, Gong, email, and Slack at read time for every question, three things go wrong. Accuracy degrades because the agent is doing needle-in-a-haystack search across fragmented sources. Token costs blow up because every question pre-loads massive context. Consistency collapses because two reps asking the same question get different answers depending on how the agent navigated the tool calls. Endgame’s architectural play is to move all of that upstream. Run fact extraction once. Build a dense, fact-checked one-pager per account. Serve the same compressed context to every agent and every human. The agent stops searching. It starts reading.

We go into the function Alex calls the most slept-on opportunity in AI for go-to-market. Whoever curates the context layer controls how every rep sells. He half-jokes the title is chief propaganda officer. The joke is funny. The function is real. This is the person who teaches the agent what plays to run, what discounts apply under which conditions, what the methodology is, what the company will not do. Most knowledge bases contain contradictions on basic policy questions. Do we allow this discount? It depends on segment, contract size, and quarter. The function pre-processes those contradictions into directives the agent can act on. Some of his customers run it through enablement. Some through ops. One customer just created a new AI go-to-market leader role and staffed it from solutions architecture. The title is fluid. The function is not. In a world where every rep asks the agent before talking to a customer, whoever feeds the agent is shaping the entire sales motion.

We cover what AI is actually doing to GTM org design. Smaller teams. Flatter orgs. Fewer specialists, more generalists. Full-cycle AEs replacing land-and-expand handoffs because the agent does the prep and analysis work that used to require a separate role. One of his customers replaced most of their SDR function with a go-to-market engineer, the Endgame MCP, and a handful of approval loops. A few people now review the agent’s output and click send. Alex is direct that this is not a one-to-one headcount swap. It is a structural compression. The metric every CRO is laddering to underneath all of this is revenue per employee. Revenue per employee is the new endgame.

We go into the structural argument underneath the entire AI GTM conversation. Doing stuff is easy with software. Doing the right thing is very, very hard. The current narrative is that agents should do more, autonomously, faster. Alex thinks that is missing the point. The investment mix on what to do versus doing it should be 80-20 in favor of knowing what to do. Most teams have it inverted. They scale autonomy on top of bad instructions and end up shipping faster against the wrong assumptions. His example: you buy an AISDR, you send 10 million emails, you get no conversion, you burn your domain, and your competitors still win. Doing more is not the same as doing the right thing. Architecture decides which one happens.

We go into build versus buy. The shape of the question changed. Six months ago, building meant standing up a custom data pipeline and a fine-tuned model. Today building means a forward-deployed engineer connecting Claude to a few MCP servers. Alex’s argument is that the connect-and-ask approach works for one rep on one question. It collapses the moment a team tries to scale it because everything happens at read time. His honest answer on what to buy: almost nothing. Maybe payroll. Maybe a database. Maybe a context graph (because building one requires data engineering, applied AI, and domain expertise compounded over years). And maybe a few load-bearing brand names where the customer signal matters. He uses DocuSign as the example. Cheap to replace, but the customer recognizes the logo on a million-dollar contract. Build everything else.

We cover sales cycle compression. Alex closed an enterprise deal in 15 days from first meeting. The buyer was a COO who was problem-aware, somewhat solution-aware, had budget, and was the signer. No nurture sequence. No drawn-out evaluation. The shape of the solution was already decided before Endgame walked in. Other deals take six months. The variable is not the buying committee. It is leadership. Next-generation leaders think in systems. They do not muscle through what Alex calls meat scale, where you hire 50 people and figure it out on the ground. They architect the function. The leaders who think this way close fast. The leaders who do not run RFPs.

We cover what the AI-native GTM stack looks like 12 months out. Alex sees consolidation at the horizontal layer, not the vertical. Sales leaders bought ten point solutions that each promised 3x pipeline and ended up at zero. The next motion is fewer systems sitting between the underlying data sources and the agents doing the work. Go-to-market teams are starting to operate like product and engineering teams. They run sprints. They iterate. They understand the layers of the stack. The orgs that move fastest will be the ones where the GTM team thinks like a product team, ships in cycles, and treats the context graph as core infrastructure.

We close on a sharp note about leadership. Alex’s biggest critique of CROs adopting AI is that they outsource their own intuition. They buy Claude, they buy Copilot, they tell their team they are using AI, and the result is performance theater. The leaders moving fastest are the ones spending nights and weekends building with AI on their own accounts. Intuition is the new leverage. The leaders who build it themselves are the ones designing the architecture. The leaders who delegate it are the ones being sold the architecture by people who do not understand it either.

Discussed in this episode

03:13 - Why revenue is the GTM function furthest behind on AI

05:11 - What goes inside a context graph, and why Claude plus MCP servers fails at scale

13:15 - The chief propaganda officer: whoever curates context controls how every rep sells

16:38 - Revenue per employee is the new endgame

18:49 - The data foundation matters more for agents, not less

22:55 - What the AI-native GTM stack looks like 12 months out

27:08 - Adoption strategy: meet people where they already work

30:11 - Pricing, sales cycles, and why systems thinkers move fastest

36:34 - Rapid fire: AISDR, the belief about agents that's wrong, build vs. buy, and the 30-day CRO move

Key takeaways

1. The same question producing different answers is the signal that context is fragmented The default state of most enterprises right now is agentic hellscape. Every team has its own ChatGPT project. Every rep has Claude. None of them share context. The same question about a deal, an account, a policy, gets two different answers depending on which agent or rep you ask. The failure mode is not the model. It is that every agent is reasoning from a different fragment of context. The fix is not a better prompt. It is a context layer underneath every agent that synthesizes the answer once and serves it consistently.

2. Revenue is the GTM function furthest behind on AI because context lives in eight tools at once Engineering moved fast because the context to write code lives in the codebase. Legal moved fast because the context to review a contract lives in the contract. Revenue lags because the context to sell to one account lives in Salesforce, Gong, email, Slack, the methodology doc, the pricing sheet, the policy contradictions, and last quarter’s QBR slide. No agent can reason across that without a synthesis layer doing the work upstream. Every team trying to make Claude useful for revenue without unifying the context first runs into the same wall.

3. Doing stuff is easy. Doing the right thing is very, very hard. The current narrative around agents is autonomy, volume, and speed. The investment mix on what to do versus doing it should be 80-20 in favor of knowing what to do. Most teams have it inverted. They scale autonomy on top of bad instructions and end up moving faster against the wrong assumptions. The AISDR pattern is the canonical version. You buy the agent, you send 10 million emails, you get no conversion, you burn the domain, and the competitor still wins. Architecture decides whether autonomy compounds or accelerates the failure.

4. Whoever curates the context layer controls how every rep sells The most slept-on function in AI-native GTM. The title is fluid (enablement, ops, AI go-to-market leader, sometimes solutions architecture). The function is not. This is the person who teaches the agent the methodology, the plays, the discount logic, the contradictions in the knowledge base, and the directives the agent should enforce. In a world where every rep asks the agent before talking to a customer, the person feeding the agent is shaping every conversation. Companies that recognize this are building the role. Companies that do not are letting the context default to whatever ChatGPT pulls from training data.

5. AI compresses GTM org design in ways that look like layoffs but are actually architecture changes Smaller sales teams. Flatter orgs. Fewer specialists, more full-cycle AEs. One customer replaced most of their SDR team with a go-to-market engineer, the Endgame MCP, and approval loops. The metric every CRO is laddering to is revenue per employee, and revenue per employee is the new endgame. The structural move is to compress handoffs, not just headcount. Every handoff between specialists is where context leaks. Removing the handoff produces compounding leverage that a one-to-one headcount cut cannot.

6. Adoption is not a behavior change problem when the context layer goes where people already work The fastest adoption pattern is making the context graph available inside the tools the team already uses. Claude. ChatGPT. Slack. Zapier. The admin approves Endgame in the Connector Marketplace. Reps flip a switch. They keep working the way they were already working, just with better answers. Behavior change is the hardest part of any AI rollout. The architectural move is to skip it. Meet people where they work, plug the context graph in underneath, and let the agent get smarter without anyone having to learn a new tool.

Frameworks from the episode

1. The context graph as the operating system for revenue The architectural premise of Endgame. Pull everything into one place (CRM, Gong, email, Slack, methodology, enablement, pricing, policy). Run agent loops upstream that fact-check, extract, and compress the data into dense one-pagers per account. Serve the result through a single MCP server that any agent or human queries. The output is a single source of truth that updates in real time, every time a new call drops or an email lands. Every question gets the same consistent answer because every agent is reading from the same compressed context. The graph is not a report. It is the operating system for how the company sells.

2. The 80-20 inversion: knowing what to do versus doing it Most teams allocate effort to autonomy and volume. Alex’s frame inverts the ratio. Eighty percent of the work belongs to deciding what the agent should do (methodology, plays, policy directives, conditions). Twenty percent belongs to having the agent do it. Teams that get this backwards scale broken instructions. Teams that get it right scale instructions that actually compound revenue. The framework is not philosophical. It is a budget allocation question. Where is the team spending its time, on the agent or on what the agent is told to do.

3. Build versus buy in the AI-native stack The default reverses. Almost everything that was previously a SaaS purchase is now buildable on Claude, an MCP server, and a forward-deployed engineer. The exceptions are infrastructure plus domain expertise compounded over years (databases, payroll, context graphs) and a small number of brand-recognized customer-facing tools where the logo carries trust on a million-dollar contract. DocuSign is the example. Everything else, build. The architectural question is no longer which point solution to add. It is which platforms can absorb the use cases your team will discover next quarter.

What to do this week

Pick the one or two AI use cases that move the needle today. Alex’s exact prescription. Not five. Not ten. The temptation is to spin up agents across every department. The result is sprawl and contradictory output. Pick one or two use cases (account planning, deal review, prep for the meeting, whatever the highest-leverage moment is for your team) and build for those. The discipline of choosing forces a real conversation about where AI actually compounds revenue.

Get the base data structured so you can iterate. The other half of Alex’s 30-day prescription. The mistake is treating data as a six-month CRM clean-up project. The move is the opposite. Get the context graph (or the equivalent layer) standing up against your existing data, no matter how messy. Agents fix data faster than humans do. The structure compounds across every use case you add later.

Audit how many places the context to answer one revenue question lives. Pick a real example: “is this deal stalled?” Count the systems your agent or your team has to query to get a real answer. Salesforce. Gong. Email. Slack. Calendar. Notes. If the answer requires more than one system and there is no synthesis layer compressing them, every agent and every rep is producing inconsistent answers right now. The fix is not buying more agents. It is building or buying the layer that does the synthesis once.

Identify who in your org is curating the context the agents are reading. If the answer is “no one” or “every team has their own ChatGPT project,” the company is in agentic hellscape. The first move is naming the function. The title can come later. The function (curating methodology, plays, pricing, and policy into a form the agent can act on) needs an owner this quarter.

Build with AI yourself. Spend a weekend wiring up Claude, an MCP server, and one of your own data sources. The leaders moving fastest are the ones who can describe the architecture from first principles because they have built it. The leaders falling behind are the ones who outsourced the building and now describe AI in platitudes. Intuition is the new leverage. It only comes from the building.

Why this matters

The first wave of AI in GTM was tool sprawl. Every team got Claude. Every department built its own ChatGPT project. Every vendor pitched a 3x lift on whatever the buyer’s pipeline problem was. The buyers bought ten of them and pipeline did not move. The motion was activity, not architecture.

The architectural argument Alex makes is that AI does not produce leverage on a fragmented stack. It produces noise at scale. The same model, the same agent, the same prompt, will give two different answers if the underlying context is not unified. Every rep using the agent without a context layer is making decisions on a different version of reality. The org looks like it is using AI. The output is closer to performance theater.

The deeper argument is that doing stuff is easy and doing the right thing is hard. Autonomy compounds whatever instructions are underneath it. If the instructions are wrong, the agent ships the failure faster. The teams winning with AI right now are not the teams shipping the most agents. They are the teams that invested 80% of the effort in deciding what the agent should do, then let the agent do it. The teams losing inverted the ratio.

The companies that win the next cycle are the ones that built the context layer before they bought the agent. Not because the layer is glamorous. Because every other investment compounds against it or collapses against it. AI on a coherent system produces leverage. AI on a fragmented system produces noise at scale. The orgs that figured this out are running smaller teams, flatter structures, and higher revenue per employee. The orgs that did not are still asking why their agents keep telling reps to pitch products that do not exist.

This is GTM Vault.

If this episode changed how you think about the architecture underneath your AI GTM stack, forward it to one operator still treating ChatGPT and Claude as productivity tools instead of an interface to a context layer they have not built yet.

Connect

Follow Alex Bilmes // Endgame

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. One working session to identify your primary GTM constraint and design the 90-day architecture to resolve it.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

In early 2020, Apollo.io was nearly out of cash. The company had been running a sales-led motion at a $10,000 average contract value, and the unit economics had inverted. They were spending one dollar to acquire eighty cents of revenue. The channel mix that had built the company to that point was the same channel mix that was about to kill it.

The team retired the channel. They moved Apollo to a freemium product-led model, dropped the ACV from $10,000 to $1,000, and committed to a programmatic SEO motion that the existing leadership had every reason to distrust. The new motion produced no qualified pipeline for the first several months. Sales-led numbers kept declining. The bet was that programmatic landing pages, indexed against high-intent search queries, would eventually surface a different buyer segment at a different price point. The validation came from an A/B test that showed traffic from the new motion converting at twenty times the rate of the old. The motion grew to 430,000 monthly organic visits at zero marginal cost. Twenty-four months later, Apollo was at $100M ARR. Today, more than 90% of new sign-ups come from organic word of mouth.

The structural lesson hiding inside Apollo’s pivot is the lesson hiding inside every GTM channel mix conversation. The channels that built your company are usually the channels you have to retire to grow it. The constraint is not the channel. It is whether the team is honest enough to retire the channel that built it.

Most teams are not. The result is a measurable structural failure I am calling Channel Drag.

Subscribe now

Channel Drag

Channel Drag is the lag between the moment a company’s stage transitions and the moment its channel mix updates to match. Measured in quarters. It is the operational measurement underneath the law that channel accumulation is not distribution architecture. The law names the failure pattern. Channel Drag names the rate at which the failure compounds. A team running the channel mix that fit at the previous ARR or ACV bracket has Channel Drag of one to two quarters. A team running the mix from two stages ago has six to eight quarters of Channel Drag, and the pipeline math is degrading every month they do not update.

The metric is observable. Pull the channels currently in your budget. For each one, identify the stage the company was at when that channel was added. Subtract from the current stage. The gap is the Channel Drag for that line item.

Most GTM teams I look at have Channel Drag of four to six quarters across half their budget. The team running LinkedIn organic at $8M ARR added the LinkedIn motion at $1M ARR. The team running cold outbound at $25K ACV added the SDR org at $5K ACV. Each individual channel was working when it was added. None of them have been re-evaluated since the company’s market shifted underneath them, and the team is running on muscle memory while the data has moved.

The pattern is the same across every team I see

Across the GTM teams I have watched make this transition, the channel mix that wins at each stage is consistent enough to be a pattern, not a coincidence.

At sub-$1M ARR, the motion is high-touch, founder-driven, and runs on personal networks. LinkedIn organic and warm outbound carry most of the pipeline, with founder brand sitting just behind them. The mix is free or nearly so, which matches the stage’s economics. None of these channels scale past the founder’s reach, but at this stage the founder’s reach is still the largest available pool.

At $1M to $10M ARR, the mix shifts. Warm outbound becomes the operational backbone. LinkedIn is still relevant but no longer the lead channel. Intent-based motions enter the picture, because the team is no longer running on the founder’s network. It is running on identified accounts with identified buying signals.

At $10M+ ARR, the mix transforms. LinkedIn and founder brand drop out of the top tier. Large conferences become the lead channel because the buyer is now a committee, and conferences are the only setting where you can put a VP, an engineering lead, and an ops director in the same room across two days. SEO becomes a serious pipeline source, because content invested in two years earlier is finally compounding. Paid ads enter the mix as a brand layer that supports inbound, not as a primary acquisition channel.

The same shift happens along the ACV axis, on a faster clock. At sub-$5K ACV, the buyer is one person making a self-serve decision in days. SEO and paid ads dominate because they intercept the buyer at the moment of search. LinkedIn confirms the brand exists but does not carry the conversion. At $5K to $25K ACV, the buyer is researching with intent across a shortlist over weeks. Warm outbound becomes the lead channel because it offers a structured comparison at the moment the buyer is actually evaluating. At $25K+ ACV, the buyer is building consensus across a committee over months. Large conferences and intimate events become the dominant channels because they are the only ones structurally suited to reach committees in a single setting.

The pattern is mechanical, not surveyed. The buyer behavior at each stage decides which channel mix works. Channels that ignore the buyer behavior at the current stage produce expensive noise.

Why the mechanism matters more than the recipe

The data is a description of what works at each stage. The mechanism is what tells you why, and the mechanism is what survives when the data does not exactly match your situation.

Channels are gravitationally attracted to the buying behavior at each ACV range. At sub-$5K ACV, the buyer is one person making a small purchase against a budget they control. The decision is made in days or weeks. SEO and paid ads work because they intercept the buyer at the moment of search. LinkedIn confirms the brand exists. The buying cycle does not have room for high-touch motions, so high-touch motions waste budget at this ACV.

At $5K to $25K ACV, the buyer is researching with intent. They have a shortlist, they want proof, they will take a meeting if the meeting will save them evaluation time. Warm outbound works because it offers a structured comparison. Intent-based motions work because the timing matches when the buyer is actually shortlisting.

At $25K+ ACV, the buyer is building consensus. They are not researching alone. They are bringing colleagues into evaluations, sitting through procurement, defending the decision to a CFO. Large conferences and intimate events work because they are the only channels structurally suited to reach an entire buying committee in a single setting. Warm outbound is no longer dominant, but it has not disappeared either, because committee members still need to be reached individually.

The mistake most teams make is reading the data as a recipe. The recipe says: at $25K+ ACV, run conferences. The mechanism says: at $25K+ ACV, your buyer is a committee, and conferences are the highest-leverage way to reach committees in person. The mechanism is what tells you what to do when conferences are not available, the budget is constrained, or the timing is wrong. Without the mechanism, you copy the channel and miss the principle.

The transition zones break most teams

The hardest part of channel-mix maintenance is the transition. The team at $4M ARR is not running a $1M ARR motion or a $10M ARR motion. It is in transition. Channel Drag accumulates fastest during transitions because channels have lead time, and the team that waits for the current channels to break before starting the next ones is twelve months from the next channels working.

SEO content that produces qualified pipeline takes six to twelve months from first content to first conversion. A conference presence that produces meaningful pipeline takes one or two annual cycles to optimize. Intimate events that produce trust take two or three quarters to find the right format. Channels you should be investing in two stages early, not at the moment the current channels start to break.

The team that waits until LinkedIn pipeline declines before standing up SEO is one year of zero pipeline contribution away from SEO producing pipeline. Apollo’s pivot worked because they made the SEO investment before the sales-led motion broke completely, and they had the runway to ride out the lag. Most teams do not have that luxury, which is why the discipline of starting the next stage’s channels early is the single highest-leverage move a CMO can make at a transition.

The Reference-Feedback Split applies here

The channel mix is a reference artifact unless paired with a feedback loop. Most teams have a quarterly board slide that lists the channels they are running and the budget allocated to each. That slide is reference material. It describes a strategy. It does not update from outcomes.

The feedback file is different. The feedback file logs which channels actually contributed to closed-won pipeline this quarter, segmented by ACV and segment. Not lead source. Not first-touch attribution. Source of pipeline that converted. After three or four quarters, the feedback file tells the team which channels are still in fit and which channels have aged out, in a form that overrides the reference slide. The Reference-Feedback Split is the structural discipline that prevents any GTM artifact, channel mix included, from calcifying into stale reference material.

A team that does not run a feedback file on its channel mix is making channel decisions on data from when the mix was last in fit. By definition, last stage’s data. By definition, accumulating Channel Drag.

Build Reach is the test for high-ACV channels

At higher ACV, the question of whether a channel works has a structural test that most teams do not run. The test is whether the channel reaches the buying committee, not just an individual buyer.

A LinkedIn message that lands with a single VP at a $50K ACV deal has reached one of six committee members. The deal does not move forward unless the other five also move forward. The channel produced an output (a meeting) that did not actually advance the buying motion at the committee level. By the metric that matters, the channel had a Build Reach of one when the deal required a Build Reach of six.

Large conferences and intimate events dominate at high ACV not because they are exclusive. They dominate because they are structurally suited to reach committees in a single setting. A conference puts the VP, the engineering lead, and the ops director in the same room over the same two days. The channel has built-in Build Reach across the buying committee. Cold outbound at $50K ACV requires the SDR to manually reach each committee member, and most SDRs reach two of six and call it a day.

The Build Reach test sharpens the channel selection question. Pick channels by their structural ability to reach committees, not by their cost-per-meeting. The channel that reaches one committee member at low cost is producing the same output as the channel that reaches six at high cost, and only the second channel closes the deal.

What this changes for an operator

The Channel Drag audit takes an afternoon and most teams have not run one in two years. Pull every channel currently funded. For each channel, ask three questions.

What was our ARR and ACV when this channel started working? Most channels in the budget were chosen at a stage you have already passed. The gap between then and now is the Channel Drag on that line item.

What does the buyer at our current ACV require from a channel that this channel does not deliver? If you cannot answer concretely, the channel is in fit. If you can, the channel is in transition or out of fit.

What is the lead time on the channel we should be standing up next? Whatever your answer is, you are already late.

The audit produces a working list of channels to ramp down, channels to maintain, and channels to start. The ramp-down is the hardest part. It requires admitting that a channel that worked is no longer producing pipeline at the rate it used to, and that the team’s identity around that channel is the only thing preventing the reallocation. Apollo retired a sales-led motion they had spent years building. Most teams cannot bring themselves to retire a LinkedIn motion they have spent six months building.

What this changes for a leader

Stop reviewing channels annually. The right cadence is quarterly, with a feedback file that tracks contribution-to-closed-won by channel, by ACV bracket, by segment.

The harder discipline is the future channel pipeline. At every stage, two channels should be in development that will not contribute pipeline for the next two to three quarters. If the current quarter’s channel mix is producing all of the team’s pipeline, the team is one stage away from a pipeline cliff that nobody has scheduled.

The teams I have watched cross from $5M to $20M ARR all paid the same toll. Each one made channel investments that produced no pipeline for two or three quarters before they did. SEO content that took nine months to start ranking. Conference presences that took two cycles to find the right format. Founder-brand motions that took a year before the inbound started landing. That cost is the price of low Channel Drag. The teams that refused to pay it stopped scaling at the stage their channel mix could carry, which is rarely the stage they wanted to be at.

The constraint reframed

Channel Drag is not a marketing problem. It is a structural problem about how a GTM motion stays aligned with the market it is selling into as the company grows. The channels that earned the first $1M of ARR are not the channels that earn the next $9M. The channels that earn the next $9M are not the channels that earn the $10M after that.

The teams that win update the mix on the cadence the data demands, run a feedback file that overrides the reference slide, and start the next stage’s channels two quarters before the current ones break. The teams that lose run last stage’s playbook on this stage’s market and call the resulting pipeline decline a market problem.

The constraint is not the channel. It is whether the team is honest enough to retire the channel that built it.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

The marketing team is using AI. Everyone is. Someone has ChatGPT open. Someone else is running Claude in a browser tab. The agency is generating LinkedIn posts that sound like every other LinkedIn post. Output volume is up. Quality is uneven. Brand voice drifts every time a different person prompts a different model on a different day.

This is not an AI problem. It is a context problem.

The teams getting compounding output from AI are not using better models. They are feeding the model better context, structured the same way every time, queryable on demand. Everyone else is reprompting from scratch and calling that a workflow.

A Marketing Operating System fixes this. It is a centralized repository of the company’s marketing knowledge, written in a format the model can read, organized into layers that load only when relevant. One CMO can build the first version in a few weeks of evenings. The build sequence is what this Playbook covers.

The Four Layer Model

The system has four layers. They build in order. Skipping ahead produces a system that generates fast but generates wrong.

Layer 1 is Foundation. Static context the model needs every time it produces anything: who the company is, the brand voice, the services, the ICP, the markets, the positioning, the team, the budgets. This is the layer most teams skip because it feels like documentation work, not AI work. It is the layer that determines whether anything downstream produces output worth shipping.

Layer 2 is Research and Reach. Real-time market and customer context, fed into the system through connectors when a specific task needs it. Loaded on demand, because loading everything every time clogs the model’s working memory and degrades output quality.

Layer 3 is Execution. The skills the system can perform: campaign briefs, blog drafts, LinkedIn posts, case studies, decks, press releases. Each skill reads from Foundation, optionally pulls from Research, and produces in a format the team can edit and ship.

Layer 4 is Feedback and Iteration. The mechanism that turns the system from a drafting tool into a compounding asset. Every output gets reviewed, the edits get captured, the patterns get fed back into Foundation.

Most teams stop at Layer 3 and wonder why the output stays generic. The system compounds at Layer 4 or it does not compound at all.

Layer 1: Build the Foundation

The Foundation is a set of markdown files in a single repository. Markdown because it is plain text, version controllable, readable by every model, editable by anyone who can use a text editor. Not Notion. Not Google Docs. Not a Confluence page. Markdown files in a repo.

The Foundation contains, at minimum: a company overview, a brand voice and tone guide with examples of accepted and rejected phrasing, a services or product catalog with positioning for each, an ICP document for each segment with named buyer roles and their priorities, a market and competitive landscape document, a team roster with roles and approval authority, and a current-quarter priorities document that names what the marketing team is being measured on.

The brand voice document is the highest-leverage file in the entire system. It should not be a list of adjectives. Adjectives like “bold” and “approachable” produce nothing useful when the model reads them. The document needs concrete examples: three sentences the brand would write, three it would not, and the structural reason for each. The model learns voice from contrast, not from descriptors.

The build sequence for Layer 1 is four to six weeks of evenings if one person is doing it and the source material already exists in some form. If it does not, the work is longer, but the work was needed regardless. A marketing team without a written brand voice was already producing inconsistent output. The Foundation just makes the gap visible.

Layer 3: Build Execution Before Layer 2

The natural instinct is to build the layers in order. Foundation, then Research, then Execution, then Feedback. The natural instinct is wrong.

Build Layer 3 before Layer 2. Execution skills running on Foundation alone produce output that is on-brand but generic. That is the right output to start with. It exposes which Foundation files are thin, which voice rules the model misinterprets, and which skills the team actually uses versus the ones that sounded important in planning. Adding Research before the base system is stable adds variables before the system can absorb them.

A first batch of Execution skills is four to six. A campaign brief generator. A LinkedIn post generator that follows the brand voice rules. A blog draft generator with a defined structure. A case study generator that reads from a customer template. A press release generator. A deck outline generator. Each one is a markdown file that tells the model how to read the Foundation, what format to produce, and what rules to follow.

The team should invoke any skill, get a draft in two to three minutes, and have a 60 to 70 percent starting point an experienced marketer can finish. The skill is not replacing the marketer. It is removing the blank page.

Layer 2: Add Research When the Generic Limit Is Hit

Once the team has used Layer 3 skills for a few weeks, the limits of Foundation-only output become specific and obvious. The campaign brief skill produces a strong structure but cannot speak to current competitor positioning. The blog skill writes well but does not know what the audience searched for last month. These specific gaps are the prompts to build Layer 2.

Layer 2 connectors pull live data into the system on demand. Search trend data. CRM deal context. Customer interview transcripts. Competitor content tracking. Each connector is added because a specific Layer 3 skill needs it for a specific reason. None of it loads by default.

The discipline at Layer 2 is restraint. Loading everything every time is the most common failure. The model has a finite working window. Every irrelevant file in the context dilutes the relevant ones. The architectural rule: load the minimum context required to produce the specific output, and no more.

Layer 4: The Feedback Loop That Makes the System Compound

Layer 4 is the layer most teams never build. It is also the layer that separates a drafting tool from an operating system.

The mechanism is straightforward. Every output the system produces gets compared against the final version that shipped. The differences are captured. The patterns are reviewed monthly. The Foundation files are updated to reflect what was learned.

If the LinkedIn skill consistently produces opens that are too long, the brand voice file gets a sharpened rule about opening length. If the case study skill keeps formatting outcomes wrong, the case study template gets updated. The system improves because the corrections are codified, not because the next prompt is better.

Without Layer 4, the team fixes the same model errors every week. With Layer 4, those errors get fixed once.

What This Costs to Build

A first usable version takes one builder, four to eight weeks of evenings, the documentation the company already has in some form, and a Claude subscription. No platform to buy. No vendor to onboard. The builder does not need to code. They need to write structured markdown and test outputs against what the team would actually ship.

The work that takes the longest is not the technical work. It is forcing the company to write down what was previously in three people’s heads. That work was always overdue. The Marketing Operating System is the forcing function.

The Real Moat

The model is a commodity. Every team has access to the same one. The team that wins is the team whose model is reading the most accurate, most current, most specifically structured business context.

The moat is not the AI. The moat is the Foundation. The team that codifies its positioning, its voice, its ICP, and its priorities into a system the model can read on demand has a multiplier on every piece of output it ships. The team that does not is producing the same generic content as every competitor with a ChatGPT subscription.

Within a year this will not be a competitive advantage. It will be the baseline. The leaders who start now build the Foundation while the work is still differentiating. The ones who wait will build it under pressure when the gap is already visible in the pipeline.

The Foundation is the work. Start there.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

GTM Vault has shipped over 120 essays, playbooks, podcast episodes, and foundational laws since June 2024. This page is the curated set. Organized by the problem you are trying to solve, not by the month it was written.

If you are new to GTM Vault, Start Here is still the best orientation. It maps the architecture and tells you where to enter based on what you are trying to fix. Once you know your problem, scan the category headers below and jump to the piece that names it most directly.

Most Read

The pieces operators have shared, cited, and returned to the most.

• GTM 43 | The Semantic Layer Is the Missing Architecture

• The 41-Point Gap That Vertical AI Is Built to Close

• SMYS 2 | MCPs vs APIs in a Production Enrichment Pipeline

• SMYS 3 | From Clay Tables to Intent HQ: Building the BDR Action Layer

• SMYS 1 | Review Intelligence as a GTM Signal Layer

• Category Leadership Is Built. Not Launched.

• The SaaS Motion Map

• The 90-Day GTM Blueprint

Subscribe now

The Foundational Laws

Eight structural laws that hold the architecture together. Read in order for the first pass. Return to the one you need when a specific layer breaks.

• Foundational Law 01: Every Downstream Decision Inherits the ICP

• Foundational Law 02: What Scales First Constrains Everything After

• Foundational Law 03: Pricing Restructures Every Layer It Touches

• Foundational Law 04: Function-Level Optimization Is System-Level Debt

• Foundational Law 05: Every Playbook Encodes the Stage It Was Built For

• Foundational Law 06: Channel Accumulation Is Not Distribution Architecture

• Foundational Law 07: Every Metric Compounds or Conceals

• Foundational Law 08: AI Amplifies the Architecture It Inherits

AI-Native GTM

The structural argument for what changes when AI becomes the operating layer, not a tool.

• The Architecture of AI-Native GTM

• The AI-Native Revenue Engine

• Agentic GTM Requires Systems, Not Smarter Agents

• The Three Stages of AI-Native GTM

• When the Buyer Is a Machine, Every Layer Breaks

• Modern GTM Is Entering Phase 2: From Productivity to Intelligence

• The State of AI GTM, 2025 Edition

• Agentic Marketing: The New GTM Architecture

• The New Architecture of GTM in the AI Era

Subscribe to GTM Vault to get the next piece when it ships.

Subscribe now

ICP, Positioning, and Beachhead

Who you sell to shapes every downstream decision. These are the pieces that set the identity layer correctly.

• Foundational Law 01: Every Downstream Decision Inherits the ICP

• The Beachhead Strategy Playbook

• Category Leadership Is Built. Not Launched.

• 15 Moats That Define Modern GTM Strategy

• Bottom-Up vs. Top-Down GTM in Early-Stage SaaS

• The Remote With Too Many Buttons

• The Invisible Forces Shaping Your GTM Strategy

Pricing, Monetization, and Metrics

Pricing is the GTM system, not a finance line item. Metrics compound or conceal. These are the pieces that get both layers right.

• AI Just Broke Your Pricing. Here’s How to Tell.

• Foundational Law 03: Pricing Restructures Every Layer It Touches

• Foundational Law 07: Every Metric Compounds or Conceals

• GTM Tool Spend by Growth Stage

• GTM 37 | Pricing Is the GTM System, Not a Finance Line Item

• GTM 38 | When Revenue Models Outgrow the Systems Running Them

• GTM 42 | When Dashboards Divorce the P&L

Distribution and Growth

Distribution compounds. Channel accumulation does not. These are the pieces that separate the two.

• Clip Farming: The 2025 Distribution Exploit for Founders

• Foundational Law 06: Channel Accumulation Is Not Distribution Architecture

• The Smartest Growth Plays of 2025

• The Hidden Growth Engine in AI Search

• GTM 34 | From SEO to GEO: When AI Search Becomes Distribution

• GTM 45 | The Feedback Loop Is the Missing Layer in Performance Marketing

• In AI, GTM Is the Only Moat That Lasts

• 100+ Startup Marketing Tactics That Actually Work

Org Design and Team Architecture

The team is the system. These are the pieces that rebuild the GTM org for how modern revenue actually scales.

• The Org Chart Is Dead

• The New GTM Org

• The Future of GTM Isn’t Bigger. It’s Smaller.

• The AI-Powered GTM Operator

• AI Is Rewriting the GTM Org

• Scaling GTM Alignment Across Sales, Marketing, Product, and Success

GTM Engineering and Stacks

How the operators running the best systems actually wire them, end to end. Clay, MCPs, Claude Code, signal layers, production pipelines.

• Show Me Your Stack (series intro)

• SMYS 1 | Review Intelligence as a GTM Signal Layer

• SMYS 2 | MCPs vs APIs in a Production Enrichment Pipeline

• SMYS 3 | From Clay Tables to Intent HQ: Building the BDR Action Layer

• SMYS 4 | From Win List to Win-Loss Gap: Building the Propensity Layer

• The GTM Stack You Actually Need in 2025

• 100 AI Agents That Will Redefine Your GTM Strategy in 2025

• The AI Stack You’ll Actually Use

• How to Automate 80% of Your Work with AI Agents

• GTM 21 | The GTM Engineer: Why Automation Is Eating RevOps

Playbooks and Applied Motions

Concrete motions you can install. Each one is a stage-aware build, not a tactic list.

• The 90-Day GTM Blueprint

• The Customer Journey Playbook

• The Omni-Stack Playbook: How Lovable Engineered $50M ARR Across 12 Channels

• The SaaS Motion Map

• The Non-Technical Founder’s GTM Playbook

• The GTM Debug Framework

• The Reverse Funnel Strategy That Drove $1M ARR in 12 Months

• Reverse Trials: Designing Conversion After the Trial Ends

• The New B2B GTM Playbook

Podcast Highlights

Selected episodes from the 44-episode catalog. Each one lands a structural insight that shows up in the essays later.

• GTM 43 | The Semantic Layer Is the Missing Architecture

• GTM 41 | Revenue Activation Is Architecture

• GTM 40 | Agentic Marketing Rewrites GTM

• GTM 36 | Enterprise Revenue Scales on Systems, Not Charisma

• GTM 31 | AI as the Revenue Intelligence Layer

• GTM 28 | Resolution-First AI: Support as a System, Not a Headcount Line

• GTM 27 | The AI Co-Founder: When Agents Replace Headcount

• GTM 24 | Buyer-Led GTM Replaces the Funnel

• GTM 21 | The GTM Engineer: Why Automation Is Eating RevOps

The Strategy Course

The ten-chapter build for founders and operators who want the system in one sequence, not one essay at a time.

• Build a Modern Revenue Engine (course overview)

• Chapter 1: Foundations of Winning GTM Strategy

• Chapter 2: AI-Powered GTM Execution

• Chapter 3: Demand Generation That Actually Works

• Chapter 4: Sales & Revenue Acceleration

• Chapter 5: Product-Led & Hybrid GTM

• Chapter 6: Data & Metrics That Matter

• Chapter 7: Messaging & Positioning

• Chapter 8: The 2026 GTM Operating System

• Chapter 9: From 0 to $1M ARR

• Chapter 10: War Stories & Lessons

New to GTM Vault? Start with the GTM Vault Guide, then come back to this page when you know the specific problem you are trying to solve.

Want the architecture installed rather than advised? See the Revenue Architecture Advisory.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

The ad shipped. The creative looked great. The campaign went live. Performance still stalled. Not because targeting failed, not because the budget was wrong. The team scaled ad volume faster than its ability to learn. The feedback loop between the ad account and the people making the ads never closed.

George Howes built Magicbrief to close that loop. Before Magicbrief, George spent years inside top creative agencies watching the same failure repeat at every brand. Teams launched ads, collected results, and moved on. Learning never compounded. Magicbrief was the first attempt at a creative intelligence platform that ingested ad performance and pushed it back to the teams making the ads. It worked. Canva acquired the company. George now leads Canva Grow, the product Canva is building to make the loop operate at enterprise scale.

Canva Grow ingests ad performance from every platform, ties each result back to the specific creative asset that produced the outcome, and pushes those learnings into the next round of creative before the next round of creative is made. The architectural premise is simple. Creative and media are not separate disciplines. They are the same system measured at different time scales. Every company that still treats them as two is losing compounding efficiency at every handoff.

In GTM 45, George breaks down why most performance marketing failures are not media problems but feedback loop failures, why creative teams and data teams sit at opposite ends of a broken handoff, and what changes when the learning loop runs in days instead of quarters. He explains why AI is a multiplier for creative feedback and not a replacement for it, why click-through rate lies more often than any other metric in the stack, and why small teams with all context in one place consistently outperform large teams with fragmented tooling.

This is not a conversation about better ad tools.

It is a conversation about why creative and media are the same system, and what happens when you design the feedback loop between them as infrastructure instead of a monthly report.

Subscribe now

Inside this episode

This episode maps the structural gap between how most performance marketing teams run today and what the feedback layer has to become when ad volume scales faster than learning, when AI compresses creative production to minutes, and when the buyer never sees the test matrix you ran.

George starts with the pattern he kept seeing from agencies. The creative team and the data team never sat together. Creatives made the ads. Analysts read the ad manager. The handoff between those two functions was weekly meetings, slide decks, and aging context. The people responsible for the next round of creative were almost never the people looking at the dashboards that showed what the last round produced. The learning never landed. Agencies delivered work that was, by design, detached from the context that would have made it better.

We go deep on why creative became the bottleneck, not spend or distribution. A decade ago, the constraint was production speed. Tools were expensive, crews were slow, iteration cycles were measured in weeks. That constraint is gone. Anyone can ship a variant in hours. The new constraint is knowing what to make. Volume is cheap, insight is scarce, and the teams that figure out what the account is telling them about their next creative outperform the teams that simply ship more.

We cover Canva Grow’s architecture in detail. The platform ingests creative, the product being sold, prior design history, brand guidelines, and live ad performance from every platform the company runs on. It puts that context in front of the teams making the ads, written in plain language. The contrast with the incumbent stack is architectural. Most performance stacks live in three different products with three different owners: the ad platform, the analytics platform, and the creative tool. Each has context the other needs. None of them share. Canva Grow’s play is to compress that into one surface where the context is always present and always current.

We go into the AI layer. George is direct on this. AI is a multiplier for creative teams that already have feedback loops running, and a noise amplifier for teams that do not. The failure mode is always the same: generate ten times more variants without adding a corresponding ten times to your learning capacity, and the signal degrades. The ads that work get buried. The ads that do not work get re-created in the next batch. Agentic layers only help when the loop underneath them is already closed. Without the loop, the agent is shipping faster against the wrong assumptions.

We cover why click-through rate lies. George’s framing is sharp. CTR can spike from a single hooky video where the creator pulled the viewer in without setting the right expectation. The click happens. The landing page converts at zero. The campaign metrics look good mid-funnel. The business loses money anyway. Downstream signals (add to cart, lead submitted, booking confirmed) are what separate a good ad from a curious ad. Every optimization that runs on CTR alone is running against the wrong proxy.

We go into the compounding thesis. One great static ad in a working feedback loop becomes a video ad on Facebook, a pre-roll on YouTube, an email hero image, and a paid social carousel. The asset is not consumed when it ships. It is compounded. Small teams inside Canva Grow move faster than enterprise teams with ten times the headcount because the context is in one place, the learnings transfer automatically, and the same asset gets worked across five surfaces before the enterprise team has finished its monthly retrospective on the first.

Discussed in this episode

0:00 Intro: why ads stall before spend does

2:20 What actually breaks underneath when creative "stops working"

4:30 Why creative became the bottleneck, not spend or distribution

6:15 How the bottleneck caps growth long before CAC spikes

9:30 Canva Grow: the context layer between creative and data

11:00 AI as multiplier, not savior

15:50 What good feedback looks like written out for the team

19:00 SMB versus enterprise: retargeting and accessibility

21:20 Performance metrics that lie

26:10 How one static ad compounds into video, YouTube, and email

31:40 Why small teams ship and learn faster

35:00 What enterprise can learn from SMB velocity

41:25 Rapid fire: the metric that lies most often in performance marketing

42:55 Closing: learning velocity is the new spend

Key takeaways

1. Creative and media are the same system, measured at different time scales The failure mode in most performance orgs is treating creative and media as two disciplines with a handoff between them. They are the same system. Creative makes the asset, media runs it, and the feedback from the run is what should shape the next asset. When the loop is broken, every round of creative is built against assumptions that were already out of date in the account. The fix is not a better brief. It is an architecture where the context that lives in the ad manager is visible to the people making the ads, in plain language, before the brief gets written.

2. Volume is cheap. Insight is scarce. A decade ago, the constraint on performance marketing was production speed. Tools were expensive, crews were slow, iteration was measured in weeks. That constraint is gone. Anyone can ship fifty variants this week. The new constraint is knowing which variant to invest into before running the test. Teams that figure out what the account is telling them outperform teams that simply ship more. Ad volume scaling faster than learning capacity is the silent tax at every growth stage. You only see it in CAC, months after the damage was done.

3. AI is a multiplier on a working loop, and a noise amplifier without one The teams winning with AI in performance marketing already had feedback loops running. AI compressed their iteration speed from days to hours. The teams losing with AI tried to generate their way out of a broken loop. Ten times more variants without ten times more learning capacity degrades signal faster than it produces output. Agentic layers amplify whatever is underneath. If the loop is closed, they compound. If the loop is open, they make the mess bigger at scale.

4. Click-through rate is the most dangerous single metric in the stack CTR can spike on a hooky video that pulls attention without setting the right expectation for the product. The click happens. The landing page converts at zero. The campaign metrics look good mid-funnel. The business loses money. Any optimization layer that runs on CTR alone is running against a proxy that does not correlate with revenue. The operational move is to pair CTR with at least one downstream signal (add to cart, lead submitted, booking confirmed) and drop any creative where CTR spikes without the downstream signal following.

5. One great asset, five surfaces. The compounding thesis. Most teams treat a winning ad as the end of the job. A great static in a working feedback loop is the start of it. The same asset becomes a video on Facebook, a pre-roll on YouTube, a hero image in email, a carousel in paid social, a hook in outbound. The compounding is not automation, it is deliberate propagation. Small teams with context in one place outrun enterprise teams with ten times the headcount because the propagation happens in days rather than quarters, and because every asset in the library inherits the learnings from every asset that came before it.

6. Small teams with context beat large teams with fragmentation The most counterintuitive signal in the episode. Teams of three or four with all the context in one place consistently outperform enterprise teams with dedicated specialists for every role. The reason is not talent. It is that in a fragmented stack, context leaks at every handoff. A creative director with no view into the ad manager is making decisions against last quarter’s reality. An analyst with no view into the creative brief is measuring against the wrong goal. Enterprise teams can match small teams on speed and learning only when they rebuild the context layer underneath.

Frameworks from the episode

1. The closed feedback loop as GTM infrastructure The architectural premise of Canva Grow. Ingest creative, the product being sold, prior design history, brand guidelines, and live ad performance from every platform. Make that context present in one surface. Put the surface in front of the people who make the next round of creative. The output is a loop where every new asset is informed by every old asset and every piece of live performance data from the account. The loop is not a report. It is the operating system for creative production. The specific failure mode it prevents is the one every enterprise team runs into: the people making tomorrow’s ads are not looking at yesterday’s data.

2. Creative diversity as an optimization variable Most performance marketing orgs optimize the single best-performing creative and ship tighter variants of it. The optimal move is the opposite. Run a wider diversity of angles, narratives, and hook structures, and let the ad account distribute spend to whichever performs. The algorithms underneath Meta, Google, and TikTok now optimize across angles, not within them. Shipping a narrow variant set of a single winning ad shrinks the surface the algorithm has to work with. A wider portfolio of structurally different ads gives the platform more axes to optimize and raises the ceiling of the campaign overall.

3. The asset compounding model One great static becomes a video ad on Facebook, a pre-roll on YouTube, an email hero, a paid social carousel, a landing page asset, and a sales deck slide. The asset is not consumed when it ships. It is the starting point for five other assets. Teams that treat the asset as terminal are optimizing the input. Teams that treat it as compounding are optimizing the output. The move is to make the creative team accountable not for ads produced but for surfaces the produced asset eventually runs on. The number shifts from one to five without shipping five times the work.

What to do this week

Audit the distance between your ad account and the people making your creative. If the creative team is more than one handoff away from the live performance data, the feedback loop is broken by design. The fix is not a better meeting cadence. It is a single surface where the performance data is visible to the creative team in plain language, before they write the next brief.

List the metrics your performance team optimizes against. For each one, identify whether it correlates to revenue or only to attention. If the primary input is CTR, impressions, or reach, the team is optimizing for a signal that can spike without producing pipeline. Pair every upper-funnel metric with a downstream signal, and drop any creative where the upper metric spikes without the downstream one following.

Count the number of tools between the creative brief and the live ad. If it is more than three, every handoff between them is a place context leaks. The architectural question is not which tool to buy next. It is which tools to collapse so the context lives in one place.

Before you add another variant to the campaign, ask what you learned from the last variant you shipped. If the answer is “it is still running” or “we have not pulled the numbers yet,” you are scaling ad volume faster than your ability to learn. The fix is not to ship less. It is to close the loop underneath the volume you are already shipping.

Why this matters

The performance marketing era rewarded volume. More ads, more tests, more spend. The playbook was simple because the constraint was simple. Get production capacity up, get channels diversified, get spend out the door. That constraint is gone. Production is cheap. Channels are saturated. Spend is table stakes. What separates the teams that grow from the teams that stall is not how much creative they ship. It is how fast they learn from the creative they already shipped.

Most companies have not absorbed this. They still operate with creative and media as two functions, with a handoff between them, with the creative team looking at the ad manager once a quarter if at all. The motion is not broken yet. It is losing compounding efficiency at every round compared to teams that have closed the loop.

The structural argument George makes is that AI accelerates whatever is underneath it. Teams that already had a closed loop are compounding faster than ever. Teams that did not are drowning in variants nobody has time to review. The agentic layer is not neutral. It amplifies the existing architecture, for better or worse. Building the layer on top of a broken loop does not fix the loop. It just produces more broken output, faster.

Revenue does not fail because teams stop creating. It fails when the feedback loop never closes, when creative and media sit in two different meetings with two different metrics, and when click-through rate is the only number anyone pulls from the campaign. The companies that win the next cycle are the ones that installed a learning loop underneath their creative production before the volume caught up with them.

This is GTM Vault.

If this episode changed how you think about the relationship between creative and performance, forward it to one operator still treating the ad account and the creative brief as two separate meetings.

Connect

Follow George Howes // Canva Grow

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. One working session to identify your primary GTM constraint and design the 90-day architecture to resolve it.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

Something structural happened to outbound between 2019 and 2026. The infrastructure got faster. The tools got smarter. The stack got deeper. And the outcome got worse.

Average cold email reply rate declined from 8.5% in 2019 to 7% in 2023 to 5% in 2025 to 3.43% in 2026. Open rates slid from roughly 36% to 27.7% over the same window. Global inbox placement sits at 84%, meaning one in six legitimate emails never arrives. Spam landing rate is 9.1%, roughly one in eleven. Over the same seven years, the average outbound team tripled the size of its stack.

The thing that compresses in ten minutes was never the thing that converts.

This playbook names the four architecture layers tooling did not compress, why the 3x gap between median and top-decile reply rate lives entirely inside those layers, and how to stand them up over twelve weeks. It is written for operators who already know how to wire a sequencer and who are wondering why the sequencer is not producing pipeline.

Subscribe now

The November 2025 Deliverability Cliff

One piece of context before the plays. Every send in 2026 operates against a hard constraint that was a soft preference before November 2025.

Gmail moved from temporary delays and soft bounces to permanent 5xx rejections for senders who fail SPF, DKIM, or DMARC authentication, or who post a spam complaint rate above 0.3%. Yahoo runs the same policy. Microsoft is close behind. The operational consequence is that a 500-send campaign now ships roughly 420 into inboxes, 45 into spam, and 35 into SMTP rejection the recipient never sees. The sequencer records all 500 as sent. The sender reputation dashboard, if you have one, is the only layer that knows the truth.

Once a mailbox crosses the 0.3% threshold, recovery is measured in weeks. Not hours. The ten-minute workflow has no mechanism to detect this has happened until the downstream pipeline goes flat and the team is left guessing what changed.

Play 1: Validate Intent Before Volume

The data. Intent-matched outbound converts 2.5 to 2.9 times higher than unmatched outbound. Demandbase Pipeline Predict accounts flagged “Highly Likely” convert at 31.5% within thirty days, a 2.9x lift over manual prioritization. Intent-flagged accounts advance through pipeline at 88% versus 77% without the flag, an 11-point gap. Bynder saw a 2.5x pipeline increase after layering 6sense on its outbound motion, with full ROI inside four months.

The move. Every account passes through two filters before it enters the sequencer. The ICP filter names who could buy (role, headcount, funding, region, stack). The intent filter names who is buying this quarter. Accounts that clear both filters go to the working list. Accounts that clear ICP but miss intent go to the bench and stay there until a signal fires. The bench is the 60 to 90% of your addressable market that is not in-market right now. It is not dead. It is dormant.

Signals that count. Visited pricing page in the last 14 days. New executive hired into the buying role in the last 90 days. Funding event in the last 90 days. Category keyword engagement on content. Competitor displacement in a public job description. Named event on the calendar: conference, fiscal cutover, compliance deadline, grant deployment window.

The 14-day action. Pull your top 500 accounts. Tag each one with which intent signals have fired in the last 60 days. Move anything with zero signals to a named bench list inside the CRM. Anything with two or more signals is the working list. The working list at any moment should be 50 to 150 accounts, not 500, and it should refresh weekly as signals fire and expire. If you have no intent tool, start manually with public signals (earnings calls, hiring announcements, funding news, product launches, press) and instrument as you go.

What to stop. Stop sending to accounts with zero signal in the last 60 days. Stop treating volume as a proxy for effort. Sending 100 signal-matched emails is operationally harder than sending 1,000 undifferentiated ones, and it is the only version that produces a reply.

Every send to an out-of-market account is a charge against the sender score that will eventually cost you the in-market sends.

Play 2: Tie Narrative to a Named Operating Constraint

The data. Generic cold emails get roughly 9% response rates. Emails with advanced personalization tied to the recipient’s context get roughly 18%, a 2x lift from the same stack and the same day of the week. Highly personalized campaigns using multiple custom fields produce 142% more replies than non-personalized baselines. Teams running AI personalization at depth report reply rates up to 35% on high-signal accounts. Only 5% of senders personalize every email. The 5% who do capture 2 to 3x the reply rate of the 95% who do not.

The move. Every opener names the prospect’s current operating constraint in language they would recognize as true. Not category-level (”I noticed you are in B2B SaaS”). Not resume-level (”Saw you hired 3 AEs after your Series B”). Constraint-level: what is actually making their quarter hard, and how do you know.

“The CTEIG allocation you received on October 27 has a June 30 encumbrance deadline and your current CTE vendor does not cover the biomedical pathway named in your grant application.” “Your Q3 board deck listed pipeline coverage at 2.4x against a 4x plan and the reason your 12 reps are not closing the gap is not a rep problem.” Those openers reference specific public information the sender had to read to write. They also imply a solution the prospect will hear when they reply.

The 14-day action. For the top 20 accounts on the working list, write a three-sentence opener that names a specific operating constraint, sourced from public signal (earnings call, job description, grant award, press release, board deck summary, LinkedIn announcement). Run each opener past the question: would this recipient recognize this as true about their current quarter. If no, research more before sending.

What to stop. Stop calling first-line personalization “personalization.” Stop using AI to mass-generate opener lines that reference category truths. Stop shipping sequences before the opener has been tested against three prospects in the same persona. The stack commoditized sending. Narrative specificity is the only leverage left.

If the opener could plausibly have been sent to three other companies in the same industry, it is not a constraint. It is a category pitch in a personalized shell.

Play 3: Treat Deliverability as Infrastructure, Not as a Tool

The data. One in six legitimate emails misses the inbox globally. One in eleven lands in spam. Gmail’s hard threshold is 0.3% spam complaints. Once you cross it, the sending domain is functionally dead for weeks.

The move. Three architectural decisions most ten-minute workflows skip. First, separate outbound sending domains from the corporate domain by at least one registration layer. Never send cold from the domain that also hosts your marketing site, your customer support, or your billing. A deliverability incident on outbound should not collapse the deliverability of the revenue-generating side of the business. Second, run your operational ceiling at 0.1% spam rate, not at Google’s 0.3% rejection line. By the time you cross 0.3% you have already been rejected. 0.1% is the warning. Third, ramp every new mailbox slowly. 20 to 30 sends per day for the first 14 days. 40 to 80 for the next 14. Full volume only after day 28, and only on mailboxes with a reputation score above a defined threshold.

The 14-day action. Audit the sending domains currently active. Any outbound still coming from the primary corporate domain moves to a dedicated outbound domain this week. Set DMARC to enforcement policy (quarantine or reject), not to monitor. Install per-mailbox spam rate, bounce rate, and inbox placement monitoring outside the sequencer. This last one is non-negotiable.

What to stop. Stop trusting sequencer dashboards for deliverability truth. Stop running outbound off the domain that serves customers. Stop treating a warm-up app as a deliverability strategy. Warm-up is one tactic inside a broader discipline.

The sequencer dashboard’s business model depends on showing you send volume. The inbox placement layer does not pay the sequencer to tell you the truth.

Play 4: Close the Feedback Loop Every Week

The data. Average reply rate is 3.43%. Top-decile senders clear 10%. The top decile is not running a different stack. They are running a different loop.

The move. Three metrics measured every Friday, independent of what the sequencer reports. First, reply type distribution across the week’s sends. Positive interest, negative interest, wrong person, unsubscribe, silence. Silence is the dominant category at 3.43% reply rate and it is the most useful to instrument, because silence means either the signal was wrong, the narrative was wrong, the deliverability failed, or some combination of the three. Second, signal-to-send correlation: of the sends this week, how many were tied to an intent signal that fired in the last 30 days, and what was the reply rate on those versus sends that had no recent signal. This tells you whether Play 1 is working. Third, narrative outcome mapping: which opener themes produced positive replies, which produced “wrong person” replies, which produced silence. Positive-reply openers get doubled the next week. Wrong-person openers get investigated for persona error. Silence openers get retired.

The 14-day action. Build the Friday review as a 30-minute operational ritual, not a quarterly retro. Three outputs per week: the retired opener, the doubled opener, the signal type that produced the best reply rate. Over twelve weeks of this ritual, the reply rate on the sends you are still making climbs from 3% to 8-to-10%, because the motion iteratively kills what does not work and amplifies what does.

What to stop. Stop reviewing sequencer dashboards as a substitute for running the loop. Stop pushing more volume when the reply rate is flat. Stop treating individual sends as disposable. Every silent send is data that should have retired an opener, a persona theory, or a signal type.

Outbound without a feedback loop is not compounding. It is running open-loop on assumptions that were true the day the sequence was built.

The Top-Decile Gap Is an Architecture Gap

The teams clearing 10%+ reply rates are running the same stack as the teams stuck at 3.43%. What they have that the median does not is four architecture layers running in lockstep: intent-validated ICP, narrative tied to named operating constraints, deliverability treated as infrastructure with per-mailbox monitoring, and a weekly feedback loop that kills and amplifies.

None of these four layers are compressible by tooling. They take weeks to stand up and months to tune. That is why they produce a moat. Anyone can copy a ten-minute workflow in ten minutes. Almost no one is willing to put the twelve to sixteen weeks into the four layers above it.

The 3x reply rate gap is a patience gap disguised as a tools gap.

Twelve Weeks to Top Decile

Execute the four plays in sequence. Each layer is a prerequisite for the next one producing lift. Adding a tool before the underlying layer is built is how teams end up with fifteen tools and 3% reply rates.

1. Weeks 1-2. Foundation. Separate outbound domain from the corporate domain. Install per-mailbox deliverability monitoring. Set DMARC to enforcement. Audit the current 500-account list and move anything without signals to the bench. Write constraint-named openers for the top 20.

2. Weeks 3-4. Signal layer live. Tag every account on the working list with fired signals in the last 60 days. Refresh the list weekly. Start the Friday feedback review as a 30-minute operational ritual.

3. Weeks 5-8. Narrative and deliverability locked. Every sent opener names an operating constraint, tested against the recognition question. Sender reputation held under 0.1% spam rate per mailbox. Retire the silence openers each Friday. Double the positive-reply openers.

4. Weeks 9-12. Feedback loop compounding. The Friday review has eight to twelve weeks of data. Reply rate on signal-matched sends should be 8-to-10%. Expand mailbox and domain count only after per-mailbox reputation is stable for four consecutive weeks.

By week twelve, a team running this sequence will be booking more qualified conversations than a team running the ten-minute workflow at ten times the send volume. The volume team will not know why they are losing, because the sequencer dashboard will show their numbers are up.

Doctrine for Pre-Revenue Founders

Three principles worth internalizing before the first send of the new motion.

Infrastructure compresses execution. Architecture compounds pipeline. Tools speed up the layer that was already fast. The layers that actually produce conversion (intent, narrative, deliverability, feedback) are architecture, and architecture is not compressible by design. Treating a sequencer as a GTM system is the default failure mode of 2026 outbound.

List size is a function of the motion, not a substitute for it. Seventy signal-matched accounts with constraint-named openers outperforms 500 undifferentiated ones at every stage of the funnel: inbox placement, reply rate, meeting acceptance, pilot conversion. Volume without architecture is expensive noise that spends sender reputation.

The stack you can stand up in ten minutes can be stood up by everyone. Things everyone can do are worth what everyone can pay for them. The moat is not the tools. The moat is the four layers the tools cannot touch.

The Stack Is Not the Campaign

The ten-minute workflow is infrastructure. Infrastructure compresses execution. GTM campaigns are architecture. Architecture compounds pipeline. Those two statements are not the same statement, and the difference is what separates teams that build revenue systems from teams that stack tools.

The industry traded reply rate for setup speed every year since 2019. The trade is no longer producing net gains. The teams that will win outbound in 2026 are the teams that invest in the four architecture layers before they add the sixteenth tool. The first three weeks look slower than the ten-minute playbook. The next nine weeks compound. By week twelve, the two motions are not in the same category of system.

Pick the architecture. The tools will still be there when you need them.

Sources

• Instantly, Cold Email Benchmark Report 2026 (reply rate, open rate, inbox placement trends)

• Validity, 2025 Email Deliverability Benchmark Report (global inbox placement, spam landing rate)

• Google and Yahoo, 2024 and 2025 Sender Requirements (spam threshold, one-click unsubscribe, November 2025 5xx enforcement)

• Landbase, Intent Signal Statistics 2026 (conversion lift, pipeline advance rate, Demandbase Pipeline Predict, Bynder case data)

• SalesCaptain, Cold Email Statistics 2025 (personalization lift, generic vs advanced response rate, AI at depth)

• Martal, B2B Cold Email Statistics 2026 (year-over-year trend data, top-decile benchmarks)

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

This episode: Jai Toor walks through the Niche Signal Discovery skill built on top of Claude Code and DeepLine, a workflow that pulls wins and losses from HubSpot, mines the differential signal between them, and exports a verified-lead outbound campaign into Lemlist end-to-end from a single terminal. The system compresses a month of manual propensity work and nearly two thousand dollars of enrichment spend into thirty minutes and under ten dollars. The breakdown below maps the build back to the Revenue Architecture.

Subscribe now

The Signal Commoditization Gap

Most GTM teams run their signal layer on the same three inputs: hiring posts, funding rounds, and tech stack changes. Everyone scrapes the same sources. Everyone ingests the same data into the same enrichment pipelines. Everyone reaches out on the same week. The signal stops being a signal the moment everyone is pulling from the same place.

This is not a data gap. It is a sourcing gap. The data sits on every target’s public surface. What is missing is a method for finding which specific patterns on that surface correlate with wins, and the compute to test that against every account at a cost that makes the work economical.

Jai has spent the last year building the action layer that closes that gap. Before DeepLine, Jai spent five years on growth at Uber, then built data and product at Capchase, Datafold, and VeriShop. He co-founded DeepLine, an integration layer that sits underneath the agent and handles every API call in a signal workflow through pay-as-you-go credits. He sits at the intersection of growth engineering and data infrastructure, which is exactly where this problem lives.

In this episode, Jai walks through the full build. First, the Niche Signal Discovery skill running inside Claude Code. Then the infrastructure layer that makes the skill possible: DeepLine’s connectors to HubSpot, Lemlist, and every data source the workflow needs to reach. The argument for why this is architecture and not a tool is that the same shape runs at every layer of the signal stack once the context layer exists underneath.

The Win-Loss Foundation: Why Most Signal Work Starts in the Wrong Place

Jai’s first structural point is that most signal discovery runs on the win list. Take closed-won accounts, find the common keywords on their websites, target more accounts that look like them. The output is generic ICP work dressed up as signal discovery. Everyone selling to consumer fintech will find “fintech” on the website. That is a description, not a signal.

Jai inverts that. The workflow pulls wins and losses from HubSpot together, not just wins. Both cohorts are accounts the team engaged. Both cohorts were qualified enough to reach opportunity stage. The difference between them is the real selection criterion the market is using, whether the team designed it or not.

In the cybersecurity case walked through on the episode, the dataset was seventy-four deals. Wins and losses combined. Claude Code scraped the customer websites of every account on that list, generated keyword hypotheses programmatically, tested them against the scraped content, and surfaced the keywords that separated wins from losses. The positive signal for that ICP was FDIC mentioned on the company website. Specific. Testable. Almost certainly a consumer fintech company with regulated retail deposits.

The previous version of this model had used “open an account” as the proxy for the same concept. Directionally correct. Categorically worse. The specificity of the surfaced keyword is the difference between a signal that compounds and one that decays into a category filter.

Accounts that differentiate cleanly between wins and losses are the only accounts worth running downstream signal monitoring on. Everything else produces noise in the outbound queue.

The Differential Signal Layer: Positive and Negative Fit

The other half of the architecture is the negative signal layer. Most scoring systems only reward positive fit. Keywords that correlate with wins get a positive score and everything else gets ignored. Jai’s system builds both sides.

Two examples from the episode. SOC 2 Type 2 compliance on the target’s website was a positive for B2B buyers. Intuitive. The counterintuitive one was advanced engineering culture with heavy in-house tooling. Engineering-dense companies often look like good prospects on paper because they have the technical maturity to evaluate the product. The model surfaced the pattern that they close less frequently because they tend to build rather than buy.

The consequence of running only positive fit is that the BDR team spends its time on accounts that look like wins but behave like losses. One of the enterprise customers in Jai’s data had been spending 44% of their opportunity time on bad-fit accounts. Not because the BDRs were unskilled. Because the scoring model had no way to surface the structural signals that kept those accounts from closing.

Fix the negative signal layer, reclaim the 44%, and close rate moves 15 to 17 percentage points before anything else changes.

The Niche Signal Discovery Skill: One Command, End-to-End

With the scoring architecture in place, the actual skill runs from the terminal. One command. End-to-end execution.

The agent pulls every won and lost deal from HubSpot through DeepLine. It scrapes the customer websites in parallel. It generates keyword candidates from the scraped content, tests each candidate against the win and loss pools, and scores the ones that differentiate. It builds the composite propensity model. It runs the model against a hundred unqualified target accounts pulled from the enrichment source, scores them, and drops the top tier into a Lemlist campaign with verified emails and generated first-line personalization.

The output is a markdown doc. Five takeaways. A signal model with positive fits and negative fits, each scored. A hundred verified leads exported into Lemlist, with sequence copy generated, sender deliberately unattached so the operator has to confirm before the send.

Human in the loop at the send step is intentional. Every agent in Jai’s stack gets a confirmation gate before any external action fires. The Lemlist sender is unattached by default. The email drafts wait for approval. The CRM sync confirms before writing. This is the trust-building layer that gets skipped most often, and the one that determines whether a team keeps using the system after the first misfire or abandons it.

The Compression: Why Bespoke Enrichment Beats Off-the-Shelf

Jai ran this exact workflow manually for the same cybersecurity customer about six months before Claude Code and DeepLine made the end-to-end version possible. The comparison is the case for the architectural shift.

The manual version took over a month. It cost nearly $2,000 in enrichment spend. The team had to sit together and hypothesize roughly forty candidate keywords, then pay for AI to extract each one from every website in the dataset, then manually figure out which of the forty actually mattered. Most did not.

The current version runs in under thirty minutes and under $10. The keyword hypothesis step, which was the unscalable manual bottleneck, is now generated by Claude Code based on the content the agent reads. The extraction runs through DeepLine. The scoring runs in the same session. The outbound campaign writes itself into Lemlist at the end.

$2,000 to $10. One month to thirty minutes. Same outcome. Different infrastructure.

The output is not marginally better than the manual version. It is more specific. The manual version surfaced “open an account” as the proxy for consumer fintech. The current version surfaces FDIC. That specificity compounds at every downstream step: the outbound filter is tighter, the copy is more pointed, the reply rates move. Reply rates on campaigns running on Jai’s signals land at roughly 2x the baseline. A CPG customer who flipped from scraping retail websites to scoring every company with a store locator saw the same 2x lift on cold email and LinkedIn. An enterprise customer saw 15 to 17 point higher close rates once the negative-signal layer was active.

The enabling variable is Claude Code plus DeepLine. Jai’s not writing production infrastructure code to build this. DeepLine handles the API integrations through pay-as-you-go credits. Claude Code handles the orchestration. The bottleneck moves from engineering execution to problem specification. What are we optimizing for, and what does “won” actually mean in the context of this business.

The Adoption Curve: Who Is Actually Building This

The BDR function is not disappearing. It is being redeployed.

Two patterns show up in Jai’s customer base. The first is larger BDR teams with higher per-rep ROI. A BDR who used to touch 20 accounts a day is now touching 40 to 80. The raw information gathering that used to fill the calendar is gone. The rep spends the reclaimed time on calls, campaigns, and multi-threading. Revenue per rep goes up and total rep count also goes up because the unit economics of hiring another BDR improved.

The second pattern is BDR removal. One PLG customer stopped using the function entirely. AEs close the qualified PLG leads plus the automated outbound flow directly. No BDR handoff in the middle. This works when the ACV is low enough that the AE motion is economical and the close is AE-friendly. It does not work in long-sales-cycle enterprise environments where the BDR still does orchestration, phone work, and multi-threading that AEs are not positioned to run.

Cold calls still work. Jai’s customers in restaurants, CPG, and data analytics are getting meaningful lift from phone outbound, including to titles that were supposed to have moved online years ago. Chief data officers and VPs of data still pick up the phone when the signal is specific enough to justify the call. The constraint is not the channel. It is whether the signal upstream of the channel is differentiated.

Read more

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.

Executive Summary

The GTM stack has been fragmenting for a decade. Most B2B companies now run six revenue motions across thirty-plus tools, managed by nobody in particular, reconciled by dashboards nobody trusts, and asked to produce leverage from an AI layer that starts every session at zero.

The bottleneck is not the models. It is not the tools. It is the context layer between them. Without one, every prompt is a cold start. Every agent is doing generic work on a generic description of the company. Every session dies when the tab closes.

Model Context Protocol (MCP) is the first piece of infrastructure that closes that gap. It is quiet. It is unsexy. It will not make a keynote. It is also the architectural inflection that separates the GTM stacks that will compound over the next cycle from the ones that will not.

This post establishes four structural truths.

1. The fragmentation of the modern GTM stack is a context problem, not a tooling problem.

2. MCPs convert the stack from a collection of tools into an operating system for the motion.

3. Five real stacks already operate on this pattern. The outcomes are measurable and the architecture is public.

4. Teams that install the context layer this year will compound at a rate teams on the fragmented stack cannot match.

What follows is the operator-level breakdown of each.

Subscribe now

The Fragmentation Tax

Sangram Vajre captured the underlying condition in a line worth stealing: ask most B2B CEOs what their revenue motion is and they will say “we do a little bit of everything.” That is not a go-to-market strategy. That is channel accumulation dressed up as strategy. Industry research puts the average B2B company at six revenue motions in flight, most of them unmanaged.

Each motion came with its own tooling. Outbound bought Apollo, Clay, Lemlist. ABM bought 6sense and Demandbase. Revenue ops bought Salesforce, Gong, and a data warehouse to reconcile the other two. Customer success bought Gainsight. Product bought Amplitude. Marketing bought HubSpot on top of Marketo on top of Mailchimp. Each tool solved the motion it was sold against and created a new fragmentation tax at the boundary between motions.

A side-by-side of the old playbook makes the texture concrete. Buy a static list from ZoomInfo or Salesforce. Load fifty thousand contacts into Outreach, Salesloft, or Marketo. Pay ten BDRs to grind eight-step cadences. Hope for a three percent reply. That is not a system. It is ten people manually carrying the context the stack should be carrying for them.

The tax compounds in three directions.

The first is a data tax. Every tool has its own schema. Reconciliation happens manually or through brittle scripts. Half the RevOps function exists to repair handoffs that should not break in the first place.

The second is a human tax. Every operator becomes a translation layer. The marketer formats the ICP for the sequencer, the SDR re-translates it for the caller, the AE re-translates it again for the deal desk. The same information passes through three re-interpretations before it reaches the account.

The third is a signal tax. Most of the observable intent in the stack is stranded inside a tool that cannot talk to any other. Product usage sits in Amplitude. Intent sits in 6sense. Renewal signal sits in Gainsight. Each is a rich source. None feeds the others.

The architectural point sits underneath all three. The bottleneck is not the models or access to tools. It is how well everything is connected, and how willing the company is to rewire itself when the market moves. AI layered on top of a fragmented stack does not fix the fragmentation. It amplifies it. An agent running on six to eight disconnected tools produces noise at scale, because every session starts at zero and the context it needs lives in places it cannot reach.

This is not a tooling problem. It is an architecture problem.

The Reframe: Context as Infrastructure

MCP is a protocol, not a product. It lets an agent talk to every tool in the stack through standardized servers. Pre-built servers exist for most tools a GTM team already owns. Custom servers can be built for the ones that do not.

What it replaces is mechanical. The copy-paste of context into every new chat. The tab-switching between CRM, data warehouse, calendar, and sequencer. The re-prompting of the same ICP every session. The generic output that comes from the model having no access to the company’s actual data.

Agents got the hype. MCPs got the adoption. The agent is the surface the operator interacts with. The MCP layer is the infrastructure that lets the agent act on the real stack instead of acting on a description of the stack.

Once the context layer is in place, the unit of work changes. An operator is no longer building prompts. They are composing motions. The outbound agent calls the CRM through an MCP, pulls the account, reads the last two quarters of product usage from the warehouse, checks the calendar for the next free slot, and drafts the follow-up. The surfaces do not matter. The context carries.

The structural consequence is the one that matters. When context persists across sessions and across agents, the operator stops owning the translation layer. The stack starts carrying the motion instead of the operator carrying the stack.

The Pattern in Production

Five stacks currently operating in the new architecture. Each one is public enough to verify and documented by the operators who built it. The common property is that context moves across the surface. Every one of them would collapse without it.

The sixteen-MCP reference stack. A recurring pattern across dozens of high-functioning B2B GTM systems: roughly sixteen MCPs organized by category (productivity, data, outbound, content, analytics). The architectural property is not the tool list. It is that the same context carries across every surface, so the agent is not re-learning the ICP on each call.

The role-based agent stack. Twenty-three opinionated tools structured as role-based agents. CEO. Designer. Engineering Manager. Release Manager. Doc Engineer. QA. The stack is the org chart, translated into an agent layer. Public GitHub repo. Clonable. The pattern worth noticing is that the agents are defined by their function, not by the tool underneath them. That is the operator shift.

The open-sourced GTM engineering playbook. Production-grade GTM engineering systems built for Linear, Descript, and Canva, open-sourced as a public GitHub repo. This is the first time production GTM engineering has been cloneable. Before this, the playbooks lived in internal Notion pages and in the head of the operator who built them. Now they live in a repo anyone can fork.

The high-density AI-native stack. $30M revenue target with under eighty people. Seventy-eight tools used weekly, tested down from three hundred and fifty. Signal-driven across every function, from prospect enrichment to delivery ops. The case is interesting not because of the tool count but because the tool count works. Density is a feature when the context layer holds. On a fragmented stack, seventy-eight tools is chaos. On a unified context layer, it is specialization.

The motion-first rebuild. Sixty meetings per month booked on autopilot without adding headcount. Eight structural shifts, starting with hybrid AI SDRs that augment humans rather than replace them. The architectural claim inside the case is the one to notice. The rebuild was of the GTM system, not the tool stack. The tools changed because the system changed first.

Five stacks. Five different company shapes. The common property is that context moves across the surface. More stacks in this pattern are documented weekly in Show Me Your Stack.

What Compression Looks Like in Practice

Three public cases of signal-to-action compression, each one measurable and each one dependent on the context layer working. Without the context layer, none of these three motions produce these outcomes.

$1M to $10M ARR in nine months. Interviews with more than a dozen AI-native founders across late 2025 and early 2026 show a consistent pattern. The compression from $1M to $10M ARR now runs under nine months, against a historical baseline of twenty-four-plus months for IPO-caliber SaaS. The compression is not explained by better product or more capital. It is explained by the motion, the content layer, and the outbound engine running on one context substrate instead of three.

ABM meetings with AWS, a16z, Harvey, and Anthropic in a single quarter. A seven-play Clay-based ABM motion produced Q1 meetings with AWS, a16z, HG Insights, Harvey AI, and Anthropic. The filter did the work. Target by challenge type, not firmographics. Same company size does not mean same problems. The play is possible because Clay, enrichment, and messaging share context through the stack. Without that, the filter is just another manual step.

A complete marketing rewrite in four hours. Four hours inside one agent surface rewrote a growth-stage company’s entire marketing function. Step one: find the golden segment using Stripe retention data. Step two: learn what made that segment different. Step three: rewrite every piece of acquisition to attract only that segment. The four hours did not compress because the operator was typing fast. They compressed because the context needed (payments, retention, product usage, segment signal) was all reachable from one agent surface.

The through-line across these results is not speed. It is that signal-to-action compression stops being heroic. The same rewrite, the same ABM play, and the same outbound rebuild used to take a team a quarter. The stack with the context layer makes it a week.

The Operational Shift

Most operators skip the basics and jump to tactics. Tools. Channels. Hacks. Messaging clarity and ICP clarity come later, if at all. The result is a team running fast on a foundation that was never set.

The AI layer makes that worse in the old architecture and better in the new one. On a fragmented stack, AI ships fast output with no foundation. On a stack with MCPs, the foundation is encoded once and every agent inherits it. The ICP definition lives in one place. The retention signal lives in one place. The product usage lives in one place. Every agent that touches the stack starts from that foundation instead of rebuilding it.

Anthropic’s Claude Managed Agents is the inflection that makes this mechanical. Persistent context across sessions. Sub-agents running in parallel under a single orchestrator. Built-in error recovery. The infrastructure is catching up to the architectural premise that an agent without context is a very expensive prompt loop.

The shift for the operator is straightforward. Stop thinking about the stack as a collection of tools. Start thinking about it as an operating system for the motion. The tools are interchangeable. The context layer is not.

What Is Load-Bearing

Three structural claims carry the weight of this post. If any of them is wrong, the rest of the argument collapses.

1. Fragmentation is a context problem, not a tooling problem. Every stack consolidation effort of the last decade (CDPs, data warehouses, reverse ETL, headless CRMs) attempted to solve it at the data layer and underperformed. The reason is that the unit of fragmentation is not data. It is context. Data can be centralized. Context has to be composable across agents. MCPs are the first protocol that treats it that way.

2. The agent is a surface. The context layer is the infrastructure. Teams that buy agents without building the context layer end up with a more expensive version of the problem they had. The agent amplifies whatever is underneath it. On a fragmented stack, that is noise. On a context layer, that is leverage.

3. The operator’s unit of work is shifting from prompts to motions. The team that still runs on prompts is running manual labor dressed up as AI. The team that runs on composed motions is running infrastructure. The first one hits a ceiling at scale. The second one compounds.

What to Install This Quarter

Map your stack by role, not by category. Which agent owns the outbound motion. Which agent owns renewals. Which agent owns the content layer. If nobody owns the motion, no tool in the stack will fix it. The first deliverable is an org chart of the agent layer, drafted before any MCP is written.

Identify the three places your team starts every session at zero. Those are your MCP targets. The ICP that gets repasted into every chat. The account context that never crosses the seam between CRM and warehouse. The product usage signal that lives in Amplitude and never reaches the sales team. Those are the three surfaces that need a context layer first. Start there.

Pick one motion (outbound, onboarding, or renewals) and rebuild it with a single persistent context layer. Measure conversion before and after. Teams that have done this have compressed multi-week motions into multi-day motions. The conversion lift is a side effect. The real prize is that the motion now runs without the operator who built it.

Kill the tools that exist to compensate for bad context. Most of them go away once the context layer works. The reconciliation scripts. The manual enrichment layers. The dashboards built to patch over the gap between two tools that do not talk. That is not a feature of your stack. It is evidence of what the stack is missing.

Run a context audit every quarter. The stack will drift. Agents will accumulate. New tools will ship. Without a deliberate review, the context layer will fragment faster than it can consolidate. Treat context drift the way a platform team treats tech debt. Name it. Track it. Retire the pieces that no longer carry weight.

Why This Matters

Software is no longer defensible at the code layer. Features ship in a weekend. A competitor clones the product in two. What compounds is how the system connects, how fast the team rewires it when the market moves, and how much of the company’s operating knowledge is encoded in a place an agent can reach.

The Figma week was the clearest preview of what that means in practice. On a Monday, Anthropic’s CPO resigned from Figma’s board. The same day, news broke that Claude’s next model would ship with design tools. By Thursday, Anthropic launched Claude Design. Figma closed down 7 percent. Adobe, Wix, and GoDaddy took hits in the same window. The product reads the codebase, applies the brand system automatically, and hands finished work to Claude Code for production. The application layer that took Figma a decade to build was reabsorbed into the model layer in four days. That is the dynamic every B2B company built on a foundation model is now operating inside.

MCPs are the first piece of infrastructure that makes the response to that dynamic mechanical rather than heroic. The defensibility moves from the product to the system around it. Teams that install the context layer this year are the teams running the same motion at five times the velocity twelve months from now. Teams that stay on the fragmented stack will be the ones still pasting the ICP into every new chat, wondering why AI is not producing the leverage the slide deck promised.

This is not a tooling cycle. It is an architectural cycle. The separation over the next two years is between teams that treat AI as a tool and teams that treat it as infrastructure. The difference is the context layer. It is already in production at the companies that will compound hardest.

Sources and Further Reading

The architectures, cases, and findings above are grounded in the work of operators who are publishing their systems in public. The list below is the subset whose work directly shaped this post.

1. Sangram Vajre, GTM Partners. The “little bit of everything” observation and the six-motions data point.

2. Ben Carden, RevenueFlow. Side-by-side of the legacy outbound stack and the AI-native rebuild.

3. John Hurley. The AI Transformation Model and the architectural framing that connection speed is the bottleneck.

4. Maja Voje, GTM Strategist. The “agents got the hype, MCPs got the adoption” framing, the sixteen-MCP reference stack, the seven-play Clay ABM motion, and the Revenue Architects playbooks share.

5. Garry Tan, Y Combinator. The gstack GitHub repo, twenty-three opinionated tools structured as role-based agents.

6. Nico Druelle and Karl Rafidimanana, Revenue Architects. Open-sourced GTM engineering systems for Linear, Descript, and Canva.

7. Dan Rosenthal. The $30M AI-native services stack running seventy-eight tools weekly under eighty headcount.

8. Tim Carden. The motion-first rebuild producing sixty meetings per month without adding headcount.

9. Kyle Poyar, Growth Unhinged. Interviews with AI-native founders documenting the $1M to $10M ARR compression.

10. Zayd Syed Ali, Valley. The four-hour marketing rewrite using payments, retention, and segment signal through a single agent surface.

11. Brigitta Ruha. The observation that most operators skip the basics and jump to tactics.

12. Show Me Your Stack. Weekly documentation of production AI-native GTM stacks across B2B companies.

13. Anthropic. Claude Managed Agents announcement and the Figma week coverage referenced in the closing section.

👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 25,000+ operators building GTM systems that compound.

Most demo experiences are still screenshots in a slide deck or a 45 minute call where the prospect watches someone else click. Both are artifacts of an era where the sales motion carried the product. Neither survives in a market where buyers self-serve, shortlist in private, and decide before a human ever enters the loop.

Joseph Lee built Supademo to replace both. Before Supademo, Joseph built Freshline, North America’s first predictive marketplace for seafood. $2.5 million raised. Forbes 30 under 30 at 22. COVID wiped out 90% of revenue overnight. The insight that came out of that collapse became the foundation for the second company.

Supademo is AI-native interactive demos that help teams convert faster and onboard better. 150,000 professionals across 100 countries. 2,000 paying companies. G2’s number five fastest growing product. 8x growth in 2024. 3x in 2025. Profitable. The platform now audits demos against 300,000 data points before a prospect ever sees one, and ships self-healing agents that regenerate demos when the underlying product changes.

In GTM 44, Joseph breaks down why the demo layer is becoming core GTM infrastructure, why most product-led companies lose conversion at the exact moment they should be proving value, and what changes when the demo stops being a sales artifact and becomes a composable asset that runs across every stage of the funnel. He explains why capital efficiency is an optionality decision, not a virtue signal, why distribution and brand eminence are becoming the only durable moats, and why PMF has a short shelf life now.

This is not a conversation about better demo tools.

It is a conversation about why the demo is the unit of the sale in a product-led world, and what happens when you treat it as infrastructure instead of a one-time artifact.

Inside this episode

This episode maps the structural gap between how most companies use demos and what the demo layer has to become when buying happens asynchronously, across functions, and without a human narrator in the loop.

Joseph starts with what Freshline taught him. The first company was chosen on a problem, not a market. The seafood industry had not changed in decades. The amount of change management required to move distributors off fax, pen, and paper was a fixed cost that every deal inherited. The takeaway was not “pick better markets.” It was that market readiness is an architectural property of a business, and underwriting a traditional vertical means underwriting a multi-year adoption curve whether you planned for it or not.

We go deep on the pivot. At Freshline, Joseph tried videos, Looms, screenshots, and written documentation. All of it was passive. Prospects did not watch twenty-minute videos. Documentation went out of date the moment the product shipped. The only format that produced the aha moment was an interactive back-and-forth screen share. That became the structural insight behind Supademo: the conversion moment in a software sale is touching the product yourself, in context, at your own pace, not watching someone else use it.

We cover the $1M ARR motion in detail. Programmatic alternative pages at the bottom of funnel. SEO-ranked product demos of competitor tools at the middle of funnel (Ahrefs product demo, Canva product demo) with an interactive Supademo embedded as the thing the visitor is actually looking for. Direct response on Reddit threads and changelog comments at the edges. Each layer uses the same asset. The product is the acquisition channel and the conversion asset at the same time.

We cover the reframe from demo-as-artifact to demo-as-infrastructure, the self-healing agent layer shipping in Q2, the AI demo audit that captures three hundred thousand demos of tribal knowledge into a one-click improvement loop, why capital efficiency protected optionality at Supademo where it failed at Freshline, the internal Cursor-style all-hands that forces the team to question what assumptions are already outdated, and why distribution is king and product is second.

Discussed in this episode

In this episode, we cover:

0:00 Intro: the demo as core GTM infrastructure

2:11 What Freshline taught about markets versus problems

5:47 The $1M ARR motion and why almost nothing scaled

8:51 Defensibility when anyone can ship software in a weekend

11:16 Demo as infrastructure, not artifact

13:40 What separates the demos that convert from the ones that don't

14:56 The AI demo audit and what it catches that humans miss

17:03 Who owns the demo layer inside an organization

18:35 Profitable growth and the optionality argument

21:27 PMF has a short shelf life: running your own Cursor all-hands

25:40 Content as a GTM system, not a marketing channel

27:28 Where AI genuinely accelerates and where it breaks

29:17 Change management as the invisible cost of adoption

Key takeaways

1. Market readiness is an architectural property of the business The seafood industry had not changed in decades. The amount of change management required for any new software was a fixed cost on every deal. Freshline underwrote a multi-year adoption curve without knowing it. Supademo was chosen on the opposite condition: three structural tailwinds (new tools launching weekly, AI compressing content creation, PLG expanding the buyer surface) that answered the why-now question. The lesson is not to pick easier markets. It is to recognize that the tailwinds or headwinds of a market are priced into every deal whether you modeled them or not.

2. The conversion moment is touching the product, not watching it At Freshline, videos and documentation were passive. Prospects did not engage. The only format that produced the aha moment was an interactive screen share. That is the structural insight behind Supademo. Every other artifact (pitch decks, explainer videos, written docs) is narration around a conversion moment that only happens when the buyer touches the product themselves. Product-led companies that treat the demo as a sales meeting are losing conversion at the exact moment they should be proving value.

3. The demo is the unit of the sale, not a supporting asset Most companies treat a demo as perishable. Build one hero demo, put it in the sales deck, discard it when it goes stale. Supademo’s architectural premise is the opposite. The demo is modular, composable, and reusable across every surface: email sequences, in-app product tours, support documentation, trade show video exports, product update changelogs, marketing landing pages. The content library becomes the source of truth. Updates propagate. Offshoots get created from a base. This is the difference between a pile of assets and a system.

4. Capital efficiency is an optionality decision Joseph’s first company raised too much too early, before PMF was durable. The consequence was not financial. It was optionality. A preference stack you have to clear narrows the exit surface and forces you to index on the next round instead of on the business. Supademo was built by two people for the first eight months, and is profitable at 16 people today. The capital efficiency is the mechanism that keeps the company in control of its own trajectory. Growth rate is downstream of that choice, not the other way around.

5. Defensibility lives in three places that code cannot compress Team adaptability. Distribution as a flywheel. Brand eminence. Software itself is no longer defensible at the code layer. Anything can be reproduced in a weekend. What compounds is the speed at which the team absorbs market shifts, the rate at which shared artifacts bring in new users (Supademos shared externally bring in new users at the point of highest intent), and the positioning that makes you one of the three names mentioned at a founder dinner when the category comes up. Joseph went from 500 to 20,000 LinkedIn followers over two years by posting three to four times a week. The output is not the follower count. It is the structural familiarity that closes deals before the meeting starts.

6. Change management is the invisible cost of every software purchase Microsoft Excel has been functionally replaceable for years. Better tools exist. They do not win because the cost of switching is not the feature gap. It is the training, the procurement, the info sec review, the habits, the organizational layer built on top. That cost is invisible until you try to rip the tool out. The strategic implication flips: the goal is not to be the best tool. The goal is to be the tool that is embedded deeply enough that switching is a project, not a decision.

Frameworks from the episode

1. The three-layer SEO motion that got Supademo to $1M ARR Bottom of funnel was programmatic demand capture: alternative pages for Loom, listicles for demo automation, Reprise alternatives. Latch onto existing search intent, insert a new product into the category, measure which variants accrue traffic, double down on the ones that convert. Middle of funnel was show-don’t-tell at scale: use the product itself to create product demos of other tools, rank for “Ahrefs product demo” or “Canva product demo” with a page that embeds an interactive Supademo as the thing the visitor is actually looking for. The acquisition channel and the demo become the same asset. The unscalable layer was direct response: Reddit threads, changelog comments, white-glove demos for individual prospects. Each layer feeds the others. The motion compounds because the artifact produced at every step is the same.

2. The demo-as-infrastructure model A Supademo is not a file. It is a modular definition that renders into multiple surfaces. One base demo, composed of hotspots and steps and optional voiceovers, gets deployed as an email embed, an in-app product tour, a support doc component, a downloadable video for trade shows, and a marketing landing page asset. The content library holds the source of truth. Updates propagate. The Q2 agent layer extends this: agents detect when the underlying product changes, regenerate the demo automatically, and flag where it was embedded so the live surfaces stay current. The demo stops being a perishable artifact and becomes a self-maintaining asset.

3. The AI demo audit as tribal knowledge capture Supademo has data from three to four hundred thousand demos. That is enough signal to know what converts at each funnel stage, for each use case, at each demo length, hotspot density, and narrative structure. Before the audit existed, that knowledge lived in internal tribal knowledge, the academy, the head of customer success, Joseph’s head. Customers had to go find it and apply it manually. The audit captures the aggregate judgment across all Supademo customers, scores a new demo against it, and one-click applies the fixes. This is the pattern every mature SaaS company will eventually run: aggregate outcome data across customers, build a model of what works, give every new customer the benefit of the aggregate judgment automatically. The companies that do this first will own the default in their category.

What to do this week

Audit the surfaces where your demo currently runs. If it only lives in the sales deck and the Loom link your AE sends after the first call, you are using one asset where the same definition could be running across five surfaces. The demo is either a modular system or it is a perishable one-off. Pick the architecture explicitly.

List every metric your marketing team reports on. For each one, identify whether it measures attention or revenue. If the primary metric is pageviews, sessions, or reach, the team is optimizing for the wrong input. The content that wins on attention metrics is frequently not the content that produces the highest-ACV customers.

Ask your data and product teams what assumptions from two years ago are still load-bearing today. If nobody can name one that has been retired, the business has not been interrogating its foundations. Run your own version of the Cursor all-hands. Force the question from a position of strength, not after a pivot is forced on you.

Check your capital structure against your optionality surface. If the preference stack means you can only exit above a specific number, your strategic flexibility is gone. Capital efficiency is not a virtue signal. It is the mechanism that keeps the decision of what the company becomes in your hands.

Why this matters

The demo is collapsing as a sales artifact and emerging as GTM infrastructure. That shift is downstream of a bigger change: buyers decide before they talk to you. Self-service, asynchronous evaluation, multi-stakeholder procurement. The human narrator who used to carry the sale has been removed from most of the funnel. Whatever replaces that narrator has to prove value in its absence.

Most companies have not absorbed this. They still treat the demo as a sales meeting, build one hero asset, and rely on the AE to make it work in a live call. The motion is not broken yet. It is just losing compounding efficiency at every stage compared to teams that treat the demo as composable infrastructure running across five surfaces from the same source of truth.

The structural argument Joseph makes is that distribution and brand eminence are becoming the only durable moats. The reasoning is mechanical. Software is easy to ship. Features get copied in weeks. What compounds is how often the market encounters your product and through what surfaces. A Supademo shared externally brings in a new user at the point of highest intent. A LinkedIn post published three times a week for two years builds familiarity that closes deals before the meeting starts. Neither is marketing. Both are architecture.

The second structural argument is that capital efficiency is not about burn. It is about optionality. The first company raised too much too early and lost the ability to choose its own outcome. The second company stayed profitable, stayed efficient, and kept every strategic path open. Growth compounds. So does the preference stack.

Revenue does not fail because companies lack leads. It fails when the demo layer is perishable, the content layer optimizes for attention, the capital structure removes optionality, and the founder is one round away from losing control of the outcome. The companies that survive the next cycle are the ones that installed architecture underneath every one of those layers before it was forced on them.

This is GTM Vault.

If this episode changed how you think about the relationship between the demo layer and the rest of your GTM motion, forward it to one operator still treating the demo as a one-time sales asset.

Connect Follow Joseph Lee // Supademo

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. One working session to identify your primary GTM constraint and design the 90-day architecture to resolve it.