NVIDIA Auto Ontology: Grounding Agent SQL in Business Truth

Posted on by
Contents show
NVIDIA Auto Ontology

Ask an agent a revenue question and it will confidently write SQL, connect to your warehouse, and return a number in seconds. Auto Ontology exists because that number is often wrong. The problem the enterprise has learned to fear is in the sentence: confidently. Wrong numbers from fluent agents are why a semantic layer has stopped being optional. A fast revenue answer is worthless if the number is wrong, and wrong numbers from fluent agents are quietly becoming the most expensive failure mode in enterprise AI.

NVIDIA has released Auto Ontology, an open-source library under the Apache 2.0 license that attacks the problem from below the prompt, and its design says a lot about how enterprises will govern what agents are allowed to know. It is a semantic layer framework that builds a context layer from enterprise metadata: where data lives, what fields mean, whether to use a field, how to use it, and where it came from. The release makes Auto Ontology one of the first big-vendor answers to a question every agent deployment is hitting. Agents reach that layer through MCP, a CLI, or an API, and write SQL against certified business definitions instead of raw schemas.

This article explains what Auto Ontology does, how the pieces fit together, what its benchmark story does and does not prove, and where it sits among the semantic-layer tools an enterprise might already run.

The problem: text-to-SQL got good enough to be dangerous

Text-to-SQL has improved to the point where an agent almost always produces executable queries. Execution is no longer the failure mode; meaning is.

Every enterprise warehouse carries the same sediment: a revenue column whose definition changed in 2024, three tables that all claim to hold customers, a metric the finance team computes one way and the sales team another, and a retired flag that a schema listing still advertises. A human analyst absorbs this folklore over months. An agent reading a schema sees none of it, because none of it is in the schema. The result is the class of error that passes every technical check and arrives in an executive inbox.

The company's own repository frames the stakes without decoration: a fast revenue answer is worth nothing if the number is wrong. That framing matters, because it locates Auto Ontology as a reliability layer, not a capability layer. The agent could already query the database. The question is whether it should have.

Five jobs, one context layer

Auto Ontology's design divides the work into five jobs, and together they describe a lifecycle rather than a point solution.

Discover generates a starting ontology from enterprise metadata and connects semantic models the business already owns. Ground gives agents trusted meaning for metrics, entities and relationships, reconciling definitions that disagree across systems. Validate checks generated queries against certified definitions and lineage, returning provenance with every answer. Expose serves that context to any agent harness through MCP, CLI and REST API. Learn folds certified corrections and usage back into the ontology, so the shared context improves with each question.

The deliberate sequencing matters. The output of discovery is explicitly a starting ontology, and the developer documentation is clear that business experts still test, refine and certify it. This is not a system that promises to understand your business from metadata alone; Auto Ontology promises to do the mechanical 80 percent so that humans spend their time certifying meaning rather than writing definitions from scratch. NVIDIA reports that Auto Ontology cut ontology creation time by 90 percent in its own testing, a claim about acceleration, not autonomy, and the honest one to make.

How the stack fits together

The Auto Ontology implementation is conventional in a good way, because boring infrastructure is what an enterprise will actually deploy.

Four core services compose the stack. A Next.js frontend handles the web interface and authentication. A FastAPI backend with LangChain runs the chat, natural-language-to-SQL and catalog APIs. An ingestion worker writes embeddings. Postgres with pgvector stores the catalog, the ontology and the vectors together. Source databases can be Databricks, Postgres, Snowflake or DuckDB.

Models in Auto Ontology are configured through environment triplets of endpoint, key and model, with separate roles for reasoning, non-reasoning, embedding and reranking. The defaults are NVIDIA's own: a Nemotron 30B model for reasoning, a Nemotron embedding model, and a Nemotron reranker, served through NVIDIA's hosted NIM endpoints or self-hosted equivalents. Any OpenAI-compatible endpoint works in their place, which quietly makes the whole system model-agnostic despite the branding.

Deployment of Auto Ontology is Docker Compose for a local stack or Helm for Kubernetes, with the backend also published as a container on NVIDIA's catalog. An API key from NVIDIA's build portal covers the default models.

The MCP design decision that matters in Auto Ontology

The agent-facing surface of Auto Ontology is where its philosophy shows, and one decision deserves attention.

The MCP server exposes nine read-only tools. The workhorse, ask_question, returns the answer, the SQL, and the rows as separate fields, capped at a hundred rows. A check_readiness tool confirms that a compiled semantic layer and a live database connection exist. What is absent is deliberate: there is no tool for browsing raw schemas. Agents cannot reach around the semantic layer to the tables beneath it, by design.

That constraint is the entire argument Auto Ontology makes. An agent that can browse raw schemas will eventually build a query on an uncertified table, because the schema looks authoritative and the agent has no way to know which tables carry business meaning. Removing the path forces every question through certified definitions, which is precisely the guarantee the enterprise needs and precisely the flexibility a power user will chafe against.

The security posture is likewise considered. The OpenAPI surface publishes 87 operations behind OAuth, every call carries the signed-in user's permissions rather than a service account's, and API tokens for scripting act as their owner, cannot mint successors, and revoke immediately. One deployment caveat stands out from the documentation: connection credentials added through the UI are stored in plaintext in Postgres unless HashiCorp Vault is configured, and a partial Vault configuration silently falls back. That is documented, not hidden, and it belongs on every deployment checklist.

A question's path through the layer

The clearest way to understand what Auto Ontology changes is to follow one question with and without it.

Without the layer, an agent receives the question “How many orders shipped last week?” alongside a schema listing. It sees tables named orders, shipments, and order_facts, a revenue column, a status column with fourteen distinct values, and a created_at timestamp. It picks plausible joins, guesses that shipped means a status value it finds in the data, computes revenue from the column that looks right, and returns a number. Every step was reasonable. The number may still be wrong in three independent ways: revenue might be defined net of returns by finance convention, shipped might have a certified definition tied to a fulfillment event rather than a status field, and last week might mean fiscal weeks that do not align with calendar ones.

With Auto Ontology in the path, the same question first meets the certified ontology. The term revenue resolves to a definition with an owner and lineage. The concept of shipped maps to a certified business event, not a guessed column value. The time phrase is interpreted through the company's calendar rules. The generated SQL is validated against those definitions before execution, and the response carries provenance: which definitions were used, so a reviewer can check the reasoning rather than reverse-engineer the query.

The returned SQL and rows as separate fields, rather than only an answer, are the quiet design win here. Separating them lets a reviewing human audit the query without re-running it, and lets a downstream agent consume rows without parsing prose.

The security posture, read from the documentation

Enterprise adoption lives or dies on details the demo never shows, and the Auto Ontology documentation is unusually explicit about them, which is worth rewarding.

Authentication runs through a established auth library with single sign-on support, and every API call is authorized against the signed-in user's own role rather than a shared service identity. A viewer's credentials cannot perform administrative actions even through a token. API tokens for scripts carry no permissions of their own, are stored only as hashes, revoke immediately, and cannot create successor tokens, which closes the escalation path that makes leaked service credentials so damaging in agent deployments.

The conversation design also shows threat modeling. Conversation history is scoped to the authenticated user, contextual follow-up questions are rewritten into standalone questions before execution, and internal reasoning traces, chart payloads and raw result sets are deliberately not reused as context for later turns, limiting what one answer can leak into the next. The documentation even flags its own boundary honestly: the backend port is a trusted internal service that must not be exposed publicly, because an identity header it accepts is not independently verified.

The one genuine wart in Auto Ontology is credential storage. Connections added through the interface are stored in plaintext in the application database unless Vault is configured, and a partial Vault setup is ignored with only a warning. Documented is not the same as safe, and any production deployment should treat Vault configuration as a prerequisite rather than an option.

The benchmark story: a harness, not a scoreboard

Here the Auto Ontology release is unusual in its restraint, and the restraint should be read correctly.

Auto Ontology ships a separate evaluation harness that runs two arms in a gym environment: a schema-only control agent, and the ontology-grounded agent. Scoring is deterministic execution match, with no language-model judge, which removes an entire class of evaluation disputes. Bundled datasets include BIRD Dev with 1,534 questions across 11 databases, a 500-question subset, and two smaller adversarial sets.

What the harness does not ship is results. No text-to-SQL accuracy scores are published, and the repository's own limitations section notes the confounds: optional few-shot exemplars and value anchors flow to the ontology arm only, so a measured delta covers those inputs rather than grounding alone, and the tested configuration routes both arms through a particular frontier model on NVIDIA's gateway.

That is the correct scientific posture and a commercial gamble. Publishing weak numbers would have damaged the launch of Auto Ontology; publishing no numbers leaves the burden of proof on adopters. The repository effectively says: the harness is here, run it on your warehouse. For an enterprise tool whose value depends on a specific company's messy metadata, that is arguably the only honest benchmark design, and it is also the reason no accuracy figures for Auto Ontology should be cited yet, because none exist.

Where it sits among the alternatives

The semantic-layer market is crowded, and the differences Auto Ontology brings are real but narrow.

Wren AI takes an agent-assisted approach where context files live in git and supports more than 22 data sources. Cube Core defines the layer in code with broad SQL support and mature APIs. dbt MetricFlow defines metrics inside dbt projects, which is natural for teams already standardizing transformations there. All three are open in some form.

The distinct Auto Ontology claim is the generation step: it drafts the layer from metadata rather than requiring it to be authored, then wraps certification, lineage and agent exposure around that draft. For enterprises with no semantic layer at all, which is most of them, bootstrapping is the actual bottleneck, and a 90 percent reduction in creation time targets the right cost even if the figure is self-reported. For enterprises that already run Cube or dbt, the integration story, connecting existing semantic models, matters more than the generation, and it is too early to say how well it works.

The strategic reading is that NVIDIA is not really selling a semantic layer with Auto Ontology. It is selling ground truth for the agent era, on the infrastructure it already operates, with its models as the default and its gateway as the path. The semantic layer is the wedge; the NIM inference traffic is the business.

Who should own the ontology inside a company

The tooling question is easier than the organizational one, and Auto Ontology quietly forces the organizational question, because a certified semantic layer needs an owner.

Three models exist in practice. When analytics engineering owns it, definitions are technically impeccable and drift toward the warehouse's structure rather than the business's questions. When finance or operations owns it, definitions match how the business reports upward but can fossilize into spreadsheet logic that resists change. When a dedicated data product team owns it, with Auto Ontology's certification loop as the workflow, corrections from every certified agent answer flow back into shared context, which is the Learn job in the product's own vocabulary and the most under-used feature in the release.

The last model is the one the tool is built for, and it is also the one most companies have not staffed. A useful compromise for the first year: let discovery draft, let analytics engineering validate structure, and let the business domain owner certify meaning, with every certified correction captured by the platform rather than in a chat thread. The tool makes that division of labor enforceable, which is a quiet organizational contribution beyond the code.

An adoption checklist

Stand it up against a copy, not production. Local Docker Compose with a DuckDB snapshot of a real schema generates the draft ontology without touching anything that matters. The generation step is where the 90 percent time claim applies, and it can be judged in an afternoon.

Spend the saved time on certification. The certified definitions are the product. Every hour a domain expert spends confirming or correcting a generated definition is the hour that makes agent answers trustworthy later, and skipping it leaves you with a faster path to confident wrong numbers, the exact failure the tool exists to prevent.

Run the harness with both arms, on your metadata. The shipped evaluation harness exists for precisely this purpose. Record your own delta between the schema-only control and the grounded agent, note the few-shot confound the repository documents, and keep the results internal, because your warehouse is the only benchmark that predicts your outcomes.

Configure Vault before real credentials. The plaintext fallback is documented but dangerous, and treating Vault setup as a deployment prerequisite rather than an optional extra is the cheapest security decision in the whole evaluation.

Wire one read-only agent through MCP. Give a single agent access to ask_question and check_readiness, put check_readiness in its bootstrap, and watch what it asks before trusting what it answers. The nine-tool surface is deliberately closed, which makes the blast radius of a misbehaving agent small enough to learn from safely.

Decide where it sits relative to what you own. Teams already standardizing on a code-defined semantic layer should evaluate Auto Ontology as a generation and certification front end that exports to their existing layer, not as a replacement. The integration story, connecting existing semantic models, is documented but young, and it is the part most likely to change in the first year.

Teams weighing this against their existing stack should also read it alongside the broader agent-grounding question covered in our AI gateway comparison, since the gateway and the semantic layer are both attempts to put a governed boundary between agents and enterprise resources. The reliability argument echoes what we found in the LiteLLM supply chain analysis: agent infrastructure is only as trustworthy as the layer that mediates what agents may touch. And for teams whose agents live in a full workspace rather than a chat window, the same grounding logic shows up in agent workspace design at the file and terminal level, where what an agent may see is curated before it is queried.

Sources
Subscription Form