Every metadata tool now has a chat button. Press it, ask where the revenue figure comes from, and something confident slides out of a side panel. The answer is the easy part. What matters is what happens next: can the AI change anything, through whose permissions, and with what record of what it saw? Those three questions split the market into two architectures that demo almost identically and behave nothing alike.

Watch this in action:

A chat panel is not an architecture

Bolted-on AI is a chat panel attached to an existing catalog. It reads whatever slice of metadata happened to get indexed, answers questions, and stops there. Writes either do not exist or bypass governance entirely, and nothing records which context produced a given answer. What you get is a query interface with good manners, nothing more.

Access to a language model was never the hard part. The real question is whether the AI understands your approved business meaning, your modelling standards, and the controls your platform already enforces. Attaching a chat assistant to a catalog does not make that catalog AI-native, because the catalog underneath it has not changed at all.

AI-native means the AI works on the governed metadata itself: the same business entities, models, tables, columns, relationships, and knowledge documents you edit by hand. DeltaVault is built this way deliberately. When the AI proposes business domains, it has already read the domains you have, which is why running it twice does not fill your model with duplicates. When it writes, every change arrives as a staged proposal you review item by item. Applied changes then pass through the same role checks and land in the same audit log as human edits, so “what did the AI change?” has exactly the same answer as “what did Sarah change?”

You can open the hood

In DeltaVault, every AI capability is a skill: a published, versioned configuration that declares its prompt, its inputs, the context it reads, the actions it may take, where in the product it appears, and what selection it needs to activate. None of it is sealed.

That openness matters because two things are always true of any system prompt shipped with a platform. It will not be perfectly tuned to your business vocabulary, and the models underneath it keep improving. So any organization administrator can open a skill and read the exact instructions it runs. If your team has adopted an industry ontology, fold it directly into the prompt. If you need a capability DeltaVault does not ship, build a new skill from scratch, or fork a built-in one into an editable version that shadows the original for your team alone. Before anyone else sees it, a test panel lets you run it against sample inputs, and once you publish, it operates under the same role checks and credit allowances as every other skill in the library.

A bolted-on panel gives you one feature, taken as shipped. A skill library gives you an architecture you can inspect, tune, and extend as your requirements change.

Controlled acceleration, not autonomy

The goal is not autonomous data engineering. It is controlled acceleration: the AI absorbs repetitive modelling and documentation work while you keep control of meaning, standards, and approval. Because that control is the whole point, the guardrails run deep. Spend is estimated in credits before a run starts, and a per-member allowance caps it. Every run records exactly what context was sent, and when a document does not fit, it is flagged rather than silently truncated.

A chat panel needs none of that, which is precisely the point. Proposal reviews, context manifests, and budget gates start to matter only when the AI is doing real catalog work that a real organisation has to trust. The controls are not overhead on the capability. They are the proof of it.

So when a metadata tool shows you its AI, ask two questions: what happens when it writes, and can you read the instructions it runs? In DeltaVault, both answers are on screen. Open Toolkit, then AI Skills, and see for yourself.