I have now sat through enough AI-in-engineering presentations to notice a pattern.
The slides are excellent. The vision is compelling. Somebody says “agentic” nine times. And at no point does anyone open a real model, on a real project, and show the thing working.
That is not a criticism of the technology. It is a criticism of how the technology is being presented. When a capability is only ever described and never demonstrated, engineers are right to assume it does not survive contact with a production project. We have all seen tools that worked beautifully on the vendor’s cantilever beam and fell apart on our assembly with 4,000 parts, three material databases, and a load set that changes every two weeks.
So I want to make an argument about where automation actually belongs in an FEA workflow, and then point you at a session where you can judge the claims yourself.
Where your week actually goes
Ask a structural analyst what they spent last week doing and the honest answer is rarely “analysis.”
It is chasing the current CAD version. It is finding out that the loads deck you were given is superseded. It is cleaning geometry that was never built for meshing. It is rebuilding a model you already built, because the configuration changed. It is re-running the same forty load cases you ran in June with one changed thickness. It is exporting results into a spreadsheet that feeds a template that produces a report that somebody will read for eleven minutes.
The solve, the part everyone thinks of as “the analysis,” is often the shortest step in the chain.
I have made this point before in a different context: the value an experienced analyst brings is not speed of execution, it is judgment. Deciding whether shell or solid is the right idealization. Knowing that a stress concentration at that fillet is a meshing artifact and not a finding. Recognizing that a result is converged and still wrong.
None of that is what eats the week. The week is eaten by the connective tissue around the judgment.
That is the honest case for automation in simulation, and it has nothing to do with replacing engineers. It is that a large fraction of a skilled analyst’s time is spent on work that is repeatable, deterministic, and auditable, which is exactly the profile of work a machine should be doing.
The line that matters
Here is the distinction I would ask any vendor to respect, and the one I use to evaluate every one of these tools.
Automate the workflow. Do not automate the judgment.
An agent can reasonably own: fetching the current geometry, applying a standardized cleanup recipe, generating a mesh to a documented set of controls, applying a load case matrix from a controlled source, launching the runs, extracting the quantities of interest, and assembling the results into the report template.
An agent should not own: deciding what to idealize, deciding what failure mode governs, deciding whether a result is credible, or deciding that something is fine.
The reason is not sentiment about the dignity of engineers. It is that the first list is verifiable and the second is not. You can check whether a mesh met its controls. You cannot check whether a modeling assumption was appropriate without exercising the same judgment you were trying to skip.
Any tool that blurs this line is selling you risk. Any tool that respects it is potentially giving you back two days a week.
Three questions for any demo
If you attend a demo of an agentic engineering tool, including the one I am about to recommend, these are the questions worth holding in your head.
1. Whose model is this?
Is it a real production project, or a curated example built to make the tool look good? Real projects have messy geometry, legacy assumptions, and inconvenient constraints. Demo models do not. The difference tells you almost everything about how much the demo is worth.
2. What happens when it is wrong?
Not if. When. Does the workflow surface the failure, or does it silently produce a plausible number? A tool that fails loudly is usable in an engineering organization. A tool that fails quietly is a liability, no matter how good it is on average.
3. Could you defend the output in a design review?
Can you trace every number back to an input, a version, and a decision? If the answer requires someone to say “the system generated it,” you do not have an engineering workflow, you have a black box with good manners.
Why I am pointing you at this one
Synera is running a live product demo on September 17, and the reason I am telling you about it is the format rather than the content.
Every demo in the session uses an actual customer workflow from an actual production project, with the customer’s IP stripped out. Not a purpose-built example. Not a slide about what would be possible in principle. The workflows they show are ones that engineers are running now, on work that ships.
That is the thing that has been missing from this entire conversation, and it is the only format in which the three questions above can actually be answered.
Speakers: Tehsinraza Mulla - Solution Engineer, Synera. Lorenz Flessner - Strategic Partnerships, Synera GmbH. Charles Lambert - Director of A&D, North America, Synera. Daniel Fuchshuber - Solution Engineer, Synera
If the timing does not work for you, register anyway. Registration gets you the recording, and I would rather you watch it late than not at all.
A note on what comes next
On September 29, Synera is running a second session with Aviation Week, this one featuring speakers from NASA and Airbus walking through aerospace use cases. That one is closer to home for most of you, and I will write about it properly in a couple of weeks.
Disclosure: The opinions here are my own. If the demo does not hold up, I will say so.