An AI and data platform is one platform, not two projects
AI & Data platform
AI needs context. Not a longer prompt, but a model of your operation: which assets exist, how they connect, and what every reading means. That context lives in a knowledge graph. Do you have one? Or do you need to build one? Either way, the data platform is where it gets built, and AI is why it is finally worth building.
Two halves of one job, and neither works alone
AI without the data platform
An agent answers from whatever it can reach. Point it at four systems with four spellings of the same pump and it picks one, confidently. The demo is impressive and the third answer is wrong.
The data platform without AI
Ten years of readings, cleanly stored, is an archive. The questions still queue behind the one engineer who knows which join to write, and most of them never get asked.
One platform, one picture
The model your engineers see is the model the agents read, through the same door and under the same rules. Every answer, from either, can show where it came from.
The data half
Everything the operation produces, in one model
Time-series, events, documents and the records in the business systems all describe the same plant, and today they describe it in different words. The operational data platform copies them out over standard protocols, without touching the systems they came from, and lands them against one model of the operation: which asset, which process, which moment. Getting the data in used to be the expensive part. It is not any more.
An agent can only be as right as the data it was handed.
The context
The model is what the agent actually reads
A person reading a trend already knows that TT-1183 sits on the outlet of P-204, and that P-204 feeds line 3. An agent knows none of that unless it is written down. AI needs context, and the context is in your knowledge graph: every signal, event and document attached to the asset it describes, and the assets connected to each other the way the plant is. A question follows real relationships, so the answer comes with its path, and the path is the reasoning.
Assets, not tags
The agent asks about a pump, not about a tag name. The model knows which signals belong to it, in which units, and which of the four spellings is the real one.
Relationships, not joins
Upstream, downstream, part of, measured by. The relationships exist before the question does, so the answer is a walk, not a five-table join only one person can write.
Receipts on every answer
Each answer traces back through the model to the raw signals it came from, quality flags intact. Your auditor and your engineers see the same trail.
AI needs context. The context is in your knowledge graph.
The question to ask first
Do you have a knowledge graph? Or do you need to build one?
Every AI plan for an operation comes down to this question, and it is rarely asked out loud. The graph is where the context lives, so whoever answers it decides how far the agents can see. There are three honest answers, and none of them is a dead end.
You have one
Bring it. The platform's model is an ontology and a graph, so an existing graph maps onto it rather than being rebuilt, and agents read it through MCP from the first day. What usually needs work is keeping it current, which the flows do as the data lands.
You need to build one
Start from what already exists: the tag list, the asset hierarchy in the ERP, the P&IDs, the naming convention everyone half-follows. The platform builds the graph as data is liberated into it, and agents draft the relationships a person then confirms. It is weeks of modelling, not a migration.
You are not sure
Then you have pieces of one: a maintenance hierarchy, a spreadsheet somebody keeps honest, a document store with a folder per unit. That is a start, not a gap. Product Discovery finds which pieces the first agent needs, and models only those.
You do not need the whole plant modelled. You need the part the first task touches.
The AI half
Agents plug in through MCP, under your rules
The platform speaks MCP, the open standard AI assistants use to reach the systems around them, so the assistant your team already uses, an agent you build with the SDKs, or one we build with you all connect the same way. Every request carries the identity behind it, person or agent, and policy decides what that identity may read, what it may change, and where it must stop and ask. The agent sees exactly what the person it works for may see, and a denial is logged the same as an answer.
One door for people and agents. Swap the model provider tomorrow; nothing else changes.
What it does all day
From question to work order, with a person in the loop
The work agents take over first is the work that repeats: the same figure looked up, the same record moved between systems, the same report drafted every Monday. Given the model, an agent reads the request, finds what it needs, and drafts the answer, the report or the work order. A person commits. Anything that changes a record or moves money waits for approval, and what the agent wrote lands with provenance attached, so its work is reviewable like a colleague's and reversible when review says no. Product Discovery is how we find the first task worth handing over.
It drafts, a person commits
Approval gates sit in front of anything that changes a record, sends a message or moves money. The agent's speed is in the drafting; the judgment stays with your people.
Repeatable work first
Look-ups, reconciliations, shift reports, the tenth answer to the same question this month. Boring on purpose: that is where the hours are, and where an agent is checkable.
Reversible by design
Everything an agent writes carries who wrote it and what it was based on. When a review says no, the change is undone rather than argued about.
Where it runs
On your servers, in our data centre, or in a closed network
The context your agents work from is the most sensitive description of your operation there is. It does not have to leave your environment. The platform is open source under AGPL-3.0, deploys on hardware you already own, and when you would rather not run it, we host it on hardware we own in Stavanger, under Norwegian law. The technical picture says exactly what it is made of.
Self-hosted
Your cloud, your servers or an air-gapped network. The code is yours to read under AGPL-3.0, and the operational load is real and stated up front.
Hosted by us, in Norway
Hardware we own and operate in Stavanger, answerable to Norwegian law. No hyperscaler in the chain, and no jurisdiction you did not choose.
Any model provider
MCP is an open standard, so the assistant and the model behind it are yours to pick and to swap. The platform holds the context; the model is a supplier.
By sector
The same platform, asked sector by sector
The argument above is general. The questions are not: a pump, a vessel, a pen, a dock, a bearing and a turbine each have their own data, their own vocabulary and their own first task worth handing to an agent. Each page below answers the question the way that sector asks it, and says plainly where AI does not help yet.
Oil and gas
Process data, work orders, inspection records and daily reports, walked as one model of the facility.
Read the answerMaritime business
Vessel telemetry, noon reports, maintenance and class records across a fleet, with provenance on every figure.
Read the answerSalmon farms
Pen sensors, feeding logs, registers and barge equipment for each site, in one model a report can be drafted from.
Read the answerWarehouses and transportation
Warehouse and transport records, telematics and dock events, so an exception explains itself before a dispatcher looks.
Read the answerMechanical engineers
Drawings, maintenance history and condition monitoring for the equipment you are responsible for, asked in plain words.
Read the answerThe energy sector
Turbine, transformer and substation signals, inflow and weather, outage records and reporting, in one model of the plant and the grid.
Read the answerWhat an AI and data platform is not
It is not a chatbot bolted onto a dashboard, and it is not a replacement for your control systems or your historian, which should stay exactly where they are. It is the layer above them that says what an asset is, how the measurements relate to it, and who may see what. Adding that layer is smaller than a migration and, unlike a migration, can be undone. Where the model has gaps, the agent will find them first, which is the most useful thing it does in its first month.
Common questions
Asked and answered
What is an AI and data platform?
One platform that stores an operation's time-series, events, documents and business records against a single connected model of its assets and processes, and gives AI agents governed access to that model through an open standard such as MCP. The data half makes the AI trustworthy; the AI half is why the data finally gets used.
Why does an AI agent need a data platform?
Because AI needs context, and an agent is only as good as what it can see. Pointed at raw systems it has to guess which of several asset lists is the real one, what unit a reading is in and which pump a tag names, and it guesses confidently. A data platform holds that context as a maintained knowledge graph, so the agent looks it up instead.
Can we use our own AI assistant or model provider?
Yes. The platform speaks MCP, the open standard AI assistants use to reach external systems, so the assistant your team already uses connects directly, and agents you build with the SDKs connect the same way. Because it is a standard, the model provider can be swapped without rebuilding anything.
Does our operational data leave our environment?
It does not have to. The platform is open source under AGPL-3.0 and runs in your cloud, on your own servers or in a closed network. If you would rather not operate it, we host it on hardware we own in Stavanger, under Norwegian law, with no hyperscaler in the chain.
Do we need a knowledge graph before we can use AI agents?
You need the part of one that the first task touches, not the whole plant. If a graph exists it maps onto the platform's model and agents read it from day one. If not, the platform builds it as data is liberated in, starting from the tag list, the asset hierarchy and the naming conventions you already have, with agents drafting relationships and a person confirming them. Product Discovery is a two-week engagement built to find the first task and the slice of the graph it needs.
Start with the task, not the platform
Tell us the job you would hand over first and what it runs on today. We will say honestly whether an agent can do it now, and what the data has to look like before it can.