Across the Energy sector, the noise around AI is getting louder by the month. No doubt you will have heard or seen vendor announcements and conference keynotes that promise ‘AI-first engineering’, self‑optimizing assets, and fully automated plants.

The reality though, is that inside projects things are more grounded: we are already seeing practical, explainable machine intelligence embedded into design tools, documentation flows, and plant workflows – but always with engineering  judgment in the loop.

This balance of human and machine capabilities is what we call Embracing Intelligence, and it’s what makes a material difference in Energy and Plant Engineering. Let’s be clear: this is not a slogan about AI, it is an operating system and mindset that helps decide where human and domain intelligence remain central, and where machine intelligence can safely take over. 

What Embracing Intelligence Means in Energy and Plant Engineering

In our Energy business at Cyient, most of our work falls into two broad streams: engineering for OEMs, and multi-discipline engineering and design for power plants (including nuclear), processing plants, operators in the Oil & Gas sector and those involved in energy transition.

These may look like two different businesses. But, in fact, they are shaped by the same engineering fundamentals: safety, reliability, compliance, and the need to balance performance, cost, and time. The same is true of the people we work with – whether they sit in an OEM unit or a utility, industrial or power plant operation – they are typically engineers first regardless of job title.

When customers ask about ‘intelligence’, their questions are invariably practical ones: “How do we compress time to market or modification without compromising safety or quality?”, “How do we make better use of our own tools, data and environments, rather than forcing us into a parallel universe?”, and, “How do we adapt delivery models as automation and machine intelligence start to change what is possible in engineering workflows?”.

Embracing Intelligence is a way of answering these types of questions honestly, with engineering consequences in mind. 

Intelligence in Layers: Human > Domain > Machine

One of the phrases that often surfaces in conversations is ‘artificial intelligence’. I have always found that term uncomfortable in an engineering context. Calling something both ‘artificial’ and ‘intelligent’ is something of an oxymoron. Perhaps a more accurate and useful description in our world is ‘machine intelligence’.

My belief is that in Energy and Plant Engineering, ‘intelligence’ is never just one thing. It starts with human intelligence: the  judgment of engineers who understand loads, failure modes, process dynamics, safety margins and trade‑offs under uncertainty. Around this is an important, deep layer of domain intelligence: how a particular asset class, plant type, or operating environment behaves over time, and how regulators, operators and standards bodies respond to risk. Machine intelligence then augments these: tools that process large volumes of data, automate repeatable work, and surface patterns that humans might otherwise miss.

When this ‘order’ is respected, machine intelligence can be seen as a force‑multiplier, not a threat. It allows us to cover more ground, test more options and monitor more signals than would ever be practical by hand, while still respecting the physics, safety margins and regulatory expectations that define this sector.

So, when it comes to Embracing Intelligence in a delivery organization, the practical question is: “Where in our value streams can machine intelligence safely absorb repeatable work, so that human and domain intelligence can focus on the problems where  judgment really matters?”. 

Compression Without Compromise: Where Machine Intelligence Comes First

A useful way to think about this is to look at the product and plant lifecycle. At concept stage, engineering work is still heavily driven by intent and experience. Deciding how a new component should behave under combined loads, or how a process should respond to different operating conditions, is not something we should outsource to a black‑box model. Here, intelligence must remain primarily human and domain‑led, with tools acting as instruments.

Further along the lifecycle, things change. Translating intent into detailed 3D models, generating families of drawings, and carrying out standard checks, validations and documentation steps are all areas where automation and machine intelligence can make an immediate difference. These are precisely the areas where the major engineering software providers are embedding new capabilities, and where we are already seeing reductions in manual effort and turnaround time on real  programs.

We see something similar in plant and asset environments. Customers are no longer satisfied with “scan this archive”. They are asking us to make hundreds of thousands of legacy engineering documents searchable, structured and usable at scale - extracting structured engineering information and integrating it into existing PDM and PLM systems so it can support decisions.

Once that level of intelligence is proven in one part of the workflow, expectations are raised everywhere. From a delivery standpoint, this is how intelligence pushes us to keep looking for similar compression‑without‑compromise opportunities across the lifecycle. 

The Human Side of Embracing Intelligence: Freeing Engineers for Cognitive Work

The difficult part is not spotting where machine intelligence could help – most experienced engineers can look at a workflow and identify the obvious opportunities. The more sensitive consideration of Embracing Intelligence is understanding human impact. If you have spent 10+ years in a particular area of engineering and are told that a tool can now do part of that work in minutes, it is natural to feel defensive.

This is why, over the last five years, we have invested in embedding digital and AI awareness in our Energy delivery teams, reassuring engineers that our aim is not to remove capacity for its own sake, but to free engineering bandwidth so that people can spend more time on the cognitive and  judgment ‑heavy parts of the work.

In  program where we have combined automation with clear communication, we have seen people move from scepticism to advocacy because they experience the shift in their own work.

Embracing Intelligence, is about listening, and helping people see that machine intelligence can move their contribution up the value chain rather than erode it. Culture does not change on demand; it changes through repeated proof, conversation and leadership signals. 

The Hard Constraints: Tools, Customer Environments and Decision‑Making

In theory it might be easy to sketch out an ‘intelligent’ delivery model. But, in practice there are three constraints, that I – as a delivery leader – must be conscious of.

The first is the tool environment: our engineers work inside ecosystems from vendors such as Hexagon, Ansys and Siemens. Some are open – allowing scripts, plug‑ins or connectors; others are more rigid. Where platforms are open, we can embed intelligence more quickly. Where they are not, change often depends on how quickly the wider tool landscape evolves.

The second constraint is that we often work directly inside the customer’s environment, where access may be governed through secure or virtualised desktops and tightly controlled cyber policies. Any change to the way we work must respect those controls. But that does not mean intelligent delivery stops there. It means we must design automation and machine intelligence so that it fits within the customer’s environment, rather than assuming the environment will fit around us.

The third constraint is decision‑making: even when a better way of working is clear, it must still move through reviews, risk assessments and budget cycles, which can slow things down. But this also means that once a new approach is approved, it is more likely to be adopted properly and stick.

These realities do not remove the need to embrace intelligence. They highlight that in Energy and Plant Engineering change happens step‑by‑step, within constraints, designed for the environments it has to ‘live in’ – not just for lab or prototype scenarios.

Embracing Intelligence as a Delivery Operating Mindset 

When we first introduced Embracing Intelligence as a way of working at Cyient, I was keen to test what it meant in Energy delivery, not in general terms but against our day‑to‑day work.

This started with an honest appraisal of ‘as is’ and ‘to be’ states. We asked ourselves, “Where are we already behaving intelligently in ways we can scale? Where are our habits, tools or ways of working out of step with what we say we believe?”.

That exercise did two useful things: firstly, it translated Embracing Intelligence into a checklist for delivery, ensuring that if we claim to be Embracing Intelligence in a particular area, we must be able to point to specific workflows, tools and  behavior that have changed.

And, secondly, it highlighted the importance of having a positive ‘say:do’ ratio. In engineering‑led sectors, the fastest way to lose credibility is to say things that your delivery teams do not recognise as true.

Over time, this has led to us to treat Embracing Intelligence in Energy and Plant Engineering as a delivery operating mindset with a few simple principles:

1. Engineering first – human and domain intelligence define the problem and the safety boundaries.
2. Augmented with machine intelligence – where it compresses repeatable work and reduces error, without diluting accountability.
3. Evidence over assertion – if we cannot demonstrate a more intelligent way of working in each area, must not pretend we can.

Respect for constraints – we design change that fits within customer tools, environments and governance, not in a vacuum.  

A Practical Invitation to Delivery Leaders

From my perspective, Energy and Plant Engineering does not need another broad statement about AI. It needs to consider a more precise question, which is, “Where in your delivery model does it make sense to keep engineering effort exactly as it is, and where should machine intelligence now take over?”.

Answering this requires a clear view of workflows, a willingness to engage with culture, and a realistic understanding of the environments in which delivery actually happens.

Embracing Intelligence is not about handing control to machines, and it is not about resisting them either. It is about using machine intelligence in its proper place, so that engineers can apply more of their time and skill where it matters most.

For my teams in Energy and Plant Engineering, this is the standard we hold ourselves to: engineering‑first, machine intelligence in its proper place, and an approach that our customers – and our own engineers – can trust.