Agents that advise, engineers who decide: AI for maintenance planning at a Saudi industrial operator

The situation

An industrial operator in Saudi Arabia ran several processing plants. Maintenance planning depended on a small group of senior engineers who knew the equipment's history, read sensor trends, checked past work orders and decided what to fix, when and with which spares. Their backlog grew every quarter. Data was everywhere: plant historians, a work-order system, inspection reports and spreadsheets of spares, but connecting it for one decision took days.

Why now. Large Gulf industrial companies are moving AI agents into core operations. On 1 November 2026, Aramco and the Public Investment Fund closed a deal giving Aramco 49% of HUMAIN, with Aramco planning to use HUMAIN's AI infrastructure for industrial applications¹. A day later, ADNOC announced it would run AI agents on OpenAI's Frontier platform across its operations, hosted on UAE-based infrastructure with human oversight of consequential decisions². The operator's board wanted the same benefits, with clear limits on what agents could do and where data would live, under Saudi Arabia's Personal Data Protection Law³⁴.

What had to be true

• Agents never touch the plant. No connection to control systems; read-only access to copies of data.
• One connected view of assets: equipment, relationships, history and spares, current and as at any past date.
• Every recommendation carries its evidence, so an engineer can check it quickly.
• Engineers decide. Agents draft; approved changes become normal work orders.
• Data in the Kingdom, including the personal data in work orders and shift logs.

Architecture

The data flow, end to end

The hard part: giving agents the plant's context, safely

A maintenance recommendation is only as good as its context: what this pump is connected to, how it has behaved, what failed last time and whether the spare is on site. That context was spread across systems that did not agree on names. The team built an asset knowledge graph from an event log rather than from periodic copies. The OpenTelemetry community describes the same pattern for infrastructure: producers emit entity events into a durable, event-sourced log, a live graph is rebuilt from it with full history, and both people and AI assistants query it, the latter through an MCP server⁵.

Because the graph records when facts were true, an agent can ask what the plant looked like before a past failure, not only what it looks like now. And because agents reach the graph only through read-only MCP tools, with no route back into the plant, the worst a misbehaving agent can do is draft a poor recommendation that an engineer rejects. See entity resolution for knowledge graphs and securing MCP servers.

How it ran

Key decisions and trade-offs

What I'd do again, and differently

Again: record why engineers rejected or edited recommendations. Those reasons were the best training material for better tools and prompts. Differently: start the asset model with the reliability engineers on day one; naming and relationships were the slowest part to agree. Related: an energy asset knowledge graph, when agents become the user, the 3 November tech news and the Saudi Arabia page.

If you are bringing AI agents into industrial operations in Saudi Arabia or the wider Gulf, see my knowledge graph work, or analyse your challenge and bring the result to a call.