Estimated reading time: 12 minutes
Key Takeaways
- Assembling context later increases query latency, token costs, variability, and the risk of incorrect relationships.
- A MES captures operational context at execution, when relationships are known rather than inferred.
- Resolving and recording context once at the source makes AI faster, cheaper, and more accurate.
- Manufacturing operations are best modeled as a graph linking products, equipment, processes, materials, people, and orders.
- The same authored context can support precomputed KPIs, graph traversal, and wide columnar analysis.
- This advantage is strongest on the shop floor; cross-system questions may still require downstream context assembly.
Why AI in Manufacturing Needs a Context Engineering Layer
A factory-floor measurement means little without context. A temperature, pressure, or vibration value becomes actionable only when linked to the product, process step, recipe version, operator qualifications, material lot, and order. Without those relationships, it is just a number.
Most AI pilots overlook this distinction. Models do not reason over numbers alone; they reason over context. The key question is not how quickly a demo can be built, but who assembles that context and when.
That choice determines whether execution-layer AI is fast or slow, affordable or costly, accurate or unreliable and defensible or easy to copy.
The Hidden Cost of Reconstructing Context at Query Time
The common approach assembles context late. That’s what most pilot and PoC implementations that I have seen are doing.
Events land in separate places. When a question is asked, the system re-links everything on the spot. It pulls the measurement from one store, the equipment record from another, the recipe from a third, and tries to stitch them together.
I say try, and many times it works. But you pay the stitching cost on every question. And when AI drives thousands of queries a minute, each one reassembling its own context, the cost compounds.
That is reconstruction at query time. This means slower responses and much higher tokens costs.
Read more: Why AI in Manufacturing Stalls at Execution
AI Agents Burn 1,000x More Tokens Than a Single Query
The cost problem gets worse the moment an agent is involved rather than a single question. An agent reads the task, acts, re-reads everything, acts again, so the context snowballs with every step.
A Stanford Digital Economy Lab study of agentic coding found these workloads consume around a thousand times more tokens than a single query, and that the same task runs twice can vary by up to thirty times, because the path an agent takes is stochastic. The study is about coding, but the mechanism transfers directly to manufacturing agents.
When the immediate context is thin, that variance widens. A model with little resolved context has to go looking, and where it looks is not deterministic.
One run finds the right records fast. The next wanders, re-reads, and burns tokens finding its way back. Authored context narrows that. When the relevant facts already sit next to the query, the agent has less room to take an expensive detour.
But the deeper problem is not speed, it is fidelity.
A system reconstructing context after the fact is guessing at relationships it did not witness. It infers what was connected to what, and inherits whatever ambiguity the execution layer left behind. Sometimes the guess is wrong and no one can tell.
Resolving Context at Execution Time Rather Than Reconstructing it Later
MES resolves context before anyone asks, when the event happens.
When a step completes, the execution system already knows the product, equipment, recipe version, operator, material lot, and order because it enforced them a moment earlier. It checked the operator’s certification before allowing the step. It confirmed the equipment was qualified. It bound the material lot to the order. The context was not a lookup. It was the act itself.
This way, the expensive work happens a single time, at the point where the answer was already known, instead of being repeated for every question downstream. It resolves it once, right there, and records it.
That is the distinction between authorship versus reconstruction.
The execution layer does not figure out the context. It authored it. That’s what we call the authored path. Nothing downstream can say the same.
Why MES Must Own The Context
The MES is the only layer where the relationships are known rather than inferred. A warehouse, a lake, an analytics platform, an AI service all receive the event after the fact. They are downstream by definition, and they inherit the ambiguity of whatever reached them.
The MES sits at the point of execution. It holds the full operational context at the instant an event occurs, because it is the system enforcing that context in real time.
That position cannot be occupied from downstream. It is not a feature a data platform can add.
The MES can hold this context because its model of the operation, whether explicit or not, is a graph.
How the MES Data Model Works as a Graph of Manufacturing Relationships
It is a graph in the structural sense, not a knowledge graph assembled downstream to unify sources. Think of the MES as a map of your operation. The things on the map are the dots, and the actions that connect them are the lines.
The entities are the nodes (products, equipment, processes, materials, people, orders) and the transactions are the edges (a step run, a lot consumed, an operator signed in, a unit moved.)
The edges are where the meaning lives, because they record not just that things exist but how they acted on each other and when. That structure is the ontology. It is what turns raw entities into a model that can be reasoned over.
The dots are the things on the shop floor: products, equipment, processes, materials, people, and orders.
The lines are what happens between them: a process step runs, a material lot is consumed, an operator signs in, a unit moves to the next station.
The lines are what matter the most. A list of things only tells you what exists. The lines tell you what those things did to each other, and when. That is where the real meaning is.
This is different from a knowledge graph. A knowledge graph is usually built afterwards, by pulling data from different systems and trying to connect it.
The MES doesn’t need to reconstruct those connections, because it records them as they happen.
This structure of connections is called the ontology. It turns a pile of separate facts into a model you can actually reason with. And it’s one of three pieces that work together:
1. Semantics
Semantics tells you what each thing is. A “lot,” a “step,” or a “unit” has one clear, agreed definition.s
2. Ontology
Ontology tells you how things are connected, like which material went into which product, on which machine.
3. Context
Context tells you what was true around a specific event: who was there, what equipment was used, and which order it belonged to at that moment.
You need all three to get trustworthy results. A number with a defined meaning but no relationships is still stranded. A graph with no semantics is a shape with no content.
The MES is where the three arrive together, because it defines the terms, holds the structure, and resolves the context in the same act.
A graph is the honest model, because that is what the operation is. It is the neighborhood of fact around every event that makes it interpretable.
The Limits of Context Authorship: MES vs. PLM and QMS
This argument is strongest for shop-floor execution, and it is worth being precise about that.
When the MES is the system enforcing the operation, it authors the context for that operation cleanly. That already covers a large share of the hardest and most valuable floor-level questions: yield, genealogy, root cause, equipment behavior, process excursions.
It gets harder when the relevant context lives in other systems. A PLM holds the product and design intent. A QMS holds the quality record. When a question spans those boundaries, no single system authored the whole context, and late assembly may be the only way to answer it.
That is a real limit, and pretending otherwise would be dishonest.
But the point stands where it matters most. For anything that is shop-floor execution, the context was authored at the source, and that covers a significant share of the problems manufacturers actually need answered.
Read more: What Happens When AI Makes a Decision You Can’t Explain?
The Same Context, Served Different Ways
A graph is the right way to model the operation but it’s not always the right way to serve a query. This is the step most architectures miss: authorship happens once, at the MES, but the same authored context can then be materialized in more than one shape, chosen by the question being asked. Redundancy across these shapes is deliberate, not waste.
3 patterns cover most of it.
1. Aggregated KPIs and indicators
Questions like yield by line, OEE by shift, first-pass rate over time are pre-calculated and read from a warehouse-style store. They can be columnar underneath, but the point is that the numbers are already calculated.
2. Relationship traversal
Questions that walk the operation node to node, such as genealogy, containment, root-cause paths from a failed unit back through its material and equipment history. These can be in many cases done with a pure columnar approach, but some are served best from a graph database.
3. Scan and correlate
Questions that read across millions of events, filter, and pull wide context for analysis are scan-heavy. These are served from denormalized wide columnar rows, each row carrying its full neighborhood already attached, so the AI layer reads at columnar speed with no traversal or reassembly.
So the sequence is: resolve at the source, once; model as a graph; serve in whatever shape the query needs.
The same authored context, served in three shapes by query type
There is no contradiction across these. They answer different questions, and all three draw from the same context, authored once at execution.
Why the MES Advantage Can’t Be Replicated Downstream
Anyone can build a data warehouse, a graph, or wide columnar tables. The real strength is the sequence.
You can materialize any of those shapes cheaply only if the context was resolved for free at the source. It was resolved for free only because the MES already held the graph. And the MES held the graph only because it was the system executing the operation. Remove any link and the argument collapses.
That is why a downstream platform cannot replicate it. A data platform can build every serving shape there is. What it cannot do is populate them with context it never authored. It is left reconstructing relationships the execution layer already knew, and often already discarded.
Why Pre-Resolved Context Is Non-Negotiable for Autonomous Manufacturing AI
Everything above serves three outcomes: faster, cheaper, and more accurate results.
- Faster, because the context is already resolved and the query does not stitch it back together.
- Cheaper, because a query carrying pre-assembled context spends far fewer tokens than one that has to reconstruct and reason over the raw relationships.
- More accurate, because context that was authored at execution is witnessed fact, not inference, which is the difference between a grounded answer and a hallucination.
For an analytics copilot, this could be a nice-to-have. The answers come a little faster, cost a little less, and a wrong answer is a mere inconvenience.
But the moment you go beyond that, when AI is asked to permanently act on the floor, to decide, to close a loop rather than summarize one, the three outcomes stop being nice-to-have but become a must-have. What I mean is that a slow answer could miss the window; an expensive answer does not scale; an inaccurate answer could destroy the credibility of the entire exercise.
FAQ
Structuring operational data (equipment, materials, operators, orders) so AI systems get pre-resolved, trustworthy context instead of reconstructing relationships from raw data at query time.
An authored path is context created once, at execution, by enforcing it (certifications, equipment, lots) not looked up or reconstructed afterward by downstream systems.
Authored context is captured as fact when the event happens (enforced in real time). Reconstructed context is assembled later from records, it is inferred, not witnessed.
Pre-assembled context means queries skip reconstructing raw relationships. Less stitching, less reasoning over disconnected data means fewer tokens spent per query, faster and cheaper results.
Autonomous AI acts and closes loops, a wrong, slow, or expensive answer can destroy credibility or miss critical windows while copilots just answer questions, errors are merely inconvenient.
A data platform stores records; it didn’t enforce the rules when the event happened. Only the MES authored that context. A platform can only reconstruct it, imperfectly.
Only partially. MES authors shop-floor context cleanly, but questions spanning product design (PLM) or quality (QMS) need late assembly, no single system authors it all.
Yield analysis, genealogy tracing, root-cause investigation, equipment behavior, and process excursions, all cases where MES already enforced and witnessed the relevant context.
