Context OS is one layer of a Governed AI stack.
Most manufacturers don't have an AI problem. They have a reinvention problem.
An alert fires on a cement kiln at 2 a.m. The deviation is clear on the screen. The cause is not. The process engineer starts the familiar routine. They pull historian trends, open SAP maintenance records, check the operating procedure, search old shift notes for anything similar, and call the one specialist who saw this failure three years ago.
Hours later, there is a diagnosis. It is often a good one. But it stays in that plant, in that engineer's head, and in a slide nobody will find next time.
Now multiply that by every plant, every line and every business in a diversified industrial group. A cold rolling mill in a metals business runs through the same routine with different equipment. So does a cable extrusion line. Each site eventually buys or builds its own AI pilot, and each one repeats the integration, the knowledge build and the governance setup from zero.
That is the real cost of AI in manufacturing today. The models are rarely the problem. The problem is that every deployment starts over.
This post sets out a different approach. Build the intelligence once at group level, adapt the context at each plant, and govern every action. Each validated deployment then becomes an asset for the next one.
Why context has to come before agents
The common shortcut is to point a large language model at plant data and ask it questions. It looks impressive in a demo and fails at the first real incident. The reason is simple. A model can read a temperature tag, but it does not know what that tag means for this kiln, which equipment sits upstream, or what happened the last three times the pattern appeared.
Industrial decisions depend on context:
- Equipment relationships: what feeds what, and which component failures cascade
- Temporal history: how the asset behaved before, during and after past incidents
- Operating knowledge: the SOPs, acceptable limits and process rules that define "normal"
- Validated experience: which diagnoses engineers confirmed, and which they rejected
- Provenance: where every piece of evidence came from, so a diagnosis can be defended
This is the job of a Context OS. ElixirData turns fragmented operational information into decision-grade context. It ingests historian data, maintenance records, procedures and past cases, and maps them into a ContextGraph of assets, relationships and time. It keeps lineage on every fact and acts as the agent's memory.
Agents built on that foundation do more than answer questions. They reason the way an experienced plant engineer does, and they show their evidence.
A model can read a tag. A Context OS knows what the tag means.
Build once, adapt at every plant
The shift is architectural. Instead of treating each plant as a separate project, split what is shared from what is local.
[Insert image: diagram-1-plant-by-plant-vs-group-foundation.png] — Alt text: Plant-by-plant AI rebuilds agent, skills, context, connectors and governance at every site; a shared group foundation means each new plant adds only its context and connectors.
| Shared at group level | Owned and controlled locally |
|---|---|
| Agent execution framework | Equipment and process models |
| Versioned investigation skills | Historian, SAP and MES connections |
| Governance framework | Local safety policies and approvers |
| Knowledge validation standards | Plant-specific operating rules |
| Agent evaluation and monitoring | Data access permissions |
| Approved reusable knowledge | Local operational decisions |
Take a root-cause analysis (RCA) agent built first for a cement kiln. A metals cold rolling mill can reuse the same agent framework, the same versioned investigation skills and the same governance. It supplies only its own equipment hierarchy, historian mappings, failure modes and operating rules.
The critical test is not whether both plants can run AI. It is whether the second plant can adopt a validated capability with measurably less reinvention.
Not everything transfers, and the architecture should say so plainly. A failure mode in rotating equipment may carry over to comparable assets in another business. A retail replenishment rule or a financial-services control usually won't. Reuse is selective by design.
How it works, from alert to learning
Four capabilities that are usually bought separately work as one governed path.
[Insert image: diagram-2-context-os-platform-flow.png] — Alt text: Plant systems feed ElixirData, which builds context for ElixirClaw agents using ElixirHub skills; AgentGRC checks every action, people approve high-risk ones, and validated learning returns to ElixirData.
| Capability | Role |
|---|---|
| ElixirData — Context OS | Turns scattered operational data into decision-grade context: equipment relationships, history, meaning, provenance and validated knowledge |
| ElixirClaw — Agentic OS | Runs specialist agents that investigate, compare evidence, rank hypotheses and coordinate approved tools |
| ElixirHub — Skills Registry | Stores reusable, version-controlled investigation skills that any authorised plant can install |
| AgentGRC — Governance | Applies policy decisions, permissions, human approvals and audit evidence to every agent action |
In an RCA, the loop runs Detect → Understand → Investigate → Recommend → Govern → Approve → Execute → Learn. The last step is the one most systems skip. When an engineer confirms a diagnosis, it goes back into the ContextGraph, so the next incident, at this plant or a comparable one, starts with more context than the last.
Governance by design: every action gets a policy decision
In a plant, an AI that can act is only valuable if everyone knows what it is allowed to do. So governance cannot be a report produced after the fact. It has to sit inside the action path.
Every action an agent proposes is checked against policy before it runs, and gets one of four outcomes:
| Proposed action | Policy outcome | What happens |
|---|---|---|
| Read authorised sensor trends | ALLOW | The investigation proceeds with scoped access |
| Run a sensitive diagnostic query | MONITOR | It proceeds with an enhanced trace and evidence |
| Submit a corrective maintenance action | APPROVAL | A named engineer or supervisor decides |
| Change a protected control setpoint | BLOCK | Denied outright and logged |
Every outcome writes to a decision trace: the policy ID, the rationale, the approver, the tool result and the timestamp. Audit stops being an investigation and becomes a search. Compliance evidence builds up as part of everyday operations.
The principle is simple. AI speeds up the investigation, and authorised people stay responsible for consequential plant decisions.
At group level the benefit compounds. Governance is set up once and applied to every business. Each plant still owns its approvers, its risk profile and its local policy scope.
The economics: why the second plant matters more than the first
The first AI deployment in any plant is expensive. That is normal. What matters to a CFO is the second deployment, and the third.
The cost model changes when investment is split into three parts that can be seen separately:
| Category | What it covers |
|---|---|
| A. One-time foundation | Agent infrastructure, shared skills, governance controls, knowledge standards, deployment templates |
| B. Plant-specific work | Equipment models, connectors, data mapping, local policies, testing, training |
| C. Recurring operations | Platform, infrastructure, model usage, monitoring, support, governance |
First deployment = shared foundation + plant 1 implementation
Second deployment = plant 2 implementation + incremental changes to shared capabilities
The hypothesis is that each later plant costs less, because more of the platform and its validated skills are reused. That hypothesis should be tested, not assumed. Track engineering days for plant 1 against plant 2. Count the agent and skill artifacts reused unchanged. Measure the time it takes to reach a defensible diagnosis before and after.
One warning for buyers: an output that merely looks the same is not proof of reuse. Ask for the same artifact versions, with every configuration change and every piece of new code listed separately.
How to start: one problem, two plants, then scale
You don't need a group-wide AI programme to begin. You need evidence.
- Pick one painful, measurable decision. Root-cause analysis on a critical asset works well. It has a clear owner, measurable downtime and data that already exists.
- Connect what you already have. Historians, SAP, MES and any existing process-knowledge chatbot can be connected through approved tools. Nothing needs to be ripped out or replaced.
- Model the plant's meaning. Build the equipment hierarchy, tags and failure modes into the ContextGraph.
- Agree the policies before go-live. Sit down with safety and risk teams and decide what is allowed, what needs approval and what is blocked.
- Prove reuse on a second plant, ideally in a different business. Measure what changed.
- Scale only through gates. If the evidence misses, redesign or stop. Never expand automatically.
The bottom line
The advantage in manufacturing AI will not go to the company with the most pilots. It will go to the company whose tenth deployment is the cheapest, the fastest and the best governed, because it learned from the first nine.
Build intelligence once. Reuse it where it applies. Preserve what each deployment learns. Govern every action.
ElixirData is the Context OS behind governed, reusable agentic AI for multi-plant and multi-business enterprises. Working alongside ElixirClaw, ElixirHub and AgentGRC, it helps industrial groups turn each plant's expertise into group intelligence. Talk to us about a two-plant pilot.
