EvoOntology: A Self Evolving Ontology Layer for Data Agents

Justy Okay, this is way more interesting than 'we made the prompt bigger.' They basically said your data agent keeps getting lost, so give it a map that can rewrite itself.

Cody Yeah. And the useful part is the map is not just a blob of metadata. They package the ontology as an M C P server, so the agent queries it at runtime instead of hauling the whole thing into context and hoping.

Justy Which is the product pain, honestly. If you've got tables, docs, filings, random files, whatever, the agent spends half its life playing hide-and-seek with column names and file paths instead of answering the question.

Cody Right.

Cody The paper calls that the agent-data gap. Generic tools like S Q L runners and file readers give access, but not understanding, so the agent probes blindly and burns tokens inspecting irrelevant stuff.

Justy And that gets worse exactly where teams want this most, which is messy enterprise data. Small benchmark table? Fine. Real mixed data estate? You are absolutely not shipping 'just let the agent explore' as your strategy.

Cody Mm-hm.

Cody Their split of prior approaches is clean. One camp is raw querying. The other is semantic layer injection. Raw querying means each task rediscovers the world from scratch. Full semantic injection has the opposite problem: it scales badly with context and usually stays static even when the agent keeps tripping over the same missing concept.

Justy This is also, by the way, another one of our extremely glamorous Wednesdays on coordination machinery. We keep acting surprised that the boring middle layer is the thing.

Cody You say that like you aren't delighted every time the answer is more infrastructure.

Justy Only when there's a user on the other end, Cody. If the wrapper isn't helping me ship, I start looking for the exit.

Cody Fair. Here, I think it is helping. The ontology has three parts: schema layer, content layer, and tool layer. Schema defines object types and reference rules. Content stores domain knowledge plus mappings back to the underlying data. Tool layer exposes executable interfaces so the agent can ask semantic questions and then act on the answers.

Justy Yeah.

Justy That middle piece matters. They're grounding ontology entries in observed data, which is the difference between a pretty catalog and something an agent can actually route work through.

Cody Exactly. The builder agent does the initial pass, anchors entries to what it actually found, then the self-evolution loop kicks in from trajectories. That part is the novelty, more than the word ontology.

Justy Walk me through that part without turning this into episode nine hundred ninety-six of 'Cody explains maintenance loops to a wall.'

Cody The methodology sounds more solid than a lot of agent papers because they at least try to localize updates. Typed edits are better than 'rewrite the whole semantic layer' because you can inspect what changed. Paired validation is also the right instinct if you're worried about ontology drift.

Justy My only real push is production-shaped. Self-evolving is great until the layer quietly teaches itself bad habits. So if somebody actually builds on this, I think the shippable version has review gates, provenance on every ontology entry, and probably environment-specific promotion instead of live auto-editing against prod.

Cody Yeah, no, you're completely right. I would not let this mutate freely in a sensitive stack. The paper is about effectiveness, but in deployment you'd want versioning, rollback, maybe human approval on tool-layer edits especially. Schema mistakes are annoying. Tool mistakes can become action mistakes.

Justy Which is why I don't read this as research-only. I read it as a real architecture pattern for teams already trying to build data agents over ugly mixed sources. Not a generic add-on for everybody, but very plausible for internal analytics, finance docs, operations data, that whole zone.

Cody Sure.

Cody Also this lands right in that ongoing fight we've kept circling about where agent governance and context actually live. This is one more entrant for the boring camp. Reliable shared semantics, mappings, and access tools beat making the model improvise its way through a warehouse.

Justy And the nice product consequence is cumulative learning. If the agent finally figures out that some business concept spans a database field, a spreadsheet tab, and a filing note, you don't want that insight evaporating after one run. That's the whole business case here.

Cody One thing I'd still want, and maybe the repo makes this clearer, is stronger evidence on failure modes. When does attribution point at the wrong ontology entry. When do edits overfit to one benchmark workload. The paper says three benchmarks and four backbones, which is good, but this category is young enough that I'd still be cautious.

Justy Totally. Also, side note, 'self-evolving ontology layer' sounds like something a spaceship would refuse to turn off.

Cody It absolutely does.

Justy Like, 'I'm sorry, Justy, I have updated the reference rules.'

Cody If somebody wants to poke it, the code is up on GitHub as ruc-datalab slash EvoOntology. That at least moves it out of pure paper theater. You can inspect how much of this is a clean M C P layer versus benchmark scaffolding.

Justy Yeah, that's the right next move. Read the repo, look at how the ontology entries are represented, and check what the edit and validation loop actually touches. Okay, I think that's enough ontology drama for one Wednesday-adjacent conversation, Cody.