Google BigQuery Graph with Measures: Semantic Layer Extends to Business Relationships for AI Agents

From "What Happened" to "Why It Happened"

The traditional semantic layer focused on unifying metric definitions — ensuring Revenue, Churn Rate, and Active User compute identically across BI tools and analysts. In the agent era, the question shifts: agents need to know not only what the numbers are, but which business objects they relate to, how changes propagate along relationships, and where anomalies originate. Google Cloud's August 13 article Using BigQuery Graphs with measures for trusted agentic workloads details why governed Measures and Graph belong in the same analytical model. The capability was first announced at Google Cloud Next '24 on April 22, positioning BigQuery Graph as a "business map" for enterprise agents; the August piece provides a deeper breakdown. BigQuery Graph Measures remains in Preview.

Google illustrates with a retail case: Seattle winter jacket sales drop 12%. A flat-table query answers "what happened" easily. Answering "why" requires multi-hop traversal: which distribution centers serve Seattle orders, which suppliers those centers depend on, and whether a regional storm delayed those suppliers. Without the relationship graph, an agent might only see the sales dip and recommend 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 via Measures (how the business performs), and Relationship Mapping via Graph (why it performs that way).

Graph Finds Paths, Measures Guarantees Numbers

BigQuery Graph with Measures is not merely bolting graph queries onto SQL aggregation. Graph traversal expands nodes and edges; if a standard Join is followed by SUM or AVG, duplicate rows from the expansion cause over-counting. BigQuery's solution: define MEASURE directly on node or edge properties in the Property Graph DDL. Supported aggregations are SUM, AVG, COUNT, COUNT DISTINCT, MIN, and MAX. Each Measure binds to the node or edge KEY, so even when the graph expands to duplicate rows, aggregation still computes on unique keys. At query time, GRAPH_EXPAND unfolds the graph into a table, and AGG invokes the pre-defined Measure. Google's analogy: agents need to know when to use a "calculator" (SQL/Measure for correct numbers) and when to use a "map" (Graph for relationship paths).

The official example: to answer "which distribution centers serve the most distinct customers," Graph traverses User → Order → Product → Distribution Center paths, while a user_count Measure defined on the User node prevents the same customer from being counted multiple times after expansion. Relationship traversal and business aggregation thus complete in a single governed pipeline, without requiring the model to guess which duplicate rows to deduplicate.

This division is critical for Data Agents. Without Measures, agents can follow business chains but may miscalculate KPIs after complex expansions. Without Graph, agents can produce accurate KPIs but cannot explain the business lineage behind them. Google places both "computable business definitions" and "traversable business relationships" in one governed data model, and does not require migrating data to a separate graph database. Existing BigQuery tables can be mapped in-place as Property Graphs — described as zero ETL — lowering the barrier to introducing relationship modeling into current warehouses.

Semantic Layer Boundary Expands from Metrics to Business Structure

These capabilities are already entering the agent interaction layer. BigQuery documentation shows Conversational Analytics can use Graph as a data source, leveraging Graph-defined descriptions, synonyms, and Measures to improve answer quality. Explicit graph relationships reduce the agent's need to guess join paths. Supported versions allow agents to generate GQL for traversal or use GRAPH_EXPAND for SQL access. BigQuery Studio includes a Visual Graph Modeler for point-and-click node, edge, and relationship creation, moving graph modeling out of hand-written DDL.

Google also connects BigQuery Graph with Looker's semantic model. The April integration works two ways: (1) point Looker at an existing BigQuery Graph, mapping its attributes and Measures into LookML; (2) define the Graph model in LookML and have Looker generate and maintain the BigQuery Graph DDL. Models remain manageable through Looker IDE, Git, and CI pipelines. The goal is explicit: core KPIs like Churn Rate must not have one definition in dashboards and another in agents. The semantic model evolves from describing data structure (metrics, dimensions, joins) toward describing business structure (entities, relationships, multi-hop paths).

Google Is Building the Agent's 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. Google notes traditional data catalogs focus on table schemas, while agents hallucinate without Business Semantics and Data Relationships. Knowledge Catalog combines Aggregation, Enrichment, and Search to unify definitions on one side and generate/retrieve business relationships and context on the other.

Connecting these moves reveals a clearer semantic-layer evolution. Historically: Metrics + Dimensions + Joins. For agents: Metrics + Entities + Relationships + Business Context. Boundaries matter: Google has not merged Semantic Layer, Knowledge Graph, and Ontology into a single product, nor does it imply the traditional semantic layer will be replaced by Graph. The more accurate statement: agent-oriented semantic infrastructure is absorbing more "business relationships" and "business context," with the Metrics Layer remaining one component.

This changes how enterprises expose data to agents. A reliable future Data Agent may receive not just dozens of tables, schema descriptions, and a metric catalog, but a governed business model containing metrics, entities, calculation rules, and relationships — telling the agent both "how to calculate" and "why these objects connect." As agents move from point questions to root-cause analysis, cross-domain decisions, and long-horizon execution, this structured business context becomes essential. BigQuery Graph with Measures matters not because it adds another graph query flavor, but because it surfaces the semantic layer's next requirement: agents need a governable, queryable, reusable "business relationship network" — not just to read tables or compute metrics, but to understand how the company actually operates.