How can AI help mechanical engineers? Honestly, and today
AI for mechanical engineers
Most of a mechanical engineer's week is not engineering. It is finding the last work order on that pump, the datasheet for the seal, the trend from the month it failed before, and the change that was made in between. That is retrieval, and retrieval is what an agent does well, provided the equipment is modelled well enough for it to find the right pump. AI needs context, and for this role the context is the equipment model.
Where it helps today, and it is more mundane than the demos
Finding what you already have
The datasheet, the drawing revision, the last three work orders and the vibration trend for one machine, gathered in a minute instead of an afternoon of folders and tag names.
Drafting the documents you keep writing
Root-cause summaries, inspection plans, change packages and spare-part requests are structured documents built from records. An agent drafts them from the records; you correct and sign.
Noticing what nobody had time to look at
A slowly rising bearing temperature, a pump that has needed a seal three times in two years, a spare that is out of stock for a machine due for overhaul. Not prediction, attention.
The data
One model of the equipment, not five folders
Everything about a machine already exists somewhere: the tag list and datasheets, the P&IDs and drawings, the work-order history in the maintenance system, the vibration and temperature trends in the historian. The operational data platform copies them out over standard protocols, without touching the systems they came from, and attaches each to the asset it describes in one knowledge graph: this pump, this bearing, this seal, this change. An agent asks about the pump; the model knows the rest. Getting the data in is no longer the expensive part.
An agent that cannot tell P-204 from P-204A will write a confident report about the wrong pump.
First tasks
Three things an agent can draft this quarter
Not a transformation programme. Three pieces of work that repeat, that are built from records the model already holds, and that an engineer can check in less time than it took to write. Product Discovery is how we find which of them is worth handing over first in your plant, and the agents page explains what an agent can and cannot do.
The root-cause draft
Give it the failure. It gathers the work-order history, the trend for the weeks before, the last change on that machine and the spares that were fitted, and drafts the timeline and the candidate causes with a link to every record it used. You decide what the cause was.
The inspection plan
From the equipment list, the criticality, the history and the last inspection findings, it drafts the next plan: what to look at, where, and why. You cut, add and sign. The plan lands in the maintenance system as a draft, never as an order.
The change package
A seal upgrade or a bearing change touches the datasheet, the drawing, the spares list and the maintenance plan. The agent drafts the package with each affected record listed, so the review is a review, not a hunt. Nothing is changed until it is approved.
A question, walked
The bearing is hot again, and the question is why
The question every engineer asks at the machine, and the one that usually takes a week to answer well, because the answer is spread over the work-order history, the vibration trend and someone's memory. In the knowledge graph the relationships are written down as verbs: the bearing is sealed by a seal, the seal was replaced in a work order, the work order switched to a different grease. The agent walks those verbs and comes back with the change that preceded the symptom, each hop with its source. It does not guess a cause; it shows the path.
The path is the reasoning. Every verb on it is a relationship someone modelled once.
Deliberately fiction
A postcard from a Tuesday that has not happened
This has not happened. It is written to show what the pieces above do together, and it is fiction on purpose, because the honest version of this page has no case study yet.
The bearing that got a second opinion
08:40. A vibration alarm on P-204 lands in the engineer's queue with a draft already attached: the two earlier bearing failures on this pump, both within weeks of a seal change, the trend for the last ten days beside the trend before each earlier failure, the seal change logged nine days ago, and the spare bearing in stock. Every line links to its record. The engineer reads for four minutes, disagrees with one candidate cause, writes the actual one, and approves a work order that was drafted with the right parts and the lifting crew already requested. The second opinion took the morning off the calendar, not the decision.
Nothing in the postcard is new technology. It is retrieval, a model, and an engineer who still decides.
Where AI will not help you yet
It will not design the machine, size the bearing, or decide whether the plant runs tonight. It will not know the thing you learned standing next to the pump, unless somebody wrote it down. And where the model has gaps, three spellings of one tag, a drawing revision nobody uploaded, it will find them first, which is annoying in week one and the most useful thing it does all year. Design judgment, sign-off and every safety-critical decision stay with the engineer. The agent gets the folders out of your way.
Fair questions
What engineers ask us
How can AI help a mechanical engineer day to day?
Mostly by doing the retrieval and the first draft. It gathers the datasheet, drawings, work-order history and condition-monitoring trends for one machine, and drafts the documents that are built from those records: root-cause summaries, inspection plans, spare-part checks and change packages. The engineer reviews, corrects and signs. Nothing changes in a system until a person approves it.
Does the AI need our equipment data to be perfect first?
No, but it needs one model of the equipment to work from, so that a question about a pump reaches that pump's records and not a look-alike tag. The model is built from what already exists, the tag list, the maintenance hierarchy, the datasheets, and it grows as data is copied in. Where it has gaps the agent finds them quickly, which is useful in itself.
Can it predict failures?
Treat that claim with care. What it can do today is notice: a trend drifting, a machine that keeps needing the same repair, a spare missing for an overhaul that is due, and put that in front of an engineer with the evidence. Whether a failure is coming is still an engineering judgment made by a person, with better material in hand.
Which assistant or model do we have to use?
Any. The platform speaks MCP, the open standard AI assistants use to reach external systems, so the assistant your company already uses connects directly, and works under the permissions of the engineer asking. The model provider can be swapped without rebuilding anything.
Where does our equipment data end up?
Where you decide. The platform is open source under AGPL-3.0 and runs on your own servers or in a closed network. If you would rather not run it, it is hosted on hardware IntelliStream owns in Stavanger, under Norwegian law. Drawings and maintenance history do not need to leave your environment.
Start with one machine
Bring us the pump everyone knows the story of and the folders that story lives in. We will say honestly what an agent can draft from them today, and what the model needs first.