June 17, 2026 · London
I spent today at Google Cloud Summit London, and if I had to distil the whole event into a single sentence it would be this: the era of passive intelligence is over.
That’s not a marketing line I’m borrowing — it’s the actual framing Google used in the opening keynote, and after sitting through a full day of sessions, I think they’re right. Not in a hype-cycle way, but in a quietly structural way that I think a lot of organisations are still underestimating.
Here’s what stuck with me.
The Shift From “System of Intelligence” to “System of Action”
For the past few years, most enterprise AI has been what Google’s VP of Data called a “system of intelligence” — essentially a very sophisticated search box. You prompt it, it retrieves or summarises, you act on the result. The human is still firmly in the loop for anything that matters.
The argument made today — and I find it fairly compelling — is that this model breaks under the demands of agentic AI. The goal is no longer to know, it’s to act. Autonomously, in real time, across your entire data estate.
Google’s answer to this is what they’re calling the Agentic Data Cloud: a platform built around three ideas — trusted context, borderless data, and intent-driven outcomes. The core claim is that most platforms today fail at agent scale because they hit three walls: a cost spiral (10–100x more workload than traditional deployments), walled-garden architectures that force you to ingest all your data into one place before you can use it with AI, and a trust problem where agents act without sufficient grounding in your actual business context.
Whether or not you buy the full Google pitch, the underlying problems they’re describing are real. I’ve seen all three in practice.
The Knowledge Catalogue: The Quiet Differentiator
One of the things that generated the most interest in the keynote was something that doesn’t sound flashy at all: the Knowledge Catalogue.
The idea is simple. You have data scattered across structured databases, SaaS applications, PDFs, object stores, and cloud silos. Most of it — 90% according to Google’s data VP in the keynote — is unstructured. The Knowledge Catalogue uses Gemini to autonomously map and enrich all of this metadata, building what Google calls a dynamic context graph of your entire enterprise data landscape. Not just what your data is, but how it relates — the contracts that belong to customers, the policies that govern the products, the implicit logic buried in table schemas.
The practical payoff is twofold. First, it means your agents get the right context — not all the context, just the minimum effective context needed to act correctly. That matters enormously for cost and accuracy (fewer tokens burned, fewer hallucinations). Second, it does the data stewardship work that nobody can afford to do manually. Virgin Media O2 used it to map 20,000 tables they couldn’t feasibly catalogue by hand.
This is actually the most interesting architectural idea of the day for me. Grounding agents in a continuously maintained, semantically enriched context graph feels like the right solution to the context problem — and it’s one that’s genuinely hard to replicate if you’re building on top of infrastructure you don’t control end-to-end.
The Borderless Lakehouse: Acknowledging Reality
To their credit, Google didn’t pretend everyone’s data lives in GCP. The Borderless Lakehouse is their answer to multi-cloud reality — built on Apache Iceberg, with low-latency interconnects to AWS (and Azure support coming later this year), designed to make data feel local even when it isn’t.
WPP was the cited example: their agents needed to operate across a distributed network of client data locked in separate cloud silos. The Borderless Lakehouse let them treat it as a unified fabric.
I think this is table stakes now, honestly. Any platform that requires you to centralise data as a prerequisite for AI is going to lose. The data is where it is. The intelligence needs to come to the data, not the other way around.
Governance Isn’t an Add-On — And Most People Are Building It Wrong
The breakout session on real-time event-driven agentic architecture had the most grounded, honest content of the day. The speaker made a point I want to highlight because I’ve seen this mistake made repeatedly: most organisations are building agents before they’ve built the governance layer to run them at scale.
The analogy used was shadow IT, but for agents. You end up with duplicated agents, no visibility into what they’re doing, unbounded blast radius when something goes wrong, and no way to trace outcomes back to decisions. The costs are real — in compute, in errors, and eventually in regulatory exposure.
The recommended approach was to treat agentic AI as a platform problem from day one:
- Agent Registry: A single place where all agents are known, versioned, and discoverable
- Agent Identity: SPIFFE IDs to tie agents to specific permissions
- Agent Gateway: Built into the runtime for guardrails and policy enforcement, not bolted on later
- Observability and FinOps: You need to know what your agents are doing and what they’re costing
The Gemini Enterprise Agent Platform covers most of this, but the important insight is architectural, not product-specific: governance needs to be designed in, not added on. If you’re spinning up agents for POCs and planning to “handle governance later,” you will be paying for that decision.
The Data Foundations Reality Check
The most grounding session of the day — in the best possible way — was a talk from a practitioner at a major retailer who walked through their actual journey migrating to BigQuery and building data foundations for AI.
No keynote polish. Just honest lessons:
Culture is harder than technology. The biggest barrier to data transformation isn’t the stack — it’s getting the business to care. Their approach was to work with the biggest critics first, speak their language, make them accountable for outcomes, and over time convert them into champions. “The building was on fire and we were behind, but there were points of light” — their quote, and it resonated.
Don’t introduce governance too early. This sounds counterintuitive given what I just said above, but there’s a nuance: in the early stabilisation phase, imposing heavy governance before people trust the new platform will kill adoption. Earn credibility first, then formalise.
Stabilise → Foundation → Accelerate. Their three-phase strategy. You can’t skip phase one. If you’re 99% on a legacy system when you start, you need to give your team breathing room to actually migrate while keeping the lights on.
AI use cases need to be ROI- and risk-assessed. Not every idea deserves to be built. They have a board-level governance process: every AI initiative comes in with a business case, gets risk-assessed and ROI-assessed before execution. That discipline is what lets them maintain credibility and prioritise high-value work.
BigQuery now supports vector search and embeddings, and — I hadn’t seen this announced before — graph queries. The semantic layer being built on top of BigQuery is becoming increasingly capable, and it’s closing the gap between what analytical and operational systems can do together.
What’s Changing in Databases
The databases session was technical but worth flagging for the architectural shift it described: databases are no longer just storage systems.
The idea of an AI-native database means that the system doesn’t just store your data — it processes it semantically. AlloyDB now supports querying across the data lakehouse. Spanner already supports multi-model workloads — relational, graph, vector, and full-text search in a single system, all now generally available. BM25 is now supported for hybrid search. And Google introduced a managed MCP (Model Context Protocol) server, which means you can connect your databases to AI agents without hand-rolling the auth, connection management, and schema context that currently makes this painful.
The QueryData API + Text-to-SQL tooling, wrapped in the Data Agent Platform, addresses something concrete: most business users and even many developers don’t want to write SQL, but getting natural language reliably converted to accurate SQL has historically required a lot of custom work. The demo showed near-100% accuracy using a JSON context file (a schema-aware template) to ground the translation — and the token efficiency gains over naive natural-language-to-SQL were substantial.
This is directly relevant if you’re building any kind of data-facing agent. The managed MCP approach means you don’t have to rebuild the infrastructure layer every time.
The HSBC Case: What “Industrialising AI” Actually Looks Like
The HSBC partnership announcement was the headline customer story. A few things from their CIO’s interview stood out beyond the press release:
Moving to production is easy. Having AI that’s truly impactful is hard. HSBC’s CIO made this point clearly — the technology is accessible, but genuine business impact requires re-engineering the process, not just wrapping it in AI. Their fraud prevention work with Google DeepMind isn’t about automating existing fraud detection; it’s about rethinking how fraud prevention works from first principles.
AI-powered decision assistant: HSBC built an internal tool that arms relationship managers with a real-time combination of internal customer knowledge and current external context via Gemini’s web grounding. The speed of Google’s web indexing means a news event from minutes ago can inform a banker’s next call. That’s a genuinely different capability.
Governance is codified, not aspirational. Every AI project at HSBC starts by mapping the regulations, laws, policies, and procedures that apply — and encoding them as guardrails that agents must conform to at runtime. Google Model Armour sits across all running models to detect and intercept policy violations. This is what responsible AI at scale actually looks like in a regulated industry.
Hiscox: Agentic AI in the London Insurance Market
One of the more memorable moments of the day was a demo from Hiscox showing their AI-powered underwriting workflow in action — and specifically how they’re now using multi-agent collaboration via the A2A protocol to orchestrate it.
Hiscox launched what is the London insurance market’s first generative AI-enhanced lead underwriting model, built on Google Cloud. The original model stripped out manual steps in the underwriting process to get customers to faster quotes. What the Summit demo showed was the next chapter: that pipeline is now being redesigned as an agentic workflow, where multiple specialised agents collaborate — one to extract and interpret submission data, another to assess risk, another to apply pricing logic — handing off between each other using A2A.
What struck me about the Hiscox story is how directly it maps to the governance themes discussed elsewhere in the day. Insurance underwriting is a domain where a wrong decision has real financial and regulatory consequences. So Hiscox aren’t just using agents because it’s efficient — they’ve had to be deliberate about where human judgement stays in the loop and where agents can act autonomously. Their approach, as described in their thinking on AI governance, applies the CIA triad lens (confidentiality, integrity, availability) to AI risk — a useful mental model for any regulated industry.
The broader point: A2A isn’t just a technical nicety. For complex domains like underwriting, where a decision might need inputs from document extraction, actuarial models, regulatory checks, and market data — all from different systems — a standard agent interoperability protocol is what makes the whole thing composable and auditable. Without it, you’re stitching agents together with bespoke glue code that nobody can inspect or govern.
My Takeaways
A few things I’m still thinking about on the train home:
The full-stack integration argument is getting harder to dismiss. Other hyperscalers have infrastructure but not models. AI labs have models but not data platforms. Specialised data platforms outsource both. Google’s claim that vertical integration of infrastructure, models, and data systems gives a structural advantage for agentic AI performance and cost — that argument has more substance than it did a year ago.
The human-in-the-loop question is more nuanced than it looks. One of the more interesting moments in the real-time architecture session was about using agent confidence scores to decide when to require human approval. High confidence, low stakes: let the agent act. Low confidence or high stakes: route to a human. That’s the right model — not “always human in the loop” and not “agents all the way down.”
Open standards matter more as agents proliferate. The Agent2Agent (A2A) protocol for agent interoperability, SPIFFE IDs for agent identity, Apache Iceberg for lakehouse federation — there’s a real pattern here of Google backing open standards rather than proprietary lock-in. The alternative — every vendor with their own agent protocol — is chaos. I hope this trend continues.
Data culture is still the hardest problem. After a day of architecture diagrams and product announcements, the session that resonated most was the practitioner talking about working with critics, speaking business language, and earning trust slowly. The technology is genuinely extraordinary right now. But organisations that skip the culture work will build impressive demos and struggle with scale. That’s been true for ten years of data transformation. It’s still true.
The platform really is ready. The question Google asked at the close of the keynote — what will you build? — is the right one.
But I’d add a prior question: what have you built in terms of foundations, governance, and culture? Because that determines what you’ll be able to actually deliver.
These are my personal reflections from the event.
Leave a Reply