Enterprise data agents are converging on a three-layer context stack

Enterprise data-agent products are converging on a more specific architecture than “connect an LLM to the warehouse.” The emerging stack has three distinct jobs: describe the data, execute governed business logic, and evaluate whether changes made answers better.

Descriptive context is necessary—but not sufficient

Google’s Looker integration with Knowledge Catalog shows what the descriptive layer now includes. The catalog indexes production LookML projects, models, views, Explores, dashboards and agents, along with relationships, join conditions, filters, measures and dimensions. Google says the integration uses automatic live synchronization when production LookML changes, and positions those indexed definitions as grounding for query generation against certified business logic.

That is far richer than handing a model a schema dump. It gives an agent an inventory, lineage and the official paths through the model. But Google’s own design also makes the operational boundary visible: access to the metadata requires dedicated IAM roles, while the underlying Looker and data permissions remain separate controls.

The executable layer is where trust becomes concrete

Databricks’ Genie documentation draws a useful line between free-form guidance and executable assets. A Genie Agent can hold plain-text instructions and a knowledge store containing descriptions, joins, measures, filters and dimensions. Yet Databricks explicitly warns that Genie is nondeterministic and tells administrators to remove ambiguous or conflicting guidance.

For repeatable answers, Databricks promotes “trusted assets”: parameterized SQL queries and Unity Catalog SQL functions. When Genie uses the exact parameterized query, it marks the answer verified. Functions can encapsulate complex logic that the agent may call but cannot inspect or modify, and users still need EXECUTE permission. That design turns important business rules from prose the model interprets into governed objects the runtime invokes.

Cube describes the same separation as descriptive context versus executable context. Its argument is that catalogs, glossaries, ontologies and memory help an agent decide what to ask, while a semantic layer compiles measures, joins and access policies into the query itself. Cube’s Semantic SQL exposes certified measures through SQL syntax, with the layer responsible for expansion into warehouse-specific SQL and for applying access rules.

Evaluation is the third layer

The final layer is not more metadata. It is a test harness. Cube argues that context and model changes should be evaluated before they reach production rather than judged by spot-checking outputs. Databricks likewise provides editable example queries and visible generated SQL so teams can diagnose failures and refine the agent’s configuration.

The practical lesson is architectural: do not put every fact into one giant prompt and call it a context layer. Keep catalogs and business knowledge available for discovery; move critical calculations and permissions into executable, versioned assets; and test the complete path whenever models, metadata or definitions change. An agent can sound informed with only the first layer. It becomes deployable only when the second and third layers are present.