AI Agents Expose the Data Problem Companies Have Dragged for Years, Inc42 and Oracle Debate Shows

Companies have been accumulating data for years. Making it usable for AI is proving far harder than simply storing the data itself. That was the starting point of a roundtable hosted by Inc42 in partnership with Oracle during the CTO Summit 2026 in India, bringing together CTOs and founders to discuss how to build the data foundation that supports AI agents in production.

The problem isn't new, but agentic AI has made it impossible to ignore. Systems built for different teams, functions, and use cases left information scattered across databases, applications, and workflows. An agent that needs to reason about the entire organization isn't satisfied with finding the data somewhere: it needs to understand what that data means and use it in the right context.

The Size of the Bottleneck

A Dun & Bradstreet survey cited at the event captures the scale of the problem: 73% of the Indian companies surveyed report some measurable return from AI investments, but only 4% say their corporate data is fully ready to support AI at scale. That's a big gap between "it already works somewhere" and "it works reliably and broadly."

Closing that gap means dealing with years of accumulated data debt: customer identities fragmented across systems, operational data isolated in silos, information organized for reporting that doesn't serve an agent that needs to retrieve it and act on it. For anyone working with data pipelines in Brazil, the scenario is familiar: CRM, ERP, and product datasets that were never designed to talk to each other.

Outcome First, Architecture Second

The strongest consensus in the debate was that the architecture decision shouldn't come before the business question. Dhruv Gupta, co-founder of Orchard Healthcare, described the logic he followed when building the company's customer data platform, a six-month project, like this:

The way we think about it is backwards. What is the problem to be solved?

Dhruv Gupta, co-founder of Orchard Healthcare

Syed Mohd Bilal, head of data science at Perfios, reinforced the same order of priority: desired outcome first, tool selection only afterward.

Start from an outcome focus and then figure out what to build rather than, you know, thinking about tools first.

Syed Mohd Bilal, head of data science at Perfios

Once the outcome is defined, a real architectural choice remains: build for that specific use case or invest in a platform that supports multiple applications. Bilal summarized the trade-off: use-case-driven development solves the immediate need, while the platform-first approach creates a broader foundation for future applications.

Vinay Murthy, senior director of product at Zeta, argued that AI is making that broader foundation increasingly hard to postpone, because employees and systems are starting to create agents on their own, outside central IT control.

What AI gets in is that the use cases are no longer in your control.

Vinay Murthy, senior director of product at Zeta

This places an extra demand on the underlying platform: it needs to serve already-known applications while also allowing new agents to find and interpret data for needs the company hasn't even defined yet.

The Semantic Layer Becomes a Prerequisite

Connecting an agent directly to a database doesn't solve the problem on its own. Palanivel Saravanan, head of infrastructure and cloud engineering at Oracle, cited the common scenario of information scattered across Oracle, MySQL, PostgreSQL, MongoDB, and unstructured knowledge: connecting the agent directly to those systems runs into the fact that it may not understand the database schema or generate queries the database can execute efficiently.

The solution discussed on the panel is an intermediate layer between the agent and the data, responsible for interpreting structure and meaning before planning information retrieval. In traditional systems, it was a human who connected operational data to a business decision; with autonomous agents, part of that reasoning needs to be encoded in the data layer itself.

The semantic layer is only required or is becoming mandatory to support the reasoning for the agent.

Palanivel Saravanan, head of infrastructure and cloud engineering at Oracle

For those who build pipelines, this has a direct parallel with what's already seen in RAG architectures and protocols like MCP: without a consistent semantic catalog (field names, business relationships, quality rules), the agent either hallucinates impossible joins or returns a result that's technically correct but semantically wrong. Bilal, from Perfios, added that semantics also helps reduce the model's search space, making retrieval more focused instead of scanning the entire database.

Whoever is closest to the data, according to Bilal, should be the one defining its meaning, and that definition needs to be consistent across tools and platforms, not documented only in an analyst's head.

Who Can Access What

Making information understandable doesn't resolve the question of who can use it. Abhimanyu Saxena, co-founder of InterviewBit and Scaler, illustrated the dilemma with a direct question: if a model learns from Bank A's data, can that knowledge be reused for Bank B? Using corporate data to train or improve an AI system carries legal and technical implications that go beyond the original usage contract.

The same problem appears within a single company, when employees use frontier models to work with internal data without centralized control. Himanshu Garg, CTO of Kapture CX, was direct:

So how do you build governance around this right? That is the most critical thing.

Himanshu Garg, CTO of Kapture CX

At Kapture, that means applying access control directly over the knowledge and context graphs that agents query, plus building test harnesses to automate evaluation of agent behavior before releasing it into production. For platform and security teams in Brazil, it's the same kind of IAM discipline and access policies that already exist for internal APIs, just now applied to an agent that decides on its own which calls to make.

Not Every Agent Needs a Frontier Model

The last piece discussed was purely financial. Naveen Dachuri, CTO of Yulu, separated two scenarios: internal AI tools, where the company sets the budget, and AI embedded in a customer-facing product, where usage and cost are much harder to predict. In Yulu's bicycle repair case, the math is more straightforward: you can weigh the reduction in manual touches and response time against the cost of running the agent.

So the value versus cost balance. It is most important.

Naveen Dachuri, CTO of Yulu

Maintaining that balance also involves choosing the right model for each task. Kapture uses smaller models for predictable tasks, such as order status lookups, instead of invoking a frontier model for every interaction. Saravanan, from Oracle, noted that companies are moving away from the one-model-for-everything approach, and that open-weight models have been offering a more predictable cost structure for part of these workloads.

What Remains for Those Who Build

The roundtable's takeaway for those designing data architecture is concrete: semantic layer, granular per-agent access control, and task-based model routing have stopped being a future optimization and become a production prerequisite. None of these three elements comes ready-made in an off-the-shelf AI platform; they require data modeling, governance, and observability work that falls to the engineering team, not the model vendor.

What remains open, even for those who took part in the debate, is how to standardize this work across organizations: there is still no common framework for deciding how far a context graph should extend, nor a settled answer on reusing trained data across different customers of the same AI vendor.