👋 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.

👋 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.

This episode: Garrett Wolfe walks through an account scoring and signal pipeline built in Clay, then shows the custom Intent HQ web app built in Claude Code that sits on top of it. The system has taken teams from 0 to $15M in pipeline inside 12 months. The breakdown below maps the build back to the Revenue Architecture.

The Action Gap That BDRs Live Inside

Most BDR workflows fail at the same place. The account list exists. The signals exist. The intent data exists. But the rep still spends two hours every morning toggling between the CRM, LinkedIn Sales Navigator, and Apollo, trying to answer three questions: which accounts do I own, who at those accounts should I call, and why now. The prospecting tools surface signals at the company level. The contact tools surface people. The CRM tracks ownership. Nothing connects them.

This is not a data gap. It is an action layer gap. The data is already in the stack. The rep is the integration layer, and the rep burns their highest-leverage hours doing the integration manually.

Garrett Wolfe has spent the last year building the action layer that closes that gap. He was employee number nine at Unify, where he built their automated outbound program from zero to over $15 million in pipeline inside 12 months, and helped scale ARR from under $1M to over $5M in roughly 13 months using Unify, Clay, and n8n. He founded 1GTM, a GTM engineering consultancy, and co-authored the first State of GTM Engineering report surveying 225+ practitioners globally. Before that, growth equity at TZP Group, investment banking at Morgan Stanley, CS degree from Duke.

In this episode, Garrett walks through the full build. First, how Clay tables and signal workflows actually get constructed, not the marketing version. Then the production layer: a custom web app built with Claude Code that gives BDRs a single pane of glass replacing the CRM-plus-Sales Nav-plus-Apollo shuffle. The gap between a Clay table and the Intent HQ is the entire argument for why GTM engineering is architecture, not tooling.

The Scoring Foundation: Why Most Teams Start in the Wrong Place

Garrett’s first structural point is that most BDR teams start their day picking accounts by gut feel. Ten favorites for the week. Whoever the rep met at a conference last month. Whoever’s logo is familiar. The scoring layer does not exist, so prioritization defaults to whatever is top of mind.

Garrett inverts that. He pulls tens of thousands of companies into Clay and scores every one of them across firmographic and technographic criteria before a rep ever looks at the list. Headcount. Revenue. Leadership composition. Recent news. Engineering count. Infrastructure hires. Each criterion normalized to a zero-to-one score. The composite determines tier.

The data waterfall starts with Lead Magic (Garrett’s first-call enrichment source), then layers in revenue, LinkedIn, and employee data. The waterfall pattern matters: if one vendor misses, the next one fills the gap. A single-source enrichment pipeline has a coverage ceiling. A waterfall does not.

Accounts scoring above roughly 40% qualify for signal monitoring. Everything below that gets deprioritized before signal aggregation even runs. This is the step most teams skip. They jump straight to “find hiring signals at companies” without establishing which companies qualify. The result is a BDR queue full of signals from accounts that were never a fit to begin with.

Read more

That is the wrong read. The gap is not about readiness. It is about how purchasing decisions get made. Enterprise AI adoption is high because enterprises have dedicated procurement teams, IT departments, and innovation budgets designed to evaluate, pilot, and deploy new technology. Mid-market AI adoption is lower because mid-market companies have none of those things. Not because they do not want AI. Because the way AI has been sold does not match the way they buy.

The 41-point gap is a go-to-market problem. And it is where the fastest-growing category of AI companies is being built.

Where Purchasing Authority Lives

The average B2B enterprise deal now involves 6.8 stakeholders, up from 5.4 in 2020. SOC 2, GDPR, and vendor risk assessments add two to four weeks to the average cycle. Enterprise sales cycles for software above $100K ACV run 90 to 180+ days. Some stretch past twelve months. The cycle has actually gotten longer since 2022, not shorter, as CFO scrutiny and committee buying have intensified.

This is not dysfunction. It is the natural result of how enterprise organizations distribute purchasing authority. Budget authority sits with finance. Technical approval sits with IT. Security approval sits with infosec. Business case approval sits with the executive sponsor. Each node in the chain adds time, and each node optimizes for its own risk function, not for speed.

Mid-market purchasing authority works differently. At a 200-person company, the person who feels the operational pain is often the same person who can approve a $500/month tool. There is no procurement layer between the problem and the purchase. SMB deals with less than $15K ACV close in 14 to 30 days. The constraint is not approval chains. It is whether the product demonstrates value fast enough to justify the spend.

This structural difference in how authority is distributed creates two entirely different sales architectures. Most AI companies only build for one of them.

The Vertical AI Wedge

Horizontal AI tools compete on capability breadth. They serve every industry, every function, every workflow. That generality is an asset in enterprise, where a platform needs to integrate across departments and justify a six-figure purchase to a cross-functional committee. It is a liability in mid-market, where the buyer does not need a platform. They need one problem solved completely.

Vertical AI is a $3.5 billion category as of 2025, triple the investment from the previous year. The growth is not evenly distributed. It is concentrated in companies that pick a specific industry, a specific workflow, and a specific buyer persona, then build a product that works on day one without configuration, integration, or training.

A logistics company with forty trucks does not need a general-purpose optimization platform. It needs a routing tool that accounts for its specific delivery windows, vehicle capacities, and driver schedules. A dental practice group does not need an enterprise analytics suite. It needs a system that reads patient no-show patterns and adjusts scheduling automatically. The narrower the product, the faster the buyer sees value. The faster they see value, the shorter the sales cycle.

The OECD reported that 91% of SMEs using generative AI report efficiency gains and 76% cite increased innovation. The demand is not missing. The delivery mechanism is. Mid-market companies are not waiting for better models. They are waiting for products that fit into their operating rhythm without requiring an IT department to deploy them.

Revenue Velocity, Not Revenue Size

The math on mid-market vertical AI breaks the assumptions that enterprise SaaS trained into an entire generation of founders and VPs of Sales.

Enterprise logic: optimize for average contract value. A $50K ACV deal closed once per quarter per rep, after six to twelve months of cycles, produces $200K in annual revenue per rep. The number looks clean on a board deck.

Mid-market vertical AI logic: optimize for deal velocity. A $6K ACV product ($500/month) closed in two to three weeks means a single rep can close 16 to 24 deals per month. That is $96K to $144K in new ARR per month from one person. Revenue per rep per year is not even close.

The cash flow dynamics are equally different. Enterprise revenue is deferred behind pilots, implementation timelines, and net-60 payment terms. Mid-market revenue arrives the week the customer signs up. Credit card on file. No invoice. No accounts receivable aging. For a seed-stage company trying to hit $1M ARR, the difference between collecting revenue in week three versus month twelve is the difference between surviving and running out of runway.

AI pilot-to-contract conversion rates reinforce this. 47% of AI pilots convert to paid contracts, compared to roughly 25% for traditional software. The product either works or it does not. Mid-market buyers do not run six-month evaluations. They run the tool for a week. If it solves the problem, they pay. If it does not, they leave. The binary nature of the decision compresses the entire evaluation cycle into days.

The GTM Architecture That Fits

Selling into the 41-point gap requires building a go-to-market system around how mid-market actually buys. The architecture has four structural properties, and each one maps back to the same root cause: purchasing authority is concentrated, not distributed.

First, the product must demonstrate value without human intervention. Mid-market buyers do not book discovery calls as a first step. They want to see the product work on their problem before they talk to anyone. Self-serve trials, instant demos with the buyer’s own data, or free tiers that expose the core value proposition are the entry point. If the first interaction requires a sales engineer, the architecture is wrong for this segment.

Second, the signal layer must produce intent, not firmographics. The 50% of SMEs that report lacking AI skills are not going to respond to a cold email about “AI-powered solutions.” The signal that matters is operational: a founder posted about a specific workflow bottleneck, a head of ops searched for a tool to solve a specific problem, a company left a negative review about their current vendor. The enrichment pipeline must surface people who are actively experiencing the pain the product solves.

Third, pricing must sit below the purchase order threshold. The moment a product costs more than what an operator can put on a corporate card, a procurement process activates. At most mid-market companies, that threshold is somewhere between $1,000 and $2,500 per month. Below it, the operator decides. Above it, finance gets involved, the cycle extends, and the structural speed advantage disappears. Pricing is not a revenue decision. It is an architecture decision that determines which buying motion the product triggers.

Fourth, expansion is vertical, not horizontal. Enterprise SaaS expands by adding seats across departments. Mid-market vertical AI expands by solving adjacent problems for the same buyer. The restaurant review monitoring tool adds menu optimization. The logistics routing tool adds demand forecasting. The dental scheduling tool adds patient communication. Each new capability deepens the workflow integration, increases switching costs, and grows contract value without a new sales cycle. Expansion revenue from self-serve (upsells, add-ons, higher tiers without sales intervention) is the metric that signals this architecture is working.

The Two Failure Modes

The first failure mode is applying enterprise GTM to a mid-market product. A vertical AI company raises a Series A, hires a VP of Sales from a company that sold $100K ACV deals, and builds a team designed for long cycles. SDRs qualify leads through discovery frameworks that take two weeks. Solution engineers build custom demos for buyers who wanted to see the product work in five minutes. The company layers roles designed for distributed purchasing authority onto a segment where authority is concentrated. Each added headcount increases cost of acquisition without increasing conversion. The velocity advantage that made the product work at seed stage gets buried under enterprise overhead.

The second failure mode is trying to move upmarket without rebuilding the GTM architecture. A vertical AI company that closes $500/month deals with a product-led motion tries to land $50,000/year enterprise contracts with the same approach. The self-serve trial that converted operators does not convert procurement committees. The pricing page that let buyers swipe a card does not satisfy an enterprise vendor evaluation. Moving upmarket is not a pricing change. It is a full rebuild of the signal layer, the sales motion, the pricing model, the security posture, and the expansion strategy. Companies that try to stretch one GTM architecture across both segments end up competitive in neither.

The Structural Implication

The 41-point gap will not close by mid-market companies slowly adopting enterprise AI tools. It will close because a new generation of vertical AI companies is building products and GTM motions designed specifically for how mid-market buys. The OECD data shows SME AI adoption growing 72% year over year. The McKinsey data shows the gap still wide. The companies that close it will not be the ones with the best models. They will be the ones whose go-to-market architecture matches the purchasing architecture of the buyer.

For founders: pick the vertical where the operator is the buyer. Build a product that demonstrates value in the first session. Price it within credit card authority. Build enrichment that surfaces intent signals, not company lists. Run the motion at velocity. Expand through workflow depth. The 41-point gap is not a problem waiting for a technology solution. It is a market waiting for the right GTM architecture.

Sources: McKinsey Global AI Survey Q1 2026, OECD AI Adoption by SMEs 2025, Techaisle SMB AI Adoption Trends 2025

👋 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.

Show Me Your Stack, Episode 2: Enrichment Pipelines in Claude Code

This episode: Alexander Shartsis walks through an enrichment pipeline built in Claude Code, backed by a production-grade system powering Skyp’s managed outreach. Over a dozen MCP connections. Direct API layer underneath. Stage 3 agentic workflow. The breakdown below maps the build back to the Revenue Architecture.

The Targeting Failure That Enrichment Is Supposed to Solve

Most outbound campaigns fail silently. The emails go out. The open rates look reasonable. Nothing converts. The post-mortem blames the copy, the subject line, the send time, the offer. It is rarely any of those things.

The silent killer is list quality. The people on the list are the right title at the right company. They match the ICP on paper. But they are not in market. They have no documented need. No signal. No timing indicator. The campaign was dead before the first email was drafted because the enrichment layer did not produce signal. It produced demographics.

Alexander Shartsis has spent a year building Skyp’s enrichment and outbound system. Before that, he led M&A at Opendoor, closing four acquisitions in six months for a public company doing over two billion in revenue. He has bootstrapped, raised, exited, and shut down companies. He built Skyp because the enrichment problem is not a data gap. It is an architecture gap. The tools exist. The APIs exist. The failure is in how they are composed, what order they are called in, and whether anything upstream validates the output before it reaches the send layer.

In this episode, Alex builds a basic enrichment tool live in Claude Code using plan mode and the Apollo API, then walks through the production version that runs Skyp’s managed campaigns at roughly fifty cents per lead. The gap between those two builds is the entire argument for why enrichment is architecture, not a feature.

The Live Build: Claude Code Plan Mode to Working Tool

Alex starts the build on screen. Claude Code in the terminal. Plan mode activated with Opus for planning, Sonnet for code generation. The prompt is specific: build an enrichment tool that uses web search to find signals about people and Apollo API for email and contact information. Run locally. Keep it simple.

Claude returns a plan. A Python script. Data sources, structure, output format. Alex pauses here and makes a point that most people skip: read the plan before you execute it. Claude’s plan mode is not a formality. It is the architectural review. If the plan calls the wrong APIs, structures the data incorrectly, or misses a step, fixing it after execution costs more tokens and more time than catching it in the plan.

The distinction between Claude Code’s three modes matters here. Edit-after-asking mode does not plan. It reacts to the immediate task, builds the thing in front of it, then discovers downstream dependencies. Plan mode thinks through the whole system first, breaks it into steps, then executes sequentially. For anything beyond a single-file script, plan mode produces a fundamentally different output. Alex uses it for every build.

Claude recognizes that Alex has already built a larger enrichment app in the same repo. It asks why it is building a smaller version. This is worth noting. Claude Code maintains context across the project. If you have existing code that overlaps with the new build, it will flag it. Alex redirects it to build a standalone example.

The build runs. Claude writes the Python script, wires up the Apollo API, adds web search for signal enrichment. The output is functional. A founder or operator could take this script, point it at their ICP parameters, and get enriched leads with contact information and web-sourced signals for ten to twenty cents per lead.

This is the baseline. What Alex builds next is the production layer that turns a script into a system.

The MCP Stack and When Not to Use It

Alex’s Claude Code environment has over a dozen MCP servers connected. He walks through the ones he uses most and what each one does in the workflow. But the architectural lesson is not “connect everything.” It is knowing when to use an MCP and when to drop to the API directly.

1. Gmail provides email history context. When building an outreach list, Claude can check Gmail to remove anyone Alex has already emailed. No manual deduplication. No CRM lookup. The MCP queries the inbox directly.

2. Grain is the meeting recorder. It has an MCP that lets Claude query meeting summaries and action items. The use case is follow-up prioritization: who did Alex meet with this week, what was discussed, who needs a follow-up. The data lives in Grain’s interface, but the MCP makes it queryable from the same environment where the enrichment runs.

3. Slack serves as the notification layer. Long-running enrichment processes send a Slack message when they finish. This is the difference between watching a terminal and doing other work while the system runs.

4. Intercom handles customer support content. Alex built an automation that runs every morning: it checks new GitHub commits, identifies product changes, and updates or creates Intercom help articles automatically. New features get flagged to Slack for human review before publishing. Existing feature changes publish directly.

5. Stripe provides the customer list. When building outreach lists, Claude pulls current customers from Stripe and removes them. No manual exclusion list. No stale CSV. The deduplication is live.

6. Ahrefs is the SEO and SEM data source. Competitive intelligence, keyword monitoring, website performance. This MCP is more of a data feed than an action layer.

7. Trigify monitors LinkedIn for signal data. It tracks people posting about specific topics and surfaces them as potential leads. The same function could be replicated with Claude web search, but Trigify packages it as a structured API.

8. Canva lets Claude build slides, mockups, and logos without leaving the terminal. Alex uses it for quick visual assets.

9. Calendar handles scheduling context. Meetings, availability, follow-up timing.

10. Skyp is the send layer. Once a list is enriched and validated, Claude pushes it directly to Skyp to start or add to a campaign. The full loop, from enrichment to send, runs without switching tools.

The rest are Claude’s built-in connectors (web search and others visible in the MCP list) that Alex uses but did not walk through individually.

The architectural insight is the cost tradeoff between MCPs and direct APIs. Every MCP call consumes tokens because the LLM reads the MCP documentation, constructs the request, and processes the response. A direct API call is just the raw request. For occasional tasks (checking Gmail, querying Grain), the token overhead is negligible. For high-volume operations (enriching hundreds of leads through Apollo), the overhead compounds. An hour-long enrichment run becomes two hours. Two hours becomes four.

Alex’s production system uses MCPs for convenience and context tasks. It uses direct APIs for the enrichment pipeline itself. The decision boundary is volume. If you are calling something ten times, use the MCP. If you are calling it a thousand times, use the API.

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 25,000+ operators building GTM systems that compound.

12 tools, 12 definitions of customer, zero agreement on what revenue means. The dashboards are full. The data team is underwater. The founders are making decisions on gut feel anyway.

The problem was never access to data. It was architecture.

Danylo Borodchuk dropped out of Dartmouth to build analytics infrastructure. CS background, DALI Lab, DARPA research. He went through Y Combinator’s Winter 2025 batch. Before Lopus AI was an analytics platform, it was a completely different product. A generative UI tool that got Twitter hype and zero traction in practice. YC forced the question that killed the first idea: who actually wants this? Nobody had an answer. The pivot tells you everything about where the real pain lives.

Lopus AI connects CRM, billing, product analytics, and support into one governed workspace. No SQL required. No data engineering team required. A semantic layer that locks in your definitions so every query speaks the same language. The platform is single tenant at $2K a month, with a forward deployed data engineer for onboarding and a self-healing definition layer that regenerates its own SQL when the underlying schemas change.

In GTM 43, Danylo breaks down why most analytics fail before the first query runs. He explains why every company’s CRM is a mess in the same predictable ways, why marketing and sales will never agree on “qualified” without a governed definition layer, and why the most dangerous analytics tools are the ones that answer every question, including the ones the data cannot support. The fix is not a better dashboard. It is an architectural layer between raw data and every query the business runs against it.

This is not a conversation about better charts.

It is a conversation about why your tools define the business differently, and what happens when you install a single governed layer underneath all of them.

Inside this episode

This episode maps the structural gap between the data your tools produce and the answers your teams trust, starting at the foundation: the definition layer that most companies never formally build.

Danylo explains what happens during onboarding. The CRM is always a mess. Billing data becomes the source of truth by default because it is the closest thing to financial reality. But even billing carries company-specific definitions of MRR, churn, and customer count that no off-the-shelf dashboard captures. When marketing says “qualified” and sales says “qualified,” those are two different numbers referencing two different definitions with no structural reconciliation between them.

We go deep on trust architecture. Most AI analytics tools optimize for answering your question. Lopus optimizes for refusing to answer when the data cannot support one. Danylo described a deliberate test: ask the agent to join Mixpanel product data with Salesforce lead records to find power users. The two tables are deliberately not connected. The agent examines both data sources, recognizes it cannot join them, and tells you instead of fabricating a result. The investigation agent follows the same principle, running temporal sequencing, segment isolation, and confound surfacing before it hands you an explanation.

We cover the self-healing semantic layer (what happens when Stripe changes its API and your MRR definition breaks), the forward deployed data engineer model at seed stage (and why the Palantir comparison is accurate), why a 10,000-view blog post generated less revenue than a 1,000-view one, and what the AI analytics space gets structurally wrong about the relationship between context and accuracy.

Discussed in this episode

In this episode, we cover:
0:00 Intro: 12 tools, 12 definitions, zero agreement on revenue

1:22 What killed the generative UI product and forced the pivot

2:14 What YC forces you to confront about your original idea

3:24 Why a technical founder builds for growth teams

4:30 The hardest constraint at seed stage that has nothing to do with product

6:03 The most common data contradiction between CRM and billing

7:38 Who defines the semantic layer when marketing and sales disagree

9:04 No SQL required, but RevOps wants to see the query

10:29 500 integrations at seed stage: deeply maintained versus thin

12:19 When Lopus told a customer not to trust an answer

14:48 Single tenant architecture at $2K/month

16:34 How the investigation agent separates causality from correlation

19:02 The forward deployed data engineer model and how it scales

20:25 Live in days: first dashboard or fully governed semantic layer

21:48 What their own pipeline data reveals about their conversion funnel

24:55 Rapid fire

Key takeaways

1. Every company’s CRM is a mess in the same predictable ways

The CRM is never the source of truth, but it becomes the foundation of every metric in the business anyway. Billing data is closer to financial reality, but every company carries its own quirks in how MRR is defined, how churn is calculated, how a customer is counted. The definitions diverge between tools, and every dashboard built on top inherits the divergence. The result is 12 tools producing 12 answers, and the founder picks the one that matches their intuition.

2. The most dangerous analytics tool is the one that always gives you an answer

Most AI analytics systems optimize for response. They answer every question because that is what the models are trained to do. Lopus deliberately built the opposite: an agent that refuses to answer when the data cannot support a trustworthy result. It asks clarifying questions, checks whether tables can be joined, and stops before writing SQL if the data does not support the query. The test case is instructive: ask it to join two deliberately unconnected data sources, and it tells you it cannot instead of hallucinating a result.

3. The semantic layer is the missing architecture, not the dashboard

The fix for conflicting definitions across tools is not a better chart or a prettier report. It is a governed layer between raw data and every query the business runs against it. One place where MRR means one thing, churn means one thing, and every downstream query inherits those definitions. Without it, marketing and sales will never agree on “qualified” because they are referencing two different definitions with no structural reconciliation.

4. Maintenance is the real cost of analytics infrastructure

Every new dashboard, every new metric definition, every new data source adds ongoing maintenance hours to the data team. When Stripe updates its API and a field gets nullified, the SQL that defines your MRR breaks. In a traditional BI setup, a human notices and rewrites the query. Lopus holds the definition in plain English alongside the SQL. When the underlying schema changes, the system regenerates the SQL to match the original definition. That is the argument for self-healing: not speed, but durability.

5. The forward deployed model compounds at seed stage

Every edge case the forward deployed data engineer encounters during onboarding gets folded back into the product logic. The standard tool stack across growth-stage startups is similar (HubSpot or Salesforce, Stripe or Chargebee, PostHog or Mixpanel, Intercom or Pylon), but the custom fields, internal naming conventions, and bespoke metric definitions differ in ways no automated onboarding captures. The more customers Lopus onboards, the more edge cases the platform absorbs, and the less the next customer needs manual intervention. The model does not scale linearly. It compounds.

6. The content metric that misleads is the one that measures attention instead of revenue

Lopus published two blog posts. The first got 10,000 views. The second got 1,000 views. The marketing dashboard says the first one won. When they tracked the full customer journey through their own product, connecting content engagement to CRM to billing, the 1,000-view post produced higher-ACV customers who became more active users. The 10,000-view post generated attention. The 1,000-view post generated revenue. Without the full journey connected, the marketing team optimizes for the wrong input.

Frameworks from the episode

1. The trust architecture for AI analytics

Three mechanisms prevent the agent from producing confident noise. First, clarifying questions before any query runs. The agent checks what data exists and whether it supports what you asked. Second, join validation. If two data sources cannot be structurally connected, the agent says so instead of fabricating a result. Third, the anti-hypothesis. The investigation agent does not hand you the first plausible explanation. It tests competing explanations, checks temporal sequencing (did the supposed cause precede the effect?), isolates segments, and surfaces confounds before it gives you an answer.

2. The self-healing definition layer

The semantic layer holds every metric definition in two forms: SQL and plain English. The SQL executes the query. The plain English holds the intent. When the underlying schema changes (a field is renamed, a column is nullified, an API version shifts), the system uses the plain English definition to regenerate correct SQL without human intervention. This absorbs the maintenance cost that makes traditional BI infrastructure unsustainable at scale without a dedicated data team.

3. The full-journey content attribution model

Connect content engagement data to CRM to billing. Measure not which content gets the most views, but which content produces the highest-ACV customers who become the most active users. Danylo’s own data showed a 10X gap between the content that won on attention metrics and the content that won on revenue metrics. The structural lesson: any content measurement that stops at pageviews will optimize the marketing team toward the wrong inputs.

What to do this week

Ask your data team how many distinct definitions of MRR, churn, or “customer” exist across your tools. If nobody can answer immediately, you do not have a governed definition layer.

Run one query through your current analytics tool that requires joining data from two sources that should not be joinable. If the tool gives you a confident answer anyway, your analytics are not trustworthy by default.

List every metric on your primary GTM dashboard. For each one, identify whether the underlying definition is shared across marketing, sales, and finance, or whether each function is running a different version. If the definitions diverge, the dashboard reconciles nothing.

Check how many hours per month your data team spends maintaining existing dashboards versus building new ones. If maintenance exceeds 50%, the architecture is consuming the team, not serving it.

Why this matters

The default state of GTM analytics is fragmentation. Every tool defines the business differently. Every team trusts the metric that confirms their narrative. Every dashboard presents a version of reality that diverges from the one finance uses to plan the business.

The semantic layer is the architectural fix that most companies skip. Not because it is hard to understand, but because it requires formal agreement on definitions that most organizations have never made explicit. What counts as MRR. What counts as churn. What counts as qualified. When those definitions live inside individual tools instead of inside a governed layer that every query inherits, the analytics infrastructure produces answers that look precise and are structurally unreliable.

Lopus is building that layer. One governed workspace where every tool’s data passes through shared definitions before it reaches the human asking the question. The value is not the chart. It is the architecture underneath the chart that makes the answer trustworthy.

Revenue does not fail because teams lack data. It fails when the definitions underneath the data stopped agreeing and nobody reconciled them.

This is GTM Vault.

If this episode changed how you think about the relationship between your data tools and the answers they produce, forward it to one operator still making decisions on dashboards where every tool defines the business differently.

Connect

Follow Danylo Borodchuk // Lopus AI

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 25,000+ operators building GTM systems that compound.

Ramp just gave AI agents their own credit cards. Mastercard and Google are building verification standards for agent-initiated transactions. Stripe published a six-month retrospective on its Agentic Commerce Protocol. Vercel lets you buy credits, subscriptions, and domains from the command line.

The conversation so far has been about pricing. How to make your pricing page machine-readable. How to structure documentation so an LLM can parse your tiers. How to show up in AI answer engines when an agent is evaluating vendors.

That conversation is necessary. It is also incomplete. Pricing is one layer. When the buyer is a machine, the disruption runs through every layer of the revenue architecture, from signal detection through execution. The companies preparing for this by optimizing their pricing page are solving the surface problem. The structural problem is that their entire go-to-market system was designed for a buyer that reads emails, attends demos, and makes emotional decisions. That buyer is being replaced.

The Demand Generation Layer Was Built for Attention

The entire demand generation apparatus of modern B2B GTM assumes a human on the other end. Webinars. Ebooks. Nurture sequences. LinkedIn ads. Event sponsorships. Content syndication. All of it is designed to do one thing: capture the attention of a person who has a problem but has not yet decided to solve it.

AI agents do not browse. They do not get curious. They do not stumble across your brand while scrolling. They get dispatched with a task, a set of constraints, and a budget. The agent does not need to be nurtured into awareness. It arrives with full intent and zero patience. It will evaluate you in seconds based on structured data it can find, and if it cannot find enough structured data, it will move to the next vendor.

This is not a content marketing problem. It is a layer collapse. The entire top-of-funnel infrastructure that most B2B companies spend 30 to 50 percent of their marketing budget on becomes invisible to agent buyers. Not inefficient. Invisible. The agent never enters the layer.

Distribution Channels That Require Human Participation Stop Working

Distribution architecture in most GTM systems is a collection of channels that assume human interaction at every node. A prospect clicks an ad. A prospect registers for a webinar. A prospect downloads a report and enters a nurture sequence. A prospect gets referred by a colleague. Each channel depends on a human choosing to participate.

Agent buyers do not participate in channels. They query data sources. The distinction matters because channels are designed to create engagement over time, and data sources are designed to return structured answers immediately. Your SEO strategy, your paid acquisition funnels, your community-led growth loops, your partner ecosystem referrals: none of these channels exist in the agent’s evaluation path unless they produce machine-readable data that surfaces in the agent’s query results.

The distribution layer does not disappear. It bifurcates. Human buyers still need channels. Agent buyers need data surfaces. Most companies will need to architect for both simultaneously, and the organizational challenge is that the teams, tools, and metrics for each are completely different. The marketer who runs your webinar program is not the same person who structures your pricing documentation for LLM ingestion. These are different disciplines operating on different layers of the same architecture.

Qualification Inverts

In a human buying process, the seller qualifies the buyer. Does this prospect match our ICP? Do they have budget? Are they the decision maker? Is there urgency? The seller controls the qualification criteria and applies it through discovery calls, BANT frameworks, lead scoring models, and SDR conversations.

When an AI agent is buying, the buyer qualifies the seller. The agent arrives with pre-defined evaluation criteria set by its human principal. It knows the budget. It knows the requirements. It knows the integration constraints. It is not waiting for your SDR to ask discovery questions. It is running its own scoring model against every vendor simultaneously.

This inverts the power structure of the entire qualification layer. The seller’s lead scoring model becomes irrelevant because the agent does not enter through a form, does not have a job title to score, and does not exhibit behavioral signals that marketing automation can track. The agent is not a lead. It is a procurement system with a decision tree.

The implication is that your qualification infrastructure (scoring models, SDR teams, MQL definitions, routing logic) needs a parallel track. One track for human buyers who still enter through traditional channels. One track for agent buyers who arrive fully qualified with their own criteria and need structured data to complete their evaluation. Building the second track is not a marketing project. It is an architecture project.

Subscribe now

The Sales Layer Compresses to Zero

An AI agent does not take a demo. It does not sit through a pitch. It does not need to build trust with an account executive over three meetings before signing a contract. The agent evaluates based on documented capabilities, published pricing, API quality, integration compatibility, and outcome data. If those inputs are sufficient, the agent transacts. If they are not, the agent moves on.

This compresses the entire sales layer. For commodity products and developer tools, the compression is already happening. A coding agent that selects your database, your payment processor, or your analytics tool does not call your sales team. It reads your documentation, checks your API, and either integrates or does not.

For enterprise products, the compression is slower but directional. The first wave is AI procurement tools that evaluate RFP responses, benchmark pricing, and recommend shortlists. The second wave is agents that negotiate terms within pre-authorized parameters. The third wave is agents that execute the full purchase cycle autonomously within policy constraints set by a human buyer.

Each wave removes a human touchpoint from the sales process. Not because the product got simpler, but because the structured data that the agent needs to make a decision either exists and is accessible, or it does not. Companies that expose their capabilities, pricing, and outcomes as structured, machine-readable data will transact with agents. Companies that gate everything behind “contact sales” will not appear in the agent’s evaluation set.

Pricing Restructures Every Layer It Touches

This is the Third Foundational Law for a reason. Pricing is never an isolated variable. It cascades through distribution, qualification, conversion, and expansion.

When the buyer is a machine, the pricing cascade accelerates. A human buyer tolerates ambiguity. “Contact sales” means “I will call and negotiate.” An agent buyer treats ambiguity as disqualification. “Contact sales” means “insufficient data, skip.” The pricing layer does not just need transparency. It needs structure. Machine-readable tiers, documented feature-to-price mappings, published usage calculations, maximum budget parameters.

But here is the part the pricing optimization advice misses: restructuring pricing for agents forces you to restructure everything downstream. If pricing is transparent and structured, the sales motion changes. If the agent can self-serve evaluation, the SDR layer changes. If the agent can compare you against competitors in seconds, the positioning layer changes. If the agent measures outcomes rather than promises, the expansion layer changes.

You cannot optimize the pricing page for agents and leave the rest of the architecture intact. The pricing change propagates. This is the Law at work.

The Feedback Loop Changes from Sentiment to Outcome

Human buyers generate soft feedback. NPS scores. Support ticket sentiment. Renewal conversations where the CSM reads between the lines. Expansion signals from usage patterns. The entire customer success apparatus is designed to detect human satisfaction and convert it into retention and growth.

Agent buyers generate hard feedback. The agent measured the outcome. It compared the outcome to the parameters its principal set. It either continues the subscription or terminates it. There is no loyalty. There is no relationship. There is no switching cost based on familiarity. The evaluation runs continuously, and the decision recurs at every contract boundary.

This changes the expansion and retention layers structurally. Customer success as a relationship management function loses relevance when the customer is a machine. What replaces it is outcome documentation: structured, real-time proof that the product delivered the results the agent’s criteria specified. Companies that can expose performance data programmatically (via API, via dashboard, via structured reports) give the agent a reason to renew. Companies that rely on a CSM calling the VP once a quarter will lose the renewal to a competitor whose outcome data is better structured.

Where This Sits in the Architecture

Agent-led purchasing is not a pricing problem, a marketing problem, or a sales problem. It is an architecture problem that touches every layer.

At the Signal layer, the signals change. Agent-initiated evaluations do not produce the same behavioral data as human buying journeys. You cannot track an agent’s page views, email opens, or webinar attendance. The signal layer needs new detection mechanisms for agent-originated queries and evaluations.

At the Distribution layer, the channels bifurcate. Human channels remain necessary. Agent-readable data surfaces become a parallel distribution architecture that requires its own tooling, metrics, and ownership.

At the Execution layer, the motion compresses. For some segments, the entire sales cycle collapses into a single API transaction. For others, the human sales process persists but with an agent handling evaluation and shortlisting upstream.

The companies that treat this as a pricing page optimization will capture the easiest 10% of the opportunity. The companies that restructure their revenue architecture to serve both human and agent buyers will capture the rest. The question is not whether to prepare your pricing for AI agents. The question is whether your architecture can serve a buyer that does not behave like a human at any layer.

The Structural Bet

The Second Foundational Law states: What Scales First Constrains Everything After. The companies that scale their current human-optimized GTM architecture further before addressing agent buyers are building on a foundation that will constrain them when the buyer mix shifts.

Nobody knows the timeline. Agent-initiated purchasing is already real in developer tools and commodity SaaS. It is emerging in mid-market through AI procurement tools. It is directional in enterprise. The structural bet is not about predicting the date. It is about whether your architecture is designed for one buyer type or two.

The AI does not amplify your marketing. It does not improve your sales pitch. It does not optimize your funnel. It replaces the buyer. That is not an optimization problem. It is an architecture problem. And architecture problems do not get solved by updating a pricing page.

👋 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.

Show Me Your Stack, Episode 1: Review-Led GTM for Slang AI

This episode: Vinayak Mishra walks through a restaurant review intelligence system built for Slang AI. Five tools. Five layers. Stage 2 orchestrated workflow. The breakdown below maps the build back to the Revenue Architecture.

The Targeting Problem Behind Review-Led GTM

Slang AI sells a voice AI reservation system for restaurants. The product solves a specific operational problem: restaurants that lose bookings because no one answers the phone during peak hours. The company recently closed a Series B round.

The GTM bottleneck is targeting. Slang AI needs to find restaurants that are actively struggling with phone and reservation communication. Not restaurants in general. Restaurants where the problem is already visible in the customer record. The question is where that signal lives and how to extract it at scale.

The answer is reviews. Customers leave complaints on Google Maps, Yelp, and TripAdvisor when they cannot reach a restaurant by phone, when reservations are lost, when special requests made during booking are ignored. These are not abstract intent signals. They are documented failures described in the customer’s own language, timestamped and geolocated. Every negative review mentioning phones or reservations is a qualified signal that the restaurant has the exact problem Slang AI solves.

This is not a lead list problem. It is a signal extraction problem. The system Vinayak built treats reviews as structured GTM data, not marketing noise.

Five Tools, Five Layers, One Direction

Five tools. Each one exists for a specific architectural reason.

Serper.dev serves as the discovery layer. It hits the Google Maps API to scrape restaurant listings by locality and state across the US. The query structure is simple: “restaurants in [locality], [state].” Each query returns 20 results per page. The tool exists because it provides fast, cheap access to Google Maps data at scale without building a custom scraper.

Clay operates as the master data layer. Three tables, each with a distinct function. Table one holds the raw locality and state inputs that generate Serper queries. Table two stores the scraped restaurant data (names, websites, place IDs, phone numbers, ratings). Table three receives qualified reviews pushed back from the orchestration layer. Clay is not a CRM in this architecture. It is the system of record.

Apify provides the review aggregation layer. A pre-built actor called “restaurant review aggregator” takes search keywords and location as input and returns reviews across Google Maps, Yelp, TripAdvisor, Facebook, UberEats, and DoorDash. The tool exists because building custom scrapers for six review platforms is not a productive use of engineering time when a managed actor handles it for under a dollar per run.

n8n is the orchestration and filtering layer. It receives review data from Apify via webhook, applies a star rating filter (three stars or below), passes filtered reviews to the Claude analyzer, and routes qualified results back to Clay. n8n exists because this workflow requires conditional branching (star filter, relevance check, true/false routing) that Clay alone cannot handle cleanly.

Claude performs the relevance analysis. A structured prompt instructs the model to act as a review analyst for Slang AI, evaluating each negative review against specific signals: restaurant unreachable by phone during busy periods, multiple unanswered calls, lost reservations, ignored booking requests. The prompt includes relevant signals, non-relevant signals, and edge cases. Claude exists in this stack because keyword matching would miss the semantic complexity of review language. “Called three times, no one picked up” and “tried to book for my daughter’s birthday but they completely forgot” both indicate the same structural problem, but no regex catches both.

Read more