Here is the part most AI demos skip: almost no AI agent in a real enterprise environment is allowed to touch core systems of record. On the latest episode of RevOps AF, host Matt Volm sat down with Openprise CEO and founder Ed King to unpack why that is, and what it means for anyone building AI agents for RevOps. Ed sells mostly into medium and large enterprises, so he has watched a lot of AI projects get impressively far and then stop at the same wall.
Here are the highlights from their conversation.
Why AI agents for RevOps stall at the pilot stage
Ed put numbers to it. By his read, consistent with OpenAI's own published data, roughly 65% of enterprise AI work is content generation and search replacement. Another 30% is analytics, recommendations, and planning, often fed by someone manually exporting data and pasting it into a model. The last 5% is where agents actually do something, and even that runs almost entirely through low-risk engagement tools like outreach and social.
The core systems of record stay locked. And nobody within an enterprise org is ready to let AI agents loose on their Salesforce instance.
We haven't seen a single instance where an agent is allowed to update a core system of record, CRM or marketing automation. Not a single one.
The reason is not fear of new tech. It is reliability. LLMs are probabilistic, and ops work requires deterministic logic. Nobody wants to hear, "maybe it will get done properly, maybe it won't" as Ed put it. He's blunt about the tech too and where it's heading. Hallucination, in his words, is a feature, not a bug, and it has not improved in five years. Layer security concerns on top of this, and the hesitation to let AI agents connect to backend systems seems completely rational.
Today, if you're a chief information security officer and you'll let agents connect to your backend systems — you probably should be fired.
The fix is a control layer, not more middleware
Ed calls this gap the A'sI last mile problem. If agents cannot safely reach the systems of record, then the answer is to establish a control layer that sits between the agents and your backend infrastructure. It handles identity and security, but for an ops audience it comes down to two jobs.
1) It gives AI agents structured data that's clean and ready for them to use
2) It gives them a safe set of tools and protocols to act on the systems behind it
The wrong move is to fix this with more custom integrations, which Ed flagged as a slippery slope. Build one, then another, and soon you have a tangle of tech that breaks every time a system changes. A control layer (what we at Openprise call AI orchestration) does the opposite. It hides the messy backend behind a clean set of datasets and tools, so AI agents never have to deal with it.
Start with a data catalog your AI agents can actually read
Ed's favorite test is deceptively simple. Ask your company, "Who were our customers in the last 12 months?" In most orgs, fewer than a handful of people can answer this question, and the ones who can need about a day to do it right.
That is not incompetence. Your CRM was never designed to answer that question. Custom objects, child accounts, the records marked "test" because someone tests in production, the SAP account that shows up five times but should count once. Matt captured the pain perfectly, listing how many filters and institutional knowledge it takes to pull one clean customer list. The data backs him up: in ur 2025 State of RevOps Survey, 71% of companies said poor data quality hurts their go-to-market activities, and only 11% rated their data as excellent.
Now hand that raw CRM data to an AI agent and say "go figure it out." The odds it gets it right are close to zero, and it will burn a small fortune in tokens re-asking the same question on every run. Ed's answer is to stop making AI models do tasks that don't require any actual intelligence. Ops builds a dataset called customers, a simple table with maybe 20 fields, and hands it over. The agent does not need to know whether you run Salesforce or Dynamics. It just queries the catalog.
Expose raw data to agents and the chance it figures things out reliably — for a large, complex enterprise — is almost zero.
Then build the toolbox for safe write-back
Reading data is only half the job. AI agents also need to be able to write back to systems of record: setting up campaigns, updating statuses, marking who raised a hand. The control layer handles this with a defined set of tools rather than raw API access. Think a "create campaign tool" and an "update campaign status tool," each with predictable inputs and outputs.
These usually take the form of custom APIs and MCP servers, sometimes command-line tools. The advantage is that all your governance lives inside them. Naming conventions, funnel logic, onboarding rules, all the work that requires no intelligence gets enforced in the tool instead of left to a model that might improvise.
Collectively the datasets and tools become a toolbox for your AI agents that hide the chaos living within your backend systems. You install it into whatever agent environment your teams use, whether that's Claude or Agentforce, and let them orchestrate.
The real shift: from operator to architect
This is the throughline of the whole episode. Ed frames building datasets and tools for agents as service-oriented architecture for AI. IT went through the same evolution 20-plus years ago, when point systems gave way to shared services and a new role appeared: the enterprise architect. Ops is walking into its own version of that same evolutionary cycle now.
The mindset of an ops person then moves from point-to-point integrations to capabilities as a service. Instead of wiring up one more workflow, you design a reusable set of datasets and tools, aiming for something like 20 to 30 datasets that cover most of what your agents will ever need. The trick is finding the commonality across use cases, so you build customers, ABM accounts, and whitespace accounts once rather than a bespoke dataset for every team.
Ed is a firm believer that ops has to own this layer, because only ops understands how the business actually operates well enough to build the right tools. And the payoff extends far beyond the go-to-market teams. Finance wants to know who the customers are. So does CS ops, and every other ops function multiplying across the enterprise.
Ops has to own this layer. Only ops understands how the business actually needs to operate — IT could never understand it deeply enough to build the right set of tools.
What does it look like when the foundation is there? Rippling built a fully autonomous outbound engine, the Dark TAM Engine, in six to seven weeks on Openprise. That is what AI agents doing real work looks like once the data and tools are ready for them.
Here's the catch: this will make ops a more technical role once again. Creating workflows, custom APIs, and MCP servers asks more than activating a connector and mapping fields. A no-code orchestration platform closes most of that gap, so nobody has to spend six months in programming classes, but the job is genuinely changing.
What this means for your ops team
The takeaway is not that AI is overhyped. It is that agents only get to do the exciting last 5% once ops builds the layer beneath them. The models are ready. The data catalog and toolbox are what is missing, and that work belongs to ops. Or, as Ed put it, the simplest questions are often the hardest to answer, which is exactly why ops is the team that's best positioned to answer them.
This requires a complete mindset change. Instead of point solutions and point-to-point integrations, you have to start thinking about infrastructure — capability as a service. It's a transition from thinking about apps to thinking about systems — about system architecture.
Ready to own the system architecture that powers AI at your company? Request a demo.
