EvoOntology: A Self-Evolving Ontology Layer for Data Agents
Meiduo Chong, Shaolei Zhang, Ju Fan, Xiaoyong Du
Renmin University of China
Published September 14, 2026 · on the feed September 21, 2026 · ▲ 150 · arXiv 2609.15779
The abstract
Data agents aim to fulfill natural-language instructions over heterogeneous data, including tables, files, and databases. However, data agents face a challenging agent-data gap: heterogeneous data resides outside the agent, while the agent can access it (e.g., column names and file paths) only through generic tools. Existing approaches either let agents directly explore raw data sources or inject manually constructed semantic layers into prompts. However, neither scales well to large heterogeneous data sources nor adapts to different agent behaviors. In this paper, we introduce EvoOntology, a self-evolving ontology layer for data agents. EvoOntology encapsulates the ontology as an MCP server comprising a schema layer, a content layer, and a tool layer, enabling agents to actively query and interact with the ontology at runtime. To this end, we introduce a builder agent for autonomous ontology construction and a self-evolution loop that continuously refines the ontology through attribution-guided typed edits that are accepted only after a backbone-conditional paired evaluation. Experiments on three well-adopted data-agent benchmarks with four LLM backbones demonstrate that EvoOntology consistently outperforms strong baselines and existing semantic-layer approaches, effectively bridging the agent-data gap and enabling more effective interaction with heterogeneous data. Code: https://github.com/ruc-datalab/EvoOntology
The Brief
2:26A short podcast summary of the paper. Written and voiced by AI.
Transcript
EvoOntology. A Self-Evolving Ontology Layer for Data Agents. By Meiduo Chong and three others, from Renmin University of China. Published on the fourteenth of September. Its code repository is worked out: about one hundred and eighty source files, with a readme and a licence.
Data agents take natural-language instructions and carry them out over heterogeneous data: tables, files, databases. They face what the authors call an agent-data gap. The data sits outside the agent, and the agent can reach it, things like column names and file paths, only through generic tools. Existing approaches go one of two ways. Either agents explore raw data sources directly, or manually constructed semantic layers are injected into the prompt. Neither scales well to large heterogeneous sources, and neither adapts to how different agents behave. Raw exploration leaves the agent to find its own way through everything, and a hand-built semantic layer is written once, by people, and handed over the same way to every agent that comes along.
EvoOntology places a self-evolving ontology layer between the agent and its data. The ontology is packaged as an MCP server with three layers, one for schema, one for content, and one for tools. Because it is a server rather than a block of prompt text, agents can actively query and interact with the ontology at runtime, asking for what they need when they need it. And because it evolves, the ontology is not fixed at the moment it was first written.
Two pieces build and maintain it. A builder agent constructs the ontology autonomously. A self-evolution loop then refines it continuously, through typed edits guided by attribution. No edit is taken on trust. Each one is accepted only after a paired evaluation conditioned on the backbone model, so refinement is tied to the model that will actually be using the ontology.
The evaluation covers three well-adopted data-agent benchmarks and four large language model backbones. Across them, EvoOntology consistently outperforms strong baselines as well as existing semantic-layer approaches. The authors take this as the agent-data gap being effectively bridged, with agents interacting more effectively with heterogeneous data. That the gains hold across four different backbones matters for the design, since the evolution loop was built to account for which backbone is doing the work.
Rather than choosing between leaving the agent to explore alone and handing it a fixed map, EvoOntology gives the agent a map it can query, and lets that map redraw itself. An edit survives only when it helps, as measured on the backbone in question.
Paper Quest · 7 chapters · about 40 min
Play this paper
Learn it by doing: make the calls the authors made, guess the result before you see it, and defend it in a viva graded on your own words. Chapter 1 is right here.
Chapter 1 🧩 · The problem
The data is right there, but the assistant cannot see what it means. That is the wall.
You run an LLM assistant that answers questions over a company's tables, filings and documents. It can reach them only through generic tools: SQL interfaces and file readers that show column names and file paths.
The road ahead
- 1 · The problem ~6 min An LLM assistant must answer questions over a company's tables and documents, but it sees only raw column names and file paths through generic tools.
- 2 · What came before ~3 min
- 3 · The key idea ~9 min Put a queryable ontology, served as an MCP tool server, between agent and data; build it by probing, and refine it with gated edits.
- 4 · Choose your own research ~3 min
- 5 · Build the method ~8 min Build an ontology by probing data, serve it as MCP tools, attribute failures to propose typed edits, and gate each edit with paired validation.
- 6 · The experiment ~6 min You’ll guess: Across three data-agent benchmarks and four LLM backbones, how did the evolving ontology compare with existing semantic-layer approaches?
- 7 · The viva ~5 min Three questions from the examiners, answered in your own words. Win it for the paper’s trophy.
Free, with Google or an email address. Your stars and progress are kept.