Section 13

Reference use case 3: Energy pipeline compressor reliability

This reference use case applies the architecture to operational technology: a natural gas transmission operator detecting, diagnosing and fixing compressor problems before they force unplanned outages. It is the case where an agent’s action can reach physical equipment, so it adds the safety architecture from Section 5 to the reference design. As in use cases 1 and 2, the architecture is vendor-neutral except for the transactional platforms named (SAP S/4HANA for maintenance and inventory, Workday for workforce records and Snowflake for sensor history and analytics), and control systems, historians and safety systems are described generically. The pattern carries over to power utilities and to upstream and downstream oil and gas. The final subsection shows how MuleSoft and Informatica realize the design.

Overview

Compressor stations keep gas moving through a transmission pipeline, and an unplanned unit outage forces a choice between running the remaining units harder, cutting interruptible service or, at worst, missing firm deliveries. Most operators already stream vibration, temperature and pressure data into a process historian, but turning an early warning into a planned repair still takes days of manual work across the control room, reliability engineering, maintenance planning, field operations and compliance.

The work also sits under specific rules. Under the US control room management rule, gas controllers need clearly defined authority to act, adequate information, limits on fatigue and managed alarm loads.¹⁰⁵ Operators of critical pipelines must segment operational technology from IT networks, control access and monitor continuously under the Transportation Security Administration’s security directive.¹⁰⁶ Current guidance also holds that people remain responsible for functional safety and that AI should not actively control OT without a human in the loop.⁶⁷ The agentic layer in this use case respects all three. Agents watch, diagnose, plan and prepare, people with authority approve every change that reaches equipment, and the independent safety systems act on their own.

• Trigger: an anomaly on a compression unit (vibration, temperature, pressure or efficiency drift) detected in historian data, or an alarm raised in the control room.
• End state: the unit repaired and returned to service under an approved work order and permit, with flows re-balanced within limits and every decision recorded.
• Users: gas controllers and shift supervisors, reliability engineers, maintenance planners, field technicians and their supervisors, and compliance.
• Out of scope: control logic and safety instrumented systems and their setpoints, which stay under the operator’s process-safety and management-of-change procedures.

Business case and expected outcomes

Illustrative for an operator with 40 compressor stations and about 150 compression units, about 1,200 anomaly events a year and 36 unplanned unit outages a year. Replace with the operator’s baseline.

• Fewer unplanned outages and emergency repairs, and more repairs done in planned windows.
• Controllers who see fewer, better alerts, with the information they need to act.
• Complete, reviewable records for control room management and incident reviews.
• A reusable pattern for bringing AI into operational technology without weakening the safety case.

Key performance indicators

Baselines below are illustrative and should be measured during discovery.

Solution architecture

Figure 19 shows the architecture against the same layers as the reference architecture, with one addition: a safety and OT layer beneath the systems of record, which the agents cannot reach.

Clients and channels

Gas controllers work at the control room console, where agent proposals appear next to the SCADA displays rather than in a separate chat window, and shift supervisors confirm larger changes. Reliability engineers and maintenance planners use an operations copilot. Field supervisors approve permits and work orders on mobile, again with step-up authentication, and compliance staff review records in a case workspace.

Agents and autonomy tiers

Orchestration model selected

The operator runs a dedicated orchestration tier for operations, federated under the enterprise control plane. Operations data and agents stay in the operator’s own environment, close to the historian and control systems, while identity, policy, registry, audit and cost remain centrally governed. Orchestration is event-driven (historian anomalies, alarms and work-order events), with a supervisor pattern over A2A²⁷ and deterministic workflows for anything that touches equipment. A setpoint request always needs a controller’s approval, larger changes also need a supervisor’s confirmation, and no workflow can skip either step.

Models and routing

• Anomaly models: conventional machine learning on vibration, temperature and pressure time series, trained on Snowflake history and monitored for drift under the operator’s model risk procedures. They are not LLMs.
• Hydraulic model: the operator’s existing pipeline simulation, which checks every proposed load shift against pressure, line-pack and delivery limits. Its answer is deterministic, and it has the final word over any language model.
• Fine-tuned small language model: self-hosted, it reads alarm text, maintenance history and work-order notes and drafts notifications and permits.
• Frontier model: on a private endpoint with zero data retention, it summarizes diagnostics and manufacturer guidance for engineers. Nothing it produces reaches equipment without passing the hydraulic check and a controller’s approval.
• Routing policy: operations and asset data stay on private models unless masked. Each step has a latency budget, and any advice based on data that has since gone stale is discarded.

Control plane and policy

The control plane components match use cases 1 and 2, with approval binding, cumulative limits and safe defaults added to the policy set:

• Agents may propose setpoint changes but never execute them. A request executes only if a controller approved that exact change, the approval is less than ten minutes old by the gateway’s clock, and changes above a threshold carry a shift supervisor’s confirmation as a separate attester.
• Total flow re-allocation across stations is capped per hour and per shift, across agents and sessions, so many small approved changes cannot add up to a move the hydraulic model has not checked.
• If a station’s historian feed is more than 60 seconds old, the Flow & Load Advisor drops to advice-only, pending requests are voided and the controller is told why.
• No agent tool can read or write safety logic, bypass an interlock or acknowledge a safety alarm, and no agent traffic reaches the safety network.
• Agent notifications to a controller stay within the operator’s alarm-management limits, and any beyond those limits wait in the queue.

MCP servers, APIs and systems of record

Historian and SCADA data reach agents through a read-only replica in the industrial DMZ. The only write path into operations is a setpoint-request service in the DMZ, and the control system accepts a request only after the controller approves it at the console, still enforcing its own engineering limits. On the business side, SAP S/4HANA holds maintenance notifications, work orders, bills of materials and inventory, and Workday holds workforce records. The qualification and permit-to-work systems supply certifications and permits, GIS and the asset registry locate equipment, and Snowflake keeps sensor history and model features. MCP tools give agents narrowly scoped read tools and a small set of gated write tools.

Asset data and semantics

Equipment data helps an agent only when it is tied to the right asset, so master data is on the critical path here too:

• Asset master: one record per station, unit and major component, with the functional locations and equipment hierarchy shared by SAP S/4HANA, GIS and the historian.
• Tag master: every historian tag mapped to its asset, unit of measure and normal operating range, so an anomaly on a tag is an anomaly on a known machine.
• Limits and setpoints: engineering limits with their management-of-change history, which agents can read but never change.
• Workforce and qualifications: Workday remains the system of record for people, and qualification records say who may perform which covered task.

A shared glossary gives agents, engineers and reports one meaning for terms such as unit, station, trip, outage and line pack, and lineage shows which tags and records drove each diagnosis and proposal.

Security at every level

The same zero-trust baseline applies as in use cases 1 and 2,⁹⁰ with controls specific to operational technology that follow the ISA/IEC 62443 zone-and-conduit model and NIST’s guide to OT security:^68,69

Governance and observability

Operations owns the autonomy tiers, limits and alert budget, while process safety owns the safety layer and every engineering limit. Model risk validates the anomaly models and the language models, and the control room management program covers the new displays, alarms and training.¹⁰⁵ Dashboards show events by station and cause, alert load per controller, approvals executed within their validity window, safe-default events, policy blocks and model drift, all built from OpenTelemetry traces⁹⁴ tied to an event ID.

Elena’s day in the control room

Elena Morales is a senior gas controller on the day shift. The timeline follows an illustrative day (Figure 20).

At 05:40 the condition-monitoring agent flags Unit 2 at Station 14: vibration and bearing temperature have been rising for three days, and the anomaly score has crossed its threshold. By 06:00 the diagnostics agent has matched the pattern to two earlier thrust-bearing failures on the same model of unit and recommends an inspection within 24 hours at reduced load. At 06:10 the flow advisor proposes cutting Unit 2 to 70% and picking up the flow at Stations 13 and 15, and the hydraulic model shows deliveries and pressures stay within limits. Elena reviews the proposal next to her SCADA displays and approves it. Because the change is below the threshold for a supervisor’s confirmation, it executes within its ten-minute window.

At 07:30 the planning agent has created the notification and drafted a work order in SAP S/4HANA with the bearing kit reserved at the regional warehouse, and the planner releases it at 08:15. At 10:20 a second adjustment waits too long in the queue while Elena handles a shipper’s call. When it reaches the gateway its approval has expired, so the gateway refuses it and the advisor asks again with fresh values. At 11:05 the data feed from Station 15 falls more than a minute behind, so the advisor drops to advice-only until the feed recovers nine minutes later, voiding a pending request and telling Elena why. At 13:20 a gas detector at Station 9 trips the station’s emergency shutdown. The safety system acts on its own, and the agents pause requests for that segment while the advisor offers a re-balancing plan as advice and the records agent opens the event record. At 14:00 two technicians whose qualifications the crew agent has confirmed start the repair under an isolation permit their supervisor approved on mobile. At 18:30 Unit 2 returns to service, Elena approves the return to full load, and the records agent compiles the day’s event record for review.

How the components work together

Figure 21 traces the day through the architecture, and the table explains what each component did and which controls applied.

Realizing the use case with MuleSoft and Informatica

As in use cases 1 and 2, MuleSoft Agent Fabric provides the control plane and the governed paths into the operator’s systems, and Informatica provides the data foundation, while the operator keeps its control systems, historian, safety systems, models and agent frameworks (Figure 22). The OT safeguards come from custom Omni Gateway policies (Section 7).

MuleSoft governs the agents and the paths they use and Informatica governs the data they act on, as in use cases 1 and 2. What differs this time is the boundary, since the control plane stops at the industrial DMZ, the only write path into operations runs through a controller’s bound approval, and the safety systems stay outside the agents’ reach. Confirm Runtime Fabric deployment in the DMZ and connector coverage for the historian and permit systems during planning. The custom policies are built and supported by the operator or its partner, not by MuleSoft.

Delivering in phases, with equipment last

Delivery follows the same four phases, except that nothing an agent does reaches equipment until phase 3, and even then only as a proposal that a controller approves.

Values are illustrative and before platform, model and change costs. Firm service protected, often the largest lever, is operator-specific and not included. The last step, letting agents propose changes to equipment, waits for bound approvals, cumulative limits and drills in phase 3, and the earlier phases release value through earlier detection and less manual planning.