An agent can successfully query a database and still give you the wrong answer.
Ask, “How many customers did we have last month?” and it may count every account row. Your business may define a customer as someone with at least one completed purchase. It may exclude test accounts, treat a household as one customer, or use the order date rather than the signup date. The SQL can be valid, the query can finish, and the number can still be wrong.
That is the gap NVIDIA’s Auto Ontology project is trying to address. The project builds a semantic context layer over enterprise data: information about what business terms mean, where metrics live, how entities relate, and which definitions should guide queries. It drew a lively Hacker News discussion on November 3, 2026, but the useful idea is larger than one product: database access is not the same as business understanding.
You do not need to deploy a large platform before improving this. Start with a small, reviewable data dictionary and a few approved SQL views. Give the agent those definitions before granting it database access. Then test the answers against known questions.
This walkthrough builds that minimum version. It is a design tutorial based on public documentation, not a report of hands-on use of NVIDIA Auto Ontology.
A schema tells an agent that a table has columns such as customer_id, status, and created_at. It does not tell the agent which status values count as active, whether a customer needs a completed order, or which timestamp the business uses for monthly reporting.
People often carry these details as unwritten rules. A finance analyst may know that refunds are subtracted after settlement. A support lead may know that internal test accounts are excluded. If an agent sees only tables and column names, it must guess, infer from examples, or ask someone. The resulting query can be syntactically correct but semantically inconsistent.
NVIDIA’s repository describes Auto Ontology as a framework that generates a semantic layer from metadata, reconciles definitions across systems, validates generated queries against certified definitions and lineage, and makes context available through MCP, CLI, and API. Those are project capabilities described by the maintainers, not independent accuracy guarantees. The project is a useful signal that agent builders are treating business meaning as an infrastructure concern rather than just a prompt-writing problem.
The central distinction is simple:
These layers work together, but they are not interchangeable. A glossary does not enforce permissions. A read-only account does not make a metric definition correct. A prompt alone is not a durable source of truth.
Pick one business question that is both common and easy to verify. For example: “How many purchasing customers did we have last month?” Avoid starting with every table in the warehouse. A narrow scope is easier for a domain expert to review, and it makes errors visible.
For this example, suppose a database contains customers, orders, and order_items. A first version of the semantic contract could look like this:
metrics:
purchasing_customers:
description: "Distinct customers with at least one completed, non-test order."
entity: customer
source: analytics.purchasing_customers
filters:
- "orders.status = 'completed'"
- "customers.is_test = false"
time_field: orders.completed_at
grain: customer per calendar month
owner: analytics
status: approved
entities:
customer:
primary_key: customers.id
joins:
- target: orders
condition: customers.id = orders.customer_id
This is not a universal ontology format. It is a small human-readable contract. Its value comes from making assumptions explicit and reviewable, not from choosing a particular file extension.
Write definitions as decisions, not labels. “Purchasing customers” is a label. “Distinct customers with at least one completed, non-test order, grouped by completion date” is a decision a reviewer can challenge. If Finance and Product use different definitions, record two named metrics rather than hiding the disagreement under one vague term.
Include the time rule. “Last month” can mean calendar month, trailing 30 days, or the previous completed reporting period. State the timezone and boundary rule when they affect the result. For a first version, you can write “calendar month in UTC” or link to the organization’s established reporting calendar.
Name provenance and ownership. Identify the source view or tables and the team that approves the definition. A definition without an owner can become stale while still looking official. Add a last-reviewed date if the metric changes regularly.
A prose definition helps a person review intent. It is not enough to ensure every query uses the same rules. Put the core definition into a database view, then point the semantic entry at that view.
CREATE VIEW analytics.purchasing_customers AS
SELECT DISTINCT
c.id AS customer_id,
date_trunc('month', o.completed_at AT TIME ZONE 'UTC') AS month_utc
FROM customers AS c
JOIN orders AS o
ON o.customer_id = c.id
WHERE c.is_test = false
AND o.status = 'completed';
The example uses PostgreSQL syntax. A real schema may need different names, time handling, soft-delete rules, or tenant filters. Ask the data owner to confirm those details before treating this view as canonical.
The agent can now be directed to query the approved interface instead of reconstructing joins and exclusions from raw tables:
SELECT COUNT(DISTINCT customer_id) AS purchasing_customers
FROM analytics.purchasing_customers
WHERE month_utc = TIMESTAMP '2026-10-01 00:00:00';
A view is not automatically safe or correct. It can contain a bug, expose sensitive columns, or embody a disputed definition. The practical advantage is that the query path is centralized: reviewers can inspect and test the definition once rather than hoping every generated query repeats it correctly.
PostgreSQL’s documentation describes views as stored queries that can be used like virtual tables. That makes them a useful building block for a curated query surface. Pair them with database permissions: grant the agent’s database role access only to the approved schemas or views it needs, and keep it read-only unless a specific, separately reviewed workflow requires writes.
A definition becomes more useful when a change can fail visibly. Add small fixtures or run assertions against a known reporting dataset. Test the cases that encode the business rule, not just whether the view returns rows.
For the purchasing-customer metric, useful cases include:
These tests can be implemented in your existing SQL test framework, migration checks, or a small fixture-based integration test. The exact tool matters less than having a known expected result that runs when the definition changes.
Next, create a tiny evaluation set of questions and expected answers. Include the normal question, an ambiguous question, and one that should be rejected or clarified. For example:
Store the question, expected metric or view, expected result, and reviewer. Re-run the set after changing a definition, database schema, model, or agent instructions. Do not treat a fluent explanation as proof that the number is right. Compare the generated SQL and the returned result with the approved path.
A semantic layer improves context. It does not replace access control, review, or query limits.
Use a dedicated read-only role. Give the agent access only to the curated views it needs. Do not reuse an administrator credential, and do not assume a prompt saying “do not modify data” is a permission boundary.
Limit query cost and scope. Set statement timeouts, row limits where appropriate, and resource controls through the database or query service. A well-meaning agent can still produce an expensive join or scan.
Return provenance with the answer. Record which metric, view, filters, and time range were used. For analytics answers, showing the SQL and source definition makes review much easier than returning a number alone.
Separate draft definitions from approved definitions. An automated system can propose a metric or relation, but a proposal should not silently become the definition used for business reporting. Give a person responsible for the domain a clear approval step.
Track disagreements. If two teams use “revenue” differently, the system should preserve that distinction. A forced single definition may look tidy while making the answer less useful. Name the variants and specify when each is appropriate.
The NVIDIA repository lists HashiCorp Vault as an optional component for connection credential storage. That is a concrete reminder to review credential handling, storage, authentication, and deployment settings before connecting any agent-facing system to real data. “Open source” and “read-only tools” do not remove the need for a security review.
A hand-maintained dictionary and SQL views are a good starting point when the scope is small, definitions are stable, and your team already has a review process. They become harder to manage when definitions span many databases, terms conflict across departments, lineage must be traced, or multiple agent interfaces need the same context.
That is where a dedicated semantic platform may help. NVIDIA Auto Ontology’s public project describes metadata discovery, ontology generation, reconciliation across systems, query validation, provenance, and MCP/API/CLI access. Before adopting it or a similar platform, test it against your own questions. Ask whether it can represent your definitions, how generated changes are reviewed, what credentials it stores, which permissions it honors, and how you can inspect the query and its lineage.
Do not choose based on a demo that answers one easy question. Build a small benchmark from the questions your analysts actually ask. Include ambiguous terms, exceptions, boundary dates, and questions the agent must refuse. Measure correctness of the SQL and result, not just response speed or confidence.
Before an agent queries business data, confirm that you can answer these questions:
If several answers are unknown, adding broader database access is unlikely to solve the underlying problem. Start by writing down one definition and one approved query path. Then give the agent a narrow way to use it and measure whether the result is correct.
The useful lesson in the Auto Ontology discussion is not that every team needs a new platform. It is that database structure and business meaning are different kinds of context. An agent needs both, and the second one should be explicit enough for people to inspect, correct, and govern.
If you want more practical articles about AI agents and developer tools, subscribe. What business definition has caused the most confusion in your data queries? Save the checklist above and use it to review the next agent integration.
[1] NVIDIA Auto Ontology repository and README