Here is a two-minute test for any business system claiming to have AI in it. Ask it a question that spans two departments. "If I take this order, what breaks?" "Which customers are ordering less than they were six months ago?" "What is the production schedule waiting on?" If answering requires someone to export to a spreadsheet first, the AI is describing one department's data back to you, which is a nicer way of reading a report.
The test works because it has nothing to do with how good the language model is. It is a question about where the data lives.
Why the question is hard for most systems
A copilot can only answer from what it can see. In a plant running sales in one tool, stock in another and production on a planner, each assistant sees one slice. Asked what breaks if you take a rush order, the sales assistant can tell you the deal value and nothing about whether there is caustic in the store or a free slot on the mixer.
Integrations move data between those tools on a schedule, which helps a report and does not help a question. By the time a question is worth asking, it usually concerns right now — and right now is the state the nightly sync has not copied yet.
So the limitation is not the model's reasoning. It is that three of the five facts needed to answer are in systems the model cannot reach.
AI-native means the data model came first
The distinction worth making is between AI added to a system and AI designed into one.
A copilot added to a platform built years ago sits on top of whatever structure already existed. If sales and production are stored separately in that structure, the assistant inherits the separation. It can summarise a report you already had, or draft an email about it. That is genuinely useful and it is not the same capability.
Genie was designed against a single data model covering Sales, Product, Inventory, Production and Procurement. Because those are one model rather than five, a cross-department question is an ordinary query rather than an integration project. "What is short for next week's batches" reads the schedule, the bills of materials, current stock and open purchase orders — four areas, one answer.
That is a build decision, not a feature. A system that stores sales and production separately can bolt on the best model available and still only describe one of them at a time.
The questions worth asking
Once a system can answer across departments, the useful questions change shape. They stop being "show me a report" and become operational:
- "If I accept this order, what breaks?" Reads capacity on the constraint, materials against stock, and the delivery promises already made to other customers.
- "Which customers are ordering less than six months ago?" Simple sales question on its face; only useful when it can also say whether those customers were short-shipped, which is a dispatch fact.
- "What is the schedule waiting on?" Production plus procurement. The answer is a list of purchase orders and late suppliers, not a list of batches.
- "Which materials will stop us this month?" Bills of materials for planned batches, netted against stock and inbound orders.
None of these is exotic. Every one of them is a question a plant manager already asks — and currently answers by ringing three people and building a spreadsheet.
What this does not fix
Worth saying plainly: an assistant working across a clean data model still cannot tell you something the data does not contain. If nobody records why a batch was delayed, no assistant will tell you why batches are delayed. If your bills of materials carry recipe percentages rather than real consumption, cross-department answers about material requirements will be confidently wrong — see bills of materials: yields, scrap and the numbers a recipe leaves out for why that gap is so common.
Good data first, then the assistant is useful. The other order does not work, and no vendor's demo will show you that.
Try it on what you have
Take your current system this week and ask it the rush-order question. Time how long it takes to get a defensible answer and count how many people and files were involved.
That number is your real baseline — not a feature comparison, not a licence cost. It is the thing that changes or does not change when you move.