So I did it. On my phone. In about one hour. Very light, browser based, no backend storage, export and import RDF.

Provide as input whatever you want to model, question you are trying to answer. The system has modeling skills and proposes what a minimal model should be.

It states the assumptions, decisions and other questions to consider

and then you accept or reject.

And voila, you have it.

You can keep the conversation going.

Export the ontology in RDF. You can also import one too.

All of this built on my phone in about an hour. 5 mins here, 5 mins there.

If you want to test this out, ping me.

I met Bethany back in 2019 at the Knowledge Graph Conference where she was already presenting the value they were getting from ontologies. You can watch her talk here and my trip report from that event.

Back to the present, 2026. This is what we discussed on our podcast

Listen on our Website , Spotify, Apple Podcast

Data products as a process

Slapping the label "data product" on existing data assets changes nothing. A data product has to mean something: defined boundaries, have an addressable market, start with an MVP, a clear roadmap, and an executive accountable for it because they can clearly explain the business value for their LOB. 

Capital One's approach started with a standardization strategy around three core domains: customers, accounts, and transactions. Those three things are the foundation of the business. There was a clear business need to invest in standardization. However, standardization is expensive so if you are going to do it, do it right. But standardization alone didn't solve the problem. It didn't fix broken ownership, it didn't guarantee data quality, it didn't ensure data was available in the right formats, and it didn't create feedback loops with consumers. That's when the shift happened: from standardization to treating data like a product. Standardization is the start, to get the right people talking and agreeing. But it’s just that, the start. 

Governance process as the forcing function for business value  

Capital One runs proposals through a steering committee before a data product gets created. That structure is what keeps the program from data product sprawl with no or very little business value. 

A VP or above must be accountable for the proposal. This is a deliberate accountability mechanism because if a VP isn't willing to put their name on it, it probably shouldn't be a data product yet. The committee then debates boundaries, addressable market, what the MVP looks like, what general availability looks like, and the roadmap. 

This structure also keeps scope in check. Capital One is targeting roughly 80–100 data products in their universe. Could they have 500? Technically yes. But the point is discoverability and usability. So less is more. The moment you let anyone call anything a data product without a process, you are heading towards a meaningless swamp.

Dedicated roles, not side-of-desk work

Data product managers are full-time, first-class roles. They are not responsibilities bolted onto existing jobs. One PM per data product is the target, and exceptions require explicit approval.

Data product managers have a pod of technical colleagues around them. The role doesn't require a traditional product management background. Capital One has seen business analysts, data analysts, and even ontologists transition successfully into data PM roles. What matters most is understanding who the data consumers are, what they're trying to do with the data, and the ability to influence, both up and horizontally, to get the data right upstream before it gets to consumers.

Ontology as a strategic function

Ontologists are the other half of the equation. Capital One currently has 40 enterprise-wide ontologists as a first-class job family alongside data engineers and data scientists. They model data, partner with PMs, build tools to automate knowledge capture, and connect semantics to actual data. The critical skills are strategic thinking and working backwards from consumers; the technical skills can be learned. 

AI expands what counts as a data product 

AI enters the picture in two ways. First, it's going to accelerate the creation of high-quality data products: more products getting to market faster. Also this is an exciting opportunity for ontologists to think about what the profession looks like next. Capital One is actively figuring out what that trailblazing looks like.

Second, working backwards from agents is forcing a rethink of what counts as a data product in the first place. Some of it will require building net-new products designed primarily for non-human consumers. The original estimate of 80–100 products may be off, because AI is hungry for types of data that weren't previously in scope (e.g unstructured data, call transcripts, etc) 

Final advice

Just start. But start from your data consumers, not from the technology. Don't start with the ontology. Don't start with the technical solution. Start with understanding who your consumers are, why your consumers need the data and what they're trying to do with it. Build a use case, show the value, and use that to get the next thing funded.

Upcoming guests:

• Bethany Sehon on data products and ontologies

• Patrick McGarry on organizational transformation

• Dora Boussias on preserving executive trust and credibility

• David Krauza on business choices that affect AI

• John Licata on quantum readiness

• Tara Raafat, PhD on semantics and metadata

• Hannes Mühleisen on how tables rock

• Shachar Meir on failure & success of data teams

• Rainer Struck on executive alignment

• and more!

In our kick off episode, these were the topics that we ranted on:

• The new website (honestnobsdata.com) and discussed building a knowledge graph of the podcast itself

• Two types of semantics: for AI context vs. for system interoperability

• The vendor hype gap vs. practitioner reality

• AI agent proliferation and the governance surface area explosion

• AI cybersecurity: models escaping their sandboxes

• The economics of AI: accuracy, latency, and token cost as the new CAP theorem

• The great convergence, “triangle of consolidation” and “postmodern data stack”

• OSI and Apache Nessie

• Work as the center of gravity

• Bridging the operational and analytics worlds

Get more from Juan Sequeda in the Substack app

Available for iOS and Android

Get the app

There were a lot of reasons for the break. It has now been a year since we became part of ServiceNow, and there have been a lot of exciting moving pieces professionally.

But I also decided to use some of my personal time this summer for something I haven’t been able to do lately: play with AI coding agents, build things, and get my hands dirty again.

There was one problem: time.

I travel a lot. Work is busy. And when I’m home, my weekends are family time. I don’t want to disappear into my office for hours on a Saturday to work on a side project.

So I gave myself a different challenge: What can I build five minutes at a time?

Literally.

If I’m walking down the hallway and can make a five-minute pit stop in my office, what can I get done? Five minutes here. Five minutes there. Come back to it next weekend.

That experiment turned into something I’m pretty excited about.

We finally built a website

After almost seven years of doing the podcast, we finally have a website:

https://honestnobsdata.com/

A little embarrassing? Maybe. But the content has always been the point.

We now have hundreds of conversations with incredible people across data, analytics, knowledge graphs, governance, AI, and everything in between.

That is not just a pile of podcast episodes. It is a knowledge base.

So I didn’t want to simply build a website. I wanted to build something underneath it that could be reused for a lot of other things.

Drinking my own Cocktail

One topic I have been talking about a lot is the distinction between two uses of semantics:

Semantics for AI and Semantics for interoperability of systems.

There is enormous attention right now on the first one: how do we give AI enough context to understand our data?

That is important. However my position is that we should start with the second: define the meaning of things so systems can interoperate. Then AI becomes one of the systems that can consume that meaning.

So I decided to drink my own cocktail. Instead of designing a website for our podcast, I built a knowledge graph describing the podcast.

Nothing enormous. No boiling the ocean. Started with a simple ontology describing things like episodes, guests, topics and a lightweight taxonomy of the subjects we discuss. Then data pulled together from places where it already exists: the podcast RSS feed, YouTube, Spotify, guest LinkedIn profiles. All of that becomes one graph.

Define once. Reuse everywhere.

This is the part I care about most. The knowledge graph isn’t being built for the website. The knowledge graph is the source. The website is simply one projection of it.

I should be able to use the same knowledge graph to:

• Generate a static website

• Query it as a graph

• Produce JSON-LD structured data

• Build analytics

• Create visualizations

• Connect an MCP server

• Let an AI system interact with the podcast knowledge

• Eventually connect transcript segments to specific topics, guests, claims, and conversations

Same semantics. Different consumers.

Define once. Reuse over and over again.

That is the interoperability point.

The website is just consumer #1

That’s probably the biggest point of this entire experiment. The new podcast website is essentially a projection of the knowledge graph. And if another consumer comes along tomorrow, I don’t redesign the underlying model around that consumer. I create another projection.

A lot of software starts with the application:

“We need a website. What database schema should the website have?”

I’m intentionally starting somewhere else:

“What is the knowledge we have, what does it mean, and how should we represent it independently of any particular consumer?”

Then:

Website? Consumer.

Search? Consumer.

Analytics? Consumer.

AI? Consumer.

MCP? Consumer.

The middle stays the same.

And this is exactly what I mean when I talk about semantics for interoperability first. AI fits into the architecture.

Five minutes at a time

Another constraint I gave myself was to keep this extremely lean. I don’t want a giant application stack. I don’t want ten services that need to stay running just so someone can read a podcast page. And I especially don’t want to build infrastructure before I know that I need it. I’m leaning heavily on open standards I’ve been working with for a long time: RDF, OWL, SPARQL.

There is still a ton I want to do.

Transcript-level knowledge is probably the part I’m most excited about: connecting very specific moments in six years of conversations to the topics being discussed, who said what, and where that conversation happened.

I want to experiment with querying it.

Visualizing it.

Giving agents access to it.

Publishing more of the underlying graph itself.

And seeing what other people build with it.

But I’m intentionally doing this incrementally.

Five minutes here. Five minutes there. A little more each weekend.

I’ll share the architecture and implementation in more detail in future post to help explain what it actually look like to build semantics for interoperability and then let AI become one of many consumers of it.

And meanwhile, Catalog & Cocktails is back for year seven. It’s good to be back.

CDOIQ is different from most data conferences. It’s not a Snowflake or Databricks conference where the keynotes are designed to sell you a platform. It’s not a Gartner where analysts are presenting their perspectives and vendors are sharing use cases and their capabilities. Many of the people attending CDOIQ are data executives and leaders (and some practitioners) who are accountable for outcomes. They have to deliver. That accountability forces an honest conversation among peers. Many folks attend because they want to get out of their bubble and see what other leaders are doing. People are talking about what’s actually hard.

Naturally, there are vendors, consultants, thought leaders in the audience and giving talks. I self selected and focused on attending talks by data leaders at large enterprises. Therefore, this takeaway trip report reflects what I heard and learned from that audience.

If I were to summarize my takeaway in one word: grounded.

The Room Was Grounded. That’s a Signal.

The dominant energy at CDOIQ was not excitement. It was not transformation theater. It was groundedness.

Leaders talking and presenting about foundations, governance, data quality, organizational models, and the unglamorous work of building something that lasts. There was almost no concrete talk about business reinvention, agentic transformation, or AI-driven disruption in the “we have transformed our business with data and AI, and here’s how we did it“ sense. The aspiration was present. The execution playbook was not.

At first pass, you might read that as disappointing. But I think it’s actually the most important signal from the event.

These are the leaders who are accountable. If the transformation story were real and replicable at scale, they’d be telling it. Instead, they’re heads-down on fundamentals. That’s either genuinely encouraging because the right work is happening and the foundations are being built. Or it’s a gap signal: the leap from solid foundations to actual business transformation hasn’t happened yet for most of these organizations, and nobody quite knows how to close it.

I left believing it’s both. And the tension between those two readings is what I want to unpack.

Part One: Most Organizations Are Still in the Middle of Fundamentals

Across every session, every panel, every hallway and dinner discussion, one thing came up over and over again in different forms: You cannot shortcut the foundation.

Not governance. Not data quality. Not ownership models. Not semantics. Not the organizational design that makes any of it stick. These are not prerequisites you check off before the real work begins. They are the real work. Most large enterprises are still in the middle of them.

This is not a new insight. But hearing it repeated, independently, by data leaders from insurance, financial services, healthcare, retail, and defense contracting, all at roughly the same moment during this AI hype cycle, tells you something. The gap between what the industry is being told AI can do and what the data infrastructure can actually support is real, it is wide, and the people who have to close it know it.

Nationwide: Making Trust Measurable

Bill Snider from Nationwide gave an operational talk on data quality. Nationwide is a complex organization: 36 product lines, 500 critical business applications out of 2,500 total, 4,500 production databases, running virtually every flavor of data storage imaginable.

Their answer to that complexity? Don’t govern everything. Figure out where governance actually matters.

Out of 12,500 schemas under management, Nationwide concentrated their real governance focus on approximately 100 “lake houses”: the places where data should actually be discoverable, shareable, and usable across the company. That’s where the leverage is.

They also built the Trusted Data Score, a five-category star-rating framework applied against those 100 lake houses: ownership, curation, quality, protection, and observability. A Yelp for data. The goal is to make trust measurable, improvable, and visible. Also important to remember that trust is not binary; it is scalar and contextual.

A great analogy is the health inspector score: a restaurant with a great score will serve a safe meal, but not necessarily a good one. A high trust score means the data is well-governed, however fit-for-purpose for a specific AI use case is still a separate judgment.

Version 1 weighted all five categories equally, which they quickly realized was wrong. Having a name in an ownership box counts as much as actual data quality. Version 2 shifted roughly 40% weight to data quality and 35% to curation. Substance over compliance theater. I truly appreciate that he shared these different versions. No one gets it right the first time.

What was an organizational unlock? Publishing the scores to executives. Teams weren’t sufficiently engaged until their leadership could see the numbers. This is a topic I’ve been bringing up more and more: the incentive structure matters more than the framework. You can build the most elegant scoring system in the world. If there’s no consequence for a bad score and no recognition for a good one, it’s decoration.

One thing I’m flagging is the high number of point solutions: data catalog, quality monitoring, lineage, reference data, classification, etc, ... all separate tools. Their future state is consolidating all of it into a unified metadata layer. They’re not alone in this. Consolidation is coming across the industry, and anyone who built their governance stack on multiple vendor relationships should be paying attention. This is another question I’ve been asking leaders: what’s your partner/vendor strategy? What happens if a point solution gets acquired by a platform which you do not have a strategic relationship with? .

KeyBank: What Does Sustained and Discipline Execution Looks Like?

I have to say, when I saw this session where all the panelists were from the same organization, KeyBank, I thought to myself: this is weird. But it wasn’t. It was clear that one of the messages they wanted to deliver was to highlight the team, and the camaraderie, as an important means of success.

Four years ago, KeyBank had data but no adoption. The catalog had been attempted and failed. Similar problems were being solved differently across business units. Trust in data was low. Sound familiar?

What they did differently wasn’t a tool purchase or a platform migration. It was a deliberate, sustained organizational effort.

They reset the data catalog, not by picking a better tool, but by driving adoption differently. Gamification. Monthly prizes for top contributors. Incentives anyone? :) A moderator connecting subject matter experts to people with questions. Community building. The catalog is only valuable if people use it, and people only use it if someone makes it worth using.

They built executive alignment through hundreds of one-on-one meetings over years. Not a PowerPoint. Not a town hall. Hundreds of conversations, consistently delivering the same message, over years. This is what real organizational change looks like. It’s unglamorous and probably why most organizations skip it.

They launched an internal Data Summit, an annual event where business units showcase their data products. The third one drew over 400 attendees and 20 booths. This is cultural infrastructure. It makes data work visible, celebrated, and connected to the business in a way no governance mandate ever could.

The turning point came when they shifted to a data product ownership model. Once business units owned their data as a product with real accountability, everything downstream changed. Legacy data quality issues that had been kicked down the road for years, because no single business unit would pay to fix them, finally got resolved. The narrative shifted from “here comes the governance team” to “here’s the team that can solve our big, snarky problems.” That’s the shift you’re looking for.

When it comes to AI: “No context, no AI.” Through four years of foundational data management work (data catalog, data quality, data lineage, etc) stitched together now with business context, they’ve built what AI actually needs to be genuinely useful. They’re early on the AI side, but they have the foundations in place, which are both technical and social.

Kudos to Caroline Serio, Head of Data and Analytics Governance and her team Douglas Kanouff, Kevin Eichas, Brendan Sullivan, and Steve Kimmett.

Diamond model data strategy

Kris Mork, CDO of Leidos, presented a diamond model data strategy through a horse herd leadership metaphor.

The model: Attention first. Direction second. Energy third. Congruence throughout. Skip any step and you get fragmentation, wasted effort, or cultural collapse.

Most data leaders get this backwards. They start with energy (ie “we’re transforming data!”) before they’ve done the work to understand what their stakeholders actually need, before they’ve defined direction clearly, and without establishing congruence between what they say publicly and what they do privately. The result is motion without progress.

Meet one-on-one with leaders (that’s a trend 😉) . Ask: What is your role? What business value do you bring? What’s working and what are you proud of? Deliberately avoid complaint conversations. Synthesize feedback anonymously so people see aggregated insights. This surfaces genuine motivation and you get to learn what people actually care about. This translates into direction which is grounded in reality rather than your own assumptions about what the organization needs.

On the data product structure, data contracts seem to be playing an important role, technically and socially. Open Data Contract Specification is being leveraged. The business owner of the data product is accountable. However, enforcement is not yet automated. This is an observation I’m having across many enterprises: data contracts are currently defined as expectations and enforcement is tied to the maturity of an organization, and the technology/vendors.

Farm Credit Services of America

Narayanan Nair, CDO of Farm Credit Services of America, “don’t boil the ocean” approach identified 15–20 critical data elements across 15–20 critical systems (~400 total elements) with defined quality metrics, dashboards, and scorecards. These are the elements most likely to feed AI and agentic systems. These are the elements that matter.

They also appointed a dedicated knowledge manager to ensure knowledge articles are current and accurate before they’re used as AI inputs, and consolidated all unstructured documents onto a managed platform before touching them with AI. This is applying data governance practices to unstructured data.

Part Two: The Tech Company Divide

ADP and Capital One data journeys are impressive. But that’s almost the problem. They are were the benchmark companies at this conference. And they should be because what they’ve built is genuinely impressive over the past decade. Not just foundations, but the full vision of data as a product on a data platform that delivers real, measurable business value. Not aspirationally. Real.

Amin Venjara, CDO of ADP captured the journey that all organizations have been going through with an analogy to the Muruntau gold mine in Uzbekistan, one of the largest on Earth, producing $12B in gold annually. Gold was discovered there in 1958, but the value wasn’t realized until the mining infrastructure was built. Many organizations are “sitting on a gold mine” of data, but without the right capabilities and infrastructure, the value can’t be extracted (sound familiar?). Having data is necessary but not sufficient. The idea that putting data in a lake would unlock value. It didn’t. Over a decade of broken promises. What actually worked was sustained platform and culture investment over years, before it was fashionable, before the business case was obvious, before the vendors were selling it.

They built for three distinct user personas: builders (data engineers), analyzers (data analysts), and operators. They designed their data platform around what each persona actually needed. Driving adoption, enablement, community, self-service. This is product management applied to data, and they were doing it before data mesh gave it a name.

Capital One’s model is equally deliberate, as presented by Amy Lenander CDO and Christina Egea SVP of Product Management. This is a clear distinction that I see compared to other data teams doing data products: one dedicated owner responsible for both operational and analytical environments.

Most organizations think about data product ownership just from an analytics standpoint, and my position is that is short sighted and why that model will ultimately underdeliver. The owner isn’t doing this as a side job. Federated model with a strong center: the hub sets standards and owns the platform, the spokes own analytics and stay close to the business. The center exists to enable the edges, not to do the work for them. And critically, spokes consumption is what justifies hub investment. If the center can’t point to adoption and value generated by spokes, it can’t justify itself.

Capital One also explicitly rejects boiling the ocean on standardization. They ask: where is the leverage? High-reuse data first, historically hard-to-use data next. Mature the core deeply before expanding broadly. This is the pragmatic strategic choice.

And then there’s semantic. ADP invested heavily in entity resolution and graph infrastructure not just for analytics but to connect operational systems. Capital One has had semantics baked in from the start: identifiers, linking, ontologies. They formalized the ontologist as a job title in 2022, with defined talent profiles and career paths. I met Bethany Sehon at the Knowledge Graph Conference in 2019 where she presented how a knowledge graph pilot improves data quality while providing a customer 360 view (watch that video!). This was 7 years ago! Btw, she will be on the podcast soon. This is semantic infrastructure treated as first-class. Not a project. Not a tool purchase. True Infrastructure.

Both companies are now turning to unstructured data. This is the current signal of maturity I’m seeing. First focusing time (a decade) getting structured data right and earned the right to go there.

But here’s the honest no-bs question

If the ADPs and Capital One’s of the world can do this, can everyone else?

ADP and Capital One are technology companies that happen to be in their respective industries, HR and Finances. Tech is in their DNA. Their organizational culture, talent model, engineering mindset, and ways of working are built around building and operating technology at scale. Data excellence is not a transformation for them. It’s a natural extension of who they already are.

For most organizations who strive to be data driven, these companies become the North Star. But there’s also a risk: the distance between where you are and where the ADPs or Capital One’s are might be harder to close than what a roadmap suggests. Not because you lack talent or budget or will. But because the gap might not be a capability gap. It might be an identity gap. Or as it was discussed in our #HonestNoBS Dinner: “Institutional delusion, thinking you are what you’re not”.

You can copy the practices. You can hire the people. You can buy the tools. You can read every case study from every tech-forward company and build a roadmap that mirrors theirs. But can you transplant the organizational DNA? Can you replicate a decade of compounding investment, made before the ROI was proven, sustained through multiple technology cycles, in an organization whose core identity is insurance, banking, pharma, telecommunications, etc ... not technology?

I don’t have a clean answer to this. The grounded leaders at CDOIQ may actually be grounded because they sense this tension. They’re not chasing the hype partly because they know the distance is real.

What I will say is this: there might be a different, valid path to data value that doesn’t require becoming a tech company. The question is whether the data industry is doing the work to define that path. Or whether it’s just measuring non-tech companies against a tech-company standard and calling the gap a capability problem.

Part Three: The CDO Role, What’s Actually Changing

The CDO panel at CDOIQ brought together three leaders: Bhagyesh Phanse CDAO at Humana, Caroline Buckley CDAIO at Ford, and Chandhu Nair SVP Stores, Data, AI, and Innovation at Lowe’s, moderated by Randy Bean.

The consensus: the role has clearly moved from defensive and compliance-oriented to offensive value creation and business transformation. This is not a new observation, but hearing it from three executives across three different industries and three different org structures gives it weight.

What’s interesting is the nuance underneath the consensus.

Ford: Caroline is a strategic partner to business unit leaders. Not a data custodian. The key relationship is with the AI Business Transformation Lead on the executive committee. Running parallel tracks: fixing data for current AI “big bets” while building the enterprise semantic layer. Not waiting for perfection. Moving on both simultaneously.

Lowes: Chandhu doesn’t have a CDO title at all. Deliberately. The function is embedded in broader technology and innovation leadership to avoid title-driven silos. It’s about “business translation” where the AI and data function exists to help the business imagine and capture white space, with market share as the ultimate metric. They are building a “builders” culture, decoupling job title (“uniform”) from functional role (“hat”) to enable cross-functional knowledge building

Humana: Bhagyesh is navigating the dual mandate that might be the defining tension of the CDO role right now: driving offensive value with AI while managing the defensive risk that comes with it. In healthcare, that tension is critical. In healthcare, the transformative opportunity is data interoperability and access: better outcomes through seamless patient data transfer.

The CDO turnover question is more complicated than “high demand”

When the panel addressed CDO tenure and turnover, the answers diverged.

Caroline framed high turnover as a positive because it implies massive demand pulling great talent to new opportunities. Bhagyesh framed it as a structural problem: expectations are up, patience is dramatically down, and the gap between what leaders are asked to deliver and the timeline it actually takes is the real driver. Chandhu saw it as a natural technology adoption cycle, centralization, democratization, recentralization, that will resolve differently by industry.

I think they are all right but I’m focusing more on Bhagyesh’s point because this is what I’m hearing a lot from the field. The organizations hiring CDOs expect AI-era results on governance-era timelines. When that doesn’t happen, because foundations don’t happen overnight, someone gets replaced. Then the new CDO starts the foundation work over again. And the cycle continues.

This is one of the most damaging patterns in the industry. And it doesn’t get fixed by better hiring (or better technology). It gets fixed by better expectation-setting and incentives at the board and CEO level about what this work actually requires.

Skills are shifting in ways that matter

Chandhu stated that data storytelling has evolved to value realization storytelling. You’re not telling the data story anymore. You’re telling the story of what changed in the business because of the data. That’s a different skill which requires true understanding from business. Successful data leaders are the ones coming from the business side, or investing in learning the business. Pure technical data leaders are not being that successful.

Bhagyesh added that the democratization of AI has leveled the playing field in a way that changes the CDO’s competitive position inside the organization. You’re no longer competing just with other executives for relevance. You’re competing with AI-augmented talent at every level. The bar for what the CDO function needs to deliver has risen and patience for slow delivery has fallen, partly because the tools exist to do more, faster, and executives know it.

Part Four: Agents, AI, and the Reality Check

The panel with Radha Kuchibhotla Lead Director, AI Solutions Design at CVS and Art Morales VP, Technology Enabled Science at CSL, and financial services panel with Nachiket Mehta VP of AI and Data Engineering at The Hartford, Andy Ghosal VP Product Management at JPMC and Narayanan Nair CDO at Farm Credit Services of America were the ones focused on AI.

What do you mean by Agent?

Most agents are Gen AI-assisted or deterministic/rule-based. Agentic AI is non-deterministic where the next action depends on prior output, and it could always change. This type of agents carry different risk profiles, different governance

Art’s said out loud what I hope everyone should be thinking: the goal in production should be to minimize the non-determinism of agentic AI and convert as many steps as possible to deterministic processes. This reduces AI exposure. Once you’ve converted steps to deterministic, you often don’t even need the large foundation model anymore. A smaller or local model suffices. Lower cost, higher reliability, more auditable. The pure non-determistic agentic AI framing is useful for prototyping and MVP. It’s often the wrong target state for production.

This is the opposite of the direction that a lot of the industry’s messaging is pushing. Everyone is selling “agentic everything.” The practitioners who are actually running this in production are saying: get the agentic surface area as small as possible. I am in full agreement and this is why workflows are at the center of agentic AI and how work gets done in an organization. While going through this process is how you understand the current business processes and identify what needs to be reinvented.

On the topic of build vs buy: Build when it’s a competitive differentiator, buy when it’s a commodity. The complication is that many agentic frameworks are immature startups that may not exist in two years, making production system decisions genuinely risky.

Art made the stronger case for building because what used to take months to buy and integrate, his team can now build to spec in hours or days... if the data is right. Custom-built solutions can be far more fit-for-purpose than SaaS tools designed for the broadest common denominator. But only if your data products are in good shape. Which circles back, again, to the foundation. And if you have the DNA of building.

In another panel, the discussion centered on the idea that agent governance requires traceability (the ability to audit agent decisions), human-in-the-loop oversight, and proper access controls. The “shadow agent” problem is real: employees building their own agents, then leaving, with no documentation of what those agents do. This is a real and growing risk in organizations that move fast on AI without a governance framework.

Another aspect to consider is the balance between foundation vs. use-case slicing. Some work must be foundational and enterprise-wide. Other work can be built use-case by use-case. The skill is knowing which is which. The risk is when you either try to do everything foundationally (which takes too long and loses business support) or everything use-case by use-case (which creates fragmentation that gets harder and more expensive to resolve over time).

Productivity Gains and Unstructured Data

Farm Credit Services writes approximately 12,000 credit narratives annually for manual loan decisions. Each one covers the five Cs of credit: character, capacity, capital, collateral, conditions. It took analysts anywhere from 30 minutes to four hours to write. Their team built an agentic solution with five to six specialized agents, pulling from a consolidated enterprise data warehouse, to automate narrative generation. Time per narrative cut roughly in half. Estimated savings: 20,000 to 24,000 hours per year. A human reviewer still validates every narrative, but the review takes about five minutes versus hours of original writing.

That’s not a pilot. That’s production. That’s a real number. And it matters because it’s one of the few stories at CDOIQ where someone could say exactly what changed, exactly how much, and exactly why.

How did they get there? Not by starting with the model. By starting with the data. They validated the system by regenerating hundreds of past narratives and comparing them against analyst-written originals, producing a variance analysis. Once variance fell within a threshold defined by the credit analysts themselves, not the data team, not IT, but by the analysts, then trust was established.

Part Five: Semantics, The Thread Running Through Everything

You can’t have a post by me without talking about semantics :) I’m leaving the best for last.

First of all, this is not a niche technical conversation anymore. Semantics and ontologies came up in more sessions, in more different ways, than anything else at this conference. And it’s still not being treated with the seriousness it deserves.

The CDO panel was explicit: all three leaders are actively working on semantic layers and knowledge graphs. Chandhu at Lowe’s is using AI at scale to parse and create taxonomies across unstructured documents, treating it as an engineering problem that requires both ontologists and engineers. He noted that PhDs in ontology are now in high demand after years of being overlooked and people working at this for 20 years. This was my reaction when I heard it, caught right in the perfect moment: FINALLY!

Caroline at Ford is building a metadata layer with heavy business involvement that breaks the historical pattern of IT-owned data definitions with no frontline business input. Nationwide identified curation (natural language descriptions at schema, table, and column level) as one of its five trust categories, and is weighting it at roughly 35% of the total trust score. KeyBank’s “no context, no AI” framing is a semantic argument.

And then there’s Capital One, who has had semantics baked in from the start. Identifiers, linking, ontology. An ontologist job title since 2022 with defined talent profiles. ADP defined their enterprise knowledge graph to link 1M clients. This is not a tool they bought or a framework they adopted. It’s infrastructure they built and maintained.

Here’s what I want to say clearly: semantics are a must for AI. Without it, agents are navigating your data environment blind. Without it, your data catalog is a directory, not a knowledge system. Without it, the governance work you’ve done for structured data doesn’t transfer to unstructured. Without it, the “no context, no AI” problem is unsolvable.

And yet semantics is not only for AI. Semantics is also for the interoperability of systems, where AI is one of those systems. Semantic interoperability is about defining what your data actually means, consistently, across all your systems, so everything can align around a shared understanding. The organizations that are furthest ahead have been treating semantics as infrastructure from the beginning. And these aren’t just the ADPs and Capital Ones of the world. These are organizations that have been investing in semantics for interoperability of systems and when AI came along, they were well along on their foundation journey.

If you are building a data strategy right now and semantics is not explicitly on your roadmap with real investment, real ownership, and real timeline accountability, you are building a foundation with a critical piece missing. The AI use cases will surface this problem. You’d rather find it before they do.

My Talk: Scar Tissue and 20 Lessons from 20 Years of Building the Foundation AI Actually Needs

I first gave a version of this talk at Data Day Texas in January 2026 as a means for me to rant. I’ve delivered it a few times already and every time it evolves. This time, I started off acknowledging what every data leader is hearing and thinking. We’re in an era of platform convergence where every vendor now claims to do everything (AI, data, context). Before doubling down on your tech stack, you need a vendor partnership strategy grounded in three filters:

• Autonomous Governance leveraging deterministic workflows (see Art’s points above)

• Semantics for both AI and interoperability of systems

• Optionality for both data & semantics

The pendulum has swung from modern data stack and best-of-bread to consolidation. As a data leader, your point solutions are at risk of being absorbed by platforms you may or may not have a relationship with. Now is the time to get intentional.

I then kicked off going through each of the 20 lessons, 1 minute each. I summarized each lesson in a series of LinkedIn posts that you can find on my substack. This is what I want data executives and leaders to takeaway:

On AI and Knowledge Graphs: Ontologies and knowledge graphs meaningfully improve LLM accuracy. Our research, that kicked off this topic back in 2023, showing a 3x improvement in query accuracy when grounding LLMs in a knowledge graph is a compelling ROI argument for investing in semantic infrastructure.

On Automation Limits: Anyone promising to auto-generate your ontology or knowledge graph is overselling. The real model is assisted automation with human governance in the loop. The Google-scale companies have taxonomists and dedicated processes. That’s not accidental.

On Structured vs. Unstructured Data: Most AI POCs start with unstructured text because it’s easy. The real business value is in structured data (my bold claim) but structured semantic integration is a fundamentally harder problem. Don’t let your POC success with text set false expectations for your structured data initiative.

On Methodology: The “pay as you go” approach is the right mental model: start with one business question, trace it all the way from strategy to data, extract the semantics, govern it, then compound. One well-executed question creates reusable knowledge infrastructure. The ROI is compounding, not linear.

On the Biggest Organizational Failure: The 30-year-old data integration problems still exist because we haven’t fixed the incentive structure. Teams are rewarded for fast POCs, not durable infrastructure. That’s a leadership call, not a technology call.

On Identity: Every entity in your organization should have a stable, unique identifier. Treating identity as a first-class citizen from the start eliminates downstream MDM and integration pain. Most organizations do this cleanup retroactively, at enormous cost.

On Governance: Governance is what gets you out of POC land and into production. The majority of AI POCs never reach production and the root cause is almost always lack of governance infrastructure. Governance isn’t a brake; it’s what lets you drive fast safely.

On Semantics as Foundation: Don’t build semantic layers just for AI context. Build them as enterprise infrastructure where AI is just another consumer. Otherwise you’ll replicate the “1,000 dashboards, none trusted” problem, except now with agents giving conflicting answers.

Three questions every data executive should be asking themselves:

1. Do my vendors support true data and semantics optionality, or are they creating lock-in behind the language of openness?

2. Do I have the governance infrastructure to take my AI POCs to production?

3. Are my incentive structures rewarding durable knowledge infrastructure or just fast wins that create tomorrow’s technical debt?

The underlying message across all 20 lessons: knowledge is a first-class citizen, not a byproduct of data. The organizations that treat it that way will compound value. The rest will keep having the same conversations about the complaints their former colleagues were having in 1996.

Closing Thoughts

Let me pull back and say what I think the full picture is, because I don’t think any single session or any single theme captures it.

The CDO community is doing serious, important work. The governance programs, the data product ownership models, the quality frameworks, the semantic layers, etc... This is real work, done by real practitioners, building real infrastructure. It’s not hype. It’s not theater. It’s the unglamorous, multi-year effort that actually matters.

But the transformation leap hasn’t happened yet for most. The leaders at CDOIQ know what good foundations look like. They’re building them. What they don’t yet have, with a handful of exceptions, is the story of how those foundations connected to genuine business transformation. The aspiration is present. The execution playbook is not. This is my honest no-bs take on the state of the industry.

The tech company benchmark is both inspiring and can be misleading. What the ADPs and Capital Ones of the world have built is real and impressive. But they built it over a decade, as technology-native companies, with organizational DNA that makes this kind of investment natural. Treating their outcome as the North Star for non-tech enterprises is reasonable. Treating their path as the replicable template may not be. The industry needs a serious conversation about what the alternative path looks like and honestly, that conversation isn’t happening.

Semantics is the differentiator. The gap between the organizations winning with AI and the organizations struggling isn’t primarily about model selection or platform choice. It’s about whether they’ve built the semantic infrastructure that makes data usable by agents and humans alike. This is the investment that most organizations are underweighting, and it’s the one that will be hardest to catch up on later.

The organizational challenge is harder than the technical one. This was stated explicitly and implicitly across almost every session. Change management. Executive alignment. Incentive structures. Cultural transformation. Business ownership of data. These are the hard problems. Technology is the easy part. Any organization that is treating its AI and data transformation as primarily a technology problem is going to be disappointed by the results.

The question that’s going through my head now is whether the current moment represents a healthy, necessary phase of foundation-building before the transformation wave, or whether it represents a structural ceiling for most non-tech enterprises. I bring this up because the problems we are tackling right now are the same ones enterprises have been complaining about for 30 years. So why will it be addressed this time?

I think the honest answer is: it depends on whether the organizations doing this foundation work also develop the organizational muscle to get to the other side: the patience, the sustained investment, the executive alignment across multiple leadership cycles. Some will. Many won’t. And the ones that don’t won’t necessarily fail at data. They’ll just never fully close the gap with the organizations that treated data and knowledge as first-class infrastructure from the beginning.

The CDOs who understand this are the ones who haven’t been chasing a hype. They have been busy building real foundations. And they deserve credit for that, even when the headline isn’t exciting.

Congrats to the organizers for an amazing event! Thank you for everything!

Additional Takeaways Posts

Sharing a few takeaways posts that have come up on my Linkedin feed:

• David Krauza including posts for Day 1, Day 2 and Day 3

• Dan Everett

• Aaron Wilkerson

• Arvid Murali

• Malcolm Hicks

• Olivia Kew

• Kevin Petrie

• Malcolm Hawker

• Dora Boussias

I’m going to focus on four things: the context layer, the bigger shift toward work, AI governance, and the open-source release that made me feel a lot better about my own browser-tab chaos.

1. Context: they boiled the ocean, and now they need a search engine

Databricks went deep on context and they’re doing it, supposedly, in a two- way hybrid approach (or at least that is how I’m seeing it).

The top-down approach is Unity Catalog.

This is the deterministic side: humans defining metrics, building out glossaries, adding governance controls.

And it’s very clearly built for analytics. The new metric views, the glossary work, all of it is oriented around Genie getting better answers out of your fact-dimension star schema analytical data.

Databricks is tightly coupling the catalog to question-answering. That’s the coherent, well-scoped bet that basically every platform and context layer point solution is doing.

The bottom-up approach is the one everyone’s talking about: Genie Ontology.

And the best way I can describe what they did is that they found a way to boil the ocean. They built a system that automatically indexes everything — documents, dashboards, code, notebooks, whatever it can connect to — and constructs an “ontology” (in quotes on purpose) out of it without asking a human to model anything first.

But here’s the thing about boiling the ocean: once you’ve done it, you have a new problem. You need to figure out what’s actually worth surfacing. That’s exactly the problem web search engines solved a couple decades ago when they indexed the entire web, and Databricks borrowed the same playbook. Their answer is OntoRank, a PageRank-style algorithm that ranks things by popularity.

And popularity is an interesting proxy. It is not the same thing as enterprise importance.

My honest no-bs read is that after talking to several customers who spoke with Databricks, this was a solution looking for a problem. Not in a dismissive way. It’s a genuinely clever piece of engineering, but I think Databricks needed a checkbox for “ontology” because the term has been gaining mindshare in data circles, and they hadn’t been playing in that space. So they built something fast, of course to provide context for AI, but now they’re figuring out the concrete use cases after the fact.

I’m also going to set aside the fact that they’re using the words “ontology” and “knowledge graph” pretty loosely relative to how those terms have been used for the last 20+ years. I don’t want to be pedantic about it. But it’s worth naming: this is fairly marketing-heavy. And I suspect part of the play is redefining what “ontology” means, rather than building toward the existing definition. I think all vendors are trying to do this. But oh well... pick your battles :)

What Databricks has done is that they lowered the barrier to entry. Automatically generating a starting point for your enterprise semantics is a real unlock for a problem that has historically been brutally manual. They have scaled knowledge engineering and knowledge acquisition, and the roles of knowledge engineer and what I’ve called the knowledge scientist. That matters.

What we have to be careful about is the vanity-metrics framing. They announced that they created 4.5 million ontology snippets internally. I don’t know what to do with that number. Am I supposed to be impressed? Is that good? Bad? Volume of generated context tells me nothing about whether the context is accurate, relevant, or governed. None of the size claims matter if the answer you get back is wrong.

And that gets to the open question I keep coming back to: how do these two approaches, the deterministic top-down catalog and the automatically generated bottom-up “ontology”, actually meet in the middle? The catalog has governance. The ontology has scale. Right now it’s not clear to me where the human-in-the-loop governance actually attaches to the automatically generated layer. In the Unity Catalog Semantics architecture (picture above), the unity catalog semantics is an input to Genie Ontology. So what is governing Genie Ontology? That gap is the whole game.

This connects to something I’ve been writing about for a while: there are two distinct reasons organizations need semantics. One is semantics for AI agents: giving a model or an agent enough context to answer a question well. The other is semantics for the interoperability of systems: a shared foundation of meaning that lets different platforms, teams, and processes actually understand each other over time, independent of whichever AI happens to be asking.

Databricks is unambiguously building for the first one.

There is no real intention here toward semantic interoperability across systems and honestly, that’s consistent with their incentives. Their goal is to get all your data inside the Databricks ecosystem, in which case you don’t need interoperability between systems, because everything’s already one system. But that ambition runs into the same old problem that’s always existed: humans disagree about meaning, and that disagreement doesn’t disappear just because an algorithm generated a graph faster than a person could.

Zoom out and the bigger pattern is obvious: every platform right now wants to be the place where you manage context. Every single one. So the real question for any data leader isn’t “which vendor has the best ontology/context layer demo.” It’s: what are you actually optimizing for? If your honest answer is “we need this for AI because the board wants AI,” you’re going to reach for the fast, automatically-generated, quick-and-dirty option. I don’t think that’s where the long-term value lives. We’ve seen this story before: investing in big data and data science and not getting clear ROI from it. If your answer is that you want a durable semantic foundation that AI consumes as just one more system among many, that’s a fundamentally different, more strategic conversation, and it requires real organizational alignment.

And underneath all of it: governance. Governance is getting more complicated by the week, not less: data governance, AI governance, GRC, security, etc, and increasingly the connective tissue between them. Which means we need more automation in governance, not less, and this type of automation requires determinism. That’s where workflows come in. Wherever your context lives, you need a deterministic way to govern it, and that’s a workflow problem.

2. Work is the center, and everyone is finally heading there

This is the theme I’m most fired up about, because it’s something I’ve been arguing for a while and we’re now starting to see it show up across the entire industry.

We’ve been operating in a world that treats data as the center of the universe. Data is the new oil, be data-driven, build the data warehouse, build the lakehouse, build the analytics... and then we declare victory. But that’s backwards. Data is an enabler. Work is the center. Work is your processes: IT, HR, customer service, finance, whatever your business actually does. Context is an enabler for that work. Governance is an enabler. Analytics and insight are enablers. And AI and agents are simply the latest way work gets done.

Btw, my colleague Tim Gasper just wrote a piece on how governance is moving into the work that you should read.

This is exactly why the data and analytics field has struggled to prove ROI for so long. We built impressive infrastructure and called it done, without ever tracing the line back to the actual work it was supposed to improve. If the business doesn’t understand the value, it’s because we never connected what we built to the work itself.

I’ve talked before about a framework I keep coming back to: the triangle of convergence. One corner is your systems of record (CRM, ERP, HR, IT systems). Another corner is your systems of insight (data warehouses, lakehouses, analytics). The third corner is your systems of action (workflow and orchestration), what Gartner calls Business Orchestration and Automation Technologies (ServiceNow is a leader 😀). For a long time these have lived as three separate worlds, connected by integration.

What’s happening right now is convergence. Everyone is moving toward the center of that triangle at once. You can see it in how platforms that started in one corner are now reaching into the others.

And this is exactly why Databricks announced what they announced this year. The vertical apps, Lakewatch, a security product and CustomerLake, a customer data platform, are a tell. They’re not just trying to be the analytics layer anymore; they want you building your next system of record on top of their platform.

That’s why all the deep technical announcements mattered: LTAP, the new Reyden query engine, the Delta Lake and Iceberg convergence. Those aren’t separate stories. They’re the plumbing required to merge systems of record and systems of insight into one physical platform.

Choice was a big topic: no lock-in, open formats, any cloud, any model. And I think that’s real, but I’d push on where the choice actually lives. It’s a choice at the technical layer. The moment your business logic, your semantics, and your context get built on top of any one platform, you’ve made a much deeper commitment than your storage format. Open file formats don’t make your decisions reversible if everything else is coupled to one ecosystem.

So here’s the question I keep putting to people: what’s your center of gravity? Where does your data actually live? Where do your use cases actually live? Where does work actually get done today? And just as importantly, who are you already invested in, and who do you want to invest more in?

This matters more right now because the market is consolidating fast. If your strategy depends on a constellation of best-of-breed point solutions, ask yourself what happens when one of them gets acquired by a vendor you have no relationship with. I’m seeing more customers get genuinely thoughtful about this. Not paranoid, just appropriately careful about concentration risk and backup plans.

The underlying signal is consistent everywhere you look, including from Databricks’ own CEO Ali Ghodsi opening the keynote: “AGI is here today. Just not at work.”

If you work in data, this is your cue: go understand how the business actually works, because that’s where this is all heading.

3. AI governance: it’s not just tracking anymore, it’s the budget

AI governance is having a moment, and it’s not subtle. Gartner just published a Magic Quadrant for it and a Magic Quadrant existing at all tells you something real: there’s a validated market, real buyers, and real urgency. (ServiceNow landed as a Leader 😀 )

What’s striking is the shape of the curve. Data governance interest has grown steadily for years, a slow, grinding climb. AI governance showed up and exploded almost overnight. Same underlying discipline, wildly different adoption curve.

Databricks announced Unity AI Gateway.

The part I found genuinely interesting wasn’t the tracking because every AI governance platform tracks agents and models now. It was the budget enforcement. Actually managing and enforcing spend limits. That’s exactly what’s keeping people up at night right now: the token-maxing problem, the unbounded cost curve of agentic workloads. It’s a very direct echo of the early cloud-computing days, when an entire category of tooling emerged just to manage and control cloud spend. We’re rediscovering that we should build cost controls in from day one instead of retrofitting them after the bill arrives.

But AI governance, done right, is much bigger than tracking AI agents plus budget. In Tim Gasper’s article “Governance is Moving into the Work” he talks about connected governance, which is the right framing. There’s data governance, AI governance, GRC, security, identity and all of it needs to connect. Every platform will tell you they integrate with the rest of your stack. The real question is how much of that is actually built versus aspirational. Every vendor is strongest at governing what happens inside their own walls. The harder, more valuable question is what’s happening outside those walls across your entire environment, not just one platform’s slice of it.

Nobody has this fully solved today, because the need is new. But it’s worth figuring out which vendors already have data governance, AI governance, GRC, security, and identity functioning together as connected disciplines, versus which ones are starting to assemble that picture now. That’s a materially different starting position.

One more open question I don’t have a clean answer to yet: everyone’s managing consumption-based AI spend right now. Is there a path from consumption pricing to something closer to value-based pricing where you’re tracking and paying for outcomes rather than tokens? I think that’s coming.

4. Omnigent: glad to know I’m not the only one copy-pasting between browser tabs

This one’s just fun, and it’s a good reminder of how technical Databricks is at its core. That’s genuinely in their DNA.

During the keynote, Matei Zaharia described his own workflow: multiple browser tabs open, copying the result of a prompt out of one model, pasting the output into another. I had this satisfying moment of recognition: I thought I was the only one doing this. Good reminder: when you think you’re behind, you’re probably not.

That is the setup for Omnigent, a meta-harness for composition, collaboration, and contextual control across any agent harness or model. The live demo was genuinely cool: switching between Claude and Codex mid-session, running a multi-agent supervisor, bringing in a live remote collaborator, and tying the whole thing to enforced cost policies on a per-task basis.

I don’t know yet how much this picks up or how broad the support ends up being. But as a concept, it’s solving a problem of stitching different models and tools together by hand because no one tool does everything well. Worth watching.

The Bottom Line

Context and Governance are in service of getting work done. We say this at Snowflake Summit. We are seeing this at Databricks Summit. The industry is slowly admitting that data was never the point. Work was always the point. Glad more of us are starting to say it out loud.

The two-persona pattern

Snowflake’s two headline announcements: CoCo (agent-driven development) and Co-Work (personal AI work agent for end users).

CoCo is for the technical persona, the engineers, data practitioners, and developers building agents and data infrastructure.

CoWork is for the business persona, the end users who consume what the technical persona has built.

This map directly onto what Anthropic is doing with Claude Code and Cowork. One product for the technical persona building the capability. One for the business persona using it. This is not a coincidence.

The honest question I got on the podcast with Tony Baer: are vendors following customers or leading them? My answer: both, but with a nuance. Customers don’t fully know where they want to go yet. Vendors are painting the future. Customers are reacting, picking what they like, pushing back on what they don’t. This is normal for any major technology transition. What’s different right now is the pace. The world is moving so fast that things I had no idea were possible six months ago are real today.

Work is the center

I keep coming back to this because I think the industry is still thinking about it wrong.

We’ve been operating in a pre-Copernican mindset. Before Copernicus, everyone believed the Earth was the center of the universe. We have the same problem right now with data. We act like data is the center of the universe. Now that “context is king”, many vendors are treating context as being the center of the universe. That’s the wrong model.

The actual center is the business getting work done (Sales, Marketing, Customer, HR, IT, etc). Data matters. Context matters. Governance matters. They are essential. But they are enablers. They orbit work, not the other way around. And AI is how you get work done.

At the Snowflake keynote they had a couple of customers showcase their agents framing not as “AI on reports”, instead “a different way of working.” In other words, they are implementing workflows! There is an entire “system of actions” universe that Snowflake is entering (Gartner calls this Business Orchestration and Automation Technologies).

This gets to something many folks have been saying for a while now. BI has always promised “insights to action.” We built data warehouses, moved to the cloud, and built analytics layers. And then we stopped at the insight. The so-what was never answered. The insight was never wired back to where people actually get work done: the operational systems (CRM, ERP, IT, HR, etc). That gap is now starting to close for data teams but workflow and business automations have always been there (I’ve been learning so much about this space since I joined ServiceNow). Agents traverse from insight to execution but what many will learn is that much of that execution can’t (and shouldn’t) be non-deterministic and need to rely on deterministic rules and workflows.

The practical implication for data and business analysts: the operational layer of that role is getting automated. Building reports, developing dashboards, acting as a BI developer in the traditional sense... I think that work is going away. What grows in importance is the strategic layer: what questions should we be asking, what do we do with the answers, how do we make sure insights drive action? The analyst who can frame the right problems and bridge to execution becomes more valuable. The analyst who only executes predefined reporting workflows does not.

The context wars are here

Snowflake introduced Cortex Sense, a runtime layer that collects context automatically and uses it to improve agent reasoning. The performance claim they put on stage: accuracy improved from 24% to 83%. I appreciated that they stated it was for a specific example so that these numbers shouldn’t be generalized. Nevertheless, it’s not a model upgrade. It’s the context doing the work.

As of June 2026, all these context announcements are the equivalent of “water is wet”, or as Niels Bohr would state: an ordinary truth.

Tim Gasper predicted “context wars” many years ago (we still need to find the podcast episode where we discussed this) meaning that a major competitive battleground of the AI era would be fought over who owns and manages context and semantics. We are now seeing this unfold. As Ton Baer stated, Snowflake’s announcements in this space were about extending their “semantic sphere of influence.”

This is the moment to think strategically about your vendor and partner strategy, especially with respect to the larger market consolidation and M&A situations. Every platform claims it can do everything: data, analytics, governance, catalog, semantics, context, agents. You need to understand where your actual center of gravity is. Context is the DNA of the business and you don’t want to have vendor lock-in. Where does work get done in your organization? Where does your most important data live? Where are your highest-value use cases concentrated? Which platforms do you invest extensively in today? Do you still want to invest in point solutions when these are features by larger platforms? That should drive where you invest.

On OSI, I’m more hopeful than cynical

Snowflake expanded Open Semantics Interchange at Summit. The partner ecosystem grew 5x in six months. ServiceNow joined too.

The skeptical argument, which Tony Bear made directly to me, is valid: standards succeed at the infrastructure layer where nobody wants to differentiate. Iceberg works because nobody fights over table formats. Semantics is different. That’s where competitive moats are built. Why would any vendor standardize it?

Here’s my counter: the historical problem with semantic standards was weak incentives, not bad ideas. Point-to-point integrations were good enough, so organizations never invested in semantics. AI agents are changing that incentive. The cost of not having semantic interoperability is now high enough to create real pull starting with customers who want their AI agents to be accurate and want to avoid their business DNA locked into a vendor, and then vendors who need their agents to work across systems, and.

Is this enough? I don’t know but I truly hope so! 20 years of my career invested in semantics, I’m here to make this succeed! I told Tony we should revisit this in a year. But we now have something that was always missing before: an incentive.

Agent maturity: the honest read

Agents were everywhere at Summit. The reality is more sober.

I sat in a session where the presenter asked: how many have agents in production? A handful of hands. How many are experimenting? Another handful. The majority of people at a major data conference are still on the sidelines.

The trailblazers are real and impressive. They have the foundations: data, semantics, governance as an enabler. They are also the minority. Pareto principle. 20%. And the real trailblazers are probably smaller than that.

One distinction I keep making: many people are “using agents” embedded in their tools. But embedded doesn’t mean genuine. A genuine agent understands intent, the context of a business, the nuance of a workflow, what the user actually wants. Most embedded agents today are sophisticated chatbots. The north star is clear. The journey to get there is substantial. Most folks are at the beginning.

My advice hasn’t changed: don’t boil the ocean. Start with the specific business value you want. Work backwards. Get one thing right. Build from there. Invest in foundations on the way, in slices. Make sure that the foundational work provides compounding value.

Governance just got harder

Data governance has been hard for decades. Agents make it harder.

Snowflake’s agent identity announcement gets at something important. It’s not just about guardrails and preventing agents from deleting databases. The harder question is: who does this agent represent, and what is it authorized to do? An agent executing a multi-function workflow might span responsibilities that no single human in an organization would normally hold. Now multiply that across platforms. There are agents in Snowflake, agents in ServiceNow, agents in dozens of other systems. Those agents need to talk to each other. When an agent in one system triggers an agent in another system, identity and authorization have to thread across both. Who is accountable? What role does it represent? The governance model we’ve built for humans doesn’t extend to this without significant rethinking. Honestly this is why we will see a lot of PoCs and not much going into production until we address this problem.

We need to move toward autonomous data governance, dynamic, real-time, operating at the speed of multi-agent systems. The static catalog and governance approach doesn’t work when agents are making decisions continuously across multiple systems. We’re not there yet. The tooling and frameworks need to catch up.

But more importantly, we need to understand our current business processes and workflows, to figure out which parts of the business can and should leverage agents first. The proverbial “low hanging fruit and high value” use cases. This is the people and process problem we need to deal with first.

The Research Connection

One moment that stood out personally: Snowflake received this year the Test of Time Award from SIGMOD, the premier database research conference. I was actually in the room in 2016 when the Snowflake team presented that original paper at SIGMOD. Seeing it recognized a decade later as work that stood the test of time is an excellent reminder of something I care about: how rigorous science and engineering gets translated into practice and actually changes the world. That doesn’t happen often enough. It was cool to witness this.

The Bottom Line

Snowflake Summit 2026 was Snowflake showing hard that they are an AI platform through CoCo, Cowork, Cortez Sense, Horizon, their openness, and much more. All in the right direction.

Let’s remind ourselves that we are in a bubble. If you get out of it, many organizations still haven’t migrated their data to the cloud. Per the informal poll, the majority of folks are not even experimenting with agents. The North Star is clear but there is so much work to be done.

Enabling businesses to get their work done… that is what should be at the center. Everything else is infrastructure enabling that.

But first, a little context.

Back to Snowflake Summit 2023

Three years ago, I was at Snowflake Summit and talking to product folks about the need to invest in semantics and knowledge graphs. The reaction was polite but skeptical. Most people believed that LLMs were going to figure it out: give the model enough training data, fine-tune it, and it would learn to write the right SQL against your database. Problem solved.

I disagreed.

The counterargument at the time was: Do you have a benchmark that shows evidence of the value?

No we didn’t. But as a group of scientists, we know we could do this work. The data.world AI Lab team kicked off the research to understand to what extent knowledge graphs could improve the accuracy of question answering using LLMs over relational databases. Our research result presented in the paper “A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model’s Accuracy for Question Answering on Enterprise SQL Databases” was one of the first to rigorously demonstrate the accuracy gap between LLMs querying raw data versus LLMs equipped with an ontology and knowledge graph. That accuracy increase was 3X at that time.

When we announced our results, it went viral and was picked up by many vendors.

That benchmark, which we published in 2023, helped shift the conversation. It wasn’t just us saying “semantics matter”, we had evidence that without them, AI systems fundamentally misunderstand your business. We continued our research and showed how further leveraging ontologies increases the accuracy, in our paper “Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue!”

That work, and the decades of foundational work done by people like my colleagues Dean Allemang, Bryon Jacob and many others in the knowledge graph and ontology space long before AI became a household word, is part of why I feel a deep sense of pride and responsibility in ServiceNow now participating in OSI.

Semantics is the DNA of your Business

I’m fortunate to speak to hundreds of customers, and even the customers who are still early in their AI journey are landing on the same realization: the semantics of their business (the definitions, the context, the meaning behind the numbers) are the DNA of their organization. And frontier models don’t come pre-loaded with that DNA. They’ve never attended your strategy meetings. They don’t know what “revenue” means in your context versus your competitor’s. They don’t know which KPI drives which decision.

You have to give them that context. And if the way you define that context isn’t standardized and open from the beginning, you are going to pay a significant tax on vendor lock-in, and that is a concern customers have from the beginning.

Two Different Things People Are Conflating

I want to make an important distinction that I think is getting lost in the hype. There are two separate, but related, mandates here:

1. Semantic interoperability as infrastructure. This is the work of defining your business concepts, your metrics, your dimensions, your business processes, and your decision logic in a way that is open, portable, and machine-readable. This work needs to happen regardless of AI agents. It’s foundational. It’s about ensuring that when any system (AI or otherwise) touches your business data, operational or analytical, and it operates from the same shared understanding.

2. Semantic context for AI agents. This is what’s driving all the attention right now. AI agents need to understand the context of the business to act on your behalf. They are consumers of the semantics. This is a powerful, urgent use case, and it’s creating the organizational incentive and funding to finally do the foundational work.

The risk I’m seeing is that organizations are building semantics purely to feed their current AI agent use case, without thinking about the semantic interoperability of their operational and analytical infrastructure. If you only do the former without appreciating the latter, you’ll build something brittle.

The AI agent incentive is real. But understand what you’re actually building. I have an upcoming rant on this topic so stay tuned.

What OSI Represents

The Open Semantic Interchange is a collaborative and open initiative to standardize how semantic models are exchanged across tools: BI platforms, AI systems, data platforms, all of it. It’s vendor-neutral. It’s built in the open. And it’s gaining serious industry momentum. What excites me is that the industry is finally aligned around the need for it

And for those of us who have been speaking the language of knowledge graphs and ontologies and pinging me about how OSI relates to the broader semantic web and W3C standards (i.e. RDF/OWL/SHACL), that’s a real conversation worth having. OSI has started at the metrics and BI layer, and has started to connect it upward to richer ontological frameworks. I’m excited to contribute here.

Where to Start Without Boiling the Ocean

The honest and “obvious” advice I give everyone: start small and think big. Do not walk in on day one and try to model your entire enterprise ontology. That path leads to nowhere.

Start with what’s closest to your analytics layer:

• Define the semantics for your data lake and data warehouse

• Build out your metric and BI semantic definitions

• Recognize that your dimensions are likely already a taxonomy

• Establish clear governance around these definitions early

That’s your first real win. And from there, you expand gradually and iteratively, toward richer logic, rules, constraints, business process modeling, decision logic, and eventually the fuller picture of how your organization operates and how AI can understand it.

Final Thought

Twenty years in, watching what was once a niche academic and enterprise architecture conversation become a top-of-mind business priority is humbling. It’s a reminder that the people who do this work before the hype cycle arrives are the ones who make the hype cycle meaningful.

Thrilled for ServiceNow to be part of OSI. More excited to see what we build together.

See the ServiceNow blog for more details: https://www.servicenow.com/workflow/news/servicenow-joins-open-semantic-interchange.html

This is my trip report with my personal, honest, No-BS takeaways of the conference

(For comparison, check out the Gartner D&A Orlando March 2026 takeaways)

1. The basics and foundations

Of course context is the current hot topic. But here’s the thing...most people are still at the absolute basics. For example, Andres Garcia-Rodeja gave a 30 min talk on how to build a context layer, on the last day, last hour, to a packed room. After the talk, he had a line of folks asking him questions for 30 mins. And it was all basic foundational questions.

Now let’s look at the data, because the numbers tell a pretty uncomfortable story.

Only 1 in 5 AI initiatives are achieving ROI in 2025. Let that sink in. 4 out of 5 AI projects are not delivering.

Meanwhile, 6 out of 10 European IT leaders have real concerns about cost overruns from AI agents, but only 1 out of 10 D&A and AI leaders share that concern. So either D&A leaders are more confident they can manage it or they’re not paying attention to the right signals.

And 47% of European organizations have already put financial guardrails or AI FinOps practices in place, which tells you the governance infrastructure is being built whether or not leadership is worried about it.

The readiness picture is even more sobering. Data availability and quality is still the number one barrier to AI implementation. Only 26% of D&A or AI leaders think their data engineering practices are highly effective for existing AI use cases. Only 13% say their D&A governance function can fully lead AI governance. And 90% of D&A leaders say their architecture needs a minor or significant overhaul to support new use cases (of course… the problem is tech, right!?!?)

But here’s the twist: CEOs are betting fairly equally among CISO, CIO and CDOs to lead AI. The Gartner CEO survey shows that CDOs rank third in perceived AI savviness across the C-suite. There’s a massive gap between what CEOs expect from data leaders and where data leaders actually are. This is a very strong indicator that CIO and CDOs need to align on the strategy! So for the CDOs not working closely with your CIO… you are in a disadvantage.

So what’s the answer? Gartner keeps saying “this is the year of the foundation.” And I have to say: when has it NOT been the year of the foundation? It’s always the year of the foundation. That’s kind of a running joke at this point.

In addition to the WHAT you should be doing (stating the obvious):

There was also conversations about HOW to build foundations, and lessons learned:

The “flip the traditional approach” message (i.e start with business outcomes and work backwards) keeps needing to be said because organizations keep doing it backwards.

Finally, Gartner presented three archetypes of AI ambition: AI-Cautious, AI-Opportunistic, and AI-First. I want to push back on the AI-Cautious framing. I don’t think anybody should be positioning themselves as AI-Cautious. If Gartner is validating caution as a legitimate archetype, that’s something worth challenging. Being cautious isn’t a strategy. It’s a posture that leaves you behind.

2. Context, Context, Context.

Context is king and queen. Everyone is talking about context layers and context platforms. Vendors are rebranding as context platforms, context layers, context engines. Context, context, context.

“Semantics, knowledge graphs and ontologies are no longer niche technologies for specialized domains but essential components of AI-ready data infrastructure” - Gartner 2026

So build knowledge graphs... now!

But, what is context? This sums it up pretty nicely:

Context consists of semantics: your ontologies, your business glossaries, your metrics definitions. It’s also rules, policies, and ownership. And also knowledge graphs. That’s the natural starting point, and it’s why data catalogs and metadata management tools are rebranding as context platforms.

Context also includes your operational state: your entities, your activities, your environmental conditions. What is actually happening in your business right now (i.e. operations) not just after the fact (i.e. analytics)?

And context includes provenance: the tracking of data, the processes it went through, the decisions that were made, the actions that were taken, the outcomes that resulted. Who decided what, when, and why? The decision traces.

I would actually extend this to include more: Users, Access, Assets. You want to know the context about users (who they are, in what department they are in, or what type of customer cohort they are in), what access they have, etc.

So if you are looking at context layer offerings, you need to be asking how much of the context is actually being supported. Data catalogs rebranded as context layer platforms are not for the AI-first archetypes.

Also, remember that when you need high reliability and trust, you stick with deterministic approaches and leverage the power of semantics. Not probabilistic inference. Deterministic, semantics-powered reasoning.

One thing I’m really excited about is to see how the practices of knowledge engineering are coming up more and more. The faster organizations move toward knowledge engineering as a practice, the faster they get value from agentic AI.

How are folks starting their knowledge engineering work? Per a live poll, 60% are starting with semantic layers for BI. The other 40% are going straight to ontologies and knowledge graphs. Honestly, if you are coming from a traditional data & analytics practice (building star schemas for BI dashboards), you should be starting with semantic layers for BI, before jumping to ontologies. If you are coming from an operational background where you are integrating data to support operational use cases that require data from different silos (i.e. Customer 360), then you may want to jump straight to ontologies and knowledge graphs

A clear message: you can’t buy context. Context already exists in your organization. It lives in your systems, your processes, your people’s heads, your institutional and tacit knowledge. It’s not missing. It’s fragmented and poorly managed.

Also remember: context is a means to get work done. It’s just one piece of the puzzle. Investing in content layer specific point solutions have a risk because the data management market is converging: “Point solutions are becoming obsolete and turning into features of data management platforms”

Which takes me to the next point.

3. What is your vendor strategy?

One of the best sessions at the conference was a panel on evaluating your strategic data management platform choices. Gartner brought together Ehtisham Zaidi, Robert Thanaraj, and Roxane Edjlali, moderated by Daniel Cota. Kudos to Gartner for running a truly honest, No-BS panel. You could tell it wasn’t scripted, and the analysts were willing to critique their own categories. You need to do more of these!

There are three main ways to build a converged data management platform (CDMP).

Option 1 — Cloud Service Providers (CSP-centric): Best when you’re already on one cloud, you want pre-integrated capabilities, and time to market matters more than differentiation. Ehtisham acknowledge that not all data management capabilities are created equal in any of these cloud data management ecosystems. Especially integration, metadata, quality, and governance.” Hyperscalers’ metadata tools typically only scan inside their own ecosystem. Multi-cloud buyers will still need ISVs.

Option 2 — Independent Software Vendors (ISV-centric): Best for best-of-breed depth, cloud neutrality, and high-maturity for specific capabilities. But Robert flagged the risks: you risk recreating the fragmented best-of-breed stitching problem of the past. And acquisition risk is real: if your ISV gets acquired by a hyperscaler or app vendor that isn’t your strategic partner, what happens to your investment?

Option 3 — Application providers (App-centric): Best when your data and use case requirements are fulfilled within the application’s footprint. Roxane called out that the next frontier is not going to be who owns your data, but who owns your metadata. Furthermore, application vendors know the semantics/context, of their own applications better than anyone else. While hyperscalers and ISVs are trying to infer the semantics, application vendors already hold it. The issue is that organizations use multiple applications.

What I found when talking to data leaders is that most don’t have a clear vendor and partner strategy. The best answer I heard was from a leader who had developed a tiered approach almost like a medallion architecture for vendors.

Think about it in three tiers across two dimensions: Strategic and Critical. These could be independent.

A vendor can be Strategic: aligned with your future direction, part of your long-term platform bet, where you’re expanding your footprint and getting preferred terms.

A vendor can be Critical: your business operations run on it today, it’s deeply embedded, it’s not going away anytime soon.

And the key insight is that a vendor can be critical without being strategic because you may not be doubling down. A vendor can be strategic without being critical because you may be open to switching, especially in this fast-paced AI world.

You should ask yourself: where is the gravity of data and context? Where should governance live? Where do the use cases live? Where are actions taking place? Where does the work get done? The ultimate question is: who is going to enables us to get the work done best?

4. Governance is also King and Queen

The scope of governance is already big and it’s increasing.

I really enjoyed Anurag Raj‘s deep dive on the future of D&A governance. We have this tendency in the data world to think of governance as just “data governance”: catalogs, glossaries, quality rules, lineage. But Anurag showed the full picture: data governance, AI governance, analytics governance, cybersecurity, MDM, decision governance, corporate risk governance, IT governance. This is converging. AI is forcing what he called a “governance singularity.” These boundaries are blurring whether we like it or not.

And there is so much to govern. We need to be clear on why it needs to be governed. This is a good framework to think about it:

And here’s the thing that has clicked for me since I joined ServiceNow: governance is already happening on the operational side. People in operations are doing governance every day: they’re managing data entry rules, they’re responsible for source data correctness, they’re notifying teams of structural changes. They may not be calling it governance, but they’re doing it.

The data and analytics world has been so focused on its own slice that it has largely ignored the operational governance that’s already happening upstream. And that’s a problem because the outcomes we care about depend on what’s happening operationally.

The following is a great visual where data contract serve as the bridge between upstream operational governance and downstream analytical governance. It carries schema, lineage, SLAs, and quality metrics. It’s the formal handshake between the people who create the data and the people who use it. This is more than data contracts for data products, because those are contracts for the data and analytics world.

This connects to policy as code, the idea that governance policies get translated into enforceable code, not just documentation. Anurag laid out six types of policies: definitions and models, quality, security, privacy, ethics, lifecycle. This is a great starting point to think about the breath of how much policy could be translated to code.

The open question for me: who and what is the enforcement engine? Implementation is tractable. Enforcement at scale is still unsolved IMO.

5. Methodologies: what we are not talking about and we need to!

What’s STILL missing though, and this is my main critique of the data & analytics industry, is a clear methodology for how you move through maturity by use case, not by big sequential layers. Organizations hear “build the foundation first” and they sometimes get into waterfall mode and boil the ocean. Big foundation project. Then the next layer. Then the next. Meanwhile, nothing is delivered and everyone loses patience. We need to present use cases directly from IT, HR, Customer, Finance, Sales, Risk & Security, etc and how you get from foundations with context and governance to AI wins.

What I’ve always advocated for is what I call the iron-thread approach. You start from the outcome, the work you’re actually trying to do. You identify the minimum foundation to support that outcome. You execute end-to-end, show value, achieve the outcome, AND build the foundation simultaneously. Then you repeat. You’re not doing foundations first and value later. You’re doing them together, use case by use case, constantly showing progress. That’s the pay-as-you-go methodology.

We should consider doing the “day in the life of a piece of data.” Follow a specific piece of data through its complete journey. Where does it originate in your operations? How does it flow through your systems? Who touches it, when, why? What governance checkpoints does it hit? Where does it land in your analytics or AI systems? What insights get generated? And how do those insights feed BACK into your operations?

When you do that exercise, something interesting happens. You stop arguing about abstract governance frameworks and you start discovering exactly what you actually need, what context matters, what policies apply, what contracts should exist between teams, what the real stewardship responsibilities are. It makes the abstract concrete.

During customer meetings, I had the opportunity to bring people from the operational side and people from the data analytics side to sit at the same table for the first time. Looking at each other. Realizing they needed to work together. That doesn’t happen enough. The “day in the life” exercise is a way to force that conversation because you can’t follow the journey of a piece of data without bringing both sides of the house into the room.

At the end of the day, when you pull all of this together — data, semantics, context layers, governance, data contracts, policy as code, knowledge graphs, insights, analytics — you realize we’re not talking about data management. We’re talking about how work gets done in an enterprise. That’s the real conversation. And the sooner we frame it that way, the sooner we start making real progress.

6. Awesome Community

I started engaging with Gartner analyst about a decade ago. My previous startup, Capsenta was a Gartner Cool Vendor in Data Integration in 2016! That is when I first Mark Beyer and Ehtisham Zaidi. I believe this was my 10th Gartner D&A conference (I’ve been attending both Orlando and London for the past 5 years). It’s been fantastic to get to know more and more analyst over the years.

Also, a great thing about Gartner is that you get to connect with more friends and colleagues from the data community.

If you attended Gartner D&A London, what were your takeaways? I’d love to hear what resonated or what you’re pushing back on.

While some may have said over the years, “the Semantic Web never worked,” I see it very differently. It introduced a shared and bold vision, ahead of its time, that brought together researchers across many areas of computer science and helped form an entirely new field: the Semantic Web.

That vision created scientific communities like the International Semantic Web Conference (ISWC), which became my scientific home. 

Today, its relevance is stronger than ever. Many of the ideas we are actively pursuing now, knowledge graphs, semantic interoperability, machine-readable context, intelligent agents, are central to the original Semantic Web vision. Check out this article I co-authored with Prof Claudio Gutierrez on the historical events that have led to Knowledge Graphs.

One of the most important deliverables of the Semantic Web community has been the development of open W3C standards of RDF, OWL, SPARQL, SHACL, SKOS, and so much more. 

In just the last few weeks, I’ve had numerous conversations with data and AI leaders who are increasingly recognizing that semantics and context are the DNA of their business and that they are looking for semantic interoperability to avoid vendor lock-in. While traditional BI semantic layers are an important first step, they are not enough for enterprise-scale knowledge interoperability. To build truly interoperable and durable knowledge foundations, they are independently arriving at the importance of RDF and OWL. Personally, that’s incredibly exciting to see. It’s a reminder that these standards weren’t theoretical exercises, they were foundational building blocks for where enterprise AI, knowledge systems, and agents are heading.

On a personal note, I have a special connection with these Semantic Web visionaries.

My very first research paper and conference talk was at a W3C workshop on RDF Access to Relational Databases in 2007, with Tim Berners-Lee sitting in the front row. An unforgettable experience. Our paths have continued to cross over the years

This became the topic of my PhD research: integrating relational databases with the semantic web, which also led to two W3C standards: A Direct Mapping of Relational Data to RDF and R2RML: RDB to RDF Mapping Language. Btw, many folks are now creating knowledge graphs from relational databases. Take a look at these standards and reach out if you have any questions. I know a thing or two 😉 about this topic.

Also, at that event I met Dean Allemang at that event decade later we ended up working together! Dean is the co-author of the seminal textbook “Semantic Web for the Working Ontologist: Effective Modeling for Linked Data, RDFS, and OWL” together with Jim Hendler and Fabien Gandon

Over the years, I’ve had the privilege of learning so much from Jim and Ora.

Ora and I have become a close friend and collaborators

Together, we authored the book Designing and Building Enterprise Knowledge Graphs. We really want to make sure folks get to learn from our work so request FREE access to our book here.

So today feels like both a reflection and a thank you:

Thank you to Tim, Jim, Ora, and the broader Semantic Web community for creating and working towards a vision that has inspired generations of researchers, practitioners, and builders. It’s a honor to say that this community is my scientific home. For 25 years, the semantic web community, and the giants they stand on, have been laying the groundwork for what many are only now beginning to fully appreciate.

Next week is the Knowledge Graph Conference, which I’m unfortunately missing. I’m sure there is going to be a great celebration for the 25th anniversary. Enjoy friends!

If you want to stay current on the cutting edge of scientific innovation in this field, attend the 25th International Semantic Web Conference this October in Bari, Italy. I’ll be there and it will be a very exciting program! ISWC remains my scientific home, a place where I reconnect with old friends, meet new researchers, and continue exploring where this field is going next. If you are interesting in sponsoring, let me know

• The “AI is like electricity” framing is true, but it’s missing the critical variable: speed. Previous technology shifts took decades. This one is happening overnight.

• Layoffs are already being attributed to AI. Whether that attribution is accurate or not, something is changing fast.

• The optimistic case is real: AI will almost certainly cure cancer in our lifetimes.

• Juan’s core framing from TED: AI is a forcing function to rethink what humanity means. The opportunity is to figure out what uniquely human things we can do more of, not just what AI is replacing.

• Intelligence and consciousness are not the same thing. Getting smarter doesn’t make something self-aware. That distinction matters more than most people realize.

What the Data Profession Needs to Hear Right Now

• We’ve been living in the era of “data at the center”: data is the new oil, big data, data democratization, data literacy, data mesh, medallion architecture. All real. All important.

• The shift that’s happening now: work is the center. Data orbits around work.

• Why do you build pipelines? Why do you govern data? Why do you generate insights? So work can get done, decisions can be made, revenue increased, risk mitigated, costs cut.

• The uncomfortable implication: if you can’t connect your data work to a specific decision or action, you’re building infrastructure for its own sake.

• Caution on AI agents generating context: agents can now produce a million descriptions of things. Quantity is not quality. The question is always: what work gets done because of this?

What Comes After the Medallion Architecture

• You got your bronze, silver, gold. You have your lakehouse. You have your data products. Now what?

• Three things we think Medallion 2.0 needs:

  • Insights to action: closing the loop between what the data says and what actually changes

  • Contextualization at scale: managing multiple versions of truth so agents can make decisions, not just retrieve data

  • Feedback loops: tracking what agents did, whether it worked, when humans had to escalate, and what their override decision was. That trace is itself a data product.

Agent Governance Is an Organizational Design Problem

• When anyone can spin up an agent cheaply, organizations will end up with agent sprawl, the same way they ended up with duplicate business logic scattered across a hundred applications.

• Do the concepts from human organizational design apply directly to agent systems: hierarchy, policy, purpose, OKRs? You may need to bake your company’s OKRs into your agent prompts.

• Key provocation: bureaucracy and org structure may not be broken byproducts of humans. They may be necessary features of any complex multi-agent system. The agents used to be humans. The coordination problems are the same.

• Flat vs. hierarchical agent structures follow the same logic as human orgs: clear goal + high coordination need = hierarchical. High creativity + autonomy = flat.

• An 80/20 rule applies: ~80% of tasks can have significant agent autonomy. The remaining 20% (i.e. regulatory, financial, mission-critical) need tighter constraints.

Library Science Still Has Something to Teach Us

• As agents proliferate, someone needs to play the role of the reference librarian: understanding the true information need before retrieving anything.

• The clarifying interview matters at the agent layer: was this agent created with a fixed, clear objective, or a loose one? The quality of its output depends heavily on how well its information need was defined.

• The data catalog’s role is evolving: from active metadata with point-to-point connections, to a context layer and MCP endpoint that agents can query self-service. But the reference interview problem doesn’t go away.

What Humans Are Actually For

• A senior engineer architect, when asked what their job is now that AI writes 100% of his code, said: “My job is to have taste”. Understand what is impactful and what is not.

• Problem-solving, imagination, taste. Those are the things AI amplifies rather than replaces.

• People who think they love coding actually love solving problems. Code was always just the means of lowering the level of abstraction until the solution worked or broke. That part isn’t going away.

• Companies are human endeavors but maybe three humans and 10,000 agents is what that looks like in five years. The humans set the purpose. The agents execute.

Catalog & Cocktails is the Honest, No-BS data podcast. New episodes drop weekly. Find us wherever you listen.

This is the first part of my takeaways centered around AI. The second part will be about “regaining faith in humanity” and inspiring messages.

What AI Is Actually Doing

The AI related talks at TED spanned a spectrum from biology to infrastructure to consciousness. Together they painted a picture of a technology that is simultaneously more extraordinary and more uneven than the headlines suggest.

A profound application: understanding the language of the cell

Silvana Konerman reaffirmed one of the most consequential applications of AI in our lifetime. Her work sits at the intersection of single-cell RNA sequencing, CRISPR, and AI. The idea: cells communicate in a language. Humans have learned to compute human language. We haven’t been able to do the same for cellular language, until now. AI models trained on the language of the cell could unlock cures for diseases that have evaded us for generations.

If AI delivers here (and from the looks of it, it will!), this won’t be an AI productivity story. It will be a story about human longevity. We may genuinely see cures in our lifetime that we currently consider impossible.

Democratizing creation — agents, robots, and builders

Peter Steinberger, founder of Openclaw and David Dobes were speaking to a related shift: the democratization of building with AI. Steinberger’s argument is that people need to actually spend time with AI to understand how powerful it is, and we need to aggressively support the builders who are creating with it.

His TED talk is now available:

Dobes is working on large robotic movement models, pushing toward a world where creating robots becomes accessible outside of specialized labs.

The hallway conversations echoed this. We are living through a “pre/post-YouTube moment” for software. Before YouTube, only trained filmmakers could produce video. Before LLMs and agentic tools, only software engineers could build software. That gate is lifting. The question is what happens to the people who were behind that gate.

Superhuman performance — and the uncomfortable status quo

Tekedra Mawakana, co-CEO of Waymo shared that Waymo now has driven 240 lifetimes worth of miles. Their vehicles are 10x safer than human drivers. However, people are comfortable with the status quo. Cars have been engineered for safety; humans haven’t changed. We are, in effect, patching around the human problem rather than solving it. Waymo’s framing is to let humans be humans, i.e. inattentive, distracted, fallible, and build systems that account for that reality.

This struck me as a broader metaphor for AI deployment generally. We keep designing for an idealized human, rather than the actual one.

The edges of the spectrum: drones, crime data, and surveillance

Adam Bry from Skydio made the case for drones for fighting crime and inspecting electricity infrastructure at scale. These are genuinely useful, under-discussed applications.

Garrett Langley from Flock was more provocative. His thesis: crime is a data problem. Flock provides surveillance networks to help solve crimes. He acknowledged the controversy. The civil liberties questions here are serious and unresolved. The fact that something is technically useful doesn’t settle the question of whether and how it should be deployed.

New models: less data, less energy

Vikash Mansinghka is working on a fundamentally different approach to training models that requires less energy and less data. This didn’t get enough attention in the broader conversation. The current trajectory of AI compute and energy consumption is not sustainable. This type of work matters enormously, even if it’s less flashy than the consumer applications.

The hardest question: where do our thoughts end and AI begins?

D. Scott Phoenix thesis: we are headed toward a merger with AI. The universe has a history of this: biological systems integrating new substrates. AI is the next integration. The question he brings up: “Where do our thoughts end and AI starts?”

Anil Seth offered the necessary philosophical counterweight. Intelligence and consciousness are not the same thing. Intelligence is about capability. Consciousness is about feeling. LLMs simulate consciousness because we see ourselves reflected in them, which is powerful and somewhat dangerous at the same time IMO. He argues that “the brain is a computer” is a myth, and treating it as one misleads us. For example, do we consider AlphaFold consciousness? An AI that seems conscious is dangerous precisely because of how it affects human behavior, not because of what the AI actually is.

AI is a forcing function to rediscover our humanity

Somewhat ironically, AI is forcing us to confront ourselves: our loneliness, our purpose, our education systems, our social contracts, our creativity and more. The technology is accelerating faster than our social and institutional capacity to absorb it. Many of the talks, in different ways, were issuing the same warning: abundance without wisdom, without participation, without purpose, does not solve human problems. It can make them worse.

Jennifer Cearns reminded us that humans have always had relationships with non-human entities: pets, gods, spirits. This is not new. What is new is how real and how fast these AI relationships feel.

AI can connect you to information. It cannot answer the worry.

Neal Kumar Katyal‘s is the lawyer who argued the tariff case before the Supreme Court in early 2026. His talk was about how he prepared for this case which was based on four parts. First, he had a coach to get out of his imposter syndrome (yes, I love hearing that everyone suffers from imposter syndrome). Second, using AI to connect with information at scale. Third and improv coach to make sure he is actually listening, acknowledge concerns, and the famous “yes and ..”. Fourth, meditation, twenty minutes of focused attention. Connecting with humans, answering the worries that other humans have: AI can’t do that.

Finding your joy, AI as a creative partner

Kelly Boesch has been making AI music and videos that I personally have found mesmerizing. Her message is that AI is enabling the best creative work of her life. AI hasn’t replaced her creativity, on the contrary it’s unlocked what she didn’t know was there. We haven’t tapped into all the possible creativity that this moment makes available. Follow it. Find your joy.

The amazing musician Jacob Collier (if you haven’t seen his presentations, this is a must!) said “when life feels like a straight line, be a wiggle” I love this because when AI is optimizing everything toward efficiency and productivity, we need to not forget to take expected turns. This is what makes us humans.

AI is a powerful creative amplifier and the question of whose creativity gets amplified, whose training data shapes the tools, brings me to the next topic.

Whose voices survive? Whose knowledge gets encoded?

Gabriella Di Laccio raised a question that is foundational to how we build AI systems: 90% of the music AI is trained on was created by men. AI learns from what exists. What exists reflects centuries of exclusion. Who decides which voices survive into the training data of future models?

She’s building a list of women composers and working to get their music recorded before the window closes. This is not a niche concern. The same dynamic applies to knowledge, to journalism, to science, to culture. The default is to encode the past. Changing that requires active, deliberate intervention.

Check out the playlist she created: https://gabrielladilaccio.com/ted-2026-all-of-us-playlist/

Filling the holes in the cheese

Matthew Prince, co-founder and CEO of Cloudflare argued that we should think of LLMs as Swiss cheese: full of holes. Those holes represent missing, unverified, or underrepresented knowledge. The insight: local news, niche expertise, original reporting, which can fill the holes in LLMs. We need to incentivize and celebrate the people doing that work. He proposed something like a “Cheese Award” for content that genuinely fills gaps in the model.

My reaction: this is the Wikipedia/Wikidata argument reborn for the LLM era. It’s a real problem. And it connects directly to questions about whose knowledge gets encoded into these systems.

Life Long Continuous Learning

Bill Gurley gave a practical and useful talk for anyone thinking about careers and education in this AI world. The ones with the best careers are life long continuous learners. Following your passion is the wrong frame, you should be following your fascination (an original framing from Jerry Seinfeld). When you’re genuinely fascinated, you study automatically, you leave big footprints, people notice. He shared that 60% are quiet quitters. 20% are in their dream job.

Three systemic problems: kids have too much pressure to know their path early, we push them to declare majors before they’ve found their fascination, and we steer them toward “safe” jobs that don’t light them up. In an AI economy, the person who learns fast and keeps learning is the one who shines.

Stage vs. city

Steve Huffman, co-founder of Reddit presented the stage vs city analogy.

On a stage, you perform. The currency is engagement. Success looks like celebrity and competition. Everything gets optimized for attention.

A city creates citizens. It distributes. Up and down votes are expressions of values, not just metrics. Neighbors help each other not because they’re incentivized to, but because that’s what neighbors do.

His argument: communities don’t emerge spontaneously at scale. They need to be developed on purpose. The question we should be asking is: how do we deliver connection intentionally? The default architecture from social media creates stages. Building cities requires different design choices, different incentives, different definitions of success.

This framing maps surprisingly well onto the AI moment. If AI-powered products default to the stage model: maximizing engagement, rewarding performance, optimizing for the loudest signal, we will get more of what we already have. If we design for the city model, something different becomes possible.

Loneliness is not a flaw. It’s a signal.

Paul Bloom reframed loneliness as a biological signal, like hunger. It evolved to push us toward social repair. It hurts because it’s supposed to. The danger of AI companionship isn’t that it’s artificial. It’s that it is too comfortable. It removes the productive friction that motivates us to create and repair real human relationships. This is a sharp argument against the “AI as companion” trend, and why we need to focus on building cities, not just stages.

Technology connecting Humanity

A nice follow up to the city analogy, is how we use technology to connect humans. The work from Matt Wu is an example of how we can enable continuous learning, regardless of timing and age through technology. schoolhouse.world connects people for peer tutoring. We think about how AI can be tutors, but we also need human connection and technology can enable that connection

Maya Higa is a conservationist and live streamer, and her work points to how technology can bring people together around things that matter beyond themselves. Her platform brings audiences into wildlife conservation in real time.

Trust, common ground, and human-in-the-loop at scale

Jay Baxter and Keith Coleman from X gave a background on Community Notes as a model worth understanding. The algorithm is open. The principle: find people with genuinely different perspectives who nevertheless agree on something, and surface that agreement as common knowledge. It is, in essence, a system for manufacturing trust at scale through disagreement resolution rather than consensus manufacturing.

My take: this is “human in the loop” at scale framing. The question isn’t whether AI or humans should decide, instead it’s how to design systems where human judgment is preserved and amplified rather than automated away.

We will automate our decline if we do not deal with the people problem

Gina Raimondo‘s central argument is that we need a Tech + Human Capital Strategy, and the United States does not have one. We are not prepared for this transition. Several points she makes:

• A job is a purpose. This is why UBI won’t work because it addresses income, not meaning.

• Today’s education system incentivizes enrollment, not outcomes. Industry knows what’s working and not working. Government doesn’t. That is why we need companies to lead.

• One-and-done education doesn’t work anymore. We need continuous learning at every stage of life — not just 18-22 (see Gurley’s point above)

• Layoffs are expensive. We need to reward and support retraining.

• We need self-employment assistance for entrepreneurs navigating this transition.

You can watch her TED talk here:

Reed Hastings touched on a related concern from a different direction. AI will generate high GDP and high unemployment, and highlight that we need to head towards sovereign wealth fund-style mechanisms. The issue here isn’t to redistribute the surplus; it’s to make sure people are active participants in generating it.

Ancient intelligence and the New New Deal

Van Jones argues that technology has been accelerating, humanity hasn’t. That gap is social unrest. He called for “Ancient Intelligence”, the wisdom that exists in communities, in traditions, in lived experience, as a counterweight to the data-rich, wisdom-poor outputs of AI systems.

Just as the original New Deal was a bargain between government and people, we need a New New Deal, but this time between Big Tech and people because abundance without participation equals scarcity. Both sides need to change. His tactical advice: don’t multiply enemies, multiply friends. Less shame and blame, more space and grace.

The Thread That Runs Through All of This

We are in a moment of genuine discontinuity. Many people compare AI to past technological waves: electricity, the internet, the printing press. Those comparisons are not wrong. But the people making them were often not reckoning with the most important difference: speed. Previous transitions gave generations time to adapt. This one is measured in years, maybe months.

AI is an enabler to cure disease, eliminate car deaths, for anyone to build software. But are we ready for it? Institutionally, educationally, philosophically? We don’t have a continuous education system. We lack a human capital strategy. We haven’t resolved the question of whose knowledge and whose voices get encoded. We haven’t figured out what to do with meaning and purpose when the economic rationale for many jobs disappears.

Honestly, it seems that the people who are most optimistic about AI are often the ones most insulated from its disruptions. And the people most worried are often the ones without a clear plan for what to do about it.

I left TED with a sharper set of questions that I need to be asking myself. I know there are many people not just asking these questions but also working on the answers. And that’s how I regain my faith in humanity.

And speaking about faith, watch Malala’s TED Talk:

I’m grateful to be part of the TED community and to meet so many amazing people and have thoughtful conversations.

Stay tuned for part 2.

The Reference Interview

When you walk up to a librarian with a question, they don’t just go find an answer. They conduct a reference interview: a structured conversation designed to uncover your true information needs. Because the first question someone asks almost never captures what they actually need.

The steps:

• Establish trust: create an environment of empathy, curiosity, and zero judgment (the “can birds fly?” example)

• Listen without interrupting: no assumptions, no jumping ahead

• Paraphrase back: active listening, reframe what you heard

• Ask open questions first, then narrow: “Are you asking about a specific type of bird? Are you traveling?” → “So you want to know if your parrot can fly with you?”

• Search collaboratively: the librarian knows the system, you know the subject. Both are required.

• Verify the need was met: accept that sometimes it wasn’t. You iterate. Sometimes you don’t have the resources. That’s important data too.

This maps directly onto data work

• For many companies, it’s the business analyst playing data concierge, translating ambiguous business questions into answerable data requests

• Consider building a data concierge function because not everyone can access data directly

• The reference interview is how you scale: invest more upfront, save more later, and next time a similar question comes up, you’re ready

The librarian lens on data strategy

• Domain expertise matters: librarians often have two degrees: library science and a subject area. Data teams need the same. It’s less about data literacy, more about business literacy

• Not everything belongs in your lake: know your scope. What is your library here to do vs. the other platforms and functions in the org?

• Collection depth is a choice: how deep you go depends on the domain and your stakeholders’ actual needs

• Know your unmet needs: build a dataset of what people asked and what you couldn’t answer. That gap is a signal.

• Curation is active, not passive: data and services need to stay fresh and relevant, or they don’t get used

The one reframe that changes everything

Stop thinking of service vs. strategy. It’s not either/or. Your focus is the user. The reference interview is the strategy.

Get more from Juan Sequeda in the Substack app

Available for iOS and Android

Get the app

The void, defined

• CDOs are set up to deliver outputs, not outcomes (see the episode and takeaways with Kyle Winterbottom where we discuss this issues too). They own transformed data. They don’t own the decisions that data is supposed to improve.

• Organizations are built in silos. Transformation requires input across all of them. But CDOs aren’t given the mandate, or the authority, to drive that transformation end to end.

• When people say they want to be “data driven,” what they actually mean is: they want better decisions. Those are not the same thing.

Where it breaks down

• A data app gets built. People use it. Doesn’t change performance (except probably for a small cohort). Why? Because you exposed the data (in a colorful way, aka dashboards), you didn’t change how decisions get made.

• Decision logic is rarely documented in organizations. When I see X in the dashboard, what should I do? How do I move the number? Nobody wrote that down.

• Most mandates are brought in for data exposure, not business process evolution. Leaning into process and asking “how is this data going to change the decision?” isn’t always welcome by others.

• Data leaders are often chosen for technical depth, not business transformation or change management capability. So when they try to push on process, others think: “That’s not why you’re here. Just give me the data”

• If you think data-driven transformation is putting numbers in dashboards, that is not transformation.

The real void

Everything is exposed. The data shows what’s working and what isn’t. And then... nothing changes. That’s the void. Seeing ≠ deciding ≠ acting.

What the right model looks like

• Build your platform around decisions, not use cases. Deconstruct the most important decisions in your organization: how they’re made, what the leading indicators are, what the underlying operating principles are.

• You shouldn’t struggle to tell me what decisions you make every week. If it’s easier to list use cases than decisions, then something is wrong.

• Understand the levers that affect outcomes. Those levers are your real inputs.

• If your company doesn’t know how it makes decisions, you shouldn’t hand that process to AI.

Pete’s 3Es and where transformation dies

• Establish (infrastructure, pipelines): largely automated now, well-trodden territory.

• Enable (data literacy): still matters, but AI is making this easier over time.

• Exploit (actually changing outcomes: this is where mandates fall apart.

Where does the CDO role go from here?

• The data org may get smaller. Governance may move elsewhere.

• The emerging model: the CDO provides decision infrastructure: the knowledge layer, semantics, analytical tooling, ML Ops. That supports how decisions get made across the business. They don’t own the decisions. They enable them.

• This has to be built in partnership with the COO. You’re enabling the organization to make good decisions, not making them for it.

Get more from Juan Sequeda in the Substack app

Available for iOS and Android

Get the app

Jesus is well known in the knowledge graph space, has spent a decade at Neo4j, and personally is a long-time friend and thought partner. We go back years through the academic and scientific world, so it was great to connect in person and have an #HonestNoBS conversation.

As expected, we covered a lot of ground: the latest trends in AI and how that makes us seek a balance between operational execution and long-term strategy, and naturally, topics like knowledge graphs, context graphs, and ontologies.

What stood out the most was our rant on how to be very pragmatic with ontologies cutting through the hype and getting back to fundamentals. And that’s what I want to focus on here.

Because despite all the excitement around AI and knowledge graphs, most people still don’t have a clear, practical way to think about what an ontology actually is and why it matters.

Pragmatic Ontology Definition

An ontology is a formal, explicit, and shared understanding of a domain.

Let’s break that down:

1. Formal → Eliminates ambiguity through code

An ontology is not just a document or a diagram. It is represented in code.

• It removes ambiguity by being machine-readable

• It can be executed, validated, and enforced

• It creates a precise representation of meaning
  
  

If it’s not formalized, it’s just documentation—not an ontology.

2. Explicit → Declarative (the what, not the how)

An ontology defines things declaratively.

• It focuses on what something is, not how to compute it

• It makes assumptions visible instead of implicit

• It separates meaning from implementation

This is critical because most “knowledge” in organizations is buried in code, pipelines, and dashboards, not explicitly defined.

3. Shared Understanding → Agreement on meaning

An ontology exists to create agreement on meaning.

• At a minimum: within a team

• Ideally: across an organization

• At scale: across an industry
  

There are degrees of shared understanding, depending on the use case, but the goal is always alignment.

You’re not just defining terms, you’re aligning on what those terms mean

Why Use an Ontology?

There are two primary reasons we discussed:

1. Interoperability (Aligning Across Systems)

This is where ontologies historically come from in modern computation (e.g., the semantic web).

• You want different systems to “speak the same language”

• You need consistent meaning across boundaries

• The scope of “shared” becomes much larger (org → industry → web)
  
  

The broader the interoperability need, the stronger the requirement for shared understanding.

2. Automation (Making Systems Smarter)

Ontologies enable automation by making meaning executable.

• Validate incoming data against defined concepts

• Ensure consistency and correctness

• Enable inference (derive new knowledge automatically)
  

And this works because the ontology is:

• Formal (in code)

• Explicit (declarative)

• Shared (agreed meaning)

Automation without explicit semantics is brittle.

The Practical Takeaway

When thinking about ontologies, don’t start with tools or hype. Start with two dimensions:

Dimension 1: What makes it an ontology?

• Formal (code)

• Explicit (declarative)

• Shared (agreed meaning)
  

Dimension 2: Why are you doing it?

• Interoperability (alignment across systems)

• Automation (making meaning executable)

Final Thought

Yes, there’s a lot of excitement around ontologies right now. But before reinventing the wheel:

• There are decades of standards and prior art (see RDF and OWL). (Note: LLMs know this very very well)

• Many “new” approaches are rediscovering old ideas
  

Use whatever technology you want but ground your thinking in these fundamentals.

Get more from Juan Sequeda in the Substack app

Available for iOS and Android

Get the app

The Core Problem

• Organizations have been doing data, analytics, and now AI for years and still can’t point to tangible, specific value

• The CDO mandate is almost never aligned to value. It’s aligned to building technology and frameworks

• The mandate is a symptom of a deeper problem: boards see data as a technical problem to be fixed, not a business lever to be pulled

The Accountability Gap

• CDOs are hired to do data, not to deliver business outcomes

• If you deliver exactly what you were asked to deliver, you’ll probably still get fired (That’s a t-shirt quote!), because the original goals were never linked to outcomes

• 9/10 mandates are built around outputs, not outcomes

The Hiring Loop

• The type of mandate boards drives leaders to manage stakeholders generating outputs, builds literacy programs, etc and not one who challenges the business and drives performance

• Companies keep hiring what the board asked for (platforms, frameworks, governance) instead of what they actually need (revenue, efficiency, competitive advantage)

• This has trained an entire industry to play the wrong game

The Structural Chaos

• The CDO role has bounced from IT → business → back toward IT, and the complaints have stayed the same throughout

• Decentralization is emerging as a response — embedded VPs/Director/Heads of data in business units — but roles are fragmenting without a clear north star

• Matrix structures and dotted-line reporting are adding noise without adding accountability

What Needs to Change

• Data leaders trying to challenge the mandate in the interview process get perceived as difficult so they don’t get hired. So most nod along, get hired, and once you are in, try to change things from the inside

• The ideal mandate isn’t universal, but one thread is consistent: start with the business goals, the KPIs, and work backwards (stating the obvious but the obvious needs to be stated over and over again)

• Until boards change what they hire for, we will continue to play the wrong game

Get more from Juan Sequeda in the Substack app

Available for iOS and Android

Get the app

• It gets siloed in compliance teams whose primary goal is “don’t get sued” — not “build well”

• Business leaders get excited about AI without thinking about risk or guardrails, especially in the US where regulations are still murky

• With AI, the “we’ll patch it later” mentality is dangerous — once trust is lost, it’s really hard to get back

• Audits are painful precisely because the evidence is scattered across a dozen different places

The governance as code argument

Take governance rules that live in documents and put them where engineers actually work — in your DevOps, MLOps, and DataOps pipelines.

Four things make it real:

• Codify — express rules in JSON, YAML, etc. to remove natural language ambiguity

• Version control — who changed what, when, and why. Fully auditable by design

• Automate — checks that run continuously, not spot checks before an audit

• Make it auditable — every action becomes data and metadata, verifiable proof

This isn’t something you jump into. You need a foundation of good DevOps practices first.

Practical things every org should do

• Build an AI Collaboration Charter — a living strategy doc for governance. Don’t try to make it perfect; start small and iterate. Treat it like a participatory process the way good cybersecurity programs do

• Maintain an inventory — who is using what AI tools, who has access, and to what data

• Create a RACI — every company is different. Governance could roll up to the CISO or the CDO, but someone has to own it or no one will

• Do risk tiering — not all AI use cases carry the same risk. Build a rubric and apply it continuously

• Tie governance to performance evaluations — if it’s not incentivized, it won’t happen

The “minimum viable governance” mindset

You don’t need to boil the ocean. The goal is minimum valuable governance — start with what matters most, make it auditable, and add to it as you learn.

Think of it like CI/CD for risk: continuous discovery, continuous checking, continuous improvement. When you get new information (a new regulation, a new use case, a new failure mode), you incorporate it into the existing framework rather than starting over.

T-shirt Quote: Engineers need to become strategic engineers

The bottom line: governance isn’t a compliance team’s job. It’s a shared responsibility — and that’s actually good news, because it means it can be built into everything from the start rather than bolted on at the end.

Listen to the full episode of Catalog & Cocktails wherever you get your podcasts.

Get more from Juan Sequeda in the Substack app

Available for iOS and Android

Get the app

The Dirty Secret Nobody Wants to Admit

Everyone is behind. Not a little behind. Significantly behind. And yet if you walked the conference floor or listened to the hallway conversations, you would think every organization was crushing it with AI. They are not. They are shipping things just to say they shipped something. Board pressure is real: over half of IT and AI leaders feel pushed into adopting GenAI tools before they are ready. The result is a lot of activity that looks like progress but is not.

This is not a technology problem. This is a leadership and prioritization problem.

And by the way, this is the year of foundations. Of course it is. It always is. Until we actually build them.

The Three Numbers That Tell the Whole Story

From the Gartner opening keynote:

14% are confident their data is secured and governed.

44% of organizations implemented a semantic layer in 2025. 48% plan to by 2027.

Let that sink in. Half of organizations are building semantic layers. One in seven has their governance in place. We are building on sand and calling it AI ready data. The ungoverned semantic layer is the new ungoverned data lake. We are about to make the same mistake again, just one layer up the stack.

Semantics Is No Longer a Niche Topic

If there was one theme that ran through every session, every analyst conversation, and every dinner table discussion, it was semantics.

Gartner said it plainly: semantics break the barrier to providing AI agent-ready data. Anthony Mullen went further: by 2030, universal semantic layers will be treated as critical infrastructure, right alongside data platforms and cybersecurity. Budget for semantic capabilities is non-negotiable.

But here is the part people are not talking about enough: vendor lock-in around semantics is real and it is coming. We did this with data. We ended up with a dozen point solutions, painful integrations, and fragmented everything. We are about to do it again with semantics if we are not intentional about portability and standards.

The answer is not one more proprietary semantic layer. The answer is a coordinated, federated approach and as Robert Thanaraj said “interoperability is key”. Master your semantics in one place. Expose them everywhere. Build to standards. Upcoming standards such as OSI is a start but it’s only for BI/Analytics semantics. For ontologies, there is a need to look into RDF and OWL

The Intelligence Capability Stack — But Flip It

Carlie Idoine presented a solid maturity model, the Intelligence Capability Stack,  showing how organizations progress from AI Cautious to AI Opportunistic to AI First. The layers go from information at the bottom up through context, intelligence, and interaction to outcomes at the top.

The framework is right. The presentation was backwards: bottoms-up, starting with data and technology. Classic technical thinking.

But companies do not have a data problem. They do not have an intelligence problem. They have a work problem.

We must start explaining these frameworks starting from the top. What outcome do you actually need to achieve? What interaction or action drives that outcome? What intelligence supports that decision? What context is required? And only then — what data powers it all?

Flip the stack. Outcomes first. That is where the value lives.

Data Products Are Not Optional Anymore

Amy Lenander, CDO of Capital One, made this clear: getting data products off the ground was one of her highest-leverage achievements. Because everything builds on top of it. New ERP rollouts. Marketing transformation. AI models. It all sits on that foundation.

The data product is the authoritative source for AI agents. Not a data lake. Not a raw table. The curated, defined, governed data product.

And this line was music to my ears: “We have a number of ontologists. It’s a legit role.”

Yes. It is.

The Data Product Manager is definitely an emerging role: someone obsessed with making data usable for the business. They sit at the gap between the consumer who needs data for a business process and the producer whose primary job generates data others need. That bridge is the job. Data stewards will evolve into this role over time, with AI helping them manage more products than any human could alone.

On Governance: Stop Using It as a Clutch

Only 14% of organizations are confident in their data governance. Governance comes up as a reason things could not get done.

Here is an honest take I heard: too many data leaders use governance as a clutch. A way to say “we can’t do that.” If governance is hard, that is not a reason to stop. That is the problem to solve. 

Governance should be embedded in engineering, not bolted on as a blocker. Policy as code is the direction. 

AI governance, D&A governance, and corporate governance need to stop living in separate silos and start being harmonized.

Decision Governance, who owns the decisions AI is making, and who is accountable when something goes wrong, is the most underrated trend Gartner called out this year. It is coming whether you are ready or not.

On Data Catalogs: TJ Craig Said What Needed to Be Said

The least valuable way to start with data cataloging is with technical metadata. Stop doing that!

Focus on data flow instead. I call this the Iron Thread approach: identify the outcome you need to achieve, find the minimal data and semantics required to get there, and that is your thread. Then expand from there.

Cataloging is a skill. It comes from knowledge management. It requires understanding taxonomies, ontologies, controlled vocabulary, and standards. The industry has massively underinvested in enablement here, and it shows.

And if you want a best practice that almost nobody follows: create a metadata application profile, the way library science has done for decades. Use Dublin Core. Use DCAT. Build on standards that were designed to last.

The Platform vs. Point Solution Debate Is Over

Robert Thanaraj said it directly: stop investing in point solutions. They are disappearing. They are becoming features that will be absorbed by platforms.

The average enterprise has over a dozen data management solutions. That is not a portfolio, that is a mess! And that is not solving business problems. 

The target is one processing control plane. You can have multiple persistence layers. But the fragmentation has to stop.

The signal from analysts and practitioners is consistent.

The open question is what happens to all the customers who are mid-contract with point solutions when their terms expire. That transition is coming.

The Bottom Line

Context is king. Or queen. Context carries the crown… however you want to say it.

The organizations that will win are the ones that stop chasing AI demos and start building the foundations that make AI actually work: governed data products, portable semantics, federated context, and a clear line from data to outcome. I’m stating the obvious over and over again. 

The foundations are not glamorous. They never were. But everything else is built on top of them. And right now, most organizations are building on sand.

The solution? Send your ontologist to the fulfillment center. Build tiger teams. Shift your data teams left to act like software product teams. And most importantly: connect the five why’s back to your OKRs, or you’re just building features nobody needs.

Thank you , , and many others for tuning into my live video! Join me for my next live video in the app.

Get more from Juan Sequeda in the Substack app

Available for iOS and Android

Get the app