Data agents need per-model ontologies, not shared schema dumps

The core problem EvoOntology addresses is embarrassingly common: a data agent querying a large, heterogeneous collection of tables, files, and databases has no prior map of what lives where. It rediscovers schemas from scratch on every task, burns turns on exploratory probes, and discards whatever it learned when the session ends. The paper calls this the agent–data gap, and the proposed fix is an ontology layer that persists, adapts, and exposes itself through tools rather than flooding the prompt.

The architecture is three-layered: a content graph of typed semantic objects (Terms, Mappings, Constraints, Evidence), a schema that governs what those objects can express, and a tool layer that wraps everything as an MCP server. Agents query it selectively at runtime instead of receiving a static dump. That distinction matters more than it sounds. The paper shows that injecting the same semantic content as a static prompt fragment either fails to improve performance or actively hurts it—on Claude-Sonnet-5, the static baseline drops trajectory-wise accuracy relative to no layer at all. The MCP-tool approach avoids that by letting the agent pull only what the current step needs.

Construction is autonomous. A builder agent issues probe queries over raw sources, commits only candidates whose type, filter, and value-distribution checks pass, and retains the supporting evidence. Evolution then runs on historical trajectories: the system attributes failures to specific ontology levels, proposes a single-level edit, and accepts it only if it clears a backbone-conditional paired evaluation gate. Removing that gate causes the largest ablation drop of any component tested, because unfiltered edits introduce regressions the next round cannot reliably undo.

The efficiency finding is counterintuitive. Adding the ontology layer increases per-turn input tokens modestly, but the evolved ontology shortens average trajectories enough that total tokens per task fall below the no-ontology baseline on DDR-Bench, while trajectory-wise accuracy rises substantially over the same comparison. The ontology pays for itself in reduced redundant exploration.

One result worth sitting with: evolved ontologies are backbone-specific. Pairwise Jaccard overlap of accepted Term identifiers across the four analysis backbones is low—no pair exceeds the reported ceiling—and applying one backbone's evolved store to a different backbone drops trajectory-wise accuracy relative to the matched store. The ontology is not a neutral knowledge base; it encodes how a particular model interacts with data. That has real deployment implications: organizations running multiple models against the same data warehouse would need separate evolution runs, not a shared artifact.

Content growth stabilizes quickly. Most new Terms and Mappings appear in the first three rounds; per-round additions fall below a small fraction of the total after round three, and performance curves flatten in parallel. The system converges rather than accumulating indefinitely, which is a meaningful engineering property for production use.