Walk into any KPI review meeting right now and count the artifacts.
Everyone's got one. Their own AI-generated view, their own confidently formatted summary, their own number for the exact same metric. The AI told each of them a slightly different story that afternoon, and it told all of them beautifully. Grammatically flawless. Completely sure of itself. Oftentimes, quietly, wrong.
We've all seen this movie. It played for years before anyone said the word "AI" in a leadership meeting, and it was called DIY CRM reports.
Before we lock governance into place, everyone can build their own report off their own filters. So they do. Marketing has one MQL number. Sales has another. Finance has a third, and every one of them is convinced the other two are either incompetent or lying.
I sat in the meeting where the VP of inside sales openly accused the CMO of inflating their MQL number and pipeline credit. Then I spent precious cycles doing forensic accounting on discrepancies instead of building a better definition of an MQL.
The worst part wasn't the wasted time. It was the impact on trust. Once a team decides the numbers can't be trusted, they stop trusting each other.
So no, agent sprawl doesn't scare me because it's new. It scares me because it's familiar, and now it moves at machine speed.
"AI is your most confident, most incompetent colleague." – Shantanu Shekhar, VP of RevOps at Personio
Scaling AI is not a technology problem. It's an architecture problem, and RevOps owns the architecture. You get to decide, over the next few quarters, whether you're the architect who drew the blueprint or the cleanup crew that mops up after everyone else. You need a strong data foundation to scale anything, let alone AI.
Let's talk about how to be the architect.
While editing the London RevOpsAF session "AI in RevOps: Force Multiplier or Chaos Generator?" presented by Shantanu Shekhar, VP of RevOps at Personio, and Paddy Hanley, Principal GTM Engineer at Personio, the most useful line I heard came from Paddy, framing how their teams actually think about a build: data, then reasoning, then outcome.
Most of our GTM end users start at the end. They bolt a model onto whatever they've got, and then act shocked when the reasoning hallucinates. It hallucinates because the data underneath it is broken. Fast answers, very wrong, at scale.
That sequence is the whole game, and it's why I've been building on a framework I very slightly modified from Sandy Robinson called SAGES.
Sandy Robinson's SAGE is Standardize, Architect, Govern, Evolve. Sandy is VP of RevOps and GTM Enablement at Quavo Fraud and Disputes, and she laid it out in her RevOpsAF London keynote. I extended it to SAGES by adding one letter, Sanction, for the organizational decision layer that governs what AI is allowed to do at scale. (I unpacked the full framework in a previous piece.) The short version that matters for scaling:
Behavior, process, and data all come before you pick a system. Tools live dead last in the SAGES sequence. The Personio operators put it plainly: if you can't articulate the process, if the behavior change isn't clear, if the data isn't clean, fix those things first or fail.
If you take nothing else from this article, take the order of operations. Everything below is a consequence of getting it wrong.
Shantanu and Paddy shipped a real AI project: a tool that auto-generated handover briefs so new customers didn't have to reintroduce themselves to the implementation team. Fill rates went from around 40 percent to 75. A genuine win, and they were refreshingly honest on stage about what it cost them to learn. Three failure modes, and I've lived all three in one form or another.
They bought before they defined the problem.
This is the oldest trap in ops, and AI has made it worse because the demos are dazzling, but too often it’s something that’s glued together right before the call or a demo of a brilliant way to solve a problem you don’t actually have. The fix isn't a better vendor. It's writing down what you're solving for before you ever take the call.
They threw it over the wall.
When and how you launch matters. Because Q4 was upon them, they launched the tool with a Slack post and forgot to circle back once things had quieted down on the sales floor. A Slack post is not change management. Nobody changed their workflow because nobody was asked to. The tool worked; the adoption didn't happen.
They automated on top of data ambiguity.
When the underlying data was thin, the model filled the gap with a confident guess and shipped it to 300 customer-facing reps at once. Remember, AI is a confident, incompetent colleague, now operating at scale. Mess scales, fast.
So what about the most tempting escape hatch, "just don't build anything yet"? I'll push back, because "do neither" is rarely a true option, and pretending it is will get you a very angry GTM team.
If you're a small org, the right move may be letting your SDRs and AEs play with AI, as long as they've got no direct pipe into your core systems. Let them experiment in a sandbox that can't write back to the source of truth. But you control your core systems, and that means if you need to delay a real integration while you build the right architecture, that is completely fine.
One condition. You have to actually be working, and you have to be communicating the progress.
"Not yet" while you're visibly building the foundation is strategy. "Not yet" in silence is how RevOps teams get overrun.
If you’re quiet about progress, your sales leaders will assume you're the bottleneck, find a way to bypass you altogether (typically à la the corporate credit card), and stand up their own shadow stack. By the time you notice, the coup already happened. You can delay, but do it with a roadmap and a status update. Never delay in the dark.
Shantanu and Paddy's RevOpsAF London session gave me the cleanest governance model I've seen for scaling AI: ideas flow up, standards flow down.
It runs on three tiers:
This is exactly where I'm spending my energy right now, and I'll be specific about the moves because abstraction doesn't help anyone.
I locked reps out of the direct HubSpot connector for Claude in the app marketplace. Full stop. Not because I'm anti-AI, but because a connector that inherits a user's permissions and strolls right past the validation guardrails your UI enforces is a direct line from an eager rep to a corrupted system of record. That's Sanction in the wild: the organization deciding, out loud, what AI is and isn't allowed to touch at scale.
Then I started defining a data dictionary in Petavue that documents every key metric, in writing, so the logic lives somewhere other than my own head. Then we'll connect it to Claude through Petavue's MCP server, so everyone pulls numbers built on those definitions. This is the S in SAGES, Standardize, done properly.
The dangerous reports that created chaos in the C-Suite were never the ones tied to a meticulously maintained calculation. They were hidden filters and date logic baked into a report years ago, working perfectly until an LLM started reading the field directly and confidently misinterpreting it. If it isn't documented, it isn't a standard, and no one can be blamed for doing the “wrong thing” when pulling their own numbers.
The last piece of the review process is a verified register, which Personio calls a GTM AI hub. A tool earns a badge only after rigorous testing, so reps can easily see what the ops team vetted. Build the equivalent. The badge is how you scale trust instead of scaling chaos.
Here's the letter everyone skips, because it isn't a purchase order. It's the Evolve in SAGES, and it's the part that determines whether any of this survives contact with real humans.
Start with behavior, not with the tool. Before you roll anything out, answer the only question your team actually cares about: what's in it for me? Every affected role needs its own answer. Your new-business reps, your BDRs, and your post-sales team are not living the same day, and post-sales in particular tends to gain the most from AI, so don't hand all three the same generic pitch and hope.
Then name the owner. "The team will start doing this" is not a plan; it's a hope. Somebody specific owns the new motion, or it belongs to no one.
And do the thing almost everyone forgets: tell people what to stop doing.
When you hand a rep a new AI workflow without explaining what’s in it for them, they assume you’re asking them to do yet another thing they never asked for, and they quietly ignore it. Teach them the new motion AND the four old things they can stop doing because of it. Get them out of the manual account research. Get them out of living inside Salesforce all day. Give them the new tool and give them back the time, in the same breath.
The key to adoption isn't a mystery. It's improving their current state.
The steel-brick CPQ decision you made eighteen months ago is one you're still living with today. Similarly, the AI architecture decisions you make this year are the same kind of decision, except the blast radius is bigger and the ground is moving faster.
RevOps can invent what governed, scaled AI looks like inside a company. We have the tools to build the foundation, lock the source of truth, sanction what's allowed, and enable the team.
In other words, you get to choose whether you architect the gold standard or spend the next few years explaining for the hundredth time why the numbers don't match.
Credit where it's due. The ideas-up-standards-down model and the tactical framing in this piece come from a RevOpsAF London session by Shantanu Shekhar, VP of RevOps at Personio, and Paddy Hanley, Principal GTM Engineer at Personio. SAGE is Sandy Robinson's framework, extended here to SAGES.
