The CD player problem

Imagine an iPhone music app that controls a robotic arm. The arm walks across your living room, opens a CD case, places the disc in a tray, and presses play. You can skip tracks from your phone. You can even queue the next album.

It works. Nobody would call it progress.

This is what happens when enterprises connect AI to legacy software through protocol adapters. The Model Context P

Protocol – MCP – lets an AI model call into Salesforce, fetch a record from ServiceNow, trigger a workflow in Jira. The connection is real. The intelligence is not.

MCP is the robotic arm. Legacy SaaS is the CD.

The robotic arm works. That’s the problem.

The danger of a functional workaround is that it looks like a solution. MCP connects AI models to enterprise systems through standardized tool calls. The model can read a Salesforce opportunity. It can pull a Jira ticket. It can query Zendesk for open cases.

What it cannot do is think across those boundaries.

Ask an MCP-connected model “What’s happening with Acme Corp?” and it makes five separate API calls – one to the CRM, one to support, one to engineering, one to Slack, one to the product backlog. Each returns a fragment. The model stitches fragments together through prompt engineering and hopes the result is coherent.

This isn’t reasoning. It’s collage.

The AI fetches. It does not understand. It retrieves records but has no memory of what changed between retrievals, no awareness of how objects relate across systems, and no ability to trace causation from one domain to another. Every call starts from zero.

Digitizing music didn't just make CDs faster to access. It created entirely new capabilities that were structurally impossible before.

Dheeraj Pandey

Co-founder & CEO, DevRev

What music learned that enterprise software hasn’t

When the music industry moved from CDs to digital formats, it didn’t just make playback more convenient. It created entirely new capabilities that were structurally impossible before.

Shuffle across your entire library – impossible with physical discs. Algorithmic recommendations based on listening patterns – impossible without a unified data layer. Collaborative playlists that merge tastes from different people – impossible when each album lives in its own case.

The transition wasn’t about faster access to the same medium. It was about eliminating the medium entirely and building something native to the new architecture.

Enterprise AI is stuck in the CD era. MCP gives you faster access to the same fragmented records, the same isolated systems, the same architectural limitations. It mechanizes access to software that was never designed for reasoning.

The question isn’t whether the robotic arm is fast enough. The question is why you still have CDs.

Five things a robotic arm can’t do

Unified memory – a persistent, indexed knowledge graph that holds cross-system context – enables capabilities that no adapter framework can replicate. Here are five.

Temporal reasoning. When a deployment fails on Tuesday and three P0 tickets land on Wednesday, a unified memory system knows these events are connected because it tracked both in the same graph. An adapter model sees two unrelated data points from two different systems. Temporal reasoning means understanding not just what exists, but what changed, when, and what that change triggered.

Cross-domain summarization. “What’s the full picture on Acme Corp?” should return a single synthesized answer – combining CRM notes, support escalations, engineering blockers, product feedback, and renewal timelines. Not five separate API responses stapled together by a prompt. Unified memory pre-connects these objects at ingestion time, so the query runs against a graph, not against five disconnected APIs.

Causal inference. A deployment failure caused a spike in P0 tickets, which triggered a 48-hour delay on a feature release, which led to an executive escalation from a strategic account. No single system holds this full story. An adapter model sees each event in isolation. A memory architecture traces the chain because every node in the graph carries its relationships and timestamps.

Coordinated action. “Prepare me for the Acme QBR tomorrow” is a single intent that requires pulling account health metrics, identifying open risks, suggesting talking points based on recent escalations, and preloading resolutions for known issues. With adapters, this becomes a multi-step prompt chain where each step calls a different API and passes results to the next. With unified memory, it’s one query against a connected graph – one intent, one execution.

Grounded trust. Every answer Computer provides cites its source objects. Every action can be audited. The model doesn’t hallucinate over gaps between systems because the gaps don’t exist – the data lives in one graph with full provenance. Adapter models fill gaps with inference, which is a polite word for guessing.

Models are commodities. Memory is the moat.

GPT-5, Claude, Gemini – frontier models will be everywhere within 18 months. Every enterprise will have access to the same reasoning capabilities. The differentiator won’t be which model you run.

It will be what that model knows about your business.

Contextual knowledge graphs. Persistent organizational memory. Temporal awareness across every business interaction. This is the layer that separates an AI that fetches records from one that actually understands your company.

The companies that win won’t be the ones with the best adapter framework connecting AI to 50 legacy systems. They’ll be the ones that eliminated the need for adapters entirely – by building on a single, unified memory from day one.

The integration approach assumes that intelligence lives in the model. It doesn't. Intelligence lives in the memory.

Dheeraj Pandey

Co-founder & CEO, DevRev

Three questions for your next vendor meeting

If you’re evaluating enterprise AI, these three questions separate adapter approaches from genuine intelligence:

Where does context live? If the answer is “distributed across source systems, accessed on demand” – you’re looking at a robotic arm. If context lives in a persistent, indexed graph that’s always in memory – you’re looking at native intelligence.

Can it reason across domains? Ask the vendor to answer a question that spans sales, support, and engineering data in a single response. Not three responses stitched together. One coherent answer with citations from all three domains.

Does it know what changed? Ask for a timeline of meaningful changes to an account over the past 90 days – not an activity log, but a curated narrative of what changed, why it mattered, and what it triggered. Adapter models can’t do this because they’re stateless. Memory-native systems do it by design.

Stop upgrading the robotic arm

Digitizing music didn’t make CDs faster to access. It created shuffle, playlists, recommendations, and discovery – capabilities that were structurally impossible in the old format.

The same transformation is available for enterprise data. Computer by DevRev is the digital-native architecture – a unified memory layer where every business object, every decision, every interaction lives in a single knowledge graph with full temporal awareness, cross-domain relationships, and permission-aware access.

The CD player problem isn’t a connectivity problem. It’s an architecture problem. And you don’t solve architecture problems with a better robotic arm.

This article is based on the DevRev whitepaper “The CD player problem.” Read the full whitepaper for the detailed capability framework and enterprise buyer evaluation guide.

See how Computer replaces the robotic arm →