Google Cloud Unifies Six Semantic Models in Context Graph to Boost Data Agent Accuracy 4x

SQL Executes but Business Logic Fails

Enterprise Data Agents have improved Text‑to‑SQL generation, yet a persistent gap remains: a query can run without syntax errors yet return results that contradict official financial reports. The article illustrates this with a sales leader asking for last quarter’s net revenue. The Agent generated valid SQL and a chart, but the figure differed from the finance report because the model included cancelled orders and used an unverified intermediate table. The core issue is not SQL generation but the Agent’s lack of awareness of business rules — such as revenue recognition policies, refund handling, discount treatment, and fiscal calendars.

Two specific failure modes are highlighted: Metric Definition Drift (different Agents producing different formulas for the same metric) and Join Fan‑out (one‑to‑many joins inflating row counts and distorting aggregates). These errors stem from the model’s ignorance of verified business logic; it can only guess from schema and context.

Fragmented Semantic Layers

Enterprises already maintain mature semantic layers: Looker’s LookML, dbt’s MetricFlow, Snowflake’s Semantic Views, Databricks’ Metric Views, BigQuery Graph, and SAP’s Core Schema Notation (CSN). Each captures metric formulas, filter conditions, join paths, entity relationships, data lineage, quality scores, and governance metadata. However, these models live in isolated platforms. An Agent using Snowflake cannot directly access Looker’s definitions; a BigQuery‑based assistant may not understand SAP’s business entities. When business rules change (e.g., finance updates a revenue calculation), reports may sync but Agents still rely on stale prompts, causing inconsistencies.

Six Semantic Sources Unified in a Context Graph

In late October, Google Cloud announced GA support for ingesting all six semantic sources into Knowledge Catalog’s Context Graph . The graph organizes data tables, semantic models, business terms, and data products as nodes; data lineage, business associations, schema keys, discovered join relationships, and pre‑declared join paths become edges. This is not a simple catalog — it is a cross‑asset, cross‑definition, cross‑governance context graph distinct from BigQuery Graph (which is just one source).

Each source contributes different strengths:

LookML : Models, Explores, Views, field‑level SQL, filters, join paths, required joins, always_filter/access_filter, and dashboard lineage.

dbt MetricFlow : Metric definitions linked to transformation models, quality tests, filters, saved queries, freshness, and downstream usage.

Snowflake Semantic Views (via Horizon Catalog): Dimensions, facts, metric formulas, entity relationships, data quality scores, sensitive‑data tags.

Databricks Metric Views (via Unity Catalog): Measure formulas, filter scopes, join cardinalities, table certification, Lakehouse Monitoring profiles.

BigQuery Graph : Native property graph definitions, node/edge tables, Graph Measures, business synonyms, enabling GQL traversals.

SAP CSN (from SAP Business Data Cloud): Business labels, dimension/cube modeling, default aggregations, currency/unit bindings, key fields, composite associations — critical for ERP business objects where raw fields lack full business meaning.

The Context Graph retains conflicting definitions (e.g., Looker and Snowflake may define “revenue” with different refund rules) rather than picking one, allowing data stewards to reconcile them. The goal is not a single enterprise definition but enabling Agents to locate the rule appropriate for the current business scenario and trace its provenance.

Figure 1: Knowledge Catalog sits between Agent ecosystem and data sources, auto‑ingesting metadata on one side and serving semantic retrieval via Model Context Protocol on the other. Source: Google Cloud

Figure 2: Context Graph generated from SAP federated catalog — nodes are business objects (customer, sales order, product, billing document), edges from pre‑declared association paths and data lineage. Source: Google Cloud

Two‑Phase Query: Retrieve Trusted Semantics, Then Generate SQL

With the Context Graph, the query flow splits into two phases:

Context retrieval & governance discovery : Agent maps the natural‑language question to business intent, finds matching metric definitions, data assets, filters, join paths, and checks certification, quality, and permissions.

Query generation & execution : Model builds the query using the retrieved business rules instead of re‑inferring calculations from raw schema.

LookML integration exemplifies this. Knowledge Catalog indexes LookML Models, Explores, Views, and Dashboards, linking their relational logic to underlying data assets. Explore’s sql_on captures join conditions, relationship describes cardinality, required_joins enforces necessary joins, always_filter and access_filter impose mandatory filters. View‑level field SQL, primary keys, time dimensions, and derived‑table logic are also indexed. A concrete example: a company uses a non‑calendar fiscal year. If an Agent interprets “last fiscal quarter” as calendar Q3 (Jul‑Sep), the SQL may be syntactically correct but the result deviates from the finance report. With the fiscal calendar and LookML rules ingested, the Agent applies the correct fiscal period (e.g., fiscal month offset = 1, yielding FY2026 Q2).

Figure 3: Same fiscal‑quarter question in two Agents — left uses calendar quarter (2026‑07‑01 to 2026‑09‑30), right reads certified metric with fiscal_month_offset=1, switching to FY2026 Q2. Source: Google Cloud

Gemini Enterprise can query Knowledge Catalog via built‑in read‑only and hybrid search, passing context to the federated BigQuery connector for SQL generation. Custom Agents can use the LookupContext API. The division of labor: model handles intent understanding, context location, and query orchestration; metric formulas, join cardinalities, and mandatory filters reuse verified definitions , reducing ad‑hoc inference errors.

Google also introduced Context Sets (Preview) — bounded collections of metrics, concepts, semantic models, and validated queries for a specific business domain. A finance Agent can prioritize finance‑domain definitions; common questions reuse vetted SQL templates; complex queries combine semantic models and business docs. Context Sets are IAM‑controlled; underlying data access respects existing permissions.

Accuracy ~4×, Tokens ‑75%: Why Both Improve

Google disclosed internal benchmark results for Knowledge Catalog’s context‑augmented Agents:

Accuracy nearly 4× baseline.

Response latency reduced up to 33%.

Token consumption reduced up to 75%.

These figures appeared in an October 22 announcement on self‑learning context augmentation, so they cannot be attributed solely to the six‑model GA release. Test‑set size, task composition, baseline configuration, and independent contribution of each optimization are not fully disclosed; interpret as vendor‑internal benchmarks.

Mechanistically, the gains are consistent: traditionally, developers stuff prompts with hundreds of tables’ schemas, field descriptions, business rules, and example SQL. As schema grows, context balloons, increasing token load and confusing the model with irrelevant or similar fields. For a net‑revenue query, only the relevant metric formula, a few filters, join paths, and quality metadata are needed. The Context Graph makes these retrievable, so the Agent fetches precisely what’s needed instead of scanning massive prompts or iterating through failed SQL attempts.

Figure 4: Before/after telemetry — tool calls 10→3, total tokens 26,058→15,150, end‑to‑end latency 29.32s→16.78s. Source: Google Cloud

Verified LookML join conditions and aggregation logic lower Join Fan‑out risk; maintained metric formulas shrink the space for ad‑hoc calculation; quality, certification, and lineage help the Agent choose among similar data sources. The principle: context need not be exhaustive, but must be task‑relevant and deterministic.

Self‑Learning Context Enhancement (Preview)

Business rules evolve. Finance may change channel‑rebate calculations; updates appear in docs or code repos before semantic models and prompts sync. Knowledge Catalog’s self‑learning enhancement analyzes Agent‑user interactions to detect missing definitions, metric ambiguities, and repeated query failures. It then searches business documents, runbooks, and code repos for candidate knowledge, proposing updates to business definitions, join relationships, and validated queries with source citations and confidence scores.

Figure 5: Knowledge Catalog enhancement suggestions list — each change tagged with confidence and rationale, expandable to show diff, awaiting data steward approval. Source: Google Cloud

Proposals are not auto‑applied to production . Admins configure auto‑publish policies and confidence thresholds; sensitive or low‑confidence changes require steward approval, with audit trails and rollback. Since this capability is still in Preview, it is not a fully autonomous governance system. Its practical value is shifting context management from one‑time setup to continuous maintenance, so Agents don’t rely on static knowledge frozen at a past prompt‑engineering moment.

Enterprise Agents Reuse Years of Accumulated Business Knowledge

Integrating six semantic models into the Context Graph changes not just the query entry point but how enterprises organize and maintain AI‑ready business knowledge. Previously, each Data Agent (finance, sales, supply chain) required separate prompts, term mappings, and example SQL — duplicating definitions even when sharing underlying data assets. Rule changes triggered cascading updates across applications, raising maintenance costs and inconsistency risks.

The Context Graph lets business definitions stay with the teams that know the data, while multiple Agents reuse them via a unified context layer. Semantic models cease to be mere BI configuration files and become first‑class business knowledge for AI systems. Finance, sales, and operations Agents each pull permitted definitions without re‑implementing revenue calculations, customer segmentation, or time‑dimension logic. Enterprises with mature semantic layers preserve their investment instead of rebuilding on an Agent platform.

This is especially critical for cross‑system tasks. A supply‑chain analysis may join ERP purchase orders, warehouse real‑time inventory, logistics delivery status, and finance settlement data. These systems differ in field names, object definitions, and update cadences. Merely exposing APIs doesn’t guarantee the Agent understands how to join them — it must know whether order IDs represent the same business object, what inventory counting convention applies, how to treat exceptional deliveries, and which source is more trustworthy. The unified context graph makes these relationships explicit, reducing ad‑hoc cross‑system inference.

However, the Context Graph cannot create business knowledge that doesn’t exist in source systems, nor automatically resolve all metric conflicts. Incorrect formulas, missing lineage, and unmaintained semantic models remain incorrect even inside the graph. What ultimately supports enterprise Agents is curated business definitions, traceable data relationships, and ongoing permission and quality governance. Google’s advance connects previously siloed knowledge from BI, data warehouses, lakehouses, and ERP platforms so Agents can use it — without each application rebuilding its own business‑understanding machinery.

Years of enterprise investment in semantic layers, metric frameworks, and data governance have not been obsoleted by large models. As Agents start performing independent analysis and cross‑system tasks, those foundational capabilities directly determine whether AI outputs can be trusted by business units. Writing SQL only proves the Agent can manipulate data; finding the correct business definition, obeying calculation rules, and tracing result provenance proves it can handle real enterprise analytical work. The next phase of enterprise Data Agent competition isn’t how many questions a model can answer, but whether its answers withstand scrutiny under actual business rules.