Claude Cowork is impressive.
Here's the infrastructure it assumes you already have.
Last month, Claude told one of our customers their pipeline was on track. It had HubSpot, Gong, Stripe and Slack connected via MCP. They were missing target by 21%. Nine deals hadn't been touched in 30 days. A Gong call flagged a budget blocker. The weekly summary said "stable, on track."
HubSpot
Gong
Stripe
Slack
→ 
Claude Cowork
=
Confidently wrong
For RevOps teams building their GTM on top of AI agents, the question isn't whether Claude Cowork is useful. It's whether the data underneath it is trustworthy enough to act on.
The gap isn't data access. It's data architecture — the layer between your tools and Claude that reconciles identities, enforces meaning, and remembers outcomes.
What follows is one customer's story. Anonymized details, real data, real consequences.
Claude won't tell you
it's wrong.
MCP is the connector layer. It gives Claude access to your CRM records, call transcripts, billing events, Slack threads. Most teams connect HubSpot, Gong, Stripe and Slack and assume they've covered their bases. Four pipes are still pipes.
Claude doesn't say
"I'm not sure."
It says "here's your pipeline summary" — and it's wrong in a way that looks exactly like being right. Every MCP reports CONNECTED. The gap is what sits between them.
No shared definitions
What's an SQL? How do you calculate NRR? A "qualified lead" in HubSpot, a "high-intent signal" in Gong, and a "converted trial" in Stripe might describe the same account — or three different ones. Claude can't reconcile what nobody has defined.
No identity resolution
The same contact exists as a HubSpot record, a Gong participant, and a Stripe customer. Without identity resolution, Claude treats them as separate entities. The Gong call where budget was flagged doesn't connect to the deal where it matters.
No plan or targets
Claude can pull closed-won totals from HubSpot, but doesn't know your number, which motion carries it, or how pace compares to target.
No outcome memory
Claude reasons on current state. It doesn't know the last 4 deals with this exact pattern — stalled at Stage 3, no exec contact, competitor mentioned in calls — all closed-lost. Every deal is assessed from scratch.
No cross-tool sequencing
HubSpot thinks in deals & contacts. Gong thinks in calls & speakers. Stripe in subscriptions. Slack in threads. Nobody has told Claude how these relate, how to sequence them into a deal journey, or which signal overrides which when they conflict.
What "confidently wrong"
actually looks like.
B2B SaaS. Mid-seven-figure ARR. 38 active accounts. Claude Cowork connected to HubSpot, Gong, Stripe, and Slack via MCP — a full setup. Anonymized details; real data.
Pipeline is stable. You're on track for the quarter.
- ✓9 active deals across Mid-Market and Enterprise.
- ✓MQL→SQL conversion: 75% — healthy funnel performance.
- ✓Quarter tracking to $240K target. No alerts.
- ✓Norden renewal looks on track — all subscription events firing.
Hubspot Gong Stripe Slack
Same company. Same week.
Here's what the data actually said.
- ✕ A 21% revenue gap. $180,390 actual against a $240,000 target. No tool in the stack encoded the target — so no tool flagged the miss.
- ✕ SQL → SAL conversion: 34%. Claude reported MQL→SQL (75%) — the one HubSpot tracks cleanly. Qualification to acceptance required a definition MCP doesn't carry.
- ✕ 9 deals with zero engagement 30+ days. No Gong calls. No emails. No stage changes. HubSpot still showed them "active." No rule connects cross-tool silence to a stalled deal.
- ✕ Norden cancelled payment, closed bank account. The Stripe event existed — Claude had access. Stripe customer ID ≠ HubSpot company without identity resolution.
- ✕ Kepler: budget flagged as "huge challenge" on a recorded Gong call. Call participants didn't map cleanly to HubSpot contacts. Signal floated, unconnected.
- ✕ Meridian: competitor displacement called out in a Slack thread — "they're evaluating [Competitor X] — we need to move fast." No schema tied a deal-channel thread to a HubSpot opportunity.
The automation didn't just miss signals. It replaced the manual check that would have caught them.
Won't Claude
just get better
at this?
Probably. MCP is evolving. Model generations keep improving. Over the next 12–24 months, cross-tool reasoning will get meaningfully better.
But there are categories of knowledge no model improvement will conjure from your data — because the knowledge doesn't live in your data.
Your definitions
What counts as an SQL at your company? Churn vs downgrade? These are business decisions, not data patterns. The same data supports multiple valid definitions.
Your plan
Quota targets, motion-level benchmarks, segment thresholds. These exist in spreadsheets, board decks, and planning sessions — not in any system Claude connects to.
Your outcome history
Which patterns led to wins, losses, or churn? CRMs store deal status — not the causal chain. No reasoning model can reconstruct what was never recorded.
Your identity map
Revenue decisions need deterministic, auditable identity resolution. "Probably the same account" isn't good enough for a billing risk alert.
Claude will get better at reasoning across data it can access. It won't get better at reasoning across data that doesn't exist. Definitions, plans, outcome tags, and identity maps are infrastructure — they need to be built, not inferred.
What Claude needs underneath it:
a revenue context graph.
Dashboards tell you what happened. Context graphs tell you why. Claude without a context graph just tells you what happened faster.
HubSpot's Dharmesh Shah recently wrote about context graphs — the idea that AI needs more than raw data; it needs the relationships and decision traces that connect data to meaning. He added a sharp caveat: most companies aren't ready.
He's right about the gap. But revenue teams don't need a fully instrumented decision-trace graph. They need a specific, bounded version — one that connects the five or six systems that already hold 90% of your revenue context and gives them a shared schema, shared identities, and shared definitions.
The three layers
Claude needs underneath it.
Foundation, planning, context. Each is a layer of infrastructure — not a feature a model will grow into.
Context — what the graph knows.
The graph itself: shared identities, cross-tool sequencing, tagged outcomes, validated patterns. Plug Claude in here and it stops guessing; it cites the structure.
Planning — targets, motions, benchmarks.
What "on track" means at your company. Quota, motion-level pace, segment thresholds, ramp curves. A number Claude can compare against — not an implicit vibe.
Foundation — connectors + definitions.
HubSpot, Gong, Stripe, Slack — and a single, authored dictionary of what SQL, NRR, pipeline, and churn mean at your company. Garbage in is still garbage out; this is where garbage stops.
How the graph
actually learns.
A graph that only connects systems is useful. A graph that learns from outcomes is transformational. Here's how the loop works mechanically.
- 1
Outcome tagging
Every deal and customer gets a tagged outcome — Won, Churned, Expanded, Downgraded, Stalled — from CRM close reasons, validated against billing.
- 2
Pattern extraction
With 50+ won / 50+ lost tagged, the graph runs comparative analysis — closer to cohort analysis than ML. Correlations with confidence scores tied to sample size and consistency.
- 3
Correlation validation Human in loop
RevOps enters the loop to validate whether patterns reflect causal mechanisms — not spurious correlations. "CISO engagement pre-Stage 3 → 2.4× close" only becomes a rule when the team says so.
- 4
Continuous recalibration
As new outcomes flow in, correlations update. Playbooks refine themselves week after week. A rule that held for 6 months may die after a pricing change — the graph flags degradation.
Graph
What this changes
in practice.
Same customer, six months of data. Two findings no CRM report could surface.
38% of pipeline was structurally unlikely to convert.
Winning profile: Series C+ Fintech & HealthTech, 200–500 employees, compliance pain. These closed in 132 days at $62K ACV. Outside the ICP, the numbers collapsed.
Reallocate 60% of outbound SDR capacity to mid-market Fintech. Stop targeting sub-50. Pivot messaging to "Compliance Automation for International Expansion" — the pain in 80% of won deals.
Speed, not effort — and the graph proved it.
Top performers closed 3× larger ACVs ($25K vs $7,560) despite lower activity volume. The differentiator wasn't effort — it was velocity.
Early qualification discipline · executive stakeholder mapping · proactive ROI defense. Written by the graph, from patterns, not gut feel. Updates as new deal data flows in.
What breaks
when you build it
yourself.
You can. Some teams do. But the failure mode is almost always the same: ship v1, works for a quarter, then drifts because nobody maintains it.
If you've done all of this and maintain it continuously, you don't need a platform. If you haven't — that's exactly what Vasco was built for.
| What we handle so you don't have to | DIY reality | With Vasco |
|---|---|---|
| Identity resolution across HubSpot / Gong / Stripe / Slack | Multi-week engineering · ongoing maintenance | ✓ |
| Shared definitions (SQL, NRR, churn) | Drift with every GTM change | ✓ |
| Plan + target ingestion | Lives in a sheet no system reads | ✓ |
| Outcome tagging pipeline | Requires CRM hygiene you don't have | ✓ |
| Pattern memory + recalibration | A data-science hire and a yearlong project | ✓ |
| Account journey reconstruction | Schema glue nobody wants to own | ✓ |
| Auditable alerts + playbook outputs | Dashboards get ignored; alerts drift | ✓ |
Claude is a reasoning engine.
Give it something to reason on.
MCP gives access.
It plumbs Claude into your systems. Necessary — but it is not, and was never meant to be, the architecture.
Vasco gives meaning.
Identities reconciled, definitions enforced, journeys sequenced, outcomes remembered. The layer Claude actually needs to stand on.
You set the rules.
Definitions, plan, ICP, validated correlations. RevOps remains the author. Claude reasons on what you've authored — not on what it inferred.
Questions we get from RevOps leaders.
You have access. You don't have architecture. Each MCP delivers its own schema, identities, and vocabulary. The case study above had all four connected and still missed a 21% revenue gap.
MCP will improve at access and basic entity matching. But definitions, plan targets, outcome history, and validated identity maps are business decisions encoded as infrastructure — not patterns a model infers.
Those tools analyze the data they own. A context graph is an infrastructure layer underneath all of them — it doesn't replace any tool; it connects them, reconciles them, and remembers outcomes.
No. Claude is useful today for drafting and summarizing. What you should solve is trusting its output for pipeline reviews and forecasting — anywhere a wrong number leads to a wrong decision.
Tagged outcomes (Won, Lost, Churned, Expanded, Stalled) mapped to complete deal journeys. Statistical floor ≈ 50+ outcomes per category. Below that, the graph connects and reports; above it, it starts identifying what works.
RevOps. MCP connections inherit whatever permissions the authorizing user holds. Treat Claude's data access like any integration: explicit authorization, documented scope, named owner.
Use Claude now.
Just know where the trust boundary is.
Vasco is the revenue context graph underneath your AI. See it reconcile your four MCPs into one queryable layer — in a 30-minute demo on your actual data.