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

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

The short version

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

The Term Means Two Things and Nobody Has Said So

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

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

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

The Test Is Adoption Burden

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

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

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

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

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

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

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

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

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

What the Benchmark Measures

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

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

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

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

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

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

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

One Checkbox, Seven Layers

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

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

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

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

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

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

Subscribe now

Why the Order Still Decides This

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

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

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

The AI Layer Is the Eighth

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

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

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

What a Half-Built System Looks Like

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

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

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

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

The Audit

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

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

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

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

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

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

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

Where This Framing Breaks

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

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

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

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

What This Decides

The practical consequence is a reallocation, not a purchase.

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

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

Common Questions

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

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

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

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

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

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

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

Related Reading

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

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

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

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

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

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

Subscribe now

In 2023 the industry standard for revenue AI was to pass an entire call transcript into a language model and hope. Gorish Aggarwal tried it. It failed at producing something as basic as next steps unless you massaged the input first, feeding the model context about the output you wanted, the customer, and the deal. So he stopped treating the transcript as the product and started treating it as raw material. Six to eight months later the rest of the market was still dumping full transcripts into models and calling it AI.

That gap became the company. His read was that as models improve, the value of what you pass them improves faster than the models themselves. If that is true, the durable asset is not the model and it is not the recording. It is the structured understanding of your business that decides what gets passed in.

This is not an argument about transcription quality. It is an argument about which layer of the revenue stack is being repriced to zero, and Sybill spent eighteen months building the other layer while better-funded competitors shipped features.

Gorish Aggarwal is co-founder and CEO of Sybill. Sybill launched as an AI sales assistant for account executives, then spent eighteen months building an org-level context graph underneath it, a self-evolving layer connecting customers, team, and company process that updates daily from every new conversation. The bet was made with a fraction of the capital his category raised, which is the part that shaped the architecture rather than just the burn rate. Gorish now argues the next Cursor-scale company in GTM tech emerges from exactly this layer inside twelve to eighteen months, and he is explicit that he is building to be it.

In GTM 48, Gorish breaks down why passing the full transcript into a model was never the product, what a context layer actually means operationally across its three pillars, why Sybill shipped an MCP connector into Claude’s directory instead of defending its own dashboard, why incumbents cannot bolt a context layer onto platforms architected before language models existed, where agents with complete context still produce garbage, what identity resolution is quietly doing to every CRM in the market, and the single roadmap question that let a smaller team out-build the field for eighteen months.

This is not a conversation about note takers. It is a conversation about which half of your revenue stack is the commodity and which half is the asset, and what that means before your next renewal cycle.

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

Inside this episode

This episode maps the structural difference between recording what happened and understanding it, and what happens to a category when the first one becomes free.

Gorish opens with the 2023 realization. Passing a full transcript into a model did not work, and it failed in a specific way that mattered. Even getting usable next steps required feeding the model context about the desired output, the customer, and the deal alongside the raw text. The transcript was an input, not a signal. He assumed the market would catch on quickly. It did not. Six to eight months later the standard was still transcript in, output out. That lag is where the head start came from, and he is candid that he expected it to be much shorter.

We go deep on what a context layer means operationally, because the phrase has been diluted into meaninglessness over the last year. Gorish defines it as three pillars. Customers, meaning the prospects, accounts, and opportunities. Team, meaning every person from rep to CRO, their strengths, weaknesses, objectives, and preferences for how they work. Company process, meaning product lines, pricing, the objections that actually come back, market verticals, and the competitors you keep running into. Most revenue tools capture the first pillar and treat the other two as configuration. The graph only compounds when all three evolve daily against new conversations, and that daily evolution is the part that cannot be retrofitted.

We cover why he does not consider this a repositioning. Gorish pushes back on the framing directly. The technology moved and the product moved with it, and the visible change was that a second buyer appeared. Sybill started as an automation layer over an AE’s deals, helping one rep write a better follow-up and save time. As the org-level graph came together, the CRO and the VP of Sales became buyers of the same asset for entirely different reasons. He is honest that this made the offering muddier before it made it stronger.

We go into the MCP decision, which is the counterintuitive move in the episode. Most vendors Sybill’s size were building another dashboard. Sybill exposed its context layer through an MCP connector in Claude’s directory, then built an ingest MCP running the other direction so website data, Notion, Drive, and Slack flow in, get systematized against the graph, and become available downstream. Giving up the screen cost them depth of insight into how the work gets done. What they gained was a builder persona in RevOps creating agents on top of the layer, and those agents scale across an entire organization. One builder’s workflow becomes a thousand reps’ default. Gorish is clear that the interface still matters for a typical seller who wants the job done rather than a system to build, so this is a segmentation call rather than a religion.

We cover the demo that keeps closing deals, which is not a demo of Sybill. It is running Claude twice against the same deals and the same calls, once with the Ask Sybill MCP connected and once without. The delta in output is the pitch. Nothing about that comparison requires the buyer to trust a vendor claim, which is why Gorish reports MCP usage skyrocketing past what he predicted.

We go into personal agents versus GTM agents and where they collide, which is the architecture question most teams have not thought about yet. Gorish runs five personal agents through an OpenClaw setup covering fundraising, people ops, GTM, product, and a personal assistant he calls Dobby. A personal agent knows his preferences and his relationships, so a LinkedIn message referencing this podcast gets connected to this conversation without being told. A GTM agent is organizational. It knows process, product lines, pricing, and objections, it ingests data sources that actively compete with each other, and it scales across hundreds or thousands of reps. His resolution of the ownership fight is the useful part. The company’s benefit is that no knowledge walks out the door when a strong rep leaves. The individual’s benefit is a preference layer they carry from company A to company B. No sane org graph imports a single rep’s perspective. It triangulates across fifteen to fifty and picks the best pattern per domain.

We cover the honest failure mode, and it is not the one people expect. Give an agent all the context in the world and it still fails at creativity. Genuinely novel choices, the strategic decision unique to this deal in this organization, remain human work. Gorish points at the LinkedIn auto-commenter era as the market learning this in public. Everything templated or close to templated, agents handle. The line sits exactly where critical thinking begins.

We go into why incumbents cannot ship this as a feature, and Gorish gets specific about architecture rather than hand-waving about innovator’s dilemma. Revenue platforms were designed before language models existed. Their data pipelines, storage models, indexing strategies, and application architecture were all optimized for capturing structured data and querying it. Continuously connecting people, conversations, emails, meetings, CRM changes, and outcomes into a living model of how a company wins is a different problem needing a different foundation. His image for the retrofit: replacing a skyscraper’s foundation while millions of customers are still inside it, working.

We cover identity resolution, the unglamorous thing actually breaking the CRM. Rick Koleta on LinkedIn, Rick K in email, RK in the CRM. If an agent cannot collapse those into one node, it does not know where to look before it acts. The same failure runs through internal meetings, where a single pipeline review covers twenty to thirty deals, each carrying real decisions about discounts, MSA terms, and next steps, and most tools cannot attribute what was said to which deal. Slack is worse, a firehose with no labels and no reliable classification, where nobody tags the account record when they mention a customer. Agents bolted onto that data inherit every fragment of it.

We go into Sybill’s own stack, which is the part operators will want. They run their entire sales process on it: forecast calls, coaching, deal execution, follow-up, dashboards, decks, and proposals. Marketing and product use it to read what messaging is landing and where the product gaps are. The interesting build is the in-house signals engine, made after evaluating the well-known tools in the space and finding nothing that did the job. Watchers run across LinkedIn and Slack communities to see who is talking about what, output flows into a master list with enrichment and joining, and records connect by the actual LinkedIn identifiers rather than the canonical ones. The result tracks a single person across Slack, a Pavilion community, LinkedIn, and internal context, with news layered on top. Gorish notes in passing that the message which booked this podcast carried his agent’s fingerprints.

We close on capital discipline and the rapid fire. Sybill did not go wide early, and Gorish is blunt that doing so would have failed epically. Every roadmap item had to clear one question. Then the rapid fire compresses the entire thesis: the metric that deserves more attention is win rates, the most overrated capability in revenue AI is note taking, the thing a founder should delete from their stack today is Gong, and in three years the CRM is a database.

Discussed in this episode

(0:00) The Bet: Transcript Is the Commodity, Context Is the Asset
(4:50) What a Context Layer Means: The Three Pillars
(5:53) The MCP Connector Bet: Distribution Over Dashboard
(8:55) Personal Agents vs GTM Agents
(12:10) Failure Modes and Category Casualties
(15:40) Why Incumbents Cannot Bolt This On
(17:26) What Breaks When Agents Run on Stale CRM
(19:19) Inside Sybill's Own Stack
(22:20) Capital Discipline and the Roadmap Question
(25:02) The 2028 Picture and Rapid Fire

Key takeaways

1. The transcript was never the product, and the market took eight months to notice.

Even in 2023, getting usable next steps out of a model required feeding it context about the desired output, the customer, and the deal. The raw text alone produced nothing worth sending. The inversion underneath this is the load-bearing idea in the episode: as models improve, the value of what you pass them improves faster than the models themselves. That makes the model the commodity and the input the asset, which is the opposite of how most revenue AI is priced today.

2. A context layer has three pillars, and most tools touch one.

Customers, meaning prospects, accounts, and opportunities. Team, meaning every person’s strengths, weaknesses, objectives, and working preferences from rep to CRO. Company process, meaning product lines, pricing, real objections, verticals, and competition. Nearly every revenue tool in the market captures the first pillar and treats the other two as configuration. The graph only compounds when all three update daily against new conversations, which is why this cannot be bought as a data import.

3. Identity resolution is the unglamorous failure quietly breaking every CRM.

Rick Koleta on LinkedIn, Rick K in email, RK in the CRM. If the agent cannot collapse those into a single node, it does not know where to look before acting, and it will act on a fraction of what the company knows. The same fragmentation runs through internal meetings, where one pipeline review covers twenty to thirty deals with real decisions inside each, and through Slack, where a firehose of relevant context arrives with no labels and no consistent account references. Every agent deployed on top of that data inherits the fragmentation and produces confident, partial answers.

4. Distribution through the agent layer beat defending the dashboard.

Sybill exposed its context layer through MCP rather than forcing usage through its own screen, and adoption grew faster than Gorish predicted for a reason he did not anticipate. RevOps builders create agents on top of the layer, and those agents scale across the whole organization. One builder’s workflow becomes a thousand reps’ default. The vendor gives up depth of insight into how the work is done and gains a distribution surface it did not have to build. The screen was never the moat.

5. Incumbents cannot bolt on a context layer, because it is a foundation and not a feature.

Revenue platforms were architected before language models existed, with pipelines, storage, and indexing optimized for structured capture and query. Continuously connecting people, conversations, emails, CRM changes, and outcomes into a living model of how a company wins is a different problem requiring a different foundation. Gorish’s image is a skyscraper whose foundation has to be replaced while millions of customers are still inside working. This is the strongest argument in the episode for why a startup owns this layer, and it is architectural rather than cultural.

6. One roadmap question enforced eighteen months of discipline.

Every feature request, and there were many, including a forecasting module, a coaching module, a performance dashboard, and a deal room, had to answer two things. Does this help the context graph learn, and does it compound the intelligence already built. Two nos meant not built. That is capital discipline expressed as architecture rather than as a spending cap, and Gorish credits it directly with surviving where wider, shallower competitors stalled.

Frameworks from the episode

1. The context graph

A self-evolving information layer built on three pillars: customers, team, and company process. It ingests conversations, emails, meetings, and CRM changes daily, resolves identities across every surface a person appears on, and outputs the context an agent needs to act without a human feeding it instructions each time. The test for what belongs in it is the same test Sybill uses on its roadmap: does this input help the graph learn, and does it compound what the graph already knows. The measured output Gorish reports is a 95 percent reduction in the human actions required to produce a single follow-up email.

2. The roadmap question as capital allocation

For a company with a fraction of its category’s funding, the constraint is not what to build, it is what to refuse. Sybill’s filter was one question applied to every request: does this help the context graph learn and does it compound existing intelligence. Feature parity with better-funded competitors was never the goal, so the requests that would have consumed the eighteen months, the forecasting module and the coaching module and the deal room, were declined. The output is a company with one deep asset instead of six shallow ones, and a foundation that is now the thing being scaled rather than the thing being rebuilt.

3. The org layer and the personal layer

Two graphs with a deliberate boundary between them. The org graph holds process, product, pricing, and objection handling, triangulated across fifteen to fifty reps rather than imported from any single one, which is how knowledge stops walking out the door when a strong rep leaves. The personal layer sits on top and holds an individual’s preferences, relationships, and working style, and it travels with them from company A to company B. The architecture question is not who owns the context. It is where that boundary sits, and most teams have not yet asked it.

What to do this week

• Run the with-and-without test on your own data

  Ask your AI assistant one real deal question using CRM data alone, then ask it again with calls, email, and Slack context connected. This is the comparison Sybill runs in sales conversations, and it works because it requires no vendor claim. The gap between the two outputs is the size of your context problem, measured before you spend anything on solving it.

• Count your identity fragments

  Pick ten active deals and count how many name variants each buyer has across the CRM, email, LinkedIn, and Slack. Then check whether any system in your stack collapses them into one record. Every unresolved variant is a place where an agent will act on partial information and report it as complete.

• Apply the roadmap question to your stack, not just your roadmap

  For every tool you pay for, ask whether it makes your account context compound or whether it records activity. Recording is available from Zoom, free from Fathom, and bundled into a dozen tools already on your laptop. Per this episode, the recorders are the commodity layer and the first candidates for deletion at renewal.

• Audit one internal pipeline review for lost context

  Take the recording of your last forecast or pipeline call, list every deal discussed, and check what made it into the CRM against the right record. The decisions inside those meetings, on discounts, on MSA terms, on next steps, are the richest context your company produces and the least likely to be captured correctly. Whatever is missing is what your agents will not know.

Why this matters

Every tool in your revenue stack does one of two things. It records what happened, or it compounds what your company understands. For most of the last decade the distinction did not matter, because recording was expensive and understanding was a human job performed on top of the record. Gong built a multi-billion dollar company in that world, and it was the right company to build.

The market has repriced the first half. Recording comes with Zoom, is given away by Fathom, and is bundled into a dozen tools already running on the laptop. When a capability is free at every price point, the value does not disappear. It moves. It moves to whoever can take the recording, resolve who is being referenced across fifteen surfaces, connect it to what was said in Slack two months ago, and hand an agent enough context to act without a human writing the instructions.

That is a different piece of software than the one most revenue teams bought. It cannot be assembled from a data import, because the pillars have to evolve daily against new conversations. It cannot be shipped as a feature by a platform architected before language models existed, because the pipelines, storage, and indexing were optimized for structured capture rather than continuous learning. And it cannot be solved with a longer context window, because the failure is not capacity. The failure is that the model does not know Rick Koleta and RK are the same person.

The teams that feel this first are the ones deploying agents on top of a CRM they already know is fragmented. The agent will be confident and it will be wrong, and the fragmentation will get blamed on the model. The teams that feel it second are the ones paying for four tools that record and none that compound.

Before your next renewal cycle, know which side of that line each line item sits on.

This is GTM Vault.

If this changed how you read your own stack, send it to whoever signs the renewals.

Share

Connect

Follow Gorish Aggarwal // Sybill

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.

Subscribe now

The hard part of agentic outbound is not building the agent. Anyone can wire an LLM to Apollo and get a list. The hard part is that the rep does not use it. The demo lands, adoption stalls at the handful of people who enjoy tinkering, and six months later the build is a line item nobody defends. Most teams respond by training reps harder on the tool, which treats an adoption problem as an education problem.

In episode seven of Show Me Your Stack, Angelo Quiambao runs the opposite play. He is a GTM engineer at Intellistack, two months into rebuilding an outbound architecture he first proved at Qualified, where the agents went from an opt-in productivity boost to mandatory, with every BDR required to send fifty agent-generated emails a day. For twenty minutes he shares his screen and runs the live system, terminal on the left, agent workforce on the right. The design principle underneath all of it is one line: the best use of AI is the indirect use of AI.

His stack is Claude Code as the terminal, Relevance AI as the agent host, and MCP as the connective tissue, sitting on Databricks, Salesforce, Gong, and Apollo. The tool list is not the story. The story is that a rep triggers this entire architecture by checking a box, and is never told what happens next.

Watch now: Angelo Quiambao - AI GTM Engineer

Share

The Context Layer: What Gets Built Before Any Agent Exists

Angelo’s first move on any build is not a build. Before a single agent exists, he maps account tiering definitions, ICP definitions, product information, and buying teams, then takes them to RevOps, marketing, and sales until the definitions are uniform across all three. Those definitions live in knowledge bases the agents pull from, refreshed daily.

His reasoning is blunt. Hand an agent zero context and the outputs are, in his word, horrendous. Teams skip this part because it looks like documentation rather than engineering, and it is the input that decides whether everything downstream is usable. His line for the market condition: companies are very data rich, because AI can pull data from anywhere, but no one is context rich. That gap separates working agents from cut-and-paste templates that may or may not fire.

The Architecture: One Orchestrator, Four Single-Job Agents

The build is hub and spoke. Prospecting, account research, contact research, and emailing are separate agents, and each one does a single process. That constraint is deliberate. An agent that makes multiple decisions creates too many areas for error, so no agent makes two.

One orchestrator sits in front of them. Its only job is to take a request, route it to the right agent, and assemble what comes back. It also holds the memory. Ask it to research an account the system already covered and it answers with what it found sixty days ago and asks whether to run it again. It tracks errors. It logs which sequence a contact is in and how many days since last touch. It writes back to the CRM as the run progresses. Deduplication is not a cleanup job at the end. It is a gate enforced before work happens twice.

The agents also outrank a plain MCP connection. He wrapped the Apollo API into an agent rather than calling it from Claude directly, which gives it decision-making power plus read and write access to Salesforce, Gong, and Databricks, instead of prompting a model and hoping it handles the response correctly.

The Live Run: Internal Data Before External Signal

Angelo types “find me some hot leads” into the terminal. The command travels over MCP to Relevance, the orchestrator wakes the workforce, and account research starts running against three accounts at once.

What the research agent does first is the decision worth copying. It checks internal data before it touches anything external. Is this an open opportunity. Is there a closed-lost history worth re-engaging. Is there first-party intent, are they on our site. Are there MQL or MQA personas on the account. Only then does it reach for third-party intent and external signal. This is exactly the work that takes a human a long time, which is why it is the work worth handing over.

Then the gates. ICP gate, duplicate check, and a pre-check for accounts already in a deal cycle. Anything that fails is blocked and logged rather than emailed. The expensive mistake in outbound is not a weak email. It is an agent emailing an account your own team is mid-deal with, at forty-rep scale, every day.

Outputs error, and Angelo treats that as normal rather than as failure. Errors get tracked, logged, and reviewed in evals at the end of the week, the same cadence a manager would run on a human rep. Personalization carries a fallback so nothing ships as AI slop when the agent finds nothing real to say. The run on screen finishes with four contacts, no flags, sequence assigned, CRM updated. He mentions in passing that it was the first live run on the new build.

The Translation Layer: Ten Words or the Build Is Wrong

Angelo reports to the CRO, historically to a VP of RevOps, and he weights the enablement half of his job equal to the build half.

His test for a build is a sentence. If he cannot describe to leadership in five to ten words what an agent does, the build is too intricate and has too many places to fail. Translation runs both directions from there. Up the org chart it becomes goals and results, down the chart it becomes process.

For the rep it collapses to a single instruction. Click this checkbox and an email to your top prospect will be in your drafts, ready to send. They do not need to know they are activating a seven-layer agent architecture, that it is deduping, that it is running Databricks research. Where reps live in Slack instead, the trigger is a natural-language message to a query agent. Same rule either way: put the trigger where they already are.

This is why rep adoption is the number one thing Angelo measures, ahead of any measure of agent capability. Agents nobody uses are useless, and occasional tinkering wastes his time and theirs. The framing he gives leadership is five times the output of one person rather than the replacement of one person, which is also the version reps can hear without going defensive.

The Numbers, and What Happens If They Go the Other Way

At Qualified the adoption curve only ran one direction. Early on the agents were a productivity boost BDRs could opt into. At peak they were mandatory, with every BDR required to send fifty agent-generated emails a day, anchoring the team’s push into enterprise accounts. The system carried its own quota, set at four times a standard BDR target, was paired with AEs like any rep, and was held to the same performance standards as the human team. On screen, four contacts were researched, gated, enriched, and queued in the time it took to explain the architecture.

The cost side is real. Scale this to a forty-rep enterprise sales team running daily and Angelo estimates burning something like ten million credits a day across Relevance and Claude. He is unsentimental about it: it generates revenue, so it is worth it, and his job is keeping the error rate low enough that it stays true. He is equally direct about the inverse. At enterprise scale, agents that do not work do not merely waste money, they generate errors that cost the team more time than they saved. That is why he keeps returning to context, and why he says you cannot automate something you have not done yourself.

Where This Goes by the End of September

Angelo is two months into the role and calls the current architecture a first version. He expects it to look different by the end of September, and floats the possibility that the whole thing collapses into one agent. That is not a walk-back. It is what happens when the underlying models absorb the orchestration you had to hand-build a quarter earlier.

His prompting rule survives that shift, because it is architectural rather than tooling-specific. If you want lazy prompts, the system needs to be intricate, and not the other way around. Lazy prompt plus no context gives you bad output. Lazy prompt plus an intricate, context-loaded system is the entire point. Nobody wants to write structured prompts, so the structure has to live somewhere else.

The Pattern

Every team building GTM agents is solving for capability. Angelo is solving for who has to understand the thing.

That reframes the whole build. If the rep has to learn your agent, you have shipped another tool into a stack they already resent, and adoption decides the outcome no matter how good the architecture is. If the rep never meets your agent, the complexity budget moves entirely to you, which is where it belongs, and the only thing they experience is a draft appearing in their inbox after a click they already knew how to make.

The measure of a GTM agent is not what it can do. It is how little the person triggering it needs to know. If your reps need training to use your AI, the architecture is backwards.

Seven Things Worth Stealing

1. The best use of AI is the indirect use of AI. Reps do not operate agents, they trigger them from wherever they already work. Every hour you spend teaching a rep your interface is an hour that says the interface is wrong.

2. If you cannot describe an agent in ten words, the build is wrong. Angelo’s test is for leadership, not for engineers. An agent that needs a paragraph to explain has too many decision points and too many places to fail silently.

3. No agent should make two decisions. One process each, one orchestrator in front. Multi-decision agents feel efficient to build and become impossible to debug once they are running against live pipeline.

4. Deduplication is a gate, not a cleanup task. The orchestrator remembers what it researched sixty days ago and asks before repeating it. Systems that dedupe after the fact have already spent the money and, worse, already sent the email.

5. Internal data before external signal. Open opportunities, closed-lost history, first-party intent, and MQL personas get checked before any third-party source is called. Reversing that order is how an agent emails an account your team is mid-deal with.

6. Agents get managed like reps, evals included. Errors are expected, so they are tracked, logged, and reviewed weekly on the same cadence a manager reviews a human. Personalization carries a fallback so nothing ships as slop when there is nothing real to say.

7. Lazy prompts require intricate systems. Nobody wants to write structured prompts, so the structure has to live somewhere else. Lazy prompt plus no context gives you garbage. Lazy prompt plus a context-loaded system is the entire point.

Timestamps

(0:00) Meet Angelo Quiambao

(0:38) The stack: Claude Code, Relevance AI, MCP

(3:10) Context before agents: tiering, ICP, buying teams

(4:28) The orchestrator and its 60 day memory

(6:01) Why rep adoption is the number one metric

(7:54) Seven layers behind one checkbox

(9:46) Live run: internal data before external signal

(11:30) Wrapping the Apollo API into an agent

(15:05) Credits versus revenue at enterprise scale

(16:24) Data rich versus context rich

Links

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

Follow Angelo on LinkedIn - https://www.linkedin.com/in/angelo-quiambao

Try Intellistack - https://www.intellistack.com/

Previous episodes include

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

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

Hi. I’m 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.

Subscribe now

Nineteen days at full speed

GTM Vault runs on the same doctrine I write about here: positioning, motion design, RevOps, and an AI-native execution layer, installed as a system instead of accumulated as a pile of tools. For nineteen days, from July 17 to August 4, 2026, I let that system run at full speed and logged every action it took. Four hundred and twenty one of them.

The machine never slowed down. Subscriber growth did. That gap is the entire lesson: we removed the production constraint in about three weeks, and the constraint did not disappear. It moved to the one layer we never automated, the human decision. If you are pointing your AI budget at generating more, this is the field report on what happens after generation stops being scarce.

What the machine actually is

It is not one agent. It is a set of rails, each owning one layer of the go-to-market motion, each writing to a shared log so no rail can misreport what it did.

The distribution rail takes a published essay and puts a carousel across X, LinkedIn, Instagram, and Substack Notes on a synchronized schedule. The clips rail cuts podcast episodes into shorts and stages them across three surfaces. A community rail drafts substantive answers to real questions on Reddit and elsewhere. A reply desk drafts responses to every inbound guest, sponsor, and partner thread. A sponsor rail ranks prospects, finds contacts, and writes first-touch and follow-up. A guest rail sources operators for the podcast and Show Me Your Stack and tracks them through a pipeline. An essay-research rail assembles the next topic before I write it. A nightly loop reconciles all of it against the logs and scores the week.

None of these are demos. They ran against the live business, into the live 26,000 subscriber list, every day.

Where it is strong is exactly where you would expect

Production. The machine is very good at production.

In one recent day the community rail landed three substantive answers on three different subforums, all verified, and in the process found that a nine and a half minute spacing between posts was the difference between landing and getting filtered. The guest pipeline crossed one hundred seventy five enriched rows. The distribution rail now ships a single essay across four surfaces at one synchronized nine a.m. Eastern slot without me touching a composer. The research rail had two full essay packs staged and sourced before I had decided which one to write.

This is the part of the AI-native promise that is real. The cost of producing a competent draft, a competent answer, a competent outreach sequence has collapsed to near zero. If your bottleneck was ever that you could not make enough, that bottleneck is gone. We removed it in about three weeks.

And then the number that matters did not move.

The constraint moved to the layer nobody automated

Here is the pattern the nightly loop named on its own, in its own words: the drafting layer is healthy, the sending layer is stalled.

The machine produces faster than any human can approve. Sponsor outreach went out at volume and the reply rate lagged the production rate badly. Dozens of finished drafts, connection requests, and follow-ups sat in a queue waiting on a single human decision, mine. The rails that generate never stopped. The one gate they all funnel through, a person deciding what is good enough to send, became the ceiling on the entire system.

This is not a staffing problem. It is a structural one. We installed machine-speed production on top of a human-speed decision layer, and the two speeds do not reconcile. The output of the fast layer piles up against the throughput of the slow layer, and the slow layer sets the real rate of the business.

If that mechanism sounds familiar, it should. It is the same one I described in “Why AI SDRs Failed.” Agents installed on top of a broken or slower layer do not fix the layer. They amplify the mismatch. AI on a coherent system produces leverage. AI on a system with an un-designed decision layer produces a backlog at machine speed. We did not escape our own doctrine by running it. We proved it on ourselves.

What is actually broken, said plainly

Two of the fleet’s roughly thirty rails currently produce no output I can verify. One fires on schedule and leaves no trace in either log location, which means for auditing purposes it did not run at all. A second logged two runs with no record of what it touched. In a system whose entire integrity depends on every rail writing to a shared log, a rail that acts without logging is worse than a rail that does nothing, because it looks like coverage while providing none.

I am naming this because build-in-public that only reports the wins is marketing with a timestamp. The honest state is that the production rails outran the observability around them, and observability is now on the same repair list as the decision layer.

The lesson, and what it changes

The reflex in AI-native GTM is to point the budget at generation. Better models, more agents, more surface area. We did that. It worked, and it revealed that generation was never the scarce resource in this business. The scarce resource is qualified human judgment applied fast enough to keep up with what the machine already makes.

So the next thing we architect is not another producing rail. It is the decision layer itself. Batching approvals instead of handling them one at a time. Pre-qualifying drafts so the human gate sees fewer, better candidates. Raising the bar for what a rail is allowed to send with no human at all, and lowering it only where the cost of a wrong send is small. Designing the gate as deliberately as we designed the pipeline that feeds it.

The distribution rail sitting idle this week is not a failure of the rail. It is idle because I have not published the next essay yet, and that decision, like the sponsor sends and the guest follow-ups, lives in the human layer. The machine is waiting on the same constraint everything else is waiting on. The production problem is solved. The next problem was hiding behind it the whole time, and it is the one worth building for.

The redesign of that decision layer, the batching, the pre-qualification, and the exact rules for what earns the right to send without a human, is the next deep dive, and it lives in GTM Vault Pro at gtmvault.co/subscribe.

Common questions

Is AI the bottleneck in go-to-market?

No. In our own system, AI removed the production bottleneck entirely inside three weeks. The bottleneck moved to the human decision layer, the point where a person approves what the machine produced. Generation is no longer the scarce resource. Qualified judgment applied at speed is.

What is an AI GTM machine?

A set of rails, each owning one layer of the go-to-market motion (distribution, content clips, community answers, reply drafting, sponsor outreach, guest sourcing, research, and nightly reconciliation), running autonomously and writing to a shared log. It is not a single agent. It is an architecture where each rail produces and one gate decides.

Why did automating GTM not increase subscriber growth?

Because output volume was never the constraint on growth. Automating production raised how much got made, not how much cleared the approval gate or converted. When the fast layer feeds a fixed-speed decision layer, the extra output becomes backlog, not results. Growth is set by the slowest layer, and that layer was human.

What is the decision layer in GTM?

The point in the system where finished work waits on a human to approve, send, or publish it. Most AI GTM stacks invest heavily in generation and leave this layer un-designed. Once production is cheap, the decision layer becomes the actual throughput ceiling and has to be architected on purpose: batched, pre-qualified, and selectively delegated.

Does this mean AI in GTM is overhyped?

No. It means the value moved. AI on a coherent system with a designed decision layer compounds. AI on a fragmented system, or a system with a bottlenecked human gate, produces noise and backlog at machine speed. The tool is real. Where you install it decides whether it helps.

Related reading

• Why AI SDRs Failed. The same mechanism at category scale: generation installed on top of broken qualification, stale data, and rented channels.

• What Is Revenue Architecture?. The layer model this machine is built on, and why build order determines whether agents compound or amplify.

• GTM Is Not a Headcount Plan. Why adding capacity to an un-designed system scales the problem, not the outcome.

Subscribe to GTM Vault: revenue architecture for founders and GTM leaders, read by 26,000+ operators building systems that compound.

Subscribe now

If this edition was useful, help it travel by clicking the ❤️ and 🔄 at the top of this post.

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

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

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

The Distinction Most GTM Automation Misses

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

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

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

What I Built

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

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

The Team Became a System

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

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

What a System Knows That an Automation Does Not

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

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

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

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

The Number That Matters, and the One That Does Not

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

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

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

Automate the reversible. Gate the irreversible.

Why This Installs in a Company That Sells Differently Than Mine

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

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

The Diagnosis

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

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

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

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

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

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

— Sean Ellis, Founder of GrowthHackers

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

GTM Vault is read by 26,000+ founders and revenue leaders across 140+ countries, including inside OpenAI, Anthropic, Meta, and Google.

The Doctrine, in full

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

The GTM Strategy Course

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

The Blueprint Session

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

Who this is for

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

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

What upgrading does

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

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

Upgrade to Annual Pro

Common questions

What is revenue architecture?

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

What does GTM Vault Pro include?

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

What is the Blueprint Session?

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

How do I get the Blueprint intake form?

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

Is Pro monthly or annual?

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

What is the difference between the free publication and Pro?

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

Who should not upgrade?

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

Upgrade to Annual Pro

Explore GTM Vault

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

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

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

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

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

GTM Playbooks · the applied builds, end to end.

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

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

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

The Promise, Stated Fairly

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

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

Eighteen Months From Category to Cautionary Tale

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

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

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

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

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

The Mechanism: Four Structural Failures

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

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

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

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

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

What Actually Failed, and What Didn’t

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

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

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

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

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

Where the Value Settled

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

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

How to Evaluate Agentic Sales Tools Now

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

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

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

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

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

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

The Falsifiable Version

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

Questions Operators Ask

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

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

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

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

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

The First Casualty Report

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

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

Subscribe now

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

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

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

Why the Term Needs Defining

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

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

What Revenue Architecture Is Not

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

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

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

The Five Eras of the Revenue System

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

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

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

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

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

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

The Four Forces Behind the Architecture Era

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

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

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

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

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

The Eight Layers

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

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

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

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

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

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

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

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

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

Sequencing Is the First Decision

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

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

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

The Leverage Repricing

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

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

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

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

The Revenue Architect

Someone has to do this work, and at most companies nobody formally does. At Seed, the founder is the revenue architect whether they accept the title or not: every early decision about ICP, pricing, and motion is an architectural decision made under a different name. By Series B, architecture needs to be a designed responsibility, held by a specific person, because the system has grown past what any one function sees.

The revenue architect is not the GTM engineer. The architect decides what the system should be and in what order it gets built. The GTM engineer builds and runs it: the workflows, the pipelines, the agents. One is a design function, the other an engineering function, and conflating them produces systems that are beautifully built to the wrong spec.

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

Questions Operators Ask

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

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

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

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

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

Where the Eras Leave Us

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

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

Subscribe now

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

Subscribe now

Why is AI-native GTM a sequencing problem? Because the layers only work in one order: data first, intelligence second, agents third. Clean the data every agent will reason over, fix qualification before you scale volume, then install agents on top of coherent structure instead of on top of fragmentation. The companies stalling on AI bought the full stack at once and automated their existing chaos at machine speed. The tools are identical across the winners and the losers. The order is not.

The sequencing problem, stated once: an AI agent is only as good as the structure beneath it, and structure has to be built before the agent, not retrofitted after it. Buy the agent first and you do not get intelligence. You get your current fragmentation, running faster.

The sequence at a glance. These seven steps run in order. Skipping to Step 3 is the failure mode this essay documents.

1. Map the revenue motion before you touch the stack.

2. Hire the GTM Engineer before you buy the stack.

3. Choose your system of record first, then build outward.

4. Design the copilot layer, not the autopilot layer.

5. Restructure what humans do, not whether to keep them.

6. Commit to a 12-month timeline, not a 90-day pilot.

7. Measure outcomes, not activity.

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

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

Same tool category. Opposite results.

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

This playbook is the build sequence.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Step 7: Measure Outcomes, Not Activity

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

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

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

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

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

What This Looks Like at 12 Months

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

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

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

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

The Failure Mode to Avoid

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

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

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

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

Frequently Asked Questions

Why is AI-native GTM a sequencing problem?

Because the layers only compound in one order: data, then intelligence, then agents. An agent reasons over whatever structure sits beneath it, so if the data is fragmented and qualification is broken, the agent automates that fragmentation at machine speed. The winners and the losers in the 2026 Ramp data run the same tool categories. What separates them is the order they built in.

What is the correct sequence for building an AI-native GTM stack?

Map the revenue motion and its manual hops first. Hire or designate the GTM Engineer who will architect the system before you buy tools. Choose your system of record and build the agent layer inside it. Deploy agents as a copilot layer with a human at the decision point, not as autopilot. Restructure roles around judgment, commit to a 12-month timeline, and measure outcomes rather than activity.

What happens if you install AI agents before fixing your data?

You do not get intelligence. You get your existing fragmentation, running faster. A scoring or research agent built on incomplete CRM data prioritizes the wrong accounts and drafts confident, wrong outreach, and no amount of workflow automation fixes a broken signal underneath it. This is why teams end up with six tools that each do something and none of which compound.

Why did autonomous AI SDRs fail?

The failure was architectural, not technological. Fully autonomous outbound placed the human in the wrong part of the workflow by removing them entirely, and reply rates on that model run 1 to 3% against 5 to 12% for copilot-assisted outbound where a human reviews and approves before the send. The correct design moves the human to the decision point and removes them from the preparation steps.

Should AI agents live inside the CRM or run as standalone tools?

Inside, or natively connected to, your system of record. A standalone tool that sits outside the CRM requires a human to carry each insight to where the action happens, which reintroduces the exact latency the agent was supposed to remove. The 2026 consolidation wave, HubSpot absorbing Warmly and Zoom acquiring Common Room, was the market pricing in that architecture.

Why do 90-day AI pilots fail?

Meaningful output gains appear 6 to 12 months after implementation, and the curve does not bend in the first quarter. A one-quarter pilot exits at month three, before compounding begins, then concludes the investment is not working. It evaluates a six-month investment on a three-month clock and almost always reaches the wrong answer.

What should you measure to know if AI GTM is working?

Outcome metrics, not activity metrics. Track pipeline generated per seller, stage-by-stage conversion change, cost per meeting booked, and revenue per head against a baseline you defined before the infrastructure went live. Activity metrics like prompts sent or time saved trend up quickly but never answer whether the system produced a commercial return.

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

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

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

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

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

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

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

Inside this episode

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

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

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

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

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

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

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

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

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

Listen & subscribe now across:

Apple // Spotify

Discussed in this episode

00:00 Intro

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

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

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

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

10:07 Continuous authority versus authentication in practice

11:28 Where other identity vendors' coverage ends

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

13:56 What a qualified deal looks like right now

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

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

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

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

Key takeaways

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

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

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

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

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

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

Frameworks from the episode

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

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

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

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

3. The train versus the taxi

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

What to do this week

• Map what is actually running

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

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

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

• Identify who owns agent governance today

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

• Audit your LLM standardization assumption

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

Why this matters

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

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

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

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

This is GTM Vault.

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

Connect

Follow Mark van Oppen // SecureAuth

Follow Rick Koleta // GTM Vault

Thanks for listening. See you in the next episode.

P.S. Annual paid subscribers get a Private GTM Blueprint Session. One working session to identify your primary GTM constraint and design the 90-day architecture to resolve it.

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

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

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

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

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

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

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

Read more

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

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

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

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

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

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

Subscribe now

Why the Play Mental Model Breaks

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

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

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

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

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

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

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

The Five Signal Types That Drive Most of It

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

1. Account motion

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

2. Relationship change

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

3. Buying intent

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

4. Expansion surface

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

5. Competitive displacement

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

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

Read more

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

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

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

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

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

The moat moved. It is sitting in distribution now.

Subscribe now

The Historical Record

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

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

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

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

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

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

The Sequence Changed

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

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

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

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

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

The Benchmarks Confirm It

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

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

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

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

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

The Anthropic Signal

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

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

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

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

Distribution Is a System, Not a Channel

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

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

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

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

The Structural Implication for GTM Teams

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

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

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

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

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

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

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

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

Subscribe now

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

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

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

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

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

Read more

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

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

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

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

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

Subscribe now

The Skill Stack

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

The math is non-linear, not multiplicative.

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

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

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

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

Why most operators build isolated skills

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

The pattern is sticky for three reasons.

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

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

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

The four design principles for stacks

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

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

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

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

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

The four failure modes

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

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

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

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

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

A working example

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

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

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

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

Channel Drag applies to stacks too

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

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

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

What this changes for an operator

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

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

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

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

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

What this changes for a leader

Stop counting skills. Start counting compositions.

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

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

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

The constraint reframed

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

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

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

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

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

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

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

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

Subscribe now

Inside this episode

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

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

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

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

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

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

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

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

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

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

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

Discussed in this episode

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

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

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

16:38 - Revenue per employee is the new endgame

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

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

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

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

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

Key takeaways

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

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

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

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

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

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

Frameworks from the episode

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

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

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

What to do this week

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

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

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

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

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

Why this matters

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

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

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

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

This is GTM Vault.

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

Connect

Follow Alex Bilmes // Endgame

Follow Rick Koleta // GTM Vault

Thanks for listening. See you in the next episode.

P.S. Annual paid subscribers get a Private GTM Blueprint Session. One working session to identify your primary GTM constraint and design the 90-day architecture to resolve it.

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

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

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

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

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

Subscribe now

Channel Drag

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

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

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

The pattern is the same across every team I see

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

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

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

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

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

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

Why the mechanism matters more than the recipe

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

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

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

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

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

The transition zones break most teams

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

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

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

The Reference-Feedback Split applies here

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

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

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

Build Reach is the test for high-ACV channels

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

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

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

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

What this changes for an operator

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

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

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

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

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

What this changes for a leader

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

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

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

The constraint reframed

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

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

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

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

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

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

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

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

The Four Layer Model

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

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

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

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

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

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

Layer 1: Build the Foundation

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

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

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

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

Layer 3: Build Execution Before Layer 2

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

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

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

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

Layer 2: Add Research When the Generic Limit Is Hit

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

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

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

Layer 4: The Feedback Loop That Makes the System Compound

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

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

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

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

What This Costs to Build

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

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

The Real Moat

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

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

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

The Foundation is the work. Start there.

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

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

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

Most Read

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

• GTM 43 | The Semantic Layer Is the Missing Architecture

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

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

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

• SMYS 1 | Review Intelligence as a GTM Signal Layer

• Category Leadership Is Built. Not Launched.

• The SaaS Motion Map

• The 90-Day GTM Blueprint

Subscribe now

The Foundational Laws

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

• Foundational Law 01: Every Downstream Decision Inherits the ICP

• Foundational Law 02: What Scales First Constrains Everything After

• Foundational Law 03: Pricing Restructures Every Layer It Touches

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

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

• Foundational Law 06: Channel Accumulation Is Not Distribution Architecture

• Foundational Law 07: Every Metric Compounds or Conceals

• Foundational Law 08: AI Amplifies the Architecture It Inherits

AI-Native GTM

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

• The Architecture of AI-Native GTM

• The AI-Native Revenue Engine

• Agentic GTM Requires Systems, Not Smarter Agents

• The Three Stages of AI-Native GTM

• When the Buyer Is a Machine, Every Layer Breaks

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

• The State of AI GTM, 2025 Edition

• Agentic Marketing: The New GTM Architecture

• The New Architecture of GTM in the AI Era

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

Subscribe now

ICP, Positioning, and Beachhead

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

• Foundational Law 01: Every Downstream Decision Inherits the ICP

• The Beachhead Strategy Playbook

• Category Leadership Is Built. Not Launched.

• 15 Moats That Define Modern GTM Strategy

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

• The Remote With Too Many Buttons

• The Invisible Forces Shaping Your GTM Strategy

Pricing, Monetization, and Metrics

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

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

• Foundational Law 03: Pricing Restructures Every Layer It Touches

• Foundational Law 07: Every Metric Compounds or Conceals

• GTM Tool Spend by Growth Stage

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

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

• GTM 42 | When Dashboards Divorce the P&L

Distribution and Growth

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

• Clip Farming: The 2025 Distribution Exploit for Founders

• Foundational Law 06: Channel Accumulation Is Not Distribution Architecture

• The Smartest Growth Plays of 2025

• The Hidden Growth Engine in AI Search

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

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

• In AI, GTM Is the Only Moat That Lasts

• 100+ Startup Marketing Tactics That Actually Work

Org Design and Team Architecture

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

• The Org Chart Is Dead

• The New GTM Org

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

• The AI-Powered GTM Operator

• AI Is Rewriting the GTM Org

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

GTM Engineering and Stacks

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

• Show Me Your Stack (series intro)

• SMYS 1 | Review Intelligence as a GTM Signal Layer

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

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

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

• The GTM Stack You Actually Need in 2025

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

• The AI Stack You’ll Actually Use

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

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

Playbooks and Applied Motions

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

• The 90-Day GTM Blueprint

• The Customer Journey Playbook

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

• The SaaS Motion Map

• The Non-Technical Founder’s GTM Playbook

• The GTM Debug Framework

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

• Reverse Trials: Designing Conversion After the Trial Ends

• The New B2B GTM Playbook

Podcast Highlights

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

• GTM 43 | The Semantic Layer Is the Missing Architecture

• GTM 41 | Revenue Activation Is Architecture

• GTM 40 | Agentic Marketing Rewrites GTM

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

• GTM 31 | AI as the Revenue Intelligence Layer

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

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

• GTM 24 | Buyer-Led GTM Replaces the Funnel

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

The Strategy Course

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

• Build a Modern Revenue Engine (course overview)

• Chapter 1: Foundations of Winning GTM Strategy

• Chapter 2: AI-Powered GTM Execution

• Chapter 3: Demand Generation That Actually Works

• Chapter 4: Sales & Revenue Acceleration

• Chapter 5: Product-Led & Hybrid GTM

• Chapter 6: Data & Metrics That Matter

• Chapter 7: Messaging & Positioning

• Chapter 8: The 2026 GTM Operating System

• Chapter 9: From 0 to $1M ARR

• Chapter 10: War Stories & Lessons

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

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

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

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

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

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

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

This is not a conversation about better ad tools.

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

Subscribe now

Inside this episode

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

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

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

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

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

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

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

Discussed in this episode

0:00 Intro: why ads stall before spend does

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

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

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

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

11:00 AI as multiplier, not savior

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

19:00 SMB versus enterprise: retargeting and accessibility

21:20 Performance metrics that lie

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

31:40 Why small teams ship and learn faster

35:00 What enterprise can learn from SMB velocity

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

42:55 Closing: learning velocity is the new spend

Key takeaways

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

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

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

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

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

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

Frameworks from the episode

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

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

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

What to do this week

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

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

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

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

Why this matters

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

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

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

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

This is GTM Vault.

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

Connect

Follow George Howes // Canva Grow

Follow Rick Koleta // GTM Vault

Thanks for listening. See you in the next episode.

P.S. Annual paid subscribers get a Private GTM Blueprint Session. One working session to identify your primary GTM constraint and design the 90-day architecture to resolve it.