Architecting the Data Layer for AI Agents is not about a lack of data, but rather that the data is not ready for agent access. This changes the architecture: decisions need to be made about where to keep the source of truth, how to reduce token overhead, and how to maintain accuracy, security, and cost.
The issue here is not with the model or the amount of data. The problem is that traditional transactional systems were designed for applications, while data lakes were designed for analytics and dashboards. AI agents operate differently: they generate many unpredictable queries, are sensitive to latency, and can produce hundreds of requests in minutes. If they are connected directly to an old schema without preparation, the system will quickly run into load issues, data noise, and limitations of legacy databases.
Therefore, Fabiane Nardon describes not a single solution, but a set of trade-offs. For fresh data and write operations, a transactional system is needed because the data platform is always slightly delayed. For historical data, semantic search, and enrichment, a data platform is more convenient because it allows for data preparation, noise cleaning, and the addition of necessary semantics. This is not a question of “which is better,” but rather which layer should serve a specific workflow.
Next, the question arises about the organization of the data layer itself. Here, a data mesh is chosen because it works well in companies where data is distributed across domains. Each domain owns its data product, which means not only data but also an owner, a stable interface contract, documentation, discoverability, and quality SLA. This is an important shift for architecture: data begins to exist as a managed service rather than as a set of tables without accountability.
The approach to MCP tools is particularly illustrative. The team linked each tool with a data product, thereby transferring governance principles to the access layer for agents. This reduces chaos around generic tools like get_schema or generate_query. Instead of universal but vague interfaces, specialized tools emerge that understand the subject area and can extract data more accurately. This approach is pragmatic: it slightly complicates modeling but significantly improves manageability and accountability.
However, even a good data architecture does not solve the semantic problem. Within a single company, the same terms can mean different things. Active customer, churn, or other basic concepts often diverge between marketing, finance, and other domains. For humans, this is tolerable because context accumulates through communication. For LLMs and agents, this is a weak point because they cannot rely on the implicit knowledge of the team. Therefore, Nardon points to the Semantic Web and semantic ontologies as a way to make the meaning of data explicit.
The main engineering thought here is simple. Enterprise-grade agents cannot be built on data that has been optimized only for humans or only for analysts. A layer is needed that can balance precision, security, and cost. Different access paths are needed for different tasks. Data products with owners and contracts are necessary. And semantic models are required so that the agent does not confuse formally similar but business-significantly different entities.
The text does not contain numerical metrics of gains, aside from the general thesis of reducing token overhead and optimizing context windows. But the architectural conclusion is clear: preparing the data layer becomes part of the engineering contour of AI systems, rather than a secondary task. And the more complex the enterprise environment, the more this layer influences the accuracy of responses, the cost of queries, and the predictability of system behavior.