Podcast
June 17, 2026
Episode 96: The Rise of the RevOps Architect
AI agents can't touch your CRM — and that's a RevOps problem to solve. Ed King explains the control layer operators must build to make AI actually work.
Most AI projects aren't failing because the technology is broken. They're failing because nobody built the layer that makes the technology safe to use. That gap — between what AI agents can theoretically do and what they're actually allowed to touch — is precisely where the next generation of revenue operations work lives.
In this episode of RevOpsAF, Ed King, CEO and Founder of Openprise, joins co-host Matthew Volm for a conversation that reframes the entire AI-in-RevOps discussion. Ed's perspective is grounded in what he's actually seeing across medium-to-large enterprise customers — not what the vendors are promising — and his background in security adds a dimension to the AI conversation that most operators never hear. The episode builds toward a clear argument: the operators who thrive in an agent-driven future won't be the ones who know the most tools. They'll be the ones who think like architects.
The question Matt opens with is the one most RevOps leaders are quietly wrestling with: why, given all the investment and all the hype, are so many AI initiatives still stuck in demo mode?
Ed's answer starts with a data point that reframes the whole conversation. Based on Openprise's observations and reinforced by published research, roughly 65% of what gets called "AI projects" today falls into two categories: content generation and essentially replacing search — web crawling, data collection, personalization inputs. Another 30% covers analytics, recommendations, and planning. The last 5% is where agents are actually doing something: calling out to existing infrastructure and taking action.
"We haven't seen a single instance where the agents is allowed to actually update core system records like CRMs, marketing automation platforms — not a single one."
— Ed King
That observation is worth sitting with. The most capable AI systems in production today are being deliberately kept away from the systems that matter most. This isn't a technology limitation — it's a governance reality, and it's the primary reason AI projects can't graduate from pilot to production.
On the rare occasions where agents do connect to backend systems, Ed notes that IT typically steps in to create an intermediate layer using traditional middleware. For anyone who's spent time in ops, that phrase lands with appropriate weight. As Ed puts it, "for any ops folks, that's a slippery slope to go down."
The reason IT and InfoSec won't allow agents direct access to core systems isn't irrational caution. It's a legitimate response to how large language models (LLMs) actually work. Hallucination, Ed explains, is a feature of the technology — not a bug — and it hasn't materially improved in five years. Some academic studies suggest it's gradually getting worse.
"When it comes to execution, people only want deterministic execution. Nobody wants probabilistic execution. When you want something done, you want it done."
— Ed King
The implication here is direct: the architecture of AI agents is fundamentally probabilistic. The architecture of enterprise go-to-market systems demands determinism. Something has to bridge that gap, and that something is what Ed calls the control layer.
At a high level, the control layer does three things: it handles security and identity management, it prepares data for agents to use, and it creates the tools agents need to transact against backend systems without touching them directly. For the RevOps audience, the security piece is largely IT's domain. The second and third components — data preparation and tool creation — are squarely ops territory.
This connects to a broader challenge that Episode 92: Why AI Agents Need RevOps explored in depth: the accuracy problem in AI-driven revenue work isn't about model quality. It's about whether the data agents reason on has been properly prepared and structured. Ed's framework arrives at the same conclusion from a different angle.
The data preparation component of the control layer is where Ed gets concrete, and his example is one that will be immediately recognizable to anyone who's spent time in a CRM.
"I ask people, 'How many people do you think in your company that can answer the question of who are my customers for the last 12 months?' There's usually less than a handful of people that can answer that question properly. Oh, by the way, they need to go work on it for probably at least a day."
— Ed King
The problem isn't the question — it's the schema. Most CRM implementations were never designed to answer simple business questions directly. They've accumulated custom fields, custom objects, inherited logic, and workarounds that only a small group of institutional-knowledge holders can navigate. Asking an AI agent to reason on that raw data and produce reliable answers is, Ed argues, close to impossible for large, complex enterprise environments. And even if the agent could figure it out once, having it rederive that logic on every query burns tokens, slows performance, and produces inconsistent results.
The solution is a data catalog: a curated set of clean, purpose-built datasets that ops teams create and maintain. Instead of exposing the full CRM schema to the agent, you give it a table called "Customers" with twenty relevant fields and a clear definition. The agent doesn't need to know you're a Salesforce shop, or that someone bastardized the account object, or that there are six custom fields nobody remembers creating. It just queries the dataset.
This approach has an important secondary benefit that Matt surfaces during the conversation. The same data catalog that makes AI more reliable also makes the lives of human team members substantially easier. The answer to "where do I find our customer list?" stops being a five-step CRM tutorial and becomes a single URL. That's a quality-of-life improvement that's valuable independent of any AI initiative.
For operators thinking about where to start building this catalog, Ed's guidance points back to use cases. The goal isn't to create bespoke datasets for every team's specific workflow — it's to identify the common data needs that cut across marketing, sales, events, content syndication, and other motions. ABM accounts, white space accounts, customers: these are the reusable building blocks that power multiple agent use cases without requiring constant rebuilding.
The second component of the control layer addresses what happens after an agent has done its analysis and needs to take action. If IT won't allow direct API calls to Salesforce or your marketing automation platform (MAP), how does the agent actually get anything done?
The answer is purpose-built tools — essentially a curated set of custom APIs or MCP (Model Context Protocol) servers that wrap your backend systems in controlled, predictable interfaces. Instead of an agent calling Salesforce directly, it calls a tool named "create campaign" or "update campaign status." The tool handles the actual system interaction, enforces data logic, validates naming conventions, and manages workflow transitions. The agent never touches the raw API.
"All the stuff that requires no intelligence, you really don't wanna waste the time, bandwidth, and cost and effort to have AI do it — and also get worse results at the same time."
— Ed King
The logic here is clean: AI is good at reasoning and decision-making. It's not good at reliably enforcing business rules, campaign naming conventions, or funnel stage logic. By moving that enforcement into the tool layer, you get the best of both — AI handles the judgment calls, deterministic code handles the execution rules.
Collectively, the data catalog and the toolbox become what Ed describes as an abstraction layer: a set of interfaces that completely hide what your backend looks like. Whether you're running Salesforce or Dynamics, whether your schema is clean or chaotic, the agents see the same clean set of datasets and tools. A single well-designed toolbox of 20-30 items, Ed suggests, can support most of an enterprise's agent use cases without requiring constant customization.
This is the section of the conversation where Ed makes his most direct argument about the future of the RevOps function — and where the implications are biggest for operators thinking about their own career trajectory.
The shift he's describing isn't just about learning new tools. It's a fundamental reorientation in how ops practitioners think about their work. The historical RevOps model was point-solution-centric: expertise in specific tools, point-to-point integrations, workflow configuration. That model worked in a world where humans were the only consumers of the systems ops built.
In an agent-driven world, the mental model has to shift from applications to infrastructure. Ed draws an explicit analogy to a transformation IT went through decades ago, when the discipline moved from managing individual systems to building service-oriented architecture (SOA) — standardized, reusable services that different systems could consume. Out of that shift emerged the role of enterprise architect: someone who thinks about the whole system, not individual applications.
"The most successful people that's gonna set themselves up to be in-demand for the next three to five years — it's the ones that's gonna successfully transition themselves away from, 'I'm an expert in product one, product two, product three.' You really have to be able to come in and say, 'It's my job to understand what a business needs. It's my job to understand what infrastructure we have. How do I look at this as a system?'"
— Ed King
This connects to a theme Episode 94: The Boring Work Behind Great AI explored from a different angle: the RevOps practitioners building durable AI value are the ones doing the foundational systems thinking that less strategic operators skip. Ed's framing gives that observation a name and a shape — this is the enterprise architect mindset applied to go-to-market.
There's also an honest note on skill requirements. The toolbox-and-catalog approach requires more technical depth than traditional ops work. Creating custom APIs and MCP servers is a step beyond configuring connectors and mapping fields. Ed acknowledges this but frames it as manageable — the right no-code orchestration platform can cover significant ground without requiring ops practitioners to spend months in programming courses. The technical ceiling is lower than it might appear, if the platform choice is right.
For operators looking to develop these skills, Ed's pragmatic suggestion is simple: find your enterprise architect counterparts in IT and invest in those relationships. Take them for coffee. Learn how they think about system design. That perspective — thinking about capabilities as services, thinking about scalability and reuse before building anything specific — is the foundation the RevOps architect role requires. This connects directly to the broader strategic elevation the RevOps function has been reaching for, a topic Episode 67: Why RevOps Roadmaps Fail — Breaking the Ticket Taker Mindset examines through a different lens.
One of the most expansive moments in the conversation comes toward the end, when Ed extends the architect argument beyond go-to-market. The capability-building work he's describing — clean datasets, reusable tools, abstracted interfaces — doesn't stop at the sales and marketing boundary.
Finance wants to know who the customers are. Operations wants it. Field delivery teams want it. HR ops and finance ops are growing functions with overlapping infrastructure needs. The ops teams that design their toolboxes with enterprise-wide reusability in mind won't just be delivering RevOps capabilities. They'll be delivering capabilities that the whole organization can consume.
"Ops is also continuing to grow across the enterprise. You have HR ops, finance ops, every ops you can imagine. And a lot of the infrastructure they need, the data they need — the ops team that's gonna be really successful are the ones that are capable to design these toolboxes and datasets so that what they deliver is no longer just go-to-market capabilities. It's literally enterprise-wide capabilities."
— Ed King
This is an ambitious vision, and it's worth naming that it carries real organizational complexity. The question of how RevOps relates to other ops functions, where ownership sits, and how to avoid turf conflicts is one the community continues to work through — as explored in Episode 31: Do Business Systems Belong in RevOps?. But the direction Ed is pointing is clear: the ops practitioners who think at this scale will have both relevance and organizational leverage that narrower specialists won't.
Matt's observation at the end of the conversation captures the practical opportunity well. The work of simplifying data for AI — creating a clean "Customers" dataset, building a reusable ABM accounts list — is work that makes every human in the organization more effective, too. The AI-ready infrastructure and the human-friendly infrastructure are the same infrastructure. That's a case for this work that doesn't require anyone to believe the AI hype. It just requires caring about good systems.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
Learn more about how Openprise helps RevOps teams build the data and orchestration foundation for AI-driven go-to-market operations.
Our average member has more than 5 years of RevOps experience. That means you’ll have real-time access to seasoned professionals. All we ask is that you’re generous with your knowledge in return.
