The summit in numbers
The programme listed 45 speakers across roughly 36 sessions. Only three sessions had the word "agent" in the title and one more had "GenAI". Predictive maintenance, anomaly detection and condition monitoring sessions outnumbered those more than two to one, and data foundations and workforce topics each had four to five sessions of their own. The hallway conversations skewed even harder toward data and people.
You have enough data, turn it into decisions
Lee McFarlane of AVT Reliability opened his lightning talk by asking the room how many plants have more data today than ever before. Every hand went up. He then asked who had reached world-class reliability because of it. The hands came down.
His summary: the industry has solved the problem of gathering data and has not solved turning data into decisions.
The operators on stage agreed, and most of them put a timeline on it.
- National Grid's Pradheep Kileti rated his own organisation's data maturity as "Foundational", the lowest of four levels, and said plainly: "We cannot predict what we cannot identify, observe, connect and trust."
- SoCalGas spent 2022 to 2025 ingesting asset data, assigning named data owners and building a governed data lake before putting a single GenAI tool on top of it.
- Energy Transfer started with 250 assets that already had good data, then had to connect 3,000 more through its historian, then acquire data on 2,000 legacy assets that had none.
The cost sits in context, not storage.
- Jonathan Alexander of Albemarle said configuring the context for one unit operation used to take 40 to 80 hours of engineering time and that his team has brought it to about 4 hours in the last six months.
- Covestro's Bharat Marwaha described the same work at fleet scale: standardising sensor tags across historians in North America, Europe and Asia so a heat-transfer coefficient means the same thing in Baytown as in a European plant.
In the hallways, the version of this problem was more basic.
- A European oil major's team told us their biggest issue is field staff not entering data at all.
- A pipeline operator's data lead is fighting internal pushback over who may touch what in the bronze layer of his lake.
- Nobody we spoke to asked for more sensors.
What we would do: treat context as the deliverable of the first phase, not the model. In our work on data platforms for industrial clients, the step that moves a project is a maintained asset hierarchy with failure modes and work history linked to the tags, because that is what every later model, dashboard and agent reads from. Publish data quality scores instead of blocking data; it turns gatekeeping into transparency and takes the heat out of the bronze-layer argument.
The alert is not the problem. Trusting the alerts and hands off are.
AssetWatch's Don Ryan and Nick Braeuner put it in five words: "It isn't the data. It's the handoff."
Their argument was that sensors and alerts are already deployed almost everywhere, and the programmes that deliver are the ones that fix what happens after the alert: a named owner, a response clock, a work order in the CMMS, and the avoided cost recorded on every closed order. Their line for the executive audience: "If it isn't a work order, it isn't work. It's a suggestion."
McFarlane's version was blunter. If work management is weak, technology produces more alerts. If planning is weak, it creates more backlog. If accountability is weak, it creates more reports. He described a plant that installed wireless sensors, AI diagnostics and a cloud platform and, twelve months later, had multiple software systems, thousands of alerts, a growing backlog and little reduction in downtime. The technology worked exactly as designed. The organisation was not ready.
Covestro offered a concrete version of the same failure: an asset went down unexpectedly even though the monitoring had flagged it, and the team had to go back and work out why nobody reacted to the alert.
The most honest line of the two days came from a reliability engineer at an exploration and production company, who told us: "We tried predictive maintenance in production. It didn't work. Don't try." We are sitting down with him later this month to understand what went wrong. Our bet, based on everything else said on stage, is that it was not the model.
What we would do: before any model work, write down who owns the alert queue, what the response clock is, and how a finding becomes a work order. We now ask for this in the first week of any predictive maintenance engagement, because without it the best model in the world produces a better-looking email thread. AssetWatch's five KPIs are a good starting set: mean time to first comment, mean time to resolution, alert effectiveness, validated dollars saved, and adoption.
Fewer engineers, more sites, and the knowledge is walking out the door
Amber Randon, Reliability Director at Dow, described a reliability team that went from 13 engineers to 2, covering 35 sites. Her method is "keep it simple", and her ask of any technology is that it puts the engineers inside the conversation rather than handing them another tool. She is always either in a turnaround or planning one; the next started on October 1 and the one after is already being planned. Supply chain makes it worse: a valve that used to be "drive to Houston, new pump in the ground by 10pm" now has a 16-week lead time.
Williams has 57,000 assets and reduced its rotating equipment budget by 50%, which forced the question of which assets even get monitored.
SLB's session put the average age of its workforce at 55.2 years.
National Grid talked about an engineer named Henry with 61 years of service who knows what their data systems have done, and asked the question nobody has a good answer to: how do you capture what Henry knows without making Henry feel replaced?
CPS Energy's Jonathan Tijerina gave the frontline view. His staff have been retrained four or five times in 30 years, from carbon copies to tablets to automation. His response has been to start at the top: every executive did a two-day AI course with Rice University and built a first bot, and the next step is a cohort of 100 people before the whole organisation. Freddie Wright of Georgia Power said his first data engineering hires should have been paired with subject matter experts from day one, and that he is now considering AI training for his own team after hearing CPS.
What we would do: two things that worked for the companies on stage. First, pair every data person with a field expert, as a staffing rule rather than a good intention; it is how we staff our own industrial projects and it is the single thing Wright said he would change. Second, treat training as the first deliverable rather than the last. The hands-on format where a team builds a working tool on day one is what got CPS Energy's executives to sponsor the 100-person rollout.
One asset class, prove it, then waves
Nobody on stage described a plant-wide rollout that worked on the first attempt.
Energy Transfer's roadmap, shown as their forward-looking slide, runs pilots by asset class: reciprocating engines and compressors going live on October 1, 2026, gas turbines on January 1, 2027, electric motors on April 1, 2027, each followed by a benefits validation gate before expanding to more units and sites, and enterprise rollout in 2028 to 2029.
AssetWatch's playbook starts with 15 to 20 critical assets, writes the thresholds, work order templates and KPI baselines into a playbook, then rolls out in waves. Patterson-UTI packages every change as a versioned container, pilots it on a controlled rig group, then pushes it over the air to more than 100 rigs through the same release process.
Brad Apking of Methanex and Bemi Anjous of Noble made the opposite point about commitment: pick specific assets for the proof of concept and keep implementations to months, but once you commit, go all in. Half-measures are where people get frustrated and leave.
The question we heard most often in the hallway, usually from engineers at chemical and refining sites, was some version of: do you do this for the whole plant or just one asset?
Our answer is always one asset class first. A plant-wide start stalls on data, ownership and budget at the same time.
What we would do: scope the first engagement to one asset class and one site, with a written benefits-validation gate before anything expands. For a global chemicals producer we started with a small number of asset types and used the first site's results to decide what the other 70-plus sites would monitor first. The second site is where you find out whether the context model travels; the first site only tells you whether the model works.
Vendor skepticism is the default setting
Energy Transfer's Mike Martin and Tyler Fedun summarised a year of evaluating machine learning vendors in a single slide titled "Messy". Their notes, close to verbatim: lots of two-year-old vendors with 20-plus years of experience; vaporware is relevant; very few vendors actually did it; few could handle our data; so much sounds too good to be true, trust your gut. They ran three vendors against the same real crude pump failure and picked the one that flagged it about five months ahead.
Another session that had built its own remaining-useful-life models closed with a warning to the room to check incorporation dates, and a specific aside about prototypes from "Eastern European Silicon Valley" that look polished and have never run in production. We are a Polish company that builds software, data, and AI/ML solutions for this industry, so we took note.
The point stands: the room has been burned, and a demo that has not been through a plant's IT, security and operations in production is only a disappointment waiting to happen, not an asset. Always verify that vendors have deployed what they show you in production in the past.
The flip side came from the buyers' own mouths.
- A reliability leader at an industrial gas company told us most off-the-shelf tools are not built for how his business works and he does not have time to adapt them.
- A digital operations lead at a renewables operator said something we have thought about since: bringing in a vendor forces people across the company to align, and sometimes they solve the problem themselves while preparing their answers for the vendor.
- Noble's session added the architectural version: you can build agents and models on top of a platform like IFS instead of being locked into it.
What we would do: lead with what has run in production and with the people who ran it. We only showed a prototype to four people in Houston, and in each case we said what it was built from (patterns from several delivered projects) and what it was not (a product).
The conversations that turned into meetings were the ones where we offered to walk a team through a delivered rollout, site by site, not the ones where we showed a screen. If you are evaluating a vendor, Energy Transfer's method is the right one: give everyone the same failure and see who finds it.
Operations and IT are not in the same room
This one never made a slide title, but it was in almost every hallway conversation.
- At one supermajor, a rotating equipment team built a copilot to train and coach its own engineers; when they handed it to IT for deployment, IT declined because of how it was coded.
- At the same company, a reliability systems lead described IT heading in a direction nobody in operations understands, while her team lacks the capability to build what it needs itself.
- At a chemicals site, the reliability engineer's frustration was that the technology team does not talk to the people on the ground.
- At a renewables operator, the digital lead asked whether we could come in for a few weeks as the external voice that tells IT and OT an approach is right, because the two have been at odds.
- A delivery and integration lead at a supermajor gave us the buyer's framing at a discussion table: they usually build with vendors, but the internal team has to own it afterwards, and most vendor engagements are not designed for that handover.
What we would do: put the two sides in one room before writing any code. A half-day where operations and IT draw the current and target architecture together, and leave with one diagram both sign and a short list of tools the operations team may build inside IT's guardrails, resolves more than months of tickets.
For the engineer-built copilot case, the fix is not a rewrite; it is bringing the tool up to the standard IT needs (code, tests, security, hosting) without losing what made it useful. We do this often enough that we think of it as a service in its own right.
Agents are on every roadmap and almost no plant floor
Every operator roadmap we saw ended in the same box.
SoCalGas has "Digital Assistants: Agentic AI" scheduled for Q2 to Q4 2026, after four years of data work, with the rule written on the slide: "Agents prepare knowledge and check data. People retain approval." Energy Transfer's model evolution runs from a self-organising map, to one model per data type, to asset-specific physics formulas, to "Agentic AI" as the last step.
National Grid lists generative assistance as one of four AI use types, "applied only where it improves evidence, efficiency and productivity". Heather Benoit of Cenovus described AI organising and comparing root-cause evidence across 76 pump repairs, with an explicit engineering guardrail: engineers approve the causal conclusions, risk rankings and field actions.
The only live autonomous agent described by an operator was Patterson-UTI's GenAssist, a reinforcement learning agent that controls generator start and stop decisions on drilling rigs; they claim it can avoid over $100K in annual fuel costs per rig and cut ignored alerts by 80%. Everything else was a vendor's agent (Honeywell, IFS Loops, SAP) or a plan.
Two hallway signals worth passing on.
- First, when we asked about back-office work, the response was warmer than for asset-side agents: change order requests caused by purchase order changes at Dow, finance and procurement during an SAP migration at a utility, and the "five engineers give three answers each" problem all came up as places an agent could sit today.
- Second, a surprising number of technical people asked about local and open-weight models for data privacy reasons, without using the words "sovereign" or "on-prem". Nobody on the business side knew what they meant.
Five operators put agents on a roadmap or behind an engineer's approval; one has an autonomous agent running, and it controls generators, not maintenance decisions.
What we would do: put agents where the data is already trustworthy and the approval is cheap, which in most plants means the back office before the asset. A procurement change-order agent or a system that gives five engineers one shared answer can run on data you already govern; a maintenance recommendation agent cannot until lessons 1 and 2 are done. And if your IT team is asking about open-weight models, that is the conversation to have with them first, because it decides where everything else can run.
Value is validated, not estimated
The sessions that showed money showed it as sign-offs, not projections.
AssetWatch's rule is that every closed work order records the avoided cost, signed off with operations and finance, "not estimated by a vendor"; their anonymised examples were a $150K bearing save validated with the customer and $2,120,352 in avoided cost at an agricultural export terminal.
OPPD's recloser programme spent about $2.025M on 27 reclosers since 2018 and reported about $5.67M in operations savings and 28 million customer minutes interrupted avoided. Patterson-UTI benchmarked connection times in seconds before and after each change.
National Grid gave the test we now use: "Prediction creates value only when it changes the timing, scope or priority of work." Williams brought 11 dashboards and data sources into one operational view and is using unit history and telemetry to set major maintenance intervals rather than the calendar.
Noble built a remaining-useful-life model for $200K and asked the uncomfortable question on stage: do we actually need it, or is condition monitoring enough, and what does it cost to maintain versus to build?
The hallway counterpoint came from an asset manager at a pipeline operator, who said the hardest part is quantifying financial impact at all when capital and O&M are planned in separate models. He wants a total-expenditure view per asset, and the tools he uses for investment planning cannot give it to him without condition data they do not have.
What we would do: agree the value calculation in week one, in the numbers the client's finance team already tracks, and build the benefits-validation gate into the roadmap before the pilot starts. Year-one ROI as measured savings over year-one spend is simple enough that nobody argues with it later.
-----------------------------------------------
If any of this maps to a decision you are working through, whether that is a stalled pilot, a second site that will not take the first site's model, or an IT team and an operations team that cannot agree on a diagram, we are happy to talk it through. Our predictive maintenance and data platform teams are the people who were in Houston, and the field notes brief has the questions we would ask first.
