The Lean GTM Stack Is Missing Its Record Layer

Fewer tools is the right instinct, and the record shows where it breaks

Oct 29, 2026

The short version

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

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

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

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

Animated diagram: the 5 lean stack layers build in, the record layer appears missing, then anchors the stack — **Figure 1.** *The 5 layers from the post build in, the record layer shows up missing, then anchors the stack. Every layer reads from 1 record and writes outcomes back to it.*

The Stack on the Table

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

The stack itself:

Build and reasoning: Claude Code and Codex for research, messaging, builds and automation
Signals: Grok Bot for social intent, Common Room for intent, Granola for call insights
Decisions: Jev for scoring, triage and routing
Orchestration: Clay for lists, enrichment and messaging
Full-funnel delivery: Ploy for the website, LinkedIn, Instantly for outbound, Google Ads and LinkedIn Ads for paid

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

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

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

Stack Index: operators naming a tool in each GTM layer across 23 stacks, with 1 displacement and none at the record layer — **Figure 2.** Operators naming a tool in each layer, across 23 stacks in the Stack Index. The action layers are crowded and the only displacement is at the build step. The record layer is named by 5 operators and replaced by none.

Where the Record Agrees

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

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

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

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

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

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

What operators reported after moving work into Claude Code: 4 before and after metrics — **Figure 3.** *What operators on the record reported after moving work into Claude Code. Seats disappear in build, enrichment and sending. MCP at volume leaks the savings back.*

The Missing Layer Is the Record

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

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

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

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

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

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

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

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

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

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

MCP Is How You Build, Not How You Run

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

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

Tokens Are Still Seats

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

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

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

The Corrected Stack and the Seat Test

Keep the 5 layers. Add the sixth underneath them.

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

Does it own the record, or write outcomes back to it? It keeps a seat.
Is it the production API an agent calls at volume? It keeps a metered seat. MCP-only access is a build tool, not a production one.
Does it bring data or infrastructure the model cannot produce: proprietary signal, sending reputation, ad inventory? It keeps a seat.
Everything else becomes a skill.

The corrected seat test, with every tool from the lean stack placed by criterion — **Figure 4.** *The corrected seat test, with every tool from the post placed. The stack passes almost everywhere. The one empty row is the record.*

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

Common Questions

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

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

Can Claude Code replace Clay?

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

Should a GTM stack use MCP or direct APIs?

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

Do AI-native teams still need a CRM?

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

Which GTM tools should keep a paid seat?

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

Is per-seat pricing dead for GTM tools?

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

Discussion about this post

Ready for more?