At QCon AI, Fabiane Nardon argued that enterprise AI agents fail or succeed less on model choice than on how well the data layer is prepared for them. In her talk, “Architecting the Data Layer for AI Agents: From Transactional Systems to MCP and Semantic Models,” the TOTVS executive laid out a practical approach for balancing precision, security, and cost when agents need access to transactional systems, data platforms, semantic models, and Model Context Protocol (MCP) tools.
Why enterprise data needs a different design for AI agents
Nardon said TOTVS, which has spent 40 years building enterprise systems in Brazil, encountered a familiar problem when it began building AI agents: not a shortage of data, but too much data that was not ready for agentic access. She described transactional systems as optimized for application access, while data lakes were built for analysts and dashboards. Neither, she argued, was designed for a “token-hungry, latency-sensitive reasoning loop” that may issue hundreds of unpredictable queries in minutes.
That mismatch matters because enterprise systems typically demand high precision and reliability, while LLMs and agents are probabilistic by nature. Her core message was that teams should decide which parts of an application belong in deterministic software and which can be handled by AI, then shape the data layer around that decision.
Precision starts with choosing the right source of truth
Nardon said the first question is where an agent should fetch data from: the transactional system or the data platform. For write operations, fresh reads, and business rules embedded in the source system, she said the transactional system should be the target. For historical processing, stale-but-acceptable data, semantic search, and enrichment, the data platform is a better fit.
She stressed that this is not an either-or choice. The right architecture mixes both sources depending on workflow needs. In her view, agents should reach into transactional systems only when they truly need live data or system-enforced rules, while data platforms should handle the heavier preparation work that makes agent responses more accurate.
Data mesh and data products as the organizing model
To make the data platform useful for agents, Nardon pointed to data mesh as a strong organizational pattern. In data mesh, data is split across business domains, each with a self-serve platform that lets teams manage data closer to the business context. The key unit is the data product: a piece of data prepared for others to consume, with an owner, a stable interface contract, documentation, discoverability, and quality SLAs.
She said TOTVS aligned its MCP tools with that same structure. Each tool is tied to a data product, which means the tool also inherits ownership, contracts, and governance. That approach turns MCP from a generic access layer into a domain-aware interface with clear accountability.
Semantic models help resolve ambiguity for agents
One of the most interesting parts of the talk focused on semantics. Nardon said enterprises often have multiple valid definitions for the same term. A customer may be “active” in marketing but mean something different in finance. Humans can usually resolve that ambiguity through experience and context; agents cannot.
To address that, she turned to the Semantic Web, RDF, and ontologies. Her argument was that unique identifiers for concepts and formal relationships between them can remove ambiguity and give LLMs a better understanding of the domain. She noted that while creating ontologies was once a heavy manual task, LLMs now make it much easier to generate them from documentation.
How semantics can improve response quality
Nardon gave a simple example using ChatGPT. When asked which customers bought hardware, the model inferred that servers counted as hardware. But when she supplied ontology context showing that “server” was a subclass of cloud service, the model answered differently. She cited a 2024 study claiming that adding an ontology-based semantic layer improved LLM response precision by 40%, while noting that results vary by domain and data formatting.
In practice, she said, the semantics can be narrowed to just the portion relevant to a given data product, rather than loading an entire enterprise ontology into the context window.
Low-latency data layers matter more in the agent era
Nardon also described how TOTVS structured its data platform into latency tiers. The high-latency layer uses Apache Spark for batch processing of Parquet files. A medium-latency layer based on Google BigQuery handles larger volumes, but at a higher cost. For agent use cases, the company added a low-latency layer using Postgres and DuckDB for smaller data volumes and fast retrieval.
She said the platform also needed low latency in processing, not just in retrieval. Data must be cleaned, enriched, and made available quickly so it stays fresh for agents. For heavy transformations, Spark still plays a role, but the prepared result must end up somewhere the agent can access quickly.
Her low-latency design leaned on an older technology rather than a flashy new one: a transactional database. She said Postgres triggers and stored procedures are used to fire pipelines quickly and atomically, then make the resulting data available for semantic search and agent retrieval.
Security comes from limiting what the model can generate
On security, Nardon contrasted two patterns. A generic database tool that lets an LLM inspect schema and generate queries is flexible, but vulnerable to prompt injection. TOTVS instead favors parameterized tools with security baked into the tool itself, which reduces the model’s ability to invent arbitrary queries.
She also described identity propagation. The AI agent authenticates through the company identity provider, typically with OAuth, and the logged-in user identity is passed through to the tools. That allows the system to filter results based on the user’s permissions, such as showing only employees who report to that user.
Cost control means treating tokens like a scarce resource
Nardon said token economics are especially important in Brazil, where AI costs bite sooner because of local purchasing power. Her point was broader than geography, though: every unnecessary token carries a cost, and enterprise agents should avoid sending more data than needed.
That led to two practical techniques. First, the company built what Nardon called “MCP Fabric,” a single service that can expose many virtual MCP servers rather than deploying a separate service for each one. She said this makes it cheap and fast to create dedicated MCP servers for different agents.
Dynamic tool search keeps context windows small
Second, TOTVS uses dynamic tool search. Instead of placing every available tool directly into an agent’s context, the agent first calls a search tool, which returns only the most relevant tool candidates. Those selected tools are then injected into context. Nardon said this reduced token use significantly in a benchmark spanning 10, 25, 50, and 100 tools.
She also pointed to response formatting as another cost lever. JSON is familiar and precise, but verbose. For flat data, she said CSV can cut token usage by up to 50%. She also mentioned TOON, a newer format the team is testing, which may save 30% to 60% of tokens, though with possible tradeoffs in model understanding because LLMs have been trained much longer on JSON and CSV.
The larger lesson: put the right work in the deterministic layer
Nardon’s closing argument was straightforward: the more code and business logic you can push into deterministic systems, the more precise, secure, and cost-efficient your AI application becomes. The non-deterministic layer is where the model’s strengths matter most — language understanding, reasoning over incomplete information, and handling ambiguity.
For enterprise teams building agents, her talk was less about chasing a single architecture than about assembling the right pieces: transactional systems for fresh writes and rules, data platforms for prepared and semantic data, MCP for controlled access, and careful token management so the agent can do useful work without overwhelming the context window.
Source: Original report
Was this helpful?
Explore more: AI Automation Services More AI & Automation Tech News
Last Modified: August 30, 2026 at 1:52 am
0 views
