Kyle Norton, CRO at Owner.com, is direct about how his team builds with AI. He centralizes AI builds inside a dedicated applied AI team because he doesn't want reps vibe coding their own tools on the side of their desk. In his framing on the Revenue Leadership Podcast, the applied AI team exists so that sales managers can focus on hiring and coaching, and so that the company captures compounding value from builds rather than scattering it across individual rep experiments. Owner runs a transactional SMB motion with a heavy investment in third party and first party data, and the centralized model has produced measurable results. Kyle has publicly cited a two times improvement in connect rates and three times booked revenue per dollar spent on a per AE basis compared to any team he has previously managed. Everett Berry, Head of GTM Engineering at Clay, built a different structure. Clay's GTM engineering function splits into two teams. Forward deployed GTM engineers work directly with customers on implementation. Internal GTM engineers, operating under Osman Sheikhnureldin, build and maintain the automation that powers Clay's own sales motion. That internal team runs in two week sprints, takes tickets from across the business, and ships twice a month with release notes. It operates like product engineering, with version control and explicit prioritization. And notably, Clay lets individual reps use whatever meeting tools they prefer, Granola, Attention, Gong, whatever fits their personal workflow. There is one hard requirement. The data has to flow into Clay, where the internal team can transform it. Experimentation happens at the edge. Standardization happens at the data layer. Both companies reject the default that most RevOps leaders are watching unfold inside their own organizations right now, where every AE spins up personal projects in Letter AI, Claude, Gumloop, Cursor, and whatever else landed in their inbox this quarter. Both models produce strong outcomes. They look different in practice. The question worth answering is which model fits which kind of company, and what governance looks like when experimentation is the point.

Why the default is chaos

Accessibility collapsed the barrier to building. A seller with a browser, an email address, and a credit card can ship a working workflow in an afternoon. They can connect it to a CRM through OAuth, feed it transcripts from their calls, and start sending outputs to prospects before anyone in IT knows it exists. That is genuinely new. The last time RevOps faced something comparable was when sales engagement platforms gave every rep the ability to write their own sequences, and the governance lessons from that era mostly got ignored. The consequences compound quickly. Duplicate work shows up across teams as three different AEs build three different versions of an account research workflow, none of which talk to each other and none of which reuse the good parts. Prompts touch CRM data without review, which means sensitive account information, competitor intelligence, and deal terms flow through services no one has evaluated. OAuth tokens persist long after the experiment ends, creating non human identities with persistent access that nobody is tracking. And none of it connects to outcomes, which means when someone asks whether any of this AI work is driving revenue, the honest answer is that nobody knows. The scale of the problem is now documented. Rubrik's 2026 Zero Labs research found that 86 percent of respondents expect AI agents to outpace their organization's security guardrails within the next year, and only 23 percent claim full visibility into the agents operating in their environments. Okta reports that 80 percent of organizations have already experienced unintended agent behavior. IBM's Cost of a Data Breach report found that shadow AI now accounts for 20 percent of all breaches and adds roughly $670,000 to the average incident cost. Gartner predicts that 40 percent of enterprise applications will feature task specific AI agents by the end of 2026, up from less than 5 percent at the start of 2025. That is not a security problem RevOps can punt to IT. Agents in the GTM stack touch deal data, customer communications, and pipeline. When they misbehave, they do it inside the revenue engine.

RevOps is on the hook whether the charter says so or not.

Three operating models

Three operating models are emerging for how companies structure AI in GTM. Each has a real example, a set of conditions where it works, and a failure mode that tends to show up when the conditions change. The first is pure centralization. A dedicated applied AI or GTM engineering team owns every build. Sellers submit requests, describe use cases, and consume what the central team produces. Owner is the clearest public example. The conditions that make it work are specific. Owner runs a high volume SMB motion with a relatively uniform ICP, which means use cases are shared across reps rather than highly idiosyncratic. The company invested early in third party and first party data, which gives the central team a foundation to build on. And Owner had the talent density to staff a dedicated applied AI function, which most companies do not. Where pure centralization breaks is when the motion becomes more varied, when sellers have legitimate domain knowledge the central team lacks, or when the central team becomes a bottleneck and reps go build in the shadows anyway. The second is pure federation. Every team, and often every individual seller, experiments independently. There is no central registry, no shared infrastructure, no vetting, and no attribution back to outcomes. This is what most companies land in by accident. It is the model the Slack thread that started this piece was describing. A small amount of federation is productive, because domain experts closest to the problem often have the best ideas. A lot of federation without any connective tissue produces exactly the traffic intersection metaphor that senior operators keep reaching for. Work duplicates, good ideas die with the person who built them, risk accumulates, and leadership cannot answer basic questions about what is running or what it is producing. The third is hub and spoke. A central team owns infrastructure, standards, the approved skill library, observability, and attribution. Business units and individual builders own use case discovery, domain knowledge, and iteration within the boundaries the hub defines. Clay is a hub and spoke organization. Zapier, based on what Lindsay Rothlisberger has shared publicly about their approach to AI skill governance, is evolving toward the same structure. Dataiku's research across its customer base found that companies that successfully scale AI are three times more likely to use hub and spoke than any other structure, and Microsoft's Cloud Adoption Framework explicitly recommends that mature AI organizations transition from centralized center of excellence models to advisory groups that set guardrails while frontline teams own delivery.

Hub and spoke is not a compromise between the other two. It is a different architecture that treats central control and distributed experimentation as complementary rather than opposing forces. The hub makes experimentation safer and cheaper. The spokes make the hub's work relevant to what sellers actually do.

A decision framework

Five factors determine which operating model fits a given company at a given stage. Growth stage, motion complexity, data foundation, internal AI fluency, and risk tolerance. Growth stage matters because the right structure at 20 reps is wrong at 200. Early stage companies with a small GTM team and a single motion can run pure centralization successfully, because one or two builders can cover the surface area. Once the team grows past roughly 50 GTM headcount or splits into multiple segments, centralization starts to create queue time, and queue time pushes builders underground. Motion complexity is about how much variation exists across deals. A high velocity SMB motion where every deal looks similar rewards centralization, because the same workflow serves many reps. A mid market or enterprise motion where every deal has unique stakeholders, procurement dynamics, and technical requirements rewards federation, because the seller knows things the central team cannot possibly capture in a generic workflow. Data foundation is the precondition Kyle Norton emphasizes before any of this matters. If the CRM is a mess, if call transcripts are not captured systematically, if account data is not enriched consistently, no operating model will save the company. Centralization is particularly hard without a data foundation, because the central team spends all its time fixing data quality instead of building. Hub and spoke works better in this environment because the hub can focus specifically on the data layer while spokes build on top of it. Internal AI fluency determines how much guardrailing is needed. A company where most sellers have genuine AI fluency, can write usable prompts, and understand what a model is doing can run with lighter central control. A company where AI fluency is concentrated in a handful of people needs more centralization, not because federation is philosophically wrong but because most people cannot safely build alone yet. Risk tolerance is the last factor. Regulated industries, companies with sensitive customer data, and organizations with active compliance exposure cannot tolerate federation. The risk surface is too large. Companies with less regulatory exposure can absorb more experimentation in the spokes, because the downside of a bad prompt is smaller. A decision that feels ideological, centralized or federated, becomes empirical once these factors are laid out. Most mid sized SaaS companies with mixed motions, reasonable data, patchy AI fluency, and moderate risk exposure end up at hub and spoke. That is not a coincidence. It is what the factor analysis produces.

The governance control plane

The phrase agentic governance layer has been floating through RevOps conversations for months without a clear definition. The practical answer is a governance control plane with four concrete layers, and each layer has a specific owner and a specific output. The first layer is a registry. A skill, prompt, and workflow registry that captures what exists, who owns it, what systems it touches, what data it handles, and what vetting status it has. This is the inventory problem. Anthropic shipped Skills in October 2025 as a way to package reusable workflows, and enterprise customers can now provision skills across an organization. The MCP registry pattern is doing the same thing for tool connections. These are registry primitives RevOps can adopt. The output of this layer is a living document that answers the question: what AI workflows are running in our GTM stack right now, and who owns each one. The second layer is identity and access. Agents operating on behalf of sellers need scoped permissions, not the seller's full CRM access. Okta and Frontegg have both published patterns for treating agents as first class identities with their own credentials, validity windows, and revocation paths. In a GTM context, this means an AE's account research agent should not have write access to the pipeline, a marketing agent should not have access to individual deal data, and every agent should have a revocation path when the experiment ends. The output of this layer is that every AI workflow has a scoped identity and a clear off switch. The third layer is observability. Fiddler, Kore.ai, Dynatrace, and IBM have all shipped agentic observability products in the last 12 months that capture traces, tool calls, decision flow, latency, cost, and output quality. RevOps does not need to build this from scratch. What RevOps does need is to connect the observability data to something sellers and leaders actually care about. A dashboard that shows which workflows are running, how often, with what error rate, at what cost, and with what downstream effect on deals. The output of this layer is a running picture of what AI is doing inside the GTM engine. The fourth layer is attribution. This is where the governance conversation connects to revenue and where RevOps has a natural advantage. Attribution asks whether the workflow that researches accounts is actually producing better meetings, whether the agent that drafts follow ups is producing better response rates, whether the skill that summarizes calls is producing better next steps. Without attribution, AI in GTM is a cost center that nobody can defend. With attribution, it becomes a measurable input to pipeline and revenue. The output of this layer is a feedback loop from workflow to outcome that tells leadership which investments to scale and which to retire. Those four layers together are the governance control plane. None of them exist in isolation. The registry feeds the identity layer. The identity layer feeds the observability layer. The observability layer feeds the attribution layer. A company that builds all four in sequence has an operating system for AI in GTM. A company that builds only some of them has fragments.

What the hub owns versus what the spokes own

The clearest way to make hub and spoke work in practice is to draw a sharp line between what the hub controls and what the spokes control, and then stick to that line even when it is tempting to expand central authority. The hub owns infrastructure, standards, the approved skill and workflow library, the observability platform, the attribution model, and security. These are the pieces where consistency matters more than domain knowledge. Nobody needs three different observability platforms, and nobody needs a skill library that is different in sales versus customer success. The spokes own use case discovery, domain knowledge, adoption, iteration, and advocacy. These are the pieces where proximity to the problem matters more than central control. A sales manager running an enterprise team knows what a good multithreading workflow looks like. A demand gen lead knows what account scoring signals actually predict intent. Pulling that knowledge into the hub and rebuilding it centrally loses the nuance that made it valuable. Clay's approach captures the spirit well. The internal GTM engineering team maintains the core infrastructure, which is Clay, Snowflake, Salesforce, and Gong, and the Slack app that GTM engineers interact with most of their work through. But when it comes to individual preferences around meeting tools or note taking, the team explicitly declines to dictate. The rule is that the data flows back into the central system. The method is up to the person. That is the operating principle that makes hub and spoke work at scale. The hub is strict about the things that need to be consistent and generous about the things that do not. When the line gets blurred, two failure modes show up. If the hub claims too much territory, queues form, builders go underground, and the hub's approval process becomes the bottleneck it was designed to prevent. If the spokes claim too much territory, the registry falls out of date, observability goes dark, and the attribution model breaks. The operating model depends on both sides respecting the boundary.

A phased rollout

Most companies cannot move from the current chaos to a mature hub and spoke control plane in a single quarter. The transition takes staged work across four phases, and the phases should not overlap because each one depends on the one before it. Phase one: discover and inventory. The first job is to build the registry. Run a structured discovery across sales, marketing, customer success, and RevOps to identify every AI workflow, skill, agent, and prompt that is currently in use. This includes workflows built in Zapier, n8n, Gumloop, or similar platforms, skills created in Claude or ChatGPT projects, and agents deployed through any vendor tool. The goal is not to approve or reject anything yet. The goal is to produce a complete picture. Expect this to take three to six weeks and to surface more work than anyone expected. Phase two: vet and publish. Once the inventory exists, start vetting. Use a lightweight scorecard that evaluates each workflow on five dimensions: data sensitivity, business criticality, usage volume, demonstrated value, and risk surface. The top workflows get promoted into an approved library with documented ownership, usage guidelines, and enablement. The bottom workflows get deprecated. The middle ones go into a sandbox tier where experimentation continues but with observability turned on. Publish the library in a place sellers will actually look. Zapier's approach of running a dedicated Slack channel plus a shared folder of approved skills is a reasonable pattern. Expect four to eight weeks for the first vetting pass. Phase three: instrument. With a library in place, turn on the observability and attribution layers. Pick three to five workflows that matter most and instrument them end to end. Capture usage, quality, cost, and downstream effect on deals. This is where RevOps earns back the visibility that got lost during the experimentation phase. It is also where the business case gets built, because attribution data will show which workflows deserve more investment and which need to be retired. Expect this phase to run continuously once started, but the first wave takes roughly a quarter. Phase four: evolve from gatekeeper to advisory. The final phase is where the hub changes posture. Early on, the hub has to be a gatekeeper because standards, tooling, and skills are still being established. Once those foundations exist, the hub should move toward an advisory role that sets guardrails and enables spokes to build within them. This is the Microsoft Cloud Adoption Framework's explicit recommendation, and it matches what Clay, Zapier, and other mature organizations have actually done in practice. The shift is hard for hub leaders who have spent months building control, but it is the move that prevents the hub from becoming the next bottleneck.

Common failure modes

A few failure modes show up often enough to be worth naming. Over centralization that produces bottlenecks and pushes sellers back underground, which reproduces the original problem under a different name. Under governance that announces a policy without building the infrastructure to support it, which is the cheapest and most common failure because a policy document takes a day and a control plane takes a year. Tools without standards, where the company buys an observability platform or a governance product and expects the tool to do the work that only an operating model can do. And standards without attribution, where the hub publishes rules but cannot prove that any of the approved work is producing revenue, which makes the whole function politically vulnerable the first time a CFO asks what it costs and what it produces.

What RevOps should actually do this quarter

The governance conversation tends to drift into abstraction, so here is the concrete version. Run an inventory of every AI workflow in the GTM stack in the next three weeks. Start a channel where sellers can share what they are building, because visibility follows contribution. Vet the five highest volume workflows against a simple scorecard and publish the approved versions in a shared space. Instrument one workflow end to end so there is at least one real attribution example by the end of the quarter. Publish the operating model even if it is incomplete, because an imperfect published model produces better behavior than a perfect unpublished one. The reason this falls to RevOps rather than IT or enablement is that every layer of the control plane maps to something RevOps already owns elsewhere. The registry is an extension of the tech stack documentation RevOps already maintains. The identity layer is an extension of the CRM permissions model. The observability layer is an extension of the pipeline visibility work RevOps has done for years. The attribution layer is the core RevOps competency, applied to a new input. None of it is unfamiliar territory. It is the familiar work applied to a surface that has grown faster than the function has adapted. The organizations getting this right are not choosing between control and experimentation. They are building the hub that makes experimentation productive and the spokes where experimentation actually happens. Kyle Norton's centralization and Everett Berry's engineered GTM function are two points on the same trajectory, one further along than the other, both heading toward the same place. The companies still stuck in the traffic intersection are stuck because they have not yet built the operating system that makes the intersection legible.