GTM data architecture: the warehouse is the hub

The gtm-data-architecture skill at gtmskills.com, written by Rutger Katz of Neon Triforce, is a field manual for "GTM data architecture for revenue operators who are not data engineers," published MIT-licensed on GitHub. Two things make it worth notes. The content: the most concrete operator-altitude treatment of the warehouse-native argument I have read, with real thresholds and named anti-patterns. And the format: it ships as an installable skill for AI agents, content built to be loaded into an agent's context, with test and install buttons where a newsletter signup would normally be. These are my notes on it.

Why warehouse-native won, in three forces

The page's history section calls the current setup "3rd Age data architecture" and compresses it to a rule: "the warehouse is the hub. Tools do NOT maintain copies." Three forces did it. Cost: when data lived in vendor platforms, every tool copied customer records, and "zero-copy architecture (tools querying the warehouse live instead of syncing copies) cuts storage costs and eliminates sync delays." AI: every agent, "lead scorer, sales assistant, expansion predictor," depends on complete, fresh customer context, and "unified warehouse data means agents see the single source of truth." Speed: definitions living in code across five systems change slowly. The market numbers, quoted for what they are: "by 2026, 50% of large enterprises are replacing traditional packaged CDPs with composable, warehouse-native stacks," and "composable vendor growth hit 7.8% in January 2026, six times the 1.3% industry average." This is the third source in this collection to arrive at the same diagram, after Bain's architecture decision reached it from the boardroom and the readiness essay from the platform side; this one arrives from the RevOps trenches with reverse ETL bolted on, the activation path that pushes warehouse-computed scores back into the CRM where sellers live.

Put simply: one copy in the warehouse, tools querying it live, dbt models as the versioned middle, and reverse ETL carrying the computed scores back into the selling tools. Cost, agent context, and definition-change speed all pushed the same direction, and the CDP era is ending because of it.

The honest thresholds

The section most manuals omit is "When NOT to Go Warehouse-Native," and its numbers are unusually candid: "around 20 seats or sub-€1M ARR, warehouse-native ROI is often negative," and even at "around 100 seats or €5M ARR, staying CRM-native is intentionally slower," a legitimate choice rather than a failure. The skip-list is concrete: a small revenue team with no billing or product analytics, a single-CRM stack with nothing to unify, or high compliance burden with no data engineering capability. Above the thresholds, three patterns scale by size, each priced in effort: startup-to-scale-up at 4 to 8 weeks of deployment and a few analytics hours a week to maintain; a mid-market engine at 8 to 16 weeks with a small dedicated data team; and the enterprise agentic stack at 16 to 24 weeks with engineers, a governance lead, and a RevOps architect. Costed advice with a do-not-build zone is how you can tell a field manual from a pitch.

Put simply: below roughly twenty seats or a million in ARR, do not build this; the ROI is negative and CRM-native is correct. Above it, pick the pattern for your size and budget it honestly, weeks of build and named roles, not a transformation slide.

Four anti-patterns, four boring fixes

The failure catalog names its villains. Transformation sprawl: dbt models accumulating without owners or consumers, against which the page sets the best governance sentence in the piece, "every dbt model must have a documented owner and at least one known downstream consumer (a dashboard or reverse ETL pipeline). Orphaned models get deleted quarterly." The real-time obsession: event-triggered everything when nightly ingestion would do, deflated in one line, "a 1-hour-old lead score is plenty if it is correct," correctness beating latency wherever routing is the use case. The identity-resolution bikeshed: hand-rolling entity matching instead of buying it, spending the scarce engineering on the one problem vendors already solved. And the data-quality delay: deferring governance until after the warehouse ships, which converts every downstream model into a consumer of undocumented junk. The fourth is where the page connects to the agent era with the sentence that should frame every agentic roadmap: "agents amplify bad data."

Put simply: the stack fails through unowned models, real-time theater, hand-rolled identity matching, and deferred quality, and every fix is organizational rather than technical. The agent stakes sharpen all four: agents amplify bad data, so the plumbing debts come due the day the first agent connects.

A practitioner's read

I have built this architecture more than once, so a critique from the trenches belongs next to the notes. Where the page is right in ways consultants usually are not: the do-not-build thresholds are real, and the correctness-over-latency line deserves framing, because most "real-time" requirements dissolve the moment you ask who would act differently within the hour. Where I would push back. The maintenance estimate for the startup pattern, a few analytics hours a week, holds only until reverse ETL starts writing into a CRM that sellers actively edit; the moment computed fields and hand-edited fields share objects, you own a reconciliation problem the page never mentions, and it is not an hours-a-week problem. Buying the identity matcher is right, but the hard part is not the matching, it is the survivorship policy, which record wins, when merges unwind, who arbitrates, and that is judgment you cannot procure. The quarterly orphan deletion is the best governance line in the piece and it will not survive without a named ritual; a rule nobody runs is documentation. And the vendor numbers, 15 to 30 percent CAC reduction from the reverse-ETL vendor itself, should be read the way the page teaches you to read data: unowned, untested, and activated straight into a decision. Good architecture guide. Ship it with your own denominators.

Put simply: the thresholds and the latency skepticism are the real thing; the maintenance estimate ignores write-back reconciliation, the identity problem is survivorship policy rather than matching, orphan deletion needs a ritual owner, and the vendor stats fail the page's own data standards.

The medium is the message this time

The meta-observation deserves its own section. This content ships as a skill file, versioned on GitHub under MIT, designed to be installed into a GTM agent's context so the agent gives architecture advice grounded in it. Where datacontract.com buried machine-relevant content in a bundle no plain fetch can read, gtmskills.com inverts the choice: the machine is the primary reader, and the web page is the preview. That is a genuinely new publishing posture, and it carries a genuinely new trust problem, which the adminNote files under wrong: an installable skill inherits none of the guarantees the page demands of data. Nothing signs it, nothing versions an agent's copy against drift, nothing quality-gates the claims, including the vendor-supplied Hightouch numbers, before they become some agent's confident recommendation. The page that says "agents amplify bad data" is also, structurally, unverified data waiting to be amplified. The data-contract move, ownership, versioning, and testable quality on the artifact itself, is exactly what skill files will eventually need.

Put simply: the page's format is its most interesting claim: content written for agents first, humans second. What it lacks is what it preaches, a contract, ownership, versioning, and quality gates on the skill itself, because an installable claim is data too, and agents amplify it either way.