--- title: Centralize first. Buy the layer. Build the edge. description: "Why AI-native revenue teams centralize first, buy the context layer, and build their edge on top — co-authored with Kyle Norton, CRO of Owner.com." canonical: "https://vasco.app/case-studies/build-the-edge" --- # Centralize first. Buy the layer. Build the edge. *Co-authored by Kyle Norton (CRO, Owner.com) and Guillaume Jacquet (Founder, Vasco). 10 min read.* Most revenue teams ask whether to build or buy their AI. The more useful question comes first: is your AI centralized, or scattered. Get that right and the build-or-buy line draws itself — and the one piece of infrastructure that decides everything sits on the buy side. ## The scoreboard Owner.com runs an AI-native go-to-market. None of this came from buying more AI: - **4×** closed-won ARR per rep, vs competitors - **20×** ARR per dollar of AE comp - **2×** decision-maker connect rate - **$102K** ARR per outbound rep / month, up from $36K ## The argument in short Two decisions, in the right order. The first decided where AI lives in the org. The second decided what to build and what to buy — and where most teams put the wrong thing on the wrong side of the line. - **Centralize, or stall.** Decentralized AI spreads fast, then stops at the lower rungs. Nothing shared accumulates underneath it. - **Then draw one line.** Build the intelligence that is yours. Buy the infrastructure that is not. - **The context graph is infrastructure.** It runs all the time, takes specialist skill, and gives you no edge in the building. Buy it. - **The edge is what you put on top.** Your definitions, your ICP, your plan, your validated patterns, and the agents that run on them. - **The return is structural.** Accuracy, causality, and work you can delegate, on one layer every agent reasons over. **Is this you?** Past ~$10M ARR, three or more revenue systems, RevOps but no GTM data team. The decision is identical at $10M — size only changes how expensive the wrong call gets. ## Part 01 — Centralize, or nothing compounds Two operating models. One spreads literacy. The other compounds quality. - **Decentralized**: every rep and team builds their own AI. Literacy spreads fast. Quality stays uneven, and the org stalls at the lower rungs by design. - **Centralized**: a small team builds for everyone and delivers into the tools people already use. Quality compounds across surfaces, and the team keeps climbing. The split shows from the outside. Across go-to-market orgs: **47%** have zero agents in production, **89%** of agents never ship, only **2%** run more than twenty, and **53%** see no measurable return. BCG puts the profit gap between the least and most AI-mature orgs at 25 points. On the AI maturity ladder (L0 exploratory → L1 custom tools & prompts → L2 workflow automation → L3 infrastructure & leverage → L4 recursively improving), decentralized orgs climb on literacy and stall at L1–L2; centralized orgs built on one layer reach L3, then L4. (Source: Kyle Norton, RevStar Summit 2026.) Decentralization sounds like empowerment. A sales director handed Webflow's CRO an AI coaching tool the team had built. His reply was one question — "Are you on more customer calls?" The answer was no. Decentralized AI quietly turns your most expensive customer-facing people into part-time analysts. In the centralized model, reps do not run agents. They receive the output inside Salesforce or Slack and stay with customers. Centralization is the precondition. It is also where most teams stop, because they read it as an org-chart move. It is not. > Ask the same question in two parts of the company. Two numbers means two truths, whatever the org chart says. ## Part 02 — Draw one line Build your intelligence. Buy your infrastructure. Five questions tell you which is which: 1. **Uptime** — run around the clock, or fail and retry overnight? 2. **Uniqueness** — do you get something genuinely your own by building it? 3. **Engineering ROI** — what is the return on the engineering, over a real horizon? 4. **Reuse** — does it produce intelligence you reuse across surfaces? 5. **Edge** — does owning it give you an edge a vendor cannot replicate? Two worked examples: - **BUY: the dialer.** Up all the time, everyone needs the same one, terrible ROI to rebuild, no intelligence to own, no edge. Five buy signals. Owner did not build one. - **BUILD: pre-call research.** Runs overnight, market-specific signals, two weeks of engineering returned 85% more calls and 85% more opportunities, feeds CRM and coaching, no vendor builds it. Five build signals. So Owner built it. Infrastructure confers no edge in the building, so you buy it (dialer, data warehouse, the context graph). Intelligence compounds for you alone, so you build it (pre-call research, ICP & messaging, coaching & churn agents). The line is a boundary between two categories, not a dial you tune. ## Part 03 — The layer you buy: the context graph A central team and a shared layer are different things. Without the layer, centralized AI is a slide, not a system. That layer has a name: a **context graph** — your data foundation and your semantic layer, built so an agent reasons across them as one structure instead of querying systems in isolation. It does five things, each resting on the one before it: - **Identity** — one person, one account across CRM, calls, billing, and product, with a record of why two records were judged the same. - **Timeline** — every call and event placed in the account's journey, so the agent reads *why* it moved, not only that it did. - **The plan** — targets held in the layer, so "on track" has a number to check against. - **Outcome memory** — every deal tagged won, churned, expanded, or stalled, checked against billing. The graph knows which patterns led where. - **Causality** — a competitor named on a March call linked to the velocity drop two weeks later. - Plus a **semantic layer**: pin the definition of "pipeline" once — no-code, owned by RevOps — and every dashboard, workflow, and agent uses the same one. The harder question is who can change it. GTM moves faster than a data team can ship. A new motion, a channel, a reorg, a fresh signal: each one rewrites a definition, monthly not quarterly. Route every change through a data ticket with a one-to-two-month turnaround and your definitions are stale most of the year. So the semantic layer has to be no-code and owned by RevOps, where the judgment already lives. **What the absence looks like:** a team had HubSpot, Gong, Stripe, and Slack wired to an agent through MCP. They asked how the pipeline looked. The answer came back with no hedging: stable, on track. They were 21% below target. Nine deals untouched for thirty days. A recorded call had a prospect saying the budget was frozen — it never reached the deal it belonged to. A live account that had already cancelled payment in Stripe still showed as healthy, because the billing record and the CRM company were not the same entity to the agent. Read the full case study: [Claude Cowork is impressive — the infrastructure it assumes you have](/case-studies/claude-report). > A number that does not survive scrutiny does not lose the slide. It loses the room. Access is not architecture. Four connected pipes are still four pipes. Run the context graph through the same five questions. Every answer says buy: - **Uptime**: up around the clock. An alert fires on it. - **Uniqueness**: none. Identity resolution works the same for everyone. - **Engineering ROI**: poor. A first version takes 12–18 months, then drifts the day a source changes its schema. - **Reuse**: constant, but identical for everyone. Shared plumbing, not a differentiator. - **Edge**: zero. Owning the plumbing wins nothing. Under the visible case sits a quieter one that rarely makes a slide and always makes the bill: governance, security, and access control, then performance and cost. Identity has to stay auditable. Data has to respect who is allowed to see what. And the way the graph reads your sources decides both your latency and your spend. Pour every transcript in raw, with no optimization, and you get three problems at once: **slower answers** (every query drags more tokens through the model), **hallucinations** (footer-and-filler noise crowds the signal, so the model fills gaps with confident guesses), and **a 10× AI bill** (unoptimized extraction can multiply token spend by an order of magnitude). You buy the substrate, then author the rules on top of it. The graph does not replace the tools you run — it sits above them and reads from them: seven systems (CRM, call recorder, email, Slack, product, support, billing) reconciled into one account, then the timeline, stakeholders, signals, outcome memory, and causal links the agent reasons across. ### Why Vasco, not just "a context graph" Vasco is the context layer — the GTM context graph Owner runs — purpose-built so your agents reason on grounded revenue data, not inferences. > "It is the line we already draw. We buy our GTM context graph, Vasco, so we can build our agents on top." — Kyle Norton, CRO, Owner.com - **GTM-native** — identity, stages, and outcomes modeled for revenue, not a generic CDP schema you bend into shape. - **Outcome-tagged** — every deal reconciled against billing, so won, churned, and expanded are facts, not CRM guesses. - **No-code layer** — RevOps changes a definition in hours. A dbt build changes it in a sprint. - **Cost-optimized** — extraction tuned so transcripts and threads do not 10× your token bill or your latency. [Book a 30-minute demo](/request-demo) · [Start for free](https://my.vasco.app/get-started) ## Part 04 — Build the edge: what it returns On a bought layer, you build the parts that compound for you alone, and the agents that run on them: - **Deal coaching** — every deal inspected against the patterns that won before, not a 5% manager sample. - **ICP & messaging** — tuned to a scored profile, drafted to land. - **Churn detector** — usage and sentiment decline read before the renewal date. - **Whitespace** — upsell signals surfaced from the account graph, not found by hand. Building carries one discipline. Accuracy multiplies down a chain, so four steps each 95% reliable produce an answer that is 81% reliable. Ten steps at 80% collapse toward 10. The fix is generative work inside a deterministic frame: you define positioning and ICP, the AI drafts inside it, and you read the outputs until they hold. No evals, no program — today only 37% of teams run them, which is most of why 53% see no return. A worked example — a 10pm question: "Why did demos booked in the Northeast drop 18% this month?" The graph traces it, it does not guess: demos booked down 18% in the Northeast, flat everywhere else; the drop is entirely inbound; paid-search MQL volume held flat, so it is not top-of-funnel; MQL-to-demo conversion fell from 22% to 9% on one campaign; that campaign's landing page changed on the 6th, and form routing broke. Five whys, one query, every number sourced. You fix it tonight, not at the QBR. The org metrics move with it. Manager span goes from **1:5 toward 1:10**, because an agent inspects every deal and surfaces the ones that need a person. Reps go back to customers. The number a CFO pulls matches the number a rep pulls, because both query the same layer. For a $50M business, built lever by lever, the impact runs to roughly **$5M–$9M of ARR a year** before efficiency gains — illustrative, your inputs move it; the point is the order of magnitude. ### Where to start — four moves for a VP of RevOps 1. **Centralize ownership** under one AI-fluent leader, with a small team that builds for everyone and delivers into existing tools. 2. **Put the context layer in place first**, before any customer-facing automation, with the semantic layer no-code so RevOps owns the definitions. 3. **Buy the substrate, build the rules.** A vendor keeps identity resolution and maintenance running. You author definitions, ICP, plan, and validated patterns. 4. **Sequence the build.** Data foundations first, internal copilots next, customer-facing AI last and only with guardrails. ## The layer underneath The agent will keep answering with confidence. Whether it is earned depends on the layer beneath it. Vasco resolves identity across your sources, rebuilds the account timeline, holds the plan, and remembers outcomes — with a semantic layer your RevOps team owns without code. You author the rules. Vasco keeps the layer running. Start with the test: ask your own AI for your pipeline status, then peel it three layers down and watch where it breaks. - [Book a 30-minute demo](/request-demo) - [Read the Claude field report](/case-studies/claude-report) ## About the co-author Kyle Norton runs revenue at [Owner.com](https://www.owner.com), the vertical AI platform for independent restaurants, and the AI-native go-to-market behind the numbers in this piece. He also hosts [The Revenue Leadership Podcast](https://www.therevenueleadershippodcast.com/), where real revenue operators break down the frameworks they actually run. New episodes weekly.