Enterprise data agents are becoming three systems: semantics, execution and authorization

Four recent enterprise agent designs point to the same conclusion: reliable natural-language analytics is no longer being treated as one model prompt. Vendors are separating semantic grounding, query or tool execution, and authorization into control planes that can be reviewed independently. The implementations differ, but the boundary is becoming the product.

Meaning moves out of the prompt

Snowflake’s Business Ontology stores steward-approved concepts, owners and policy context, while Semantic Views remain responsible for executable joins, filters and aggregations. A caller can be shown multiple approved meanings for an ambiguous term, and role filtering controls which concepts are discoverable. Snowflake’s product announcement and engineering guide describe that split.

NVIDIA’s Auto-Ontology makes a similar separation with certified terms, reviewed SQL attributes and declared relationships. Its documented check_answerable step lets an agent abstain or seek clarification when the ontology lacks the requested concept, instead of forcing SQL generation from incomplete context. Certification is still a human workflow state, not proof of correctness. NVIDIA Auto-Ontology

Google’s QueryData preview calls the corresponding package a context set: reviewed query blueprints, reusable facets and value-search rules are supplied before the service synthesizes and executes PostgreSQL. Conversation state and orchestration remain outside the service in an agent harness. Google Cloud QueryData overview

Execution and authorization remain separate problems

Google documents parameterized secure views for per-user filtering and tells applications to connect with a minimally privileged role, grant that role access to the view and revoke access to base tables. The policy therefore survives a changed prompt because PostgreSQL enforces it at execution time. Google Cloud secure-view guide

Oracle takes a different deployment route: Select AI Agent runs orchestration and tools inside Autonomous AI Database, while a managed MCP endpoint exposes registered tools to outside clients. Oracle still requires authentication, IAM permission and privileged registration of custom tools; database roles determine what those tools can actually do. Oracle Select AI Agent Framework and Oracle MCP Server

NVIDIA’s deployment notes expose the same distinction from another angle. Its MCP tools are read-only and use the signed-in user’s permissions, but internal backend and ingestion services rely on network isolation rather than their own authentication. The semantic layer cannot compensate for an exposed administrative service. NVIDIA Auto-Ontology

The practitioner test

A production review should now ask three separate questions. Who approves the meaning of a business term? Which component turns that meaning into SQL or a callable tool? Which database identity, view, role or network boundary limits the result? If one answer is “the prompt,” that layer is not independently enforceable.

The convergence does not prove that any one product is accurate. It does give teams a stronger architecture to demand: make meaning inspectable, make execution testable, and make authorization survive whatever the model says.