Key Highlights
- Model quality is rarely the reason enterprise AI projects stall. Frontier models have become good enough, for long enough, that switching costs between providers are now low; the model layer is becoming a commodity.
- More than 90% of industry leaders say their data infrastructure isn’t ready for AI agents; fewer than 10% believe it is, according to research cited by CData.
- Traditional analytics architectures, medallion and lambda designs, batch ETL/ELT pipelines, etc., were built to feed dashboards, not to give autonomous agents live, governed access to production data.
- CData frames enterprise AI readiness around three requirements: Connectivity (can the agent reach the data), Context (can it reach the right data efficiently), and Control (can every action be scoped, authenticated, and audited).
- Poorly curated MCP tool surfaces are a leading cause of runaway token costs and weak accuracy. CData says its Connect AI platform returns accurate answers 98.5% of the time, about 25% higher than other MCP providers, at meaningfully lower token cost, with benchmarks showing up to 95–97% token savings versus DIY MCP servers.
- As agents move from read-only access to writing back into production systems (CRM, ERP, ticketing), per-user authentication, audit logging, and tightly scoped tool access become non-negotiable.
- What’s next: semantic understanding of enterprise data as a first-class capability, and a unified “AI gateway” control plane for governing LLM traffic, MCP traffic, and tool calls in one place.
The Model isn’t the Problem Anymore
I talk to a lot of enterprises building AI agents and assistants, and there’s a pattern I keep running into: teams assume that when an AI project underperforms, the fix is a better model. That assumption is increasingly wrong. I sat down recently with Amit Naik, VP of AI Architecture at CData, for an episode of our Age of AI podcast, and his take on this was blunt: the large language models powering most enterprise AI applications have become good enough, and have been for six to nine months, that the model layer is starting to behave like a commodity. Switching from one frontier model to another is no longer the hard part.
If the model isn’t the gating factor, then where do enterprise AI projects actually break down? Naik’s answer, and it tracks with what I’m hearing across the vendors and IT leaders I brief with, is the data layer, the plumbing between the model and live business systems.
Watch the full conversation here:
Why the Demo Works and Production Doesn’t
The pattern Naik described is familiar to anyone who has watched an AI pilot go sideways. Demos are built on clean, narrow data sets, with a handful of use cases and none of the edge cases that show up in real operations. When a demo agent gets an answer wrong, the fix is to try again. In production, a wrong answer on a forecast, a customer-facing response, or a write-back action carries real cost, and that’s exactly where enterprises start to notice that accuracy in the 50–60% range, which might pass in a demo, doesn’t come close to cutting it once real budget and real customers are on the line.
Part of the reason, Naik explained, is architectural. Most enterprises exposed their analytics stack to AI first, because that’s the side of the house already set up for querying. But medallion and lambda architectures, and the batch ETL/ELT pipelines that feed them, were designed for pre-canned queries that power dashboards—not for an agent that needs live, governed, sometimes exploratory access to operational data in the moment. That mismatch shows up fast: Naik cited survey data in which fewer than 10% of industry leaders said their data was actually ready for AI agents, versus more than 90% who said their infrastructure wasn’t.
The Three C’s: Connectivity, Context, Control
CData’s framework for enterprise AI readiness comes down to three requirements, and Naik was clear that an enterprise needs all three, not just one, before an AI project can move from pilot to production.
Connectivity is table stakes: the agent needs governed access into the systems where the business actually runs; think CRM, ERP, ticketing, HR platforms, and everything in between. This is the layer CData built its original business on, and the company now maintains a catalog Naik put at somewhere between 350 and 500 connectors.
Context is where cost and accuracy are actually won or lost. Having connectivity doesn’t mean an agent knows what to do with it; without the right context surfaced into the model’s window, an agent can end up on an expensive, inaccurate exploratory tour through enterprise data, burning tokens and returning answers nobody trusts.
Control is the piece that becomes unavoidable the moment security and compliance teams get involved. Naik’s point was direct: teams that can’t answer basic questions: what did the agent do, where did the data come from, who authorized it, won’t get a production green light, no matter how impressive the demo looked.
Why DIY MCP Servers Backfire
MCP (Model Context Protocol) has moved, in Naik’s words, from feature to infrastructure, a standard way for agents to talk to enterprise systems instead of every team hand-coding bespoke integrations. But Naik, who has built MCP servers himself, was candid that spinning one up isn’t the hard part; designing it well is. Early, informally built MCP servers tend to expose tens or even hundreds of tools to an agent at once, with no real curation of schemas, scope, or permissions. No agent reasons well across that many similarly named tools, and the token math on a single poorly scoped conversation, multiplied across the thousands of conversations agents actually have, adds up fast.
Naik framed this as a build-versus-buy question that’s more nuanced than it looks. Coding agents make it trivially easy to generate an MCP server; that doesn’t mean production systems are where a team should be doing that generating. His advice: focus engineering effort on the domain where you’re actually the expert, and treat well-curated enterprise connectivity as infrastructure to buy, not build.
The Token-Cost Math Behind Accuracy
According to Naik, three factors drive whether token costs stay in control or spiral: how well the exposed tools are designed, how tightly scoped the context returned by each tool call is, and how efficiently an agent can discover the right information across a multi-step tool-calling conversation. Get any of the three wrong—ambiguous tool names, oversized schemas returning 70 columns when five would do, unscoped exploratory back-and-forth with the model—and both cost and accuracy move in the wrong direction simultaneously.
CData points to internal benchmarking showing its Connect AI platform returning accurate answers 98.5% of the time, roughly 25% higher than other MCP providers Naik referenced, while cutting token costs by as much as 95 to 97% compared with a self-built MCP server. Features like derived views, pre-built joins across systems such as Salesforce and Jira that an agent can call as a single tool are, in Naik’s telling, a big part of how that gap closes.
When Agents Start Writing Back, the Risk Model Changes
Read-only “chat with your data” use cases are a reasonable starting point, but Naik was direct that the real value, and the real risk, shows up once agents can write back to production systems: opening a ServiceNow case, updating a CRM record, posting to an ERP. Because AI systems are heuristic rather than deterministic, giving one write access to live data meaningfully expands the risk surface, and Naik walked through three guardrails he considers non-negotiable at that point: per-user authentication so every mutation traces back to a real identity rather than a generic service account; audit logging robust enough that a security team can reconstruct what happened after the fact; and scoped tool access—CData calls this toolkits and workspaces—so an agent that can read from five systems might only be able to write to one, narrowly. The goal, as Naik put it, is reducing the blast radius if something goes wrong, not assuming nothing will.
Where the Use Cases are Landing First
Naik pointed to a handful of patterns showing up repeatedly across CData’s customer base: sales and FinOps teams synthesizing account signals across CRM records, call recordings, and spreadsheets to flag which customers are worth a proactive outreach; customer support and engineering teams tying ticketing systems back to code repositories and documentation to shorten root-cause turnaround; a genuinely new pattern Naik called a “software factory,” where coding agents pull work items from Jira, reference a spec document, generate and validate code, and push it into production with far less manual hand-coding; and finance teams generating revenue and forecast answers directly from live data instead of recollection and manual pull-togethers.
What Comes Next
Naik was careful to bound his predictions to the next 18 to 24 months rather than further out. Given the rapid evolution of the AI landscape, including models, and tooling, this is where I land as well. Predictions or plans beyond that time frame are, to my way of thinking, fairly useless. Within that window, he sees two priorities defining the next phase of the enterprise data layer: deeper semantic understanding of enterprise data, so agents reasoning across CRM, ticketing, and collaboration systems can interpret what the underlying data actually means rather than relying on pre-canned joins; and a unified “AI gateway” control plane that governs LLM traffic, MCP traffic, and tool calls in one place, giving security and IT teams a single point of visibility and policy enforcement instead of stitching oversight together across five different systems.
My Take
This conversation reinforced something I’ve been saying for a while: the bottleneck in enterprise AI adoption isn’t model access, it’s implementation and organizational design. Enterprises that treat the data layer as an afterthought, something to bolt on after the demo impresses the board, are the ones that end up explaining runaway token costs and stalled pilots to their CFO and their board. The ones getting real production value out of agentic AI are treating connectivity, context, and control as a single architectural decision, made early, not three separate problems to solve in sequence after something breaks.
This article was originally published on LinkedIn.
Read more of my coverage:
Commvault and Microsoft Just Made Resilience a Native Azure Experience — Here’s Why That Matters