ABCs of AI in engineering automation

July 6, 2026

Every week brings new reports on how AI is transforming the engineering profession. Large language models (LLMs), generative design, Machine Learning and 3D ROMs, Physics-Informed Neural Networks (PINNs) – the terminology is expanding faster than most engineering teams can keep up with. And unlike the hype cycles of the past, this one directly impacts the fields of simulation and engineering process automation as well. This is also happening thanks to partnerships between tech giants such as NVIDIA and leaders in the engineering industry, including Siemens, Dassault Systems and Cadence.

When discussing AI in engineering, it is important to specify the area of application or, more precisely, the specific type of AI in question. It is safe to say that there are four main types currently being adopted and used in engineering:

• Generative AI
  Large language models (LLMs) that produce text, code, or structured content from a prompt. In engineering, this is the layer that writes first drafts of technical reports and documentation, generates scripts, summarizes test results, or answers relatively easy questions. It works with language – not numbers or physics.
  Comment: It can earn its place anywhere a skilled engineer currently spends time writing rather than thinking. It doesn't belong anywhere the output needs to be numerically correct or physically consistent due to LLM’s nondeterministic nature. A well-written wrong answer is still wrong, and LLMs have no reliable way to tell the difference.
• Predictive AI
  Machine learning models trained on simulation or test data to approximate the input-output behavior of an expensive process – typically a high-fidelity solver. Once trained, a surrogate model gives results in orders of magnitude faster than the original simulation, making it practical to run thousands of evaluations in an optimization loop or uncertainty analysis that would otherwise be computationally prohibitive.
  Comment: This is the type of AI that has been quietly running in serious engineering tools for over a decade. You may know it as response surface modeling (RSM), metamodeling, or reduced-order modeling (ROM) rather than “AI”. The engineering discipline around it is mature: you need enough training data, you need to validate the surrogate's accuracy, and you need to know where it breaks down. It's deterministic, explainable, and integrates naturally into existing PIDO workflows. pSeven offered first class solutions in this area since day one.
• Physics-Informed AI
  Neural networks trained not just on data, but with physical governing equations. The model is penalized during training if its predictions violate known physics, which means it generalizes better to conditions outside the training set and produces outputs that are at least physically feasible, not just statistically likely.
  Comment: The promise is significant with a PINN or neural operator that can potentially replace or accelerate a CFD or FEA solver at a fraction of the computational cost, while respecting the physics the solver was built to solve. It must be acknowledged that this field is still maturing: training is sensitive, generalization to complex geometries is hard, and industrial-grade validation frameworks are still being developed. It's the most technically ambitious of the four types, and the one most engineers should watch closely rather than deploy today.
• Agentic AI
  LLM-based systems that don't just respond to a prompt but act autonomously across multiple steps - launching simulations, reading results, adjusting parameters, calling external tools, and iterating toward a goal without a human directing each move. The LLM acts as the reasoning core, while tools, APIs, and software interfaces are its hands.
  Comment: This is where the other three types converge. An agentic system might use generative AI to write a report, predictive AI to explore a design space, and a physics-informed AI to validate a candidate – all within a single orchestrated workflow. The engineering implications are real: tasks that today require an experienced engineer to manually coordinate across five software packages could run overnight unattended. The prerequisite is that your workflows are formalized, your guardrails are explicit, and your sign-off points are defined before you hand the keys to an agent.

The four types of AI listed above represent merely building blocks. None of them is capable of independently managing an industrial engineering process. Generative AI writes; predictive AI estimates; physics-informed AI generalizes; agentic AI acts. However, every engineering task – such as calling a solver, reading a PLM record, scheduling an HPC task or recording a result that will ultimately be signed off – takes place within a fixed corporate context. This context includes specific CAD projects and data storage rules, CAE setups, access rules and audit requirements. Without a layer to manage this context, even a well-designed agent will quickly become a demo version that cannot survive in a real production environment.

This layer is essentially a managed execution layer for engineering AI operations. It sits between the AI side (any LLM, any agent framework) and the engineering side (CAD, CAE, HPC, PLM, in-house codes). It handles the things AI agents do not carry on their own - versioning, access control, audit log, reproducibility, sign-off points. pSeven Enterprise platform is an example of such a layer, combining a workflow engine, a runtime and governance, all of which are built around engineering process automation rather than AI itself.

In order to continue, it is necessary to define some of the terms that come hand in hand with AI in engineering automation. After reading the list below, you should probably understand the meaning of the following sentence: “The orchestration layer passes the surrogate model's output as context to the LLM with RAG, which drafts a design recommendation – but a human sign-off is required before the agent triggers the next simulation task via MCP.”

Frequently used terms

• Token – The smallest chunk an LLM works with. It’s 3-4 characters, or about ¾ of a word on average. Models don't read sentences; they read token sequences. Everything from input, output and context, is measured and priced in tokens. In other words, tokens act as AI currency.
  Comment: LLMs have a maximum context window measured in tokens. Feed in too much, for example, a massive simulation report, and older content gets dropped. Knowing this helps you structure inputs sensibly. Also, the token economy is real. The more you generate with LLM-based systems – the more you pay, unless you use a local (and thus free) LLM.
• Context – Everything the LLM can “see” at the moment it generates a response – your prompt, the conversation history, any documents or tool results fed in, and the system instructions set by the application. LLMs have no memory outside of this window; once something scrolls out of context, it's “forgotten”.
  Comment: The analogy is a RAM limit. Context is fast and immediately usable, but finite. A 200k-token context window sounds large until you try to load a full CFD results file or a long simulation log. Determining what should and should not go into context is one of the key skills required when building reliable workflows using AI.
• RAG (Retrieval-Augmented Generation) – A way of making an LLM answer questions using your own documents or data, rather than relying purely on what it learned during training. Before generating a response, the system retrieves the most relevant chunks from your knowledge base and feeds them into the prompt as context.
  Comment: RAG is a form of grounding to avoid hallucinations. Imagine asking “what were the boundary conditions for the wing optimization last month?”. In this scenario, RAG lets an LLM answer that from your internal simulation reports, not from general training data. It doesn't require retraining the model itself.