The failure we feared most on a recent retail project was a confident, well-formatted, wrong number. The client's data model had two revenue measures, both plausible, 0.7% apart. Ask a language model for last quarter's sales and it will pick one, format it beautifully and never mention the other. Nobody reading the answer can tell which one they got.
No model upgrade fixes that, because deciding which revenue measure counts is a business rule, and someone has to apply it every time. Larry Tesler, who worked on the Apple Lisa, argued that every system has complexity like this, which you can't remove, only move somewhere else. He called it the conservation of complexity. For forty years there were two places to move it to, and language models added a third:
- The user, who fills in a twenty-field form or remembers which revenue measure finance uses.
- The software, where engineers handle it once in code so nobody else has to.
- The model, which works it out for itself each time someone asks a question.
The third place is the easiest to reach, because nothing has to be built. Point an agent at a raw data model and it reads the data and makes the call. It also makes that call again in every conversation, can make it differently each time, and nobody reviews it.
In What It Actually Takes to Build a Data and AI Enabled Organisation we said you need a semantic layer so a metric means one thing, and a context layer so the agent knows what's going on. This is what building both looked like on one project. It took three attempts.
Attempt 1: Everything out of the model
Our first design took the model out of the decision entirely. Every question had a reviewed query template, and the model picked one and filled in the parameters. It never saw a revenue measure, so it couldn't choose the wrong one. It also couldn't answer anything we hadn't templated, and each new kind of question cost a template, a review and a deploy. The complexity had moved to our engineers, and they couldn't keep up.
Attempt 2: Everything back in
So we went to the other extreme and let the model write its own queries. The queries were valid, but the model guessed names, such as measures that didn't exist or a store filtered as "Newtown" when the data called it "Acme Newtown". A wrong name returns an empty result instead of an error, and the model can report that Newtown sold nothing last week. Reading the whole schema also cost the model about 135,000 tokens before it had looked at the question. The complexity was back in the model, and so was the wrong-number problem.
Attempt 3: Each kind of complexity in its own place
The design that stuck kept the reviewed logic from the first attempt and the flexibility of the second. Business rules, like which revenue measure counts, live in logic the data team owns, reviews and versions like any other code. Business meaning, like what a term means and what the data can't answer, lives in plain-English definitions the model reads before it acts. The model can still handle questions nobody planned for, but it builds on the reviewed rules instead of guessing, and we know whenever it steps off them.
Here's where the hard parts of that retail model ended up.
| Complexity | Who holds it now |
|---|---|
| Which revenue measure counts | The data team, in reviewed logic |
| Stores that must always be excluded | The data team, as rules the model can't override |
| Gross profit % doesn't add up across stores | The data team, who calculate it correctly once |
| A financial calendar that drifts | The business definitions, which the model reads |
| A bare "GP" that could mean several things | The user, because the model asks |
The model keeps the parts that need judgement: which area a question belongs to, when to ask a clarifying question, and how to write the answer.
Structure beats ad-hoc prompting
Structure can be reviewed. It's a diff a named person approves, and it doesn't change between conversations.
Structure can fail loudly. A rule that's set up wrong stops the system before anyone asks a question, and a request the rules don't allow gets rejected instead of silently ignored. The team's handover notes put it best: "A loud rejection is the feature."
Structure can be tested. Each rule can be checked on its own, so we know it's right before the model uses it.
Structure is far cheaper. The model reads only what the question needs, about 40,000 tokens instead of 135,000.
Why this is the next frontier
Barclays Private Bank's AI Mid-Year Outlook 2026 expects the next winners to be "those that can create the most economically useful system around" the model, and calls cost "the true constraint". In one study it cites, agentic coding used over 3,000 times more tokens than a single reasoning query. Every business rule the model has to rediscover gets paid for again in every conversation.
The same report warns of "cognitive surrender", where people stop checking an AI's answer and adopt its judgement as their own. A fluent answer built on the wrong revenue measure is exactly the answer people stop checking, so the checking has to happen before the answer exists.
Where to start
Tesler's law gives you a simple audit. List the decisions your agent makes that must come out the same every time, such as which measure, which exclusions and which calendar. Move each one somewhere a person can review, test and version. Leave the model the rest.
I'm David Grogan at Xephyr. We build sovereign AI agents and the data platforms that power them. If your agent is carrying complexity it shouldn't, book a call.