Podcast
May 13, 2026
Episode 92: Why AI Agents Need RevOps
AI agents hallucinating on your revenue data? Guillaume Jacquet of Vasco explains why it's a grounding problem, and why RevOps owns the fix.
If your AI agent is confidently telling you that revenue is on track, but you're actually missing your number by 21% — that’s not a hallucination problem. That’s a grounding problem. And that’s squarely a RevOps responsibility.
In this episode of RevOpsAF, Guillaume Jacquet, CEO and co-founder of Vasco, joins co-host Matthew Volm to unpack why AI agents fail on revenue data. It's not because the models are broken, but because the data they reason on hasn't been prepared to support them. Guillaume brings years of experience at the intersection of revenue operations and data architecture, and Vasco is purpose-built around the problem he describes in this conversation: the revenue data layer that makes agents production-ready.
The conversation covers four foundational requirements for accurate AI on revenue data, why operators should think of agents as hires rather than tools, and what the financial upside looks like when teams get this right.
The setup Guillaume describes is uncomfortably familiar. A new VP of RevOps comes in, promises an AI strategy, connects the MCPs (HubSpot, Salesforce, Gong, Slack, Zendesk) and starts producing reports. The reports look phenomenal. Everyone in the room is impressed.
Then someone starts poking at the numbers.
"You realize that connecting tools that have their own systems and their own APIs and their own logic and just thinking that without any work underneath it's gonna understand your business and provide accuracy is never gonna happen. And you came from a meeting that was like all on track, everything's amazing, to, 'Oh my God, we actually have to build more pipeline, otherwise we're not gonna hit the end of the quarter.'" — Guillaume Jacquet
The conversion rate was inaccurate because two teams defined it differently. The channel attribution numbers reflected the default HubSpot source configuration. Not the way the company actually measures channels. For example, a deal marked "on track" was actually at risk. A customer had emailed to cancel their account, but that email was never attached to the CRM.
None of this is the LLM's fault. The model did exactly what it was supposed to do: it reasoned on the data it was given and returned the most plausible answer. The problem is that "most plausible" and "accurate for your specific business" are not the same thing; especially when the business has years of technical debt baked into its CRM build.
This connects to a pattern the community has been wrestling with for years. The same data quality issues that sank BI projects a decade ago are now resurfacing in the AI era, and the stakes are higher because the outputs look so much more convincing.
The instinct when an AI number is wrong is to blame hallucination. Guillaume pushes back on this directly.
"I actually have a kind of a contrarian view, especially with the powerness of the model right now. It's more of a grounding problem." — Guillaume Jacquet
The distinction matters because it changes where the fix lives. If it's a hallucination problem, you wait for the models to improve. If it's a grounding problem, RevOps can solve it immediately.
What actually happens when you ask Claude "how many closed won did I get this month?" is that the model tries to reverse-engineer your semantic layer. It infers what "closed won" means based on how your system is built. It makes reasonable assumptions about attribution, conversion rate definitions, and pipeline stage logic. And it gets it wrong. Not because it's making things up, but because tribal knowledge that lives inside your company can't be inferred from API connections alone.
Gartner has noted that somewhere between 70 and 80% of business intelligence projects fail for exactly this reason. Teams ingest the data, build the dashboards, and skip the semantic layer that makes the numbers mean what they're supposed to mean. AI is setting up the same trap at scale, with even more confident-sounding outputs to obscure the root of the problem.
Guillaume lays out four foundational requirements that move AI accuracy on revenue data from 11–30% to upward of 98%. Each one is a RevOps responsibility.
The same person appears in HubSpot as a marketing contact, in Salesforce as an opportunity record, in Gong as a call participant, and in Intercom as a support ticket submitter. Without resolving those identities into a single account timeline, the agent is reasoning on fragments, and it will always be missing links.
If RevOps doesn't own this, every team member with access to Claude will define ARR, conversion rate, ICP qualification, and channel attribution however serves their narrative. The result isn't just inaccurate reporting. It's a slow-motion political battle where everyone is arguing from their own privately generated dataset. Shared metric definitions have always been foundational to trustworthy revenue reporting, and AI makes the absence of them immediately catastrophic.
An absolute number (say, $100K in MRR) is meaningless without context. Good or bad? Ahead or behind? You can only answer that if the agent has access to the plan. Without quota and target data wired in, AI can describe what happened but can't tell you what it means.
Agents shouldn't have to rediscover institutional knowledge every time they run. Capturing the outcomes of past decisions — what worked, what didn't, what changed and why — allows the system to learn rather than reset. This is the layer that moves an agent from a useful prototype to something the organization actually makes decisions on.
Wire all four into a context graph: a structure where every account is a node connected to every conversation and touchpoint that has ever touched it. The LLM can reason its way through rather than pattern-matching on incomplete inputs.
One of the most practically useful reframes in the conversation is Guillaume's argument that operators are approaching prompt engineering the wrong way. The fix is simpler than most people expect.
"People expect through a couple of sentences that the agent is gonna lift the thing that they have in their head immediately and infer everything that they thought. But if they were to recruit someone to do the same task, they would actually train that person, share a lot of context, give feedback, and then try to ground that person based on the skills that it needs." — Guillaume Jacquet
The technique Vasco has landed on is to structure agent prompts as job descriptions. That means specifying: a job title (which signals reporting level and output expectations to the model), a cadence, what regularly lands in the recipient's inbox, what the team stops doing when the agent is running, and the KPIs the agent is measured against.
Guillaume walks through a live example: an ICP discovery agent prompted as an "ICP research analyst" reporting to the VP of Marketing. With the right underlying data and a job-description-style prompt, the agent analyzed call transcripts from the last two quarters, extracted the top purchase triggers and pain points by deal type, mapped ICP distribution by company size and geography, and produced targeting recommendations with projected ARR impact. Work that would otherwise take days.
The key insight is that the quality of the agent output scales directly with the quality of the grounding beneath it. This is the same principle that applies to moving from AI experiments to production-ready revenue machines. The teams that get there aren't using better prompts than everyone else, they've built better foundations.
There's a version of this story that ends badly for RevOps: agents get deployed without grounding, numbers are wrong, trust erodes, and operators spend more time than ever firefighting the downstream consequences of AI-generated misinformation. Guillaume is direct that this is the risk if RevOps cedes ownership of the data layer.
But there's another version. And it's the one Guillaume argues for.
"I would hate for RevOps to miss that opportunity." — Guillaume Jacquet
The argument is that the current AI adoption wave — driven by pressure from VCs, boards, and executives — creates a mandate for exactly the foundational work that RevOps has always needed time and budget to do. Identity resolution, metric definitions, plan alignment, outcome tracking: these aren't new problems. They're the same problems that have kept RevOps stuck in firefighting mode for years. AI adoption pressure finally gives operators a business case for solving them.
The payoff isn't just accurate AI. It's self-serve business intelligence for the entire revenue team. A system where any stakeholder can answer their own data questions on demand, without filing a ticket. Reducing the reactive report-building burden that consumes the majority of RevOps time is what creates space for the strategic work that actually moves the business forward. That's the seat at the table.
The alternative, doing nothing while every team member quietly spins up their own Claude-powered analysis on ungrounded data, isn't neutral. It's a guarantee of 50 different versions of the same number, each one supporting a different narrative, and all of them being RevOps' problem to clean up.
For operators who need to build the business case for doing this work, Guillaume outlines four metrics that agents, properly grounded, can meaningfully move.
Quota-to-OTE ratio. The industry benchmark is 4–5x: a rep earning $200K should generate $800K–$1M in booked revenue. But reps spend significant time on research, CRM hygiene, and non-selling tasks. With the right agents handling that work and providing real-time coaching to improve win rates, Guillaume has seen teams targeting 7–10x. That same $200K rep potentially generating $1.4M–$2M.
Manager-to-IC ratio. The standard span of control is one manager to five individual contributors. Most of that manager's time goes toward gathering data, reviewing calls, checking pipeline, and assessing playbook adherence: all of which agents can handle. Teams that automate this layer have moved to one manager for 10 ICs, reducing managerial overhead while scaling contributor capacity.
RevOps strategic time allocation. The current reality for most operators is roughly 70% firefighting, 30% building. Giving the rest of the revenue team self-serve access to accurate data flips that ratio, and the reclaimed time goes directly into the system-building work that compounds over time.
Course-correction speed. The difference between a CRO discovering a miss at the end of the month versus the beginning of the month is measurable in pipeline. Agents that monitor accounts and surface signals in real time; detecting churn risk before it shows up in a renewal conversation, flagging at-risk deals when the signal is still actionable; change the economics of the quarter.
Guillaume's models for a 5–20M ARR company put the aggregate impact of moving these four metrics at $1.2M–$3.4M in ARR. Roughly a 30% top-line lift from doing the foundational work right.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
Want to learn more about Vasco's revenue data layer for AI agents? Visit getvasco.com.
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.
