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

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

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

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

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

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

Inside this episode

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

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

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

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

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

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

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

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

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

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

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

Discussed in this episode

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

Key takeaways

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

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

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

   

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

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

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

Frameworks from the episode

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

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

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

What to do this week

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

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

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

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

Why this matters

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

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

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

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

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

Connect

Follow Yoni Tserruya // Lusha

Follow Rick Koleta // GTM Vault

Thanks for listening. See you in the next episode.

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

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

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

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

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

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

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

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

The Gate: Why There Is No Install Button

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

The Harness: Chat for Intent, Browser for State

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

The Buttons: Prompts the Rep Never Writes

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

The Economics: Seats on Top of Credits

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

Where This Goes: More Products, Same Surface

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

The Pattern

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

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

The rule: ship capability as buttons, not trainings.

Five Things Worth Stealing

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

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

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

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

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

Timestamps

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

Links

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

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

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

Previous episodes include

• SMYS 7 | Your Reps Should Never Meet Your Agents

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

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

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

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

The short version

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

The Two Definitions That Rank

Take them at their word, because both are explicit.

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

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

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

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

The Test Is Authority, Not Advice

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

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

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

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

What the Role Decides

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

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

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

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

Not the GTM Engineer

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

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

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

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

Who Holds It at Each Stage

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

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

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

Where This Framing Breaks

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

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

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

What This Decides

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

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

Common questions

What is a revenue architect?

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

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

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

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

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

Do you need to hire a revenue architect?

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

Can a consultant be your revenue architect?

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

Who owns revenue architecture in a company?

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

Related reading

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

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

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

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

The short version

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

The Answer Everyone Gives

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

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

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

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

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

The Test Is Reversibility

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

Run it on real examples.

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

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

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

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

What Each One Owns

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

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

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

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

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

The Failure Mode

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

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

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

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

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

The Boundary Moves, and 2026 Is Moving It

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

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

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

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

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

Where This Framing Breaks

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

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

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

What This Decides

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

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

Common questions

What is the difference between revenue architecture and revenue operations?

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

Is RevOps part of revenue architecture?

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

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

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

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

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

Who owns revenue architecture in a company?

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

Is revenue architecture just a rebrand of RevOps?

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

Related reading

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

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

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

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

The short version

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

Five Models, No Agreement

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

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

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

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

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

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

What a Layer Is

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

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

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

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

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

The Eight Layers in Build Order

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

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

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

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

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

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

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

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

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

Why Diagnosis Runs Bottom-Up

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

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

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

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

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

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

The AI Layer Reads Everything and Repairs Nothing

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

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

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

Where This Framing Breaks

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

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

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

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

What This Decides

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

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

Common questions

What are the layers of a modern revenue system?

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

How many layers does a revenue architecture have?

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

Do revenue architecture layers have to be built in order?

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

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

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

Where does AI sit in revenue architecture?

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

Why do revenue architecture frameworks disagree with each other?

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

Related reading

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

What Is Revenue Architecture?

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

AI-Native GTM Is a Sequencing Problem

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

What Is AI-Native GTM?

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

The Revenue Architecture Map

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

Subscribe now

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

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

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

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

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

Inside this episode

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

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

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

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

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

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

Discussed in this episode

Key takeaways

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

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

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

   

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

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

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

Frameworks from the episode

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

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

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

What to do this week

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

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

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

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

Why this matters

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

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

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

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

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

Connect

Follow Hao Sheng // expertise.ai

Follow Rick Koleta // GTM Vault

Make Better Decisions With AI

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

Join the Decision Intelligence Newsletter →

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.

Each layer, its governing question and its failure signature are set out in The 8 Layers of a Modern Revenue System, along with why diagnosis runs bottom-up and what would falsify the ordering claim.

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