Google's BigQuery Graph: Semantic Layers Evolve to Business Relationships for Agents

From "What Happened" to "Why"

Traditional semantic layers focused on unifying metric definitions — ensuring Revenue, Churn Rate, and Active User compute identically across BI tools and applications. In the Agent era, the question shifts from "what is the sales figure?" to "why did sales drop?" Google Cloud's August 13 article Using BigQuery Graphs with measures for trusted agentic workloads (following the April 22 Next '24 announcement) explains why governed Measures and Graph belong in the same analytical model. BigQuery Graph with Measures remains in Preview.

A retail example illustrates the gap: Seattle winter jacket sales fall 12%. A flat table answers "what happened," but the root cause lies in a multi-hop chain — Seattle orders → distribution centers → suppliers → regional storm delays. Without that relationship network, an Agent might suggest a 15% discount, failing to fix the supply-chain issue and further eroding margin. Google frames the analysis in three layers: Metadata Grounding (what data exists), Business Metrics (Measures compute performance), and Relationship Mapping (Graph traces why).

Graph Finds Paths, Measures Guarantee Numbers

BigQuery Graph with Measures is not merely bolting graph queries onto SQL aggregation. Graph traversal expands nodes and edges; naive JOIN‑then‑SUM leads to over‑counting from duplicated rows. BigQuery's solution: define MEASURE directly on node or edge properties in Property Graph DDL. Supported aggregations: SUM, AVG, COUNT, COUNT DISTINCT, MIN, MAX. Each Measure binds to the node/edge KEY, so even after graph expansion the aggregation respects unique keys. Queries use GRAPH_EXPAND to flatten the graph to a table, then AGG to invoke the pre‑defined Measure. Google's analogy: Agent needs a "calculator" (SQL/Measure) for numbers and a "map" (Graph) for relationship paths.

Official example: "Which distribution centers serve the most distinct customers?" Graph traverses User‑Order‑Product‑Distribution Center paths; a user_count Measure on the User node prevents duplicate counting after expansion. Relationship traversal and business aggregation complete in one governed pipeline, removing the burden from the model to deduce which duplicate rows to drop.

This duality is critical for Data Agents. Without Measures, Agents navigate relationships but miscalculate KPIs; without Graph, Agents produce accurate KPIs but cannot explain the business chain behind them. Google places both in a single governed data model without requiring migration to a separate graph database — existing BigQuery tables map in‑place to Property Graphs, a capability termed "zero ETL."

Semantic Layer Boundary Expands to Business Structure

The capability now enters the Agent interaction layer. Conversational Analytics can use a Graph as its data source, leveraging Graph‑defined descriptions, synonyms, and Measures to improve answer quality. Explicit graph relationships reduce Agent guesswork on join paths. Supported Agents can generate GQL for traversal or use GRAPH_EXPAND for SQL access. BigQuery Studio's Visual Graph Modeler lets analysts create nodes, edges, and relationships visually instead of hand‑writing DDL.

Integration with Looker semantic models works bidirectionally: Looker can point to an existing BigQuery Graph (mapping properties and Measures to LookML), or define a Graph model in LookML that Looker then generates and maintains as BigQuery Graph DDL. Models stay under Looker IDE, Git, and CI governance. The goal: core KPIs like Churn Rate must not have divergent definitions in dashboards versus Agents. The semantic model evolves from describing data structure (metrics, dimensions, joins) to describing business structure (entities, relationships, multi‑hop paths).

Google Building Agent Business Context Layer

Zooming out, this is not an isolated BigQuery change. The April‑launched Google Cloud Knowledge Catalog targets an enterprise Context Engine for Agents: it aggregates BigQuery Measures, LookML, data products, and cross‑platform metadata, then continuously enriches them to discover entities, relationships, business vocabulary, and validated query patterns. Traditional data catalogs focus on table schemas; Agents hallucinate without Business Semantics and Data Relationships. Knowledge Catalog combines Aggregation, Enrichment, and Search to unify definitions while generating and retrieving business relationships and context.

Connecting these moves reveals a clearer semantic‑layer evolution. Legacy: Metrics + Dimensions + Joins. Agent‑oriented: Metrics + Entities + Relationships + Business Context. Google has not merged Semantic Layer, Knowledge Graph, and Ontology into one product, nor does Graph replace the traditional semantic layer. Rather, Agent‑facing semantic infrastructure is absorbing more "business relationships" and "business context," with the Metrics Layer as one component.

This changes how enterprises expose data to Agents. A reliable future Data Agent will receive not just dozens of tables, schema descriptions, and a metric catalog, but a governed business model containing metrics, entities, computation rules, relationships — telling the Agent both "how to calculate" and "why these objects connect." As Agents progress from point questions to root‑cause analysis, cross‑domain decisions, and long‑chain execution, structured business context becomes indispensable.

BigQuery Graph with Measures matters not because it adds another graph query flavor, but because it surfaces the next semantic‑layer requirement: Agents need a governable, queryable, reusable "business relationship network." We first wanted Agents to read tables, then to compute metrics correctly; now they must understand how the company actually operates.