Build1 distinct publisher3 min readPublished
Fabiane Nardon of TOTVS, whose systems she says carry about a quarter of Brazilian GDP, puts the engineering work in the data access layer, because that layer decides what an agent loop can read and how stale the read is allowed to be.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Applications emit a bounded set of query shapes. Someone tuned the indexes to the screens, and the screens changed on a release cadence. A reasoning loop picks its query shapes at inference time and emits them in bursts, because each tool result determines the next call, so hundreds can land in a few minutes [5]. That is a workload nobody captured before wiring the first tool.
Nardon's list of reasons not to point an agent straight at the transactional system reads like a capacity review of exactly that profile. The systems are usually not prepared to receive lots of unpredictable queries [10]. They may not have the power to run the historical processing you need to prepare the data [11]. The data may carry noise that has to be cleaned before it reaches the agent [12]. And a legacy database may not support semantic search at all, which is what pushes you toward a vector database [13].
So the data gets copied to a platform, prepared there, and exposed to the agent over MCP or another data access protocol [14]. The bill arrives as staleness: Nardon says the platform copy is always a little delayed relative to the transactional system, and some workflows therefore have to read the live system directly [15]. In my context the only way to keep that honest is to declare each tool's freshness as part of its contract, so the model is not inferring how old its answer is. That is my design opinion, not a claim from the talk.
Then the precision number. Transactional systems are usually expected to hit 99.99% [7], which is one defect per 10,000 operations [8]. Probabilistic reasoning will not match that, and Nardon's position is that you deal with the gap rather than close it [7]. Her rule for deciding what goes to the deterministic side uses three variables, precision, security and cost, and she says all three depend on how you supply data [9]. The success of the application depends on where that line falls [18].
For the TOTVS answer to transfer, a few things have to be true of your estate. You have transactional systems you cannot resize on demand, including on-premise ones [1]. Your blast radius justifies maintaining a second prepared copy of the data: Nardon puts about a quarter of Brazilian GDP through these systems [2], in what she notes is the tenth largest economy in the world [3]. And your agents are enterprise-grade in her sense, which she explicitly separates from coding agents and personal agents [16]. A coding assistant working against one repository needs none of this. She describes TOTVS as probably the biggest tech company you never heard of [19], which is about what you would expect of the software sitting under a quarter of a national economy. The published transcript breaks off mid-sentence as she starts on combining the two sources [20], so the security and cost halves of her own formula are not on the record here.
Ranked by verification strength, evidence, and original report placement.
Fabiane Nardon works for TOTVS, which has been building enterprise systems in Brazil for the last 40 years, spanning SaaS, on-premise and everything in between; most of its systems are on-premise transactional systems.
When TOTVS started building AI agents, the problem was not lack of data but too much data, none of it prepared to be accessed by agents.
Nardon frames the test as whether enterprise data is prepared to be accessed by a token-hungry, latency-sensitive reasoning loop that can fire hundreds of unpredictable queries in a few minutes.
Data in transactional systems was optimized to be accessed by applications, data in the data lake was optimized to be accessed by data analysts or dashboards, and none of it was optimized to be accessed by AI agents.
Nardon says enterprise transactional systems are usually expected to have 99.99% precision, that agents using probabilistic reasoning will never reach the same level of precision, and that teams have to deal with that gap.
Nardon says the decision about which part of the software goes to the deterministic model and which to GenAI is based on three variables, precision, security and cost, all of which depend on how data is provided to the systems.
Distinct publishers with included, body-backed reporting in this cluster.
Follow any of these and your For You feed starts watching them — no settings page required.
security
Reco puts 80% of employee AI tools outside IT oversight against 21% of SaaS2 distinct publishers
build
Four agent runtimes, four blast radii: the teammate interface converged, isolation did not1 distinct publisher
build
Agent payments stop being a demo when the wallet lives outside the model's reach1 distinct publisher
invest
Google's bank agent can read FactSet. The licence, not the model, decides how much.1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One speaker, one stage, nothing checked twice
Everything here comes from Fabiane Nardon's own talk on InfoQ; she is describing systems she helps build, which makes her a first-hand witness and also the only one. The engineering reasoning largely carries itself — query bursts, staleness, write paths — but the figures that give the story its weight, the quarter of Brazilian GDP and the 99.99% precision bar, are asserted rather than demonstrated, and the published text stops mid-sentence right before the payoff.
Real practice inside one vendor, sized by nobody
TOTVS has agents in flight and a house rule governing which reads hit the ERP and which hit the data platform, so this is practice rather than a slide deck. What is entirely missing is magnitude: no agent count, no customers named, no throughput, latency or accuracy figure, and no second organisation in this reporting doing the same thing. Internal adoption at one Brazilian software house is the full observed footprint.
Sober advice leaning on one unchecked figure
The talk under-sells more than it over-sells: its headline point is that probabilistic agents will never reach transactional precision, which is nobody's sales pitch, and the recommendations read like scar tissue. The small gap sits in the framing rather than the content — 'about a quarter of Brazilian GDP' does a lot of persuasive work for a number only TOTVS has ever produced, and the copy-then-read architecture is presented as settled company practice without one before-and-after result behind it.
Vendor engineer presenting the vendor's own answer
Nardon speaks for TOTVS, and the conclusion — prepare a copy, reach into the ERP for writes and fresh reads — is TOTVS's internal recommendation delivered by the company that sells the ERP underneath it. Pulling the other way, the conference format rewards technical credibility rather than pipeline: no pricing, no product name, no ask anywhere in the text. The interest at work is reputational more than commercial.
Firm on mechanics, thin on magnitudes
We are on solid ground about what was said and why it matters to anyone bolting an agent onto an ERP: the mechanism — systems tuned for screens and batch jobs meeting a bursty reasoning loop — is internally consistent and matches how such systems behave. We are on soft ground about size and outcome, with no second publisher, no figure that can be tested, and a transcript that ends before the synthesis it was building toward.