When infrastructure gets commoditized, data becomes the moat

Someone asked me, the day Anthropic launched Managed Agents, whether this was the beginning of the end for companies like DevRev. Reasonable question. Anthropic is now offering hosted agent infrastructure with sandboxing, state management, credential isolation, crash recovery, long-running sessions, all packaged up for $0.08 per session-hour. If you were spending months building that plumbing yourself, you can stop. If your company's pitch was "we handle the hard engineering of running agents," you should probably be worried.

But that isn't our pitch. And the distinction matters more than it might seem.

I spend most of my time thinking about what happens after you have the infrastructure. You've got your agent running in a sandbox, the state persists through crashes, credentials are isolated. Great. Now the agent needs to actually know something about your business. This is where I think people confuse two very different problems. Building the execution layer for agents is an infrastructure problem, and Anthropic just solved it convincingly. Building the data layer that makes agents useful for a specific organization is a completely different kind of problem, one that infrastructure providers have no incentive to solve.

There's a useful way to think about this that we use internally at DevRev. An AI system needs two distinct layers to be useful in an enterprise: a memory layer and an action layer. They're complementary, but they solve very different problems, and confusing them leads to architectures that look impressive in demos and fall apart in production.

MCP, the protocol that Managed Agents uses to connect to external tools and data sources, is the action layer. It lets an agent reach into Jira, Salesforce, Zendesk, Google Drive, and query them in real-time. The spec supports OAuth 2.1 for per-user authentication, so agents can authenticate as the actual end user rather than a shared service account. MCP sessions maintain state within a connection, and Managed Agents adds longer-term persistence through its append-only event log, so the agent can recover from crashes and remember what it did across tool calls. That's all genuinely valuable engineering, and it solves real problems that teams were previously building from scratch.

But MCP is a protocol for connecting to systems, not for understanding what's inside them. The difference between connecting and understanding is where most enterprise AI deployments actually break down.

Consider what happens when an agent needs to answer a question that spans multiple systems. A VP of Customer Success asks: "Which of our enterprise accounts are at risk this quarter?" To answer that well, the agent needs to pull together support ticket history from Zendesk, escalation patterns from Jira, product usage data from Pendo or Amplitude, feature request trends from Productboard, contract renewal dates from Salesforce, and maybe even engineering delivery timelines from Linear or GitHub for features those accounts are waiting on.

With MCP, the agent fans out individual queries to each system. Each query hits a separate API with its own latency, rate limits, and intermittent availability. Each source returns results using its own internal relevance logic. There's no cross-system ranking in the MCP spec, so the LLM has to do all the prioritization downstream, with no awareness of business context like revenue impact or customer tier. And here's a problem that's easy to underestimate: enterprise queries consume enormous token counts because the agent is passing raw, unstructured data (email threads, ticket histories, Slack transcripts) directly to the LLM for processing. Teams have reported that MCP tool schemas alone can consume hundreds of thousands of tokens before the model processes a single query, and early adopters have documented order-of-magnitude token reductions by moving to more structured approaches.

There's also no entity resolution happening at the protocol level. "ACME Corp" in your CRM, "Acme Corporation" in your ticketing system, and "acme-corp" in your engineering tools are all the same customer. MCP doesn't know that. Each query reaches into one system at a time (though agents can issue multiple calls in sequence or parallel), and stitching the picture together is left entirely to the LLM, every single time. The model has to rediscover these relationships on every query, with no persistent understanding of how your systems relate to each other.

This is the problem that Computer Memory, our knowledge graph at DevRev, was built to solve. It pre-ingests data from connected systems through AirSync, our patented bidirectional sync engine. We have pre-built connectors to roughly 100 enterprise systems including Salesforce, Jira, Slack, Google Workspace, Zendesk, ServiceNow, Okta, and GitHub. AirSync maps schemas from external systems into DevRev's unified data model, establishing relationships between external record types and DevRev objects so that a Jira issue, a Zendesk ticket, and a Salesforce case that all relate to the same customer are connected in the graph from the moment they're ingested. And it's continuous, not batch. When a critical customer files a ticket, that context is available in the knowledge graph within seconds, not after tonight's batch job.

When an agent queries Computer Memory, it isn't fanning out API calls to eight different systems and hoping the model can piece the results together. The retrieval engine uses three layers that work together: Text2SQL for precise structured queries (returning exact facts like "revenue is $2.4M" instead of dumping tables into the prompt), vector search for semantic matching over unstructured content (retrieving relevant passages, not whole documents), and a reverse index for lightning-fast exact lookups on ticket IDs, customer names, and error codes. A single query might use all three, assembling a tight, precise context window in a fraction of the tokens that naive RAG or raw MCP fan-out would require.

The efficiency difference is measurable. In our own benchmarking comparing equivalent queries routed through Claude directly versus through Computer Memory's retrieval engine, we've seen 60% fewer tokens consumed. DevRev's published benchmarks show sub-200ms response times for retrieval queries through distributed caching and multi-region architecture. I should note that complex cross-system questions like the VP of CS example above involve more than a single retrieval call, but even those compound queries are dramatically faster and cheaper than having an agent fan out to multiple external APIs and wait for each to respond. Fewer tokens means lower cost, faster responses, and fewer hallucinations.

I want to be careful here because it's easy to read this as "MCP bad, knowledge graph good," and that's not the right framing. They solve different problems. MCP is excellent at what it does: giving agents a standardized way to take actions in external systems and query them in real-time. If an agent needs to create a Jira ticket, send a Slack message, or update a Salesforce record, MCP is the right tool. The memory layer and the action layer are complementary. The question is whether you try to use the action layer as a substitute for the memory layer, and I think the answer, at enterprise scale, is clearly no.

This matters because wrong answers lead to wrong actions. And for enterprises, wrong actions carry real consequences.

An agent that confidently tells a customer success manager "this account is healthy" because it only queried the CRM and missed three escalations in the support system isn't just giving a bad answer. It's creating a false sense of security that could cost a six-figure renewal. I've written about how guardrails are the product in production AI, and I've come to think the data layer is the most important guardrail of all. An agent's judgment can only be as good as the context it reasons from. If the memory is fragmented, incomplete, or stale, the actions will be too.

And unlike a chatbot hallucination that a human might catch and dismiss, an autonomous agent acting on bad context can trigger workflows, update records, and send communications before anyone realizes the underlying data was wrong. A chatbot that hallucinates wastes a user's time. An agent that acts on fragmented data can damage customer relationships, misallocate engineering resources, or generate compliance violations. The more autonomy you give the agent, the more the memory layer matters.

This is also why data safety matters as much as data access. As agents become more autonomous, operator errors are inevitable, just as they were with databases for 40 years. Computer Memory treats data like code: every change is versioned, provenance-tracked, and stageable before pushing to the team. You can rollback, revert, snapshot, and recover. When an agent makes a mistake (and it will), you need to be able to trace exactly what it knew, when it knew it, and what it did with that knowledge, regardless of which model was doing the reasoning. That kind of auditability has to be in the architecture from the start. You can't bolt it on after your agent has been running in production for six months and someone asks "why did it send that email to our biggest customer?"

Permissions widen the gap further. MCP's OAuth 2.1 support means an agent can authenticate as a specific user, which is a good start. But knowing who someone is isn't the same as knowing what they're allowed to see across a dozen interconnected systems.

To give you a sense of how different these models are: Jira organizes access through project-based permission schemes with global permissions, project-level permissions organized into reusable schemes, and issue-level security. Google Drive does something completely different, using a file-centric sharing model with four permission levels inherited from parent folders. And Salesforce adds yet another approach, combining organization-wide defaults with role hierarchies, profiles, permission sets, and sharing rules. Normalizing these into a single coherent authorization model is the kind of problem that sounds straightforward until you actually try to solve it across dozens of systems.

AirSync replicates ACLs, roles, and sharing rules from every source system, normalizes them into a unified authorization model, and keeps them synchronized in near-real-time. Governance stays intact without a single rule to configure. The architecture uses a dual-layer approach: an immutable foundation that mirrors the source system's permissions exactly, and an optional additive layer for cross-team collaboration within DevRev without altering the source system's access controls. When someone loses access to a project in Jira, they lose access to that data in DevRev through the next sync cycle. The source system always remains the authoritative source of truth.

None of this was fast to build. Every source system has its own authorization model, its own notion of roles and groups and sharing, its own API for querying access controls. We have patents covering core pieces of this work. US patent 12,475,156 covers our multi-tenant vector database implementation that makes it possible to maintain per-tenant isolation at scale. A separate granted patent covers our techniques for identifying linkable items across systems and generating recommendations for linking them, which is the foundation of how Computer Memory connects records from different sources. I mention these not to wave credentials but because they represent years of engineering work on problems that most teams don't even realize exist until they're deep into a deployment. You don't replicate a knowledge graph with real entity linkage and permissions-aware retrieval on a weekend hackathon.

There's another angle that I think gets underappreciated in these conversations. Multi-model is the new multi-cloud.

Enterprises learned the multi-cloud lesson the hard way. Locking into a single cloud provider was a strategic liability. Companies that maintained optionality and invested in their application layer outperformed those that bet everything on a single provider. The same pattern is emerging with AI models, on a compressed timeline.

Managed Agents runs exclusively on Anthropic's infrastructure, using Anthropic's models. As of launch, there's no support for bringing your own model, self-hosting, or running through Amazon Bedrock or Google Vertex. That's fine today, when Claude is arguably the best model for agentic work. But every major AI lab is shipping dramatically better models at dramatically lower prices. The right strategy isn't to pick the "winning" model. It's to invest in the layer that gives you optionality regardless of which model wins.

Computer Memory is model-agnostic by design. The knowledge graph, the sync engine, the permissions layer, none of these depend on which LLM is doing the reasoning. You might use a reasoning model for deep engineering analysis, a conversational model for customer support, and a cost-efficient model for high-volume ticket deflection, all sharing the same memory, all respecting the same permissions. We can swap models as the landscape evolves without rebuilding the data foundation. That's not a theoretical capability. It's how we operate.

There's a compounding effect here that I think is underappreciated. When a better model ships (and it will), you swap it in, and it benefits from a knowledge graph that's been building and enriching itself for months or years. A smarter model reasoning over the same knowledge graph produces better search, better answers, and safer actions. You don't rebuild anything. I should be honest that "swap" understates the work involved: you do need to re-tune prompts and re-run evaluations when you change models. But the data foundation, the relationships, the permissions, the entity mappings, all of that persists. The expensive, slow-to-build part doesn't change. The model is the component that gets cheaper and better over time.

I wrote earlier that build vs. buy is the wrong framing for AI decisions. What matters isn't who builds the technology but how fast your organization learns. Managed Agents shifts where that framing applies. The infrastructure layer is now settled, buy it. But the data layer is where the build vs. buy conversation gets genuinely hard. Building a multi-system data integration layer with real-time permissions sync, unified schema mapping, and a query engine that translates natural language into precise, auditable SQL across that unified schema is a multi-year engineering commitment. It was a distraction when the agent infrastructure was also hard to build. It's an even clearer "buy" now that the infrastructure is a commodity.

I think the pattern here is familiar if you zoom out. Cloud infrastructure started emerging in the late 2000s when AWS launched S3 and EC2, and the real commoditization happened through the 2010s as Amazon, Google, and Microsoft drove prices down through aggressive competition. Nicholas Carr argued in his 2003 Harvard Business Review piece IT Doesn't Matter that IT was becoming a commodity input, that the strategic advantage of technology would erode as it became universally available, that corporate IT would go the way of the railroads and the telegraph. The prediction was directionally right about infrastructure but wrong about what it would do to software companies. Cheaper infrastructure made it easier to build software, which meant the companies with proprietary data, domain expertise, and deep customer integrations became more valuable, not less.

I should be honest that the parallel to agent infrastructure isn't perfect. Cloud compute is more fungible than agent infrastructure, and Anthropic could always decide to move up the stack. They could build or acquire a data layer company. They could extend Managed Agents with built-in knowledge graph capabilities. I don't think they will, because it would undermine the ecosystem of companies building on their platform, but I've been wrong about platform incentives before. It's also worth noting that the MCP ecosystem is evolving fast, and community-built MCP servers are starting to add caching, context persistence, and other features that partially address the problems I've described. The gap between "action layer" and "memory layer" may narrow over time, though I think the hardest problems (entity resolution, permissions normalization, cross-system schema mapping) are structurally difficult to solve at the protocol level.

"We built an agent" is no longer a differentiator. Every startup can spin one up on Managed Agents now. The differentiator is what the agent knows and how reliably it knows it. An agent backed by Computer Memory that has pre-computed the relationships between your systems, that respects the access controls your organization has already defined across Jira, Salesforce, and Google Drive, that can answer questions grounded in structured data rather than reconstructing context from scratch on every query, that's a fundamentally different product than an agent that queries systems individually at runtime and hopes the LLM can piece together the picture.

Managed Agents doesn't compete with any of this. If anything, it creates a larger market of teams who now have the infrastructure to run agents but still need something for those agents to reason over. The companies that should be worried aren't the ones sitting on years of data integration work, a knowledge graph with real entity linkage and permissions sync. They're the ones who were selling the plumbing. I suspect most of them are having some version of the conversation I had this week, except their answer to "does this threaten what you're building?" lands very differently.