How 1,146 sessions, 444 slide decks, and 323 video transcripts became 8,285 nodes and 24,421 edges of structured knowledge.
Google Cloud Next 2026 was one of the largest cloud conferences of the year — over a thousand sessions spanning AI infrastructure, developer tools, enterprise platforms, security, and industry verticals.
The challenge: how do you make sense of that much material at once?
The answer was to treat the entire conference as a corpus and build a knowledge graph from it. Here's how the data pipeline worked, layer by layer.
Five steps turned scattered conference artifacts into a graph you can query and reason about on the go.
The first layer was the structured index from the Google Cloud Next 2026 session explorer. Each entry had a title, description, speaker names, company affiliations, topic tags, room, and timing. This became the skeleton: every session title and speaker was a candidate entity in the graph.
For 444 of the 1,146 sessions, a slide deck was available on the Google site. Each PDF was downloaded, converted to images, and processed with vision analysis — extracting product names, architecture diagrams, metrics, and key claims from individual slides. This yielded 2,205 slide-level analysis records and per-session brief summaries.
Slides are uniquely valuable: they contain the distilled, intentional message a speaker wants to convey. A bullet point on a slide is more signal than two minutes of verbal framing around it.
For 323 sessions, a YouTube recording was available. Full audio transcripts were retrieved when available, or generated when needed, and stored — capturing the speaker's actual words, including Q&A, live demos, and audience interactions that never appear in a slide deck.
The combination of slides + transcript for the same session was particularly powerful: slides provided structured claims while transcripts provided context, nuance, and the path that led to each conclusion.
All 477 source files (~5 million words) were fed through graphify, an AI-powered knowledge graph builder that reads raw text and extracts named entities, concepts, products, companies, and people — along with the semantic relationships between them.
Most of the graph was built from directly sourced connections found in the conference material itself. Separately, 114 additional edges were added by cross-document reasoning, and only kept when they cleared a 0.85 confidence threshold.
The resulting graph was then analyzed for community structure using modularity-based detection. 44 distinct communities emerged — each representing a cluster of entities that are more densely connected to each other than to the rest of the graph. Community names are derived from the most distinctive nodes in each cluster.
This is the full output: 8,285 entities and 24,421 relationships rendered as a force-directed graph. Each dot is a node, each line a relationship, each color a community.
44 color-coded communities are visible as rough clusters, but the density of the core makes individual relationships impossible to read. This is the starting point for simplification.
Rather than showing every node, the strategy graph surfaces the architecture underneath: six distinct zones that Google Cloud organized its Agentic AI story around at Next '26.
The simplification works by promoting only the highest-degree hub nodes within each detected community and collapsing everything else around them. Intra-layer connections become solid lines within each bubble; cross-layer connections become dashed lines between zones. The result is a map you can actually read and reason about.
Six zones: Protocol/Tool Fabric (MCP, ADK, A2A Protocol) · Agent Control Plane (operational + security) · Governed Data Substrate (BigQuery et al.) · Agent Platform (Vertex AI, Gemini) · Runtime/Infra (GKE, Cloud Run) · Enterprise Surface (Google Workspace, NotebookLM)
The picture is pretty simple: Google appears to be assembling a full enterprise agent stack. At the bottom are the protocols and tools that let agents reach other systems. Then come the control layers that secure them, the data systems that ground them, the model and agent platform that powers them, the infrastructure that runs them, and the products where people actually use them.
The graph makes that structure visible. A long list of launches starts to read like one architecture for enterprise agents.
A knowledge graph built from 5 million words of conference material isn't just a visualization — it's a queryable model of an entire industry conversation.
The kinds of questions it can help answer span from high-level strategy down to very specific session recommendations. On mobile, tap any question to expand the answer.
The graph isn't just an outside analysis trick. Google repeatedly described agent-ready systems in graph-shaped terms: entities, relationships, connected context, and knowledge that agents can reason over.
In the opening keynote (session explorer), Google introduced Knowledge Catalog as a system that can read files, extract entities, map relationships, and learn business semantics. In What's new with data and AI governance: Building the catalog for AI (session explorer), that idea became even clearer: the goal is a connected context layer that agents can reason over directly.
This wasn't just abstract metadata talk. The source material also includes concrete product pushes around graph-native data systems. Spanner Graph appears in What's new in Spanner: enterprise-scale AI, search, graph, and analytics, where Google describes multimodel support, SQL PGQ, integrated graph algorithms, graphs on views, and UI-based graph modeling. BigQuery Graph appears in multiple decks as native property-graph support for relationship analytics, visualization, and graph-grounded reasoning on enterprise data.
That's what makes this feel new. For years, products like BigQuery and Spanner were mainly framed as places to store, query, and scale data. At Next '26, Google was also positioning them as systems for modeling relationships directly — not just rows and columns, but connected structures that agents and analytical workflows can traverse. This is Google reframing databases for the agent era.
And it goes beyond two product names. Other graph-shaped concepts also show up in the graph itself: BigQuery Property Graph, Property Graph, GQL / ISO GQL, Graph Analytics, Graph RAG, Knowledge Graph Grounding, Vertex AI Graph Neural Networks, and security-oriented nodes like Wiz Security Graph and SCC Security Graph.
That matters because it validates the method of this page. The conference graph here is external and independently built, but it is not conceptually alien to Google's own framing. If anything, the company's product story is shifting from isolated data systems toward connected context systems: not just documents, not just tables, and not just prompts, but systems that understand entities, relationships, provenance, and business meaning well enough for agents to act on them.
Three sessions at Google Cloud Next 2026 featured Geotab speakers — not as generic customer references, but as working operators paired with Google product leads.
Junaid Gill (Associate Vice President, Geotab) joined Greg Brosman (Senior Product Manager, Google Cloud) and John Murray (Group Product Manager, Google Cloud) on governing a secure agentic ecosystem.
Francois-Xavier Jeannet (Team Lead, Data & AI Governance, Geotab) joined Anit Patinker (Lead Product Manager, Google Cloud) and Shelley Hershkovitz (Product Manager, Google Cloud) on agent security at scale.
Daniel Lewis (Distinguished Data Scientist, Geotab) joined Dima Melnyk (Senior Product Manager, Google Cloud) and Alex Martin (Product Manager, Google Cloud) on the agent-quality flywheel.
All sessions with Geotab speakers → On the conceptual map, those talks land in a tight zone around platform, governance, and evaluation. One Geotab example helps explain why: their internal hackathon generated 86 agent submissions, and 2 of those later made it into production.
That gap helps explain why Geotab mattered on stage. In earlier years, Geotab often appeared as the customer saying, in effect, BigQuery works and here's how we use it. This time the posture felt different. AI is still early, but Geotab has already been building agentic systems, and Google is bringing them on stage not merely as a reference customer, but as a partner with production lessons that are helping shape the products now being pushed more broadly.
"Anyone at Geotab should be able to build an agent."
"The models are ready. The people are motivated. What's missing is the platform."
Geotab slide from Govern your agents: Architecting a secure agentic ecosystem
"Out of the 86 agents submitted, how many made it to production? 2."
That may be the cleanest summary of the real enterprise problem: generating agent ideas is easy; getting them into production is the work.
Geotab slide presented by Junaid Gill in Govern your agents: Architecting a secure agentic ecosystem
"All of our evals consume way more tokens than our production system does from our customers."
Maybe that's what it takes: at scale, the hard part is not getting agents to demo, but building the evaluation machinery that keeps them trustworthy in production.
Daniel Lewis, Geotab, in Engineer the agent-quality flywheel
Orange dots mark each Geotab session. The legend bottom-left confirms: orange = Geotab session.
Two of the three Geotab sessions landed inside the Agent Control Plane: one on governing agents and securing the agentic ecosystem with GEAP, and one on agent security at scale through the OWASP Top 10 for agents. The third landed in the Agent Platform zone, focused on the agent-quality flywheel and GEAP evaluations.
That cluster makes sense. Geotab was not up there to show a flashy demo. It was there to talk about the hard part: getting agents into production, keeping them secure, and building the evaluation loop that makes them reliable. That is also why the control-plane layer matters so much on this map. The hackathon result was not a failure case. It was an example of how an exploratory funnel narrows into a small number of production-worthy agents, and why governance, security, evaluation, and operational control matter so much once a team tries to ship them.
First: graphing the conference reveals structure you cannot reliably see by reading sessions one by one. Once 1,146 sessions, 444 slide decks, and 323 transcripts are turned into nodes and edges, repeated patterns become visible: which products sit at the center, which protocols connect otherwise separate systems, which themes cluster together, and which ideas show up across product, security, data, infrastructure, and partner talks.
That is where many of the strongest insights in this story come from. MCP starts to look like connective tissue. BigQuery starts to look like a governed substrate for AI systems. Cloud Run, GKE, security controls, evaluation loops, and enterprise data products start to read as parts of the same architecture.
Second: building the graph was fairly straightforward. Cleaning up the conference corpus was the hard part. The source material was messy: decks, transcripts, session pages, repeated product names, overlapping abstractions, and different levels of specificity. graphify made the workflow feel direct: feed in the corpus, extract grounded entities and relationships, and simplify the result into a graph that a human can actually read.
The graph also shows what Google seems to believe will matter in production. The center of gravity is a working stack: agents connected through MCP and A2A, grounded in enterprise data, deployed on managed runtimes, evaluated continuously, and wrapped in governance, identity, and security controls.
If you want to test that thesis yourself, browse the session explorer, or open the full interactive map and follow the edges yourself. The graph, the map, and the session index feel like the right publishable artifact here, without redistributing downloaded slides or transcripts.
One encouraging part of this project is how manageable it was. It took a few steps, and Graphify made the workflow pretty approachable.
A future attendee could use a graph like this during the next conference to decide which sessions to prioritize, spot the hubs everyone is converging around, and follow emerging ideas across tracks in real time. It works well as a retrospective, and it would be even more useful live.