Two prospects raised versions of the same objection recently. One compared it to Power BI: HubSpot already has dashboards, forecasting, and custom objects, so why add another layer. The other asked about wiring Copilot straight into Salesforce and skipping the middle step entirely.
Both are reasonable questions. Model Context Protocol (MCP) makes it easy to connect Claude to a CRM in a few clicks, and the summaries it produces look clean. That's exactly what makes the gap hard to spot.
AI reasoning is where CRM data breaks down
Power BI and HubSpot's native dashboards are built to display what's already in the CRM. That part works fine. The problem shows up when an AI is asked to reason across that data instead of just chart it.
Claude or Copilot connected directly to Salesforce doesn't inherit business logic. It inherits raw fields, and it treats every field as if it means exactly what it says.
That's rarely true. "Qualified lead" means one thing to the SDR team and something else to the AE who inherits the deal. "Active" in the CRM can mean a rep hasn't touched the stage in six weeks, not that the deal is actually moving. A dashboard just displays that value. An AI agent reasons on top of it and reports a conclusion with full confidence, whether or not the underlying number was ever true.
MCP is the connector that makes this possible in the first place, and it deserves credit for that. It gets Claude or Copilot into a CRM, call recordings, a billing system. What it doesn't do is clean any of it. It doesn't decide that the HubSpot record for one account and the Stripe record for the same account under a slightly different name are the same customer. It doesn't know a company's specific definition of a qualified lead versus HubSpot's default. MCP is the pipe. It was never the foundation.
Two ways to hand Claude an answer
There's a second distinction worth pulling apart, because it explains why some AI-CRM setups look sophisticated and still land at the same accuracy problem.
One approach hands Claude a skill: written instructions, often kept in a repo, that describe how to go find the answer. Call the CRM for deal stage, call the billing platform for payment status, call Slack for mentions, then reconcile all of it into a narrative. Every time this runs, Claude is improvising the join logic in the moment, on data that has never been reconciled ahead of time. The instructions describe a path to an answer. They don't describe the answer.
The other approach hands Claude the answer directly. Vasco's MCP exposes tools like query-context-graph and query-metric-engine that return a single structured result. Identity resolution, field definitions, and plan targets are resolved before Claude ever asks the question, not while it's assembling the response. Claude isn't told where to look and how to stitch the pieces together. It receives a fact that has already been checked.
Skill instructions + raw tools, step by step:
- Claude loads a skill describing how to query HubSpot, Stripe, and Slack directly
- Claude calls each raw tool separately and gets back unreconciled fragments
- Claude joins and reconciles the fragments itself, in the moment
- Claude writes an answer built from raw data, with full confidence
Result: 52% accuracy
Vasco context graph, step by step:
- Claude calls one tool: query-context-graph or query-metric-engine
- Identities and field definitions were already standardized before the call
- Plan targets and cross-tool signals were already loaded into the graph
- Claude receives one structured answer, already checked against the foundation. Result: 98% accuracy
A skill can tell Claude where to look. It can't make the data underneath trustworthy at the moment Claude looks at it. That's the gap a well-written skill file cannot close on its own, and it's the same gap the 52% accuracy test measures directly.
A real pipeline review, and what it missed
One B2B SaaS company, managing dozens of active accounts on HubSpot, connected Claude across its CRM, call recordings, billing platform, and Slack. The output looked routine: Claude reported the pipeline on track for the quarter, in the same confident tone it always used, so nobody double-checked it.
The actual number told a different story. The team had a quarterly target of $240,000, tracked in a spreadsheet the RevOps lead updated once every 90 days. Claude had never seen that spreadsheet, so when it looked at $180,390 in closed-won revenue, it had no reference point to flag a 21% miss. Claude also reported a healthy 75% lead-to-opportunity conversion rate, because HubSpot tracks that stage cleanly, while missing the real bottleneck two stages later: a 34% conversion rate from qualified opportunity to committed deal, a number that never lived anywhere Claude could see it.
Nine deals had gone untouched for over 30 days, no calls, no emails, no stage changes, and HubSpot still listed every one as active. Claude reported them as healthy pipeline. Three risks sat in systems the CRM connection never reached: a customer had canceled its payment method in the billing platform while the CRM showed the account as healthy, a prospect had flagged budget as a serious concern on a recorded call while the deal kept progressing in HubSpot as if the call never happened, and a competitor threat had surfaced in a Slack thread that nobody linked back to the deal record. Claude reported all three accounts as on track, because the systems where the real signal lived were never connected to the systems it was reasoning over.
None of this was a model failure. Claude reasoned correctly on the data it had access to. The data it had access to was incomplete, and nothing in the setup gave it a way to know that.
Research shows this is not an isolated case
This pattern shows up well beyond CRM data specifically. MIT's Project NANDA studied more than 300 enterprise AI deployments, 52 case studies, and over 150 leadership interviews, and found that:
roughly 95% of enterprise generative AI pilots failed to produce a measurable business return despite $30 to $40 billion in enterprise investment.
The researchers were direct about the cause: model quality wasn't the deciding factor.
Gartner reached a similar conclusion looking specifically at agentic AI. The firm predicts more than 40% of agentic AI projects will be canceled by the end of 2027 due to rising costs, unclear business value, or inadequate risk controls, based on a poll of over 3,400 organizations actively investing in the technology.
The 52% vs. 98% accuracy test
Vasco ran a controlled test on this exact question using CRM data instead of the broader enterprise samples in the research above. Claude was given full MCP access to raw CRM data and asked a set of common RevOps questions across five scenarios. Answer accuracy landed at 52%.
The same questions, routed through a layer that reconciles identities, enforces field definitions, and holds plan targets as a fixed reference point, brought accuracy to 98%. Same model, same questions, a different foundation underneath.
That gap is the whole argument, and it isn't a model quality problem. Claude and Copilot are both capable of correct reasoning when the inputs are trustworthy. The failure sits one layer below the model, in data that was never reconciled before the AI touched it, which is exactly the pattern MIT, Gartner, and McKinsey all describe at the broader enterprise level.
Direct connection versus governed layer, side by side
- Field definitions: whatever the CRM default happens to be, versus standardized once across every connected tool
- Duplicate accounts across systems: treated as separate records, versus resolved into a single identity
- Plan targets and benchmarks: not visible to the AI at all, versus held as a fixed reference point
- Signals outside the CRM (calls, billing, Slack): invisible unless manually cross-checked, versus reconciled and sequenced with CRM data
- Tested accuracy on common RevOps questions: 52%, versus 98%
Why Power BI doesn't solve this either
Power BI's honest tradeoff is hours, not accuracy. Cross-referencing HubSpot, Google Analytics, and call data through Power BI usually means manual joins, a data engineer's time, and a dashboard that goes stale the moment a field name changes upstream.
It gets a report. It doesn't get an agent that can look at a stalled deal, cross-reference the call transcript, notice the champion left the account three weeks ago, and write that finding back to the CRM on its own. That's a reasoning problem, and it's a different problem than the one Power BI was built to solve.
A governed layer closes the gap
Reducing hallucination risk means controlling what the AI is allowed to treat as true before it starts reasoning, not swapping in a smarter model. A governed data layer standardizes definitions across every connected tool, resolves duplicate identities, and holds targets and benchmarks as a fixed reference instead of letting each system guess at its own version.
Claude or Copilot still does the reasoning. It just does it on a foundation that agrees with itself.
Connect an AI tool straight to a CRM and the answers come fast. Connect it to a foundation where the data has already been reconciled first, and the answers hold up without a second person checking the AI's work.
See the difference on real CRM data
Book a 20-minute walkthrough and bring a real question a team has asked Claude or Copilot before. We'll show what changes when the same question runs through a reconciled data layer instead of a raw CRM connection.
