Right SQL, wrong answer: what I learned about semantics and AI at Big Data London 2026

I spent two days at Big Data London this year, and most of the sessions I picked were about the same thing from different angles: semantic layers, ontologies, knowledge graphs, context engineering and AI governance. I’ve been building AI agents for a while now, so I went in with a specific question. Why do agents that write perfectly good SQL still give wrong answers?

By the end, six speakers had answered it in slightly different ways, and they mostly agreed. The hard part isn’t generating the query. It’s agreeing on what the data means, and being able to prove afterwards that the agent used it correctly.

In this post, I’ll go through what I heard, where I agreed, and where I had doubts.

The problem: the query runs, but the answer is wrong

The most honest example came from PostHog. They asked their agents a simple question: what is our revenue? Around 200 people, using different AI tools, got different answers.

The interesting part is that none of the SQL was broken. Every query ran, and every table the agents picked looked reasonable. The problem was the warehouse itself. It had more than 60 tables with “revenue” or “stripe” in the name. Only four of them were certified. Sixteen were deprecated but still queryable. One table ending in _view, which most of us would assume is the modelled, correct version, was actually the wrong one to use.

I think this is the core issue. Language models are now very good at writing SQL. They are not good at knowing which data to trust, which definition applies, or that two columns both called customer_id mean different things. That knowledge has always lived in people’s heads. Until agents came along, it didn’t really need to live anywhere else.

First, some definitions

Before going further, let’s clarify the terms, because they get mixed up a lot. One of the talks laid them out clearly:

An ontology describes concepts of any kind, such as entities, processes and ideas, along with their relationships and constraints. It’s usually stored as a graph and works well for multi-hop questions and document-heavy domains.
A semantic model is narrower. It defines entities, how tables join, and most importantly, metrics. It maps closely to relational data and is what sits behind “ask a question, get a number.”
A canonical model reconciles systems that disagree, for example when SAP calls something a customer and Salesforce calls it an account.
Context engineering is deciding which of these, along with instructions and skills, you give to an agent for a particular task.

In practice, you often need more than one. Supply chain risk is a graph problem until someone asks how much it costs, and then it becomes a metrics problem.

One speaker also reminded us that none of this is new. Business Objects had a semantic layer in the early 90s. What has changed is who asks the questions. It’s now an agent, and it has none of the tacit knowledge an analyst carries around.

Meaning is not enough; you also need trust

PostHog’s answer to the revenue problem is something they call a context warehouse. When I looked past the name, most of it is trust metadata on top of a semantic model:

Every table and metric has a status (certified, deprecated or proposed), and agents check it before answering.
If someone edits an approved definition, it goes back to “proposed” automatically. Drift gets caught instead of silently inherited.
People can attach notes to the data, such as “lower numbers on Saturdays are normal” or “don’t join on this column.”
Freshness and data quality checks come back with the query result, so a stale sync shows up as a warning rather than a quietly wrong number.

The part I liked most is that this knowledge lives in the catalogue, not in any single agent’s memory. It doesn’t matter whether you ask Claude, ChatGPT or an internal agent. They all read the same source of truth.

The same loop, from different speakers

What surprised me was that several speakers, from different companies, described the same workflow:

Agents notice which questions are asked again and again.
Agents propose verified queries or official metrics.
Humans approve them.
Approved definitions become the grounding for future answers.

In other words, agents propose and humans own. It came up in PostHog’s product, in a Snowflake-focused governance talk (where verified queries are used as grounding), and in Juan Sequeda’s talk. When unrelated teams arrive at the same pattern, I think it’s a good sign that it’s becoming the default.

The governance talk also had a few practical guardrails that I’d reuse. Keep semantic definitions in the same repository and CI/CD pipeline as your data pipelines, so upstream breaks show up immediately. Give agents read-only access. One speaker’s client learned this the hard way when their agent started creating tables to answer questions about data that didn’t exist. And evaluate agents properly: did they pick the right semantic view, use it correctly, and get the right outcome?

A talk I disagreed with

Not every session agreed with this. One talk proposed agents that restructure messy data during ingestion and “autonomously repair” low-confidence records, with no human involved. It also used an LLM as the security layer to filter personal data.

Someone in the audience asked what happens if the outlier is actually the signal. The answer was that it depends on your implementation. Their example was a hospital, where that is a clinical risk rather than an analytics problem. I also wouldn’t want a model deciding access control. That is exactly the place where you need deterministic rules, not something that can fail silently.

Still, I found it a useful contrast. It showed what this kind of architecture looks like when the governance layer is missing.

Twenty years of knowledge graphs in twenty minutes

Juan Sequeda shared twenty lessons from two decades of building knowledge graphs. He went through them quickly, but a few changed how I saw the rest of the conference:

You cannot automate understanding. People don’t agree on meaning, so a model can’t settle it for them. The goal is assisted automation with realistic expectations.
Start with one question and unpack it. “Net sales by region” sounds simple. Then you ask whether it’s the billing or shipping address, which region Texas belongs to, and whether a sale counts when it’s booked, shipped or billed. One question teaches you most of your model. If the next use case can reuse most of that work, the value compounds.
Keep knowledge separate from data, but connected. Your first knowledge graph is your metadata.
Semantics is for interoperability, not only for AI. If every platform ships its own semantic layer, you don’t get one truth. You get ten thousand agents with ten thousand answers.
The hard part is social. We are dealing with the same problems we had 30 years ago, and technology isn’t what’s holding us back. His best example was a company that tied a quarter of everyone’s bonus to data quality metrics. Quality improved because suddenly everyone cared.

From meaning to proof: the EU AI Act talk

Most of the talks were about giving agents the right meaning. The one that stayed with me the most was about what happens when that goes wrong, and whether you can prove what happened.

Srini from IntelStack built his talk around an incident. At 09:07, an AI service at a financial firm starts giving customers eligibility answers directly, bypassing adviser review. At 09:12, the incident lead has three options: suspend, restrict or continue. They choose to restrict. No direct eligibility answers, and human support stays open. By 10:00, the CRO needs the facts, the exposure, the containment and the authority, all with evidence.

There wasn’t one big failure. There were four small ones that lined up. He organised them into five control cards:

Value: who benefits? The service drifted beyond its approved use. The fix is a written boundary for each workflow and a named approver for any channel change.
Knowledge: what may it use? An outdated policy version was still retrievable, so the closest text was the wrong authority. The fix is an approved source list with versions, effective dates and a retirement rule.
Change: what changed since approval? Separate changes to the model, prompt, index and tools added up and moved the baseline. The fix is a pinned baseline with a test gate on all four.
Evidence: can we prove what happened? The conflict in production had never been tested. The fix is a correlation ID for every decision and the ability to replay it against production state.
Cost: what does safe operation cost? The final verification step was set to fail open when the daily budget ran out. The fix is a protected verification budget that fails closed.

For me, that last one was the most realistic failure of the week. Nobody decided to remove a safety check. Someone set a cost cap, and the safety check quietly disappeared with it.

The cards also connect well with the earlier talks. The Knowledge card is PostHog’s certified-versus-deprecated problem, applied to documents instead of tables. The Change card is the same idea as resetting approval when a definition is edited. And the Evidence card answers a question I had been waiting for someone to address: how do you prove that an agent behaved as intended?

His other point was that one linked trace can serve everyone. Consumer protection, data protection, internal governance, operational resilience and the EU AI Act ask different questions, but they need the same facts: the outcome, the data used, the decision logic, the human review and the logs. If you build that record once, each team can use it.

The timeline is also real. The Digital Omnibus on AI, Regulation (EU) 2026/1744, came into force on 27 July 2026. It moves the high-risk obligations for standalone Annex III systems to 2 December 2027, and for AI embedded in regulated products to 2 August 2028. The Article 50 transparency duties, the GPAI provider obligations and the Article 5 prohibitions stayed on their original schedules [1]. As his slide said, the dates are fixed. Making hundreds of workflows provable is what takes the time.

I would add two caveats. First, scope matters. The high-risk examples he gave were specific, such as personal credit scoring and life and health insurance pricing, and not every AI workflow falls into that category. Second, for UK companies, the Act applies when systems are placed on the EU market or their outputs are used in the EU. Even so, I think the five cards are worth adopting, because UK regulations ask for the same kind of evidence.

His advice for getting started was simple. Pick a few consequential live workflows, baseline the whole chain rather than one team’s part of it, and rehearse containment before you need it. The answer you can give at 10:00 depends on the controls you put in place before 09:07.

What I’m taking away

The bottleneck has moved from infrastructure to meaning and accountability. Compute and storage are largely solved. Agreed definitions are not.
Agents shouldn’t own meaning. Let them observe, propose and draft, and let people approve what becomes official.
Trust metadata matters as much as the model. Certification, deprecation, freshness and ownership are what stop a correct query from returning a wrong answer.
Start with one question, not the whole enterprise. None of the speakers who tried to model everything first had a good story to tell.
Just because you can use English doesn’t mean you should. Sometimes the better use of AI is to generate a deterministic query once, rather than run an agent every time.
Make it provable. It isn’t enough to believe your agents behave well. You need to show what they used, what changed and who approved it, for any single decision. One linked trace per decision, replayable against production, is a good standard to aim for. For high-risk use cases, there is now a date for it.

The AI part, it turns out, was the easy part. The meaning and the proof were always the harder bits.

References

[1] Cloud Security Alliance, EU AI Act’s High-Risk Deadline: Deferred, Not Cancelled, 1 August 2026.