The first build takes days instead of months. The first change request takes an afternoon. By the tenth, nobody can say for sure what the system is supposed to mean.
More and more consultancies arrive at a customer with a toolset: a collection of skill files that teach AI agents how to build a staging layer, a type-2 dimension or a dbt project. Then they prompt the agents, and the agents build the solution.
It works, and it’s fast. We use AI agents every day ourselves, so this isn’t a post about agents being overhyped. It’s about what happens after the first build.
Six months later
A change request arrives. Customer has to be split into the account that pays and the person who orders. It touches a business definition, three source systems, two loads, a dimension that keeps history and every report that joins to it.
A new agent session starts. It has the skills, so it knows how to build a type-2 dimension. What it doesn’t know is this customer: which source is the master for Customer, which business key the loads match on, and why the dimension keeps history for some columns but not others.
So it does what any newcomer would do. It reads the code and works it out.
Code is a good record of what a system does. It’s a poor record of what the system means.
The definition of Customer and the reason a key was chosen aren’t in a SQL file in a form anyone can check. So each session reconstructs them, a little differently each time. What it works out goes back into code and chat history, to be worked out again next time.
Where markdown runs out
The usual answer is to write things down for the agents: a README, an instructions file, a folder of notes the skills point to. It helps, and up to a point it’s the right thing to do.
But prose doesn’t grow well with the system it describes. Nothing checks that a markdown file is still true, and two files can disagree without anyone noticing.
A document also can’t answer a question it wasn’t written for, such as “which loads read this column?” or “what breaks if we rename this attribute?”
It’s the problem we built Model One for, one step further along. Requirements, design and implementation still live in different places. Only now, agents carry copies between them faster than people ever could.
Skills say how. The model says what.
None of this is an argument against skills. A good skill is reusable from customer to customer precisely because it holds none of the customer’s facts. How to load a type-2 dimension is the same everywhere; which columns of this customer’s Customer dimension keep history is not.
So the question isn’t skills or a model, but where the customer’s facts live.
Skills say how to build. Something has to say what:
- the business concepts and their definitions
- the entities, keys and relationships
- which source feeds which entity
- how each load treats history
That something should be structured, checked and shared by everyone who works on the system, people and agents alike. That’s what a model is for. In Model One, the business concepts, the logical design, the loads and the physical model are one model, and agents reach it over MCP, the Model Context Protocol.
What a model gives your agents
Answers instead of guesswork. Over MCP, an agent asks the model which Flows load Sales Order, where a dictionary term is used or what a rename would affect. It gets a precise answer rather than an inference from the code. Model One exposes a project through more than 350 tools, about half of them read-only.
Code that’s generated, not rewritten. The DDL, migration scripts and dbt project are generated from the model, so a change arrives in your repository as an ordinary diff. A rename stays a rename in the migration instead of a drop and re-create, and risky steps stay commented out until someone confirms them.
The same rules as people. Agents can only make the changes the app itself allows, and they stop at anything a colleague has open. Each change goes into the audit log under the person it was made for, marked as made via the assistant or an external agent. Restoring a version reverses it.
A model that outlives the engagement. Model One runs in the customer’s own Azure subscription. When the delivery team rolls off, the customer keeps the definitions, the design, the loads and their history. The next team, or the next agent, starts from the model instead of from the code.
What it looks like in practice
If you already work with agents and skills, you keep both.
Any project member can connect Claude Desktop, or another MCP client, to a Model One project with a personal access token. The agent keeps its own skills and works as you, with your role, in that one project. Tick Read-only when it should only look.
Or use OneAssist, the assistant built into Model One. It runs on Azure AI Foundry in your own subscription, once an administrator sets it up. Project owners give it instructions and reference documents, such as your naming standard or design guides.
Either way, the prompt changes. “Build me a customer dimension” becomes “keep the history of the customer’s address in the Customer dimension, then export the dbt project again”. You prompt the model, not the code.
Where it stops
Model One designs and generates; it doesn’t do everything. It never connects to your databases or reads their rows, and it doesn’t run your loads.
It doesn’t build Power BI semantic models or reports either, and its dbt export targets Microsoft Fabric Data Warehouse and SQL Server.
So your agents will still build parts of the solution themselves. The difference is that they build them reading from the model, not reconstructing it.
Bring your toolset
If you deliver data platforms with agents, bring your toolset. Your skills make the first build fast; the model makes the tenth change request cheap.
The free Community plan is the lightest way to try it: one project, up to twenty entities and the full modeling stack, in your own Azure subscription. There’s no license fee; the Azure resources it runs on cost roughly USD 150 a month at the default sizes.
And if you’re a consultancy wondering how this fits your delivery, we’d like to hear from you.