Nvidia open-sources Auto-Ontology, a context layer for SQL agents

The pitch in the README is "an open context layer that helps agents give fewer wrong answers on enterprise data." The repo's About line calls it a framework for building semantic, graph-based reasoning layers over data. It's Apache-2.0, and when we fetched it the repo had 3.7k stars and 321 forks. The Hacker News post got 281 points and 136 comments, though tbh most of those comments are about the writing, not the code.

What's actually new

The usual shortcut for a data agent is to paste the schema into the prompt and hope the model figures out which revenue column is the right one. Auto-Ontology does something else. It reads your database metadata, profiles columns, samples values and compiles all of it into an ontology with three kinds of definition:

• Terms, business concepts like Customer or Invoice Line, with descriptions and synonyms, mapped to the columns that hold them.
• SQL attributes, reviewed SQL expressions for measures like a margin or a rolling total, so every answer computes them the same way.
• Relationships, how tables join, including bridge tables, inferred from keys and from the data.

People then review and certify those definitions in a web UI or through the API. At question time the agent pulls candidate terms and columns by embedding search, writes SQL, checks the filter values against the database, repairs the query if a check fails, and returns the answer with its SQL and steps.

The quickstart runs on Wide World Importers, Microsoft's sample sales database. One compilation produced 31 terms. Ask for revenue on the "USB food flash drive - sushi roll" in Pennsylvania in June 2015 and you get $588.80 from 3 invoice lines, plus the six-table join that produced it. Ask about return on ad spend and the agent calls check_answerable, gets a coverage of 0.5 because there's no ad spend data, and asks you to clarify instead of making a number up. That second example is the more interesting one imo.

It connects to ten engines, including PostgreSQL, MySQL, Snowflake, Databricks, ClickHouse, Trino and DuckDB. The models default to Nemotron NIMs on build.nvidia.com, and you can point each role at any OpenAI-compatible endpoint.

How agents reach it

There are three ways in. A REST API with a streaming POST /api/chat/completions, three agent skills for coding agents, and a FastMCP server with read-only tools: check_readiness, search_terms, get_term, describe_table, check_answerable, ask_question and a few more. Each user signs in through Auto-Ontology and every MCP call runs with that user's permissions. Which is the right default for data where not everyone should see everything.

Why it matters if you build agents

The README's comparison table makes the main argument. With the schema in the context window, tokens "grow with every table and column" and the agent infers meaning from column names. Through the ontology tools, the agent only loads "the terms and tables the question touches", and joins and measures come from reviewed definitions instead of being improvised per question.

That's the same fix people have landed on for tool definitions. Say your analytics agent answers the revenue question, then posts it to Slack and files it in Notion. Connected directly, every tool definition from both servers loads before the agent does anything, and MewCP's pages list 19 tools for Slack and 14 for Notion. Through MewCP the agent sees four tools, about 540 tokens, and looks up the rest when it needs them, so the context stays small on the app side too. You'd still connect Auto-Ontology's own MCP server directly though, since it runs next to your databases.

Now the costs, because there are some. You're running a real stack: a Next.js front end, two FastAPI services, the MCP server and Postgres 17 with pgvector, plus optional Vault. The README warns that the backend trusts a user id header the front end forwards, and the ingestion endpoints (ingest, delete, reset, compile) have no auth of their own, so ports 3001 and 3002 must stay on a private network. If you turn on KumoRFM for predictive questions, the agent uploads connected tables to that hosted service, capped at 20 tables by default with no row limit unless you set one. And the ontology is only as good as the review step, which is human work.

What people are saying

A lot of the Hacker News thread was about the README's opening line, "reliability gates agentic analytics", which several commenters read as unedited AI writing and stopped there. Some said they read the whole thing and still couldn't tell what it does. Others pushed back that complaining about one word isn't a review of the software.

The useful comments came from people who work with messy data. One explained it as a central metadata catalogue that maps business questions to the right tables across databases. Someone from a marketing analytics team said it would help enforce governance for blessed datasets but won't fix "the messy people issues". Another described the semantic gap with a real case where patient height is stored in SI units in the app and API but in US customary units, with no unit noted, in the warehouse. Their view was that the promise of an LLM ontology is to read application code for that context, and this tool doesn't. A few others asked what happens when column names don't match what's stored and the real meaning lives in a data scientist's head.

Open questions

• The numbers. The companion auto-ontology-eval repo runs a control arm with the schema in the prompt against the ontology arm, scored by a deterministic verifier on BIRD, BEAVER, FDABench-Lite and Wide World Importers. Neither README publishes the accuracy difference, so there's no headline result to quote yet. The eval README also notes optional extra prompts for BIRD that the control arm doesn't get, so check how any number you see was run.
• Review effort. How much human certification a real warehouse needs before answers are trustworthy isn't measured anywhere in the sources.
• Contributions. The team doesn't accept external pull requests, only issues and integration requests.

If you're building a data agent on Postgres or Snowflake, the Docker quickstart is the fastest way to see whether the answerability check alone is worth it for you.

Sources

• NVIDIA/auto-ontology on GitHub, https://github.com/NVIDIA/auto-ontology
• NVIDIA/auto-ontology-eval on GitHub, https://github.com/NVIDIA/auto-ontology-eval
• Hacker News discussion, https://news.ycombinator.com/item?id=50348962