In short: Data modelling has gone in and out of fashion for thirty years, and AI agents have made it relevant again. AI plays two roles: it writes the models, and it uses them to answer questions. A language model can build the dbt models once someone has said which questions they must answer, but it cannot find the concepts of the business by itself. The agents that use the model go wrong wherever the model is ambiguous. The work is therefore moving from writing the tables to deciding the grain, the concepts and the definitions.
Claire Gouze, co-founder and CEO of nao Labs, wanted to know what makes an AI agent for analytics reliable. She started with no context and added one source at a time, measuring how often the agent answered correctly. Table profiling and query history got her stuck at around 40 per cent. The agent failed because two columns could mean the same thing, and because a metric was calculated slightly differently in two tables. When she redid parts of the data model and wrote documentation, she reached around 90 per cent, she told dbt Labs. The figures come from her own experiment and have not been measured independently.
None of these mistakes are new. A new analyst makes the same ones in their first week, before anyone has explained which column to use. The difference is that the analyst can ask a colleague, while the agent answers with great confidence.
The data model is where AI meets the business. AI can write the model and AI can use it, but AI cannot decide what it should mean. That is why data modelling matters again.
Why does data modelling go in and out of fashion?
In the 1990s and 2000s, the information architect was a central figure in the heyday of the data warehouse. The job was to bring together data from different source systems, harmonise it and give the organisation one consistent view of its data. The books by Bill Inmon and Ralph Kimball gave the discipline its theory of normalisation, facts and dimensions, and that theory still sits underneath most data platforms.
Then came the data scientists, from around 2011. Attention shifted to unstructured and semi-structured data, experimentation and flexibility. Hadoop and NoSQL databases made it easier to store everything first and think later, and data lakes were meant to handle larger volumes with fewer rules. Information architects were partly sidelined.
With lakehouse platforms they came back. When raw data and modelled data live side by side, someone has to keep track of what is what, and order and structure came back into fashion. The information architect’s comeback was the subject of this article when it was first published in 2024.
AI agents are the next swing, and it goes the same way. An agent can read a hundred columns and all the documentation in seconds, but it cannot guess what the business means by a customer, an order or a sale.
What is AI doing to data modelling?
AI enters data modelling from two sides. One is what AI produces. Coding agents such as Claude Code and Codex write SQL, dbt models, tests and documentation in seconds, and they write a growing share of the code in data teams. The other is what AI needs. An AI agent that answers questions about sales or customers uses the data model as its map, and it can only answer correctly where the map is right.
Juha Korpela, founder of the advisory firm Datakor Consulting, describes the same two sides. He writes that modelling is being changed as much by the code AI generates as by the context AI needs, and that both move our work up a level. We go from designing technical database schemas to describing concepts and meaning, and from modelling one solution at a time to discovering how the whole organisation fits together. We have had the methods all along, he writes. The AI era simply reminds us to go back to the business users to understand how the business works and what they need answers to.
When agents both write and use the model, nobody in the loop can spot that a column means something other than its name suggests, unless someone has written it into the model. That is why the model becomes more important, not less.
Can AI model by itself?
Yes, once someone has decided what the model must answer. In April, dbt Labs tested how well language models answer eleven business questions against a highly normalised schema. With the whole schema as context, Claude Sonnet 4.6 answered correctly 64.5 per cent of the time when it wrote the SQL itself. The team then asked a language model to create as few dbt models as possible so that all eleven questions could be answered. It created three new models that joined some of the tables, without the team writing any code. With those three models, the share of correct answers rose to 90.0 per cent, and answers through the semantic layer rose to 98.2 per cent. We have written more about the benchmark in our article on metadata and ontology for AI.
Even eleven questions with known answers are not a fully specified brief. Working from a requirements document is harder. Arthur F. Siqueira and his colleagues in Brazil asked two language models, GPT-5.1 and Qwen-3, to build data models from three requirements documents about managing the people who enter a hospital. No combination of model and prompt covered all the requirements. The best was GPT-5.1 with chain of thought and a separate verification step, and on average it met a third of the completeness criteria. Some of the set-ups scored better on clarity and simplicity. In other words, the diagrams looked tidy but were missing concepts and rules stated in the requirements.
The difference between the two experiments follows the levels of a data model. Korpela distinguishes three:
- The conceptual model describes the concepts of the business and how they connect, independent of technology. It stays valid as long as the business works the same way.
- The logical model gives the data the shape a particular use case needs, such as a dimensional model, Data Vault, a normalised model or one big table. One conceptual model can lead to several logical models.
- The physical model is the implementation on the platform, with keys, indexes and partitions.
AI takes over the physical model first. The dbt experiment shows that AI can also propose a logical model once the questions are given. The conceptual model is beyond AI on its own, because the concepts are not in the data. They live in people’s heads, in contracts and in the way the company makes money.
In our view, we are still some way from AI building data models that can be reused and widely accepted across an organisation. But we can get part of the way, and AI-assisted modelling is a reasonable first step.
What does an AI agent need from the data model?
Joe Reis, co-author of Fundamentals of Data Engineering, published a manifesto in August for what he calls Mixed Model Arts. The building blocks are the same whether you model a transactional system, a data warehouse or a knowledge graph: entities, relationships, identity, grain, time and semantics. Models now have to work for both humans and agents, he writes. We use his building blocks as a checklist for what an agent needs from the model:
| Building block | The question the model must answer | What the agent does when the answer is missing |
|---|---|---|
| Entities | Which things exist in the business, and what are they called? | Picks the table whose name looks most like the words in the question |
| Identity | What is the key for a customer or a product? | Counts the same customer twice because it exists in two source systems |
| Relationships | How do the tables connect, and how many rows meet each other? | Joins the tables wrongly and multiplies the rows |
| Grain | What is one row? | Sums order lines as if they were orders |
| Time | Does the value apply now, or when the event happened? | Applies today’s customer segment to last year’s sales |
| Semantics | What does the column mean, and where is the metric defined? | Picks whichever of two similar columns best matches the wording |
The last row describes the failures Gouze found. The fix is rarely more context around an unclear model. It is to clean up the model: one name per concept, one definition per metric, and keys and relationships that are declared rather than implied. The descriptions, business rules and semantic layer all build on the model. How to build and maintain that layer is covered in our article on the data team’s harness and context.
Star schema or one big table?
We are often asked whether AI agents do better with one wide table than with a star schema, since they avoid joins. We have not found a published measurement that keeps the questions, the language model and the context fixed, and only changes the type of data model. Fivetran’s comparison from 2022 is about how fast queries run, not whether the answers are right.
In our view, the shape is a decision at the logical level and should follow the use. A star schema with dimensions shared by several fact tables keeps definitions in one place, which helps when many people use the same customer and the same product. A wide table built on top of the star schema can be a good interface for an agent that gets the same questions again and again, as long as its columns inherit the definitions rather than creating new ones. Agents are rarely confused by the number of joins. They are confused when two places in the model give different answers to the same question.
Who does the modelling when agents write the code?
When this article was first published, we wrote that we would rather have data engineers who can model than dedicated information architects who do not code. With coding agents, that position is stronger. When the agent writes the SQL in seconds, writing is not what takes time. The time goes into checking whether the model the agent proposes has the right grain, and whether it uses the definitions the business has agreed on. That judgement needs someone who can both model and read the code.
In many organisations, nobody owns the model. In April, Joe Reis asked 334 practitioners who makes the modelling decisions where they work. Of those, 42.5 per cent said whoever builds the pipeline, and 7.8 per cent said nobody does and the models emerge on their own. Only 19.2 per cent have a dedicated modeller or architect. When a coding agent builds the pipeline, the model becomes a by-product of whatever the agent writes, unless someone owns it. Only 16 of the 334 thought better tooling would do most to improve modelling. The rest pointed to training, requirements, time and ownership.
Our experience is that language models and their users, who are often not data professionals, tend to solve their own problem. If we leave the modelling to language models alone, we can end up with data model chaos, and further from the eternal vision of a single source of truth.
More of the time now goes into the conceptual model. In an organisation with several domains, the challenge is the same as before: the domains must not each create their own definition of the same concepts. Is the customer the one who pays the invoice, the one who receives the goods, or the chain the shop belongs to? If two domains answer differently, you get two numbers that both look right, and an agent pulling data from both domains has no way of knowing which one applies. Someone has to own the shared definitions, and that job grows when agents use data across domains.
We have written more about how roles in the data team are changing in our article on agentic AI and data roles.
Where should you start?
AI-assisted modelling means that AI proposes and you choose. The choices require you to understand data modelling as a craft, as the discipline has been since the 1980s. Here is how to start:
- Pick one area. Take a domain or a set of metrics you get many questions about, ideally 10 to 20 tables, as Gouze recommends.
- Write down the questions. Build an evaluation set of real business questions with known answers. The questions are also the brief for the AI that builds the model, as the dbt experiment showed.
- Build the conceptual model with the business users. Agree on the concepts, what they mean and how they connect before anyone writes SQL. One page of concepts and relationships is enough for a domain.
- Model with AI as your assistant. Let the coding agent propose the logical and physical models, but make the choices about grain, keys, shared dimensions and definitions yourselves. Reading through what the agent produces is not enough.
- Measure, and fix the model where the agent fails. Run the evaluation set and see where the agent gets it wrong. Fix the model, not the prompt, when the failure is an ambiguous column or a metric calculated in two places.
A test: ask an AI agent for three numbers you report every month and compare its answers with the report. You know where the work starts if the explanation for a gap is a column that could mean two things, or a number calculated differently in two places.
Frequently asked questions about data modelling and AI
Does data modelling still matter when AI can write SQL? Yes, more than before. AI writes the code quickly, but the answers are only right where the model is unambiguous. In her own experiment, Claire Gouze of nao Labs went from around 40 to around 90 per cent correct answers when she cleaned up the data model and wrote documentation.
Can AI build the data model for us? AI can build the physical model, and often the logical one, once someone has decided which questions it must answer. dbt Labs had a language model create three dbt models that lifted the share of correct answers from 64.5 to 90.0 per cent. Working from a requirements document is harder. In a 2026 study, the best language model met only a third of the completeness criteria.
What does an AI agent need from the data model? The agent needs a clear grain, declared keys and relationships, an answer to which point in time a value applies to, and one name and one definition per concept and metric. The most common sources of error are two columns that could mean the same thing and a metric calculated differently in two tables.
Is a star schema or one big table better for AI agents? We have not found a published measurement that settles it. The shape should follow the use. What matters most is that each definition lives in one place, so two tables do not give different answers to the same question.
Sources
- Dan Poppy: The context engineering playbook (Claire Gouze), interview with Claire Gouze in The Analytics Engineering Roundup, dbt Labs, 2 July 2026.
- Jason Ganz and Benoit Perigaud: Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, dbt Developer Blog, 7 April 2026.
- Arthur F. Siqueira and others: On the Limitations of Large Language Models for Conceptual Database Modeling, arXiv, version 2, 18 September 2026.
- Juha Korpela: Data Modeling Is Changing: From Design to Discovery, BI-Platform, 1 September 2026.
- Joe Reis: The Mixed Model Arts Manifesto, Practical Data Modeling, 19 August 2026.
- Joe Reis: Why 90% of Data Teams Are Failing at Data Modeling, on the April 2026 Practical Data Community pulse survey, Joe Reis on Substack, 15 May 2026.
- Fivetran: Data warehouse modeling: Star schema vs. OBT, Fivetran blog, 16 August 2022.
- Ralph Kimball and Margy Ross: The Data Warehouse Toolkit, 3rd Edition, Wiley, 2013.
- W. H. Inmon: Building the Data Warehouse, 4th Edition, Wiley, 2005.
Listen to the full conversation with Eystein T. Kleivenes
Listen to the Norwegian podcast «Datautforskerne», episode 8, in which systems architect Eystein T. Kleivenes and Magne Bakkeli discuss the return of the information architect. The episode is from 2024 and is available on Spotify, Apple and Acast.
Cover image: Data model illustration, Tee11/Adobe Stock.
Magne Bakkeli is co-founder and senior advisor at Glitni. He has over 25 years of experience in data platforms, data governance and data architecture, and led the Data & Analytics team at PwC Consulting for 12 years. He has built and modernised data platforms across energy, FMCG, finance and media.