Google Next 2026 for Data Engineering: Looker, BigQuery and MCP Servers

Google Cloud Next 2026 in Las Vegas ran at the scale the brand implies, with keynotes and breakouts spread across a huge venue. For anyone who delivers Looker or BigQuery projects, the sessions on analytics, data integration and agentic analytics were the ones that counted. What follows sorts out the announcements that should change how such work is scoped over the next twelve months, then adds lessons from the customer talks, which turned out more useful than most of the product news.

The framing: from answering to acting

Google's overall message for analytics and data platforms is a move from a "system of intelligence" to a "system of action". The first is reactive BI that answers when asked. The second is a set of proactive agents that watch metrics, summarise what they find and act for the business.

None of this is new in spirit. Event-driven alerts and automated responses have appeared in enterprise BI toolkits for twenty years. Still, the renewed emphasis does useful work, because it changes what belongs in the scope of a Looker delivery project commissioned in 2026.

A practical consequence follows for anyone writing a statement of work. Reports and dashboards used to be the whole deliverable. Now the conversation also has to cover who or what consumes the data (people or agents), which questions the agents are expected to handle on their own, and who certifies the business rules those agents depend on. Projects that skip that conversation tend to rediscover it later, mid-build, at a higher price.

Agentic Data Cloud and its three ideas

The keynote centred on Agentic Data Cloud, Google's answer to a mismatch: the tools built for humans to understand data were never meant for a world where AI agents act on that data on their own. Three ideas hold it up.

Agents need meaning along with data. Aiming a powerful agent at a raw lake and hoping it works out the business is an expensive gamble. It has to learn that "net revenue" leaves out returns, that a metric is computed differently in two business units, or that a clause in a contract alters how a shipment is routed. The Knowledge Catalog is meant to capture and continuously maintain that institutional knowledge, so every agent touching the data starts from the same governed understanding.

Agents need to act, not only report. A conference example: instead of a dashboard displaying a spike in order cancellations, an agent notices the spike, runs root-cause analysis across logistics and sales data, pinpoints the distribution hub responsible, recommends rerouting, and starts a monitoring agent to see when things improve. Nobody had to ask.

Data stays where it is. Cloud platforms have long demanded that everything move to one place before value appears. Here, agents query data wherever it sits, whether on Google Cloud, AWS, Azure, Snowflake, Databricks or on-premises systems, with no costly migration first.

Looker as the semantic layer and experience layer

Put concretely, the Agentic Data Cloud combines BigQuery, the Knowledge Catalog, Gemini and Looker, with Looker acting as the experience layer and the four working as one system rather than separate products. Conversational analytics, dashboard agents, triggered workflows and the other Looker news are how that architecture reaches users, the point where people feel the difference between BI that reports and BI that acts.

The new Explore pushes further. The old field-picker-and-filters model gives way to a visual, drag-and-drop interface closer to Google Search or Google Docs. Three Gemini assistants sit inside it: one for navigating by natural language, one that writes Looker expressions from plain English, and one that picks a suitable chart type for the question.

For delivery teams, this means less time spent hand-holding people through the visualisation layer and more spent on LookML quality and semantic correctness underneath, since the assistants reason from whatever the model defines. A sloppy semantic layer will yield sloppy answers, now at conversational scale.

Dashboard Agents are generally available. Dashboards stop being static, broadcast-only artefacts: users can question them, ask for summaries of content and changes, and dig into the reason behind a number in conversation. The strongest enterprise example came from YouTube, where partner managers ask about creator portfolios across fifteen merged data sources, all from what looks like an ordinary Looker dashboard.

Triggered Workflows turn agents from passive responders into proactive monitors. Metrics are tracked around the clock, and teams get alerted the moment a threshold is crossed. The near-term roadmap includes agents that compose emails or post to Slack on their own. For operational analytics that is more valuable than it sounds, and it is a kind of request clients were not making two years ago.

Other Looker announcements deserve a mention:

• Looker agents inside Gemini Enterprise. Agents built in Looker can be published to Gemini Enterprise and managed next to other enterprise agents. For clients investing there, Looker becomes part of a wider AI strategy instead of a standalone BI tool.
• Conversational Analytics API, now GA. It comes with native Looker SDK integration, iframe embedding and an open-source reference implementation. Teams embedding conversational analytics in their own applications finally have a supported route, and conversations that stalled because the API was only in preview can restart.
• LookML Agent for VS Code (preview). An extension covering the whole LookML lifecycle from natural language.
• Looker MCP as an open standard. A managed MCP server exists alongside open-source options through MCP Toolbox. Connecting Looker to assistants such as Claude enables cross-explore analysis and agentic reasoning beyond what Looker manages alone.
• Native semantic layer integrations. Looker reads BigQuery graph definitions and Snowflake semantic views directly, so semantic logic already in BigQuery no longer has to be rebuilt in LookML.
• Multi-explore agents. An agent can draw on up to five explores at once. Yahoo's setup combines HR, finance, search and support data in single agents across several Looker instances.

What Yahoo and Virgin Media O2 learned

The conversational-analytics sessions from Yahoo and Virgin Media O2 were the most valuable for people doing this work. The main finding: accuracy depends mostly on two levers, golden queries and agent instructions written in YAML. Yahoo noticed better output after moving agent instructions from JSON to YAML. They then relocated golden queries and the business glossary into LookML instead of keeping them elsewhere, which cut instruction complexity considerably, because the model now reasons from the semantic layer and not from hand-written context.

Yahoo's own summary was the most quotable line of the event: conversational analytics begins with the semantic layer, not with the AI. Once data and model are ready, conversational analytics is nearly the next step in the evolution.

The practical reading for teams is a change of effort. Writing long, carefully tuned agent prompts gives way to enriching the model itself, because anything placed in LookML is available to every agent and every user, while anything placed in a prompt serves just one agent and goes stale quietly.

A good LookML model for conversational analytics has changed as a result. The baseline now includes labels, descriptions, synonyms and comments on every field, golden queries embedded in LookML, and a YAML business glossary within the model. Agent instructions stay deliberately thin because the semantic layer does the heavy lifting. Setting up Dashboard Agents, triggered workflows and golden queries should now sit in the baseline scope of any serious Looker requirements, not in an optional extras list.

Data Studio returns

Looker Studio has been renamed back to Data Studio, with a wider remit. It now handles three kinds of artefact. The first is the familiar report or dashboard, fed from BigQuery, Google and partner SaaS connectors, or the Looker semantic layer. The second is a conversational analytics agent that was built in BigQuery and then published there. The third is a new "data apps" idea, in which Colab notebooks are published as interactive applications.

Data apps land between a dashboard and a complete application. They are relevant for clients who rely on Looker for operational reporting, want more interactivity, and would rather not commission a full embedded application.

One consequence of the rebrand and the new self-service explores: the integrated "Studio in Looker", once billed as the future of Looker's front end, is unavailable to organisations that had not enabled it, and it is scheduled to be retired on June 15th, 2026.

BigQuery: data engineering agents and a managed MCP server

A good share of last year's previews have graduated to general availability. That covers the agents for data engineering and data science, conversational analytics inside BigQuery and its API, the BigQuery ADK, a managed remote MCP server for BigQuery, the open-source MCP Toolbox, and a plugin that captures telemetry on how agents perform.

Some newer items matter more than they first appear.

Fluid Scaling. BigQuery adds compute when agents are active and removes it when they are idle, with no manual sizing. The common objection about the cost of conversational analytics at scale weakens considerably.

BigQuery Graphs. A native graph engine with no ETL step, able to scale to billions of nodes and supporting ISO GQL. The more intriguing addition is Measures in BigQuery Graph, which pair governed metrics with relationship mapping and let agents reason over multi-hop dependencies.

Measures as reasoning extensions. A useful way to tell the two kinds of measure apart: LookML measures govern calculation, defining what a metric means and guaranteeing consistent SQL for every analyst and agent using Looker. Graph measures govern reasoning, placing the same metric definitions inside a graph of connected entities such as products, suppliers, hubs and routes, so an agent can trace why a metric moved by walking the relationships between contributing factors.

Migration services

The BigQuery Migration Service has been renamed Data Analytics Migration Services, and the overhaul is large, so anyone planning a move from Snowflake, Cloudera or Databricks in 2026 should reassess it. For Cloudera and Databricks, assessment is automated and produces a blueprint listing workloads with total-cost-of-ownership estimates. SQL from Hive, Snowflake and other dialects is translated into GoogleSQL at compiler level. Lakehouse migration handles Iceberg, Parquet and Hive tables, and an agentic validation service runs inline, scoring accuracy table by table and column by column. Because the migration APIs are reachable over MCP, a tool such as Claude Code could orchestrate a whole migration.

Earlier versions of the service had a mixed record on complicated SQL translation, and the new generation looks much stronger. The validation dashboard stands out, since it takes over a lot of manual checking that has been stretching migration schedules for years. Teams that previously budgeted weeks of analysts comparing row counts and column values by hand should revisit those estimates.

Federation across clouds

On the federation side, Databricks Unity Catalog on AWS S3 can now be read in both directions, and Snowflake Polaris and AWS Glue can be read from BigQuery as well. Everything rests on the Apache Iceberg REST catalog standard, so BigQuery can query these external catalogs directly with no data movement.

For clients who cannot or will not migrate fully, the pitch changes. Instead of insisting that everything move into BigQuery, the offer becomes: leave the data in place, reach it through BigQuery, and layer Looker and Conversational Analytics above. Snowflake shops that would otherwise be ruled out of a GCP-first analytics practice get a real option, and one likely to serve as a stepping stone toward fuller migrations.

Migration lessons from Target, Wells Fargo and Virgin Media O2

A panel with these three companies surfaced patterns that many people have learned painfully but that bear repeating.

Rule one, and the weightiest: bring the semantic layer across before anything else. Stand up the Looker or BI layer on GCP so business users can reach data there while data engineering is still mid-move, and bridge the gap with tactical replication jobs that copy key datasets into BigQuery. Virgin Media O2 has pulled this off through six large platform migrations, and Wells Fargo endorsed the approach.

Other patterns:

• Shrink the footprint before migrating. AI can find unused and duplicate data up front; one enterprise on the panel found over 80% of its data was duplicated.
• Lift and shift first, modernise afterwards. Refactoring mid-migration stretches timelines unpredictably.
• Build governance in from day one. Data contracts, a business glossary and data quality rules belong inside the migration programme, since retrofitting them later often fails once the political window has closed.
• Start small on data contracts. Pick a bounded area, make supplier and consumer contracts clean for that case, and use it as the model of what good looks like before scaling.

Target also contributed a framing worth borrowing, "irrational goals": choose targets that cannot be reached unless the platform is rebuilt around AI-native methods. Doing so shifts the discussion away from how to migrate and toward how to transform.

Data Agent Kit

In preview, the Data Agent Kit pairs a VS Code extension with plugins for Gemini CLI, Cloud Code and Codex. Together they package skills and MCP tools for BigQuery data workflows: agentic skills, MCP servers, tools for reaching BigQuery, and plugins for deep VS Code customisation. The skills themselves are open source and can be adapted.

Consultancies and client teams already building internal agentic delivery tooling should evaluate it seriously. An early reading is that it covers BigQuery-layer engineering and complements broader delivery orchestration and LookML, fitting alongside skill-based approaches already in use.

Knowledge Catalog, formerly Dataplex, as agent context

Dataplex is now Knowledge Catalog, repositioned as the context backend for Google Cloud agentic workflows. Three pillars support it. The first aggregates metadata from Google services, Looker included, and from partner catalogs such as Atlan, Collibra and SAP. The second enriches that metadata, using automated generation and a business glossary that has reached GA. The third offers semantic search, with a Context API through which agents retrieve what they need.

The most instructive case came from Bloomberg Media. Its "Knowledge Gap Agent" learns from agent failures, spots where data context is wrong or missing, and proposes updates to the Knowledge Catalog for human certification. The headline result: 102 usage notes auto-generated across twenty MVP tables, lifting SQL accuracy of a data-access agent by 63%.

For smaller engagements, Knowledge Catalog will stay in the background. For clients building conversational analytics agents at scale, with institutional knowledge not yet codified anywhere an agent can reach, it is the missing piece. Bloomberg called the underlying failure the "42-dollar problem", which hits human analysts and AI agents alike: knowledge that is documented nowhere in the data platform.

In their example, a junior analyst picked the right tables, wrote valid SQL and applied standard net revenue logic, yet got the wrong number. The payments vendor charges a $42 fee for every customer dispute, and that fee has to be added to the revenue calculation. The rule was in no schema, in no pipeline and in no reachable document. It lived on a 2017 Confluence page whose author had left the company.

Is the semantic engine missing?

One critique making the rounds afterwards says Google is all-in on the agent layer while its semantic and business context stays comparatively weak. On this view, the Knowledge Catalog resembles a metadata aggregator, with little of the character of a real enterprise operating system like OpenAI's Frontier or Palantir's Foundry. Without a strong semantic engine tying business meaning to agents, even advanced tooling risks drifting outputs, hallucination or a correct answer to the wrong question.

Most of that diagnosis holds, and the semantic layer matters more in an agentic world than it ever did in a dashboard one. The more optimistic reading is that the LookML semantic layer already covers most of the business-context duties an enterprise operating system would be expected to perform. It removes the multiple-versions-of-the-truth problem, supplies governed metric definitions, and serves as the trusted metrics store for assistants like Claude via MCP Toolbox.

That the Knowledge Catalog said little about LookML integration at the conference does not mean LookML is idle. The work happens one layer lower than where critics look for it.

The concrete evidence is in Google's documented best practices for configuring Conversational Analytics in Looker. It draws on two main inputs: the structure, fields, labels, descriptions and synonyms in the LookML model, and distinct field values sampled from the data, where cardinality (the number of unique values) shapes how those values are used.

To fetch the distinct values, Conversational Analytics calls the long-standing Looker API method model_fieldname_suggestions. That is the same mechanism behind filter suggestions in the field picker and dashboard filters, now reused as a grounding signal for the model. Three existing LookML parameters, suggestions, suggest_explore and suggest_dimension, therefore double as the developer's means of steering which values Conversational Analytics is aware of.

Teams do not have to wait for the product to do this; the same idea can be assembled by hand on a BigQuery warehouse. Next to a standard data dictionary derived from INFORMATION_SCHEMA, one can maintain a markdown guide, exposed to an assistant as a skill and regenerated periodically by a profiling step. It describes each table with row counts, date ranges, and the value sets and cardinalities of high-signal categorical fields, so the assistant knows, say, that a messages table splits across iMessage, Slack, WhatsApp and others in known proportions, instead of guessing.

Conversational Analytics now does the equivalent at the LookML layer, generalised for all Looker users. Take a city dimension populated from customer or operational data. The system would sample its distinct values, such as Brighton, Hove and London, and let cardinality decide how heavily each value should count when users ask questions.

The levers for a LookML developer are those three parameters, used like this:

view: customer {
  dimension: city {
    label: "Customer City"
    description: "The city associated with the customer's primary address. Most operational activity occurs in Brighton and Hove (UK head office) and London (UK secondary office)."
    type: string
    sql: ${TABLE}.customer_city ;;
    # Hard-code a curated list of values rather than letting Looker
    # run SELECT DISTINCT against a large table.
    suggestions: ["Brighton", "Hove", "London", "Edinburgh", "Manchester"]
  }
  dimension: customer_segment {
    label: "Customer Segment"
    description: "Customer tier based on annual recurring revenue."
    type: string
    sql: ${TABLE}.segment ;;
    # Pull suggestions from another view rather than scanning
    # the much larger customer fact table.
    suggest_explore: segments
    suggest_dimension: segments.segment_name
  }
}

Combined with descriptions, synonyms and a few golden queries embedded in the model, they give a LookML semantic layer exactly the job the critics want from an enterprise operating system: grounded, governed business context for the agent layer, with cardinality-aware sampling of real values, all driven from the same LookML behind dashboards and explores.

So the reading of Knowledge Catalog versus LookML is different. Today LookML looks like one input among many in the Knowledge Catalog architecture, and it is easy to see why that seems thin. Over the next twelve to eighteen months, expect that to change significantly, since Google has every reason to make LookML the most prominent input to the catalog and not just one of several.

The semantic engine the critics call for is not really missing, because most of it already lives in LookML. What remains unsettled is whether Knowledge Catalog matures into the business-context layer that carries LookML meaning through the entire agentic stack, or whether another product fills that role. Either way, time spent getting LookML right is time that pays back.