This is a staging instance and does not serve clients. For day-to-day operations, head over to production. If you want access to our private preview features, contact us at [email protected].
The factory is not a folder.
A question like "Why did Line 4 lose yield after the changeover?" may require the current recipe, machine state, maintenance history, alarm sequence, quality records, supplier lot, SOP version, engineering change, camera evidence, and the judgment of people who have seen the failure before.
No single document contains the answer.
That is where the standard enterprise-copilot model begins to break down. General-purpose copilots are useful when the job is to summarize a file, find a message, draft content, or answer a question from a bounded set of enterprise sources. Manufacturing work is different because the meaning of the information depends on what asset, process, product, shift, event, version, and operating condition it belongs to.
A copilot can retrieve information. Manufacturing AI has to reconstruct the operating situation.
This is the distinction Facthory is built around.
The industrial AI problem is often described as a data-collection problem. Increasingly, it is not.
Rockwell Automation's 2024 State of Smart Manufacturing research found that manufacturers believed their organizations used only 44% of collected data effectively. The report explicitly points to contextualized data as a characteristic of industry leaders using data for real-time decisions. Source: Rockwell Automation, State of Smart Manufacturing
The remaining 56% is not necessarily bad data. Much of it is simply difficult to interpret and connect at the moment a decision has to be made.
A vibration value without the asset is a number. A quality deviation without the batch and process history is an event. A maintenance note without the later failure is a record. A procedure without the equipment version or local exception may be technically correct and operationally wrong.
Manufacturing intelligence comes from the relationships between these things.
Enterprise AI vendors are rapidly adding connectors. That is useful, but access and context are not the same thing.
If an assistant can search SharePoint, email, ERP exports, maintenance records, and a data lake, it has access to more information. It still needs to determine which machine a record refers to, which procedure was valid at the time, whether two differently named components are actually the same asset, which event preceded the failure, which source is authoritative, and whether the current user or agent is allowed to act on the result.
That is why manufacturing context is relational and temporal, not merely textual.
Deloitte's 2025 Smart Manufacturing and Operations Survey illustrates how unfinished this foundation still is. Among 600 large manufacturers, only 54% reported a data standard built around a unified data model, 45% reported an architecture standard, and 48% reported a training and adoption standard. At the same time, 24% had already deployed generative AI at facility or network level and another 38% were piloting it. Source: Deloitte, 2025 Smart Manufacturing and Operations Survey
The message is not that manufacturers should wait for perfect data before using AI. They should not.
The message is that a generic chat layer placed above fragmented operational systems does not remove the fragmentation underneath it.
There is a temptation to solve this by putting more information into the model's context window.
That misses the point.
Operational context is not simply more tokens. It is an understanding of relationships and state:
this defect occurred on this product, produced on this line, during this shift
this alarm belongs to this asset and occurred before the maintenance intervention
this procedure was the approved version at that point in time
this engineer approved the deviation and this quality record contains the supporting evidence
this similar incident happened at another site and the corrective action prevented recurrence
Facthory represents this as a Living Operational Model: a shared, governed model connecting people, processes, systems, assets, evidence, decisions, and outcomes.
The model matters because it gives AI something enterprise search alone cannot provide: the operational structure around the information.
There is a second limitation in the conventional copilot model.
It is usually single-player.
One user opens one assistant. The assistant answers that user. Another engineer opens another session. A maintenance lead starts another. A quality manager asks a similar question with slightly different context. Each person becomes responsible for moving information between conversations and reconciling the results.
That is not how a factory solves important problems.
A root-cause investigation may involve quality, maintenance, process engineering, production, a supplier specialist, and an operator who saw the event. An equipment problem may require several hypotheses to be tested in parallel. A corrective action may require human approval before anything changes on the line.
Facthory is multiplayer by design.
People and specialist AI agents work inside the same persistent investigation. A maintenance agent can analyze intervention history while a quality agent compares defects and a process agent examines operating conditions. Human experts can add observations, challenge a hypothesis, request additional evidence, or approve an action. Everyone works from the same governed operational context rather than rebuilding it in separate chats.
| Typical enterprise copilot | Facthory multiplayer AI | |
|---|---|---|
| Primary unit of work | User conversation | Shared operational problem |
| Context | Retrieved for the session | Persistent operational context |
| Participants | One user and assistant | Multiple people and specialist agents |
| Evidence | Documents and connected sources | Documents, systems, assets, history, media and expert input |
| Outcome | Answer, summary or draft | Investigation, decision, action and reusable memory |
This difference becomes especially important for long-running work. The problem may survive a shift change. An agent may need to wait for laboratory results. Engineering may need to review a proposed change the next morning. A supplier may provide evidence later.
The work should not disappear because somebody closed a chat window.
A manufacturing organization should get smarter every time it solves a problem.
If the same failure happens six months later, the next team should not begin from zero. The previous evidence, rejected hypotheses, approved root cause, corrective action, responsible people, and measured outcome should already be part of the operating context.
This is where copilots built primarily around retrieval reach another limit: retrieving the old incident is useful, but the enterprise needs the validated learning from the incident to become part of future work.
Facthory turns completed investigations, approved decisions, expert explanations, and measured outcomes into persistent organizational memory. That memory can then be used by the next person and the next agent working on a related problem.
The result is not simply faster search. It is cumulative operational intelligence.
The largest language models will continue to improve. Every enterprise AI vendor will gain access to stronger reasoning models, larger context windows, and better multimodal capabilities.
That makes the surrounding context more important, not less.
A frontier model still does not inherently know which Pump P-204 is installed at Site B, which work order replaced its seal, whether the current vibration pattern resembles a previous event, which SOP version applies, what the technician observed during the last shutdown, or which action the maintenance manager is authorized to approve.
Those are enterprise facts and relationships. They have to come from the enterprise.
Facthory's product thesis is therefore different from adding a better chat interface to existing information. We are building the shared operational layer that lets people and agents reason over how the organization actually works.
For office productivity, a copilot can be enough.
For manufacturing, where the answer depends on machines, processes, time, evidence, expert judgment, and coordinated action, context is the product.
And because real operational work is collaborative, that context has to be multiplayer.
