Over the past weeks, I invited you to a webinar that Synera organized with Aviation Week: “Time to First Article: NASA, Airbus & Agentic AI.” It took place on September 29, with Ryan McClelland of NASA Goddard, Patrick Kunert of Airbus Aerostructures, and Wallace Scott of Synera. This issue closes that chapter. I want to share what I learned, and where I think it touches the daily work of every stress engineer. If you missed the live session, the full recording is available, and you’ll find the link at the end of this article.
Four iterations versus one hundred
Ryan opened with a simple problem. A balloon-borne telescope needed a bracket to hold an optical assembly. NASA requirements, of course: stiff, strong, light. Done the traditional way, two engineers working two days produced four design and simulation iterations, and the part still fell short on performance and manufacturability.
With AI-driven design, one engineer in one hour ran more than 100 iterations and arrived at a part that was lighter, stiffer, stronger, and easier to make. On a sample return mission, a closure part had to be light enough to shut quickly and strong enough to take the impact of the sample. Human designs could not close that gap. The automated loop did.
Impressive numbers. But the most important part of Ryan’s talk came next.
The bottleneck moved
Once his team could produce structures this quickly, the slowest step was no longer design or analysis. It was getting the requirements from the project teams.
So they wrote a checklist. Without fully realizing it at first, they had standardized the inputs to their design process. They then documented how those inputs become the outputs: a manufacturable CAD model and a validation report. With that in hand, two interns turned the whole thing into code in about a week. As Ryan put it, once you have solved something with code, you have solved it forever. The same code now designs different mounts from different inputs, and the inputs can come from an AI agent rather than a person.
Ryan generalized this into what he calls a “Text to X” playbook:
Start from your design and simulation engines (CAD, FEA, topology optimization).
Standardize inputs and outputs.
Document the design process.
Automate the workflow.
Verify it on cases where you already know the answer.
Deploy it so agents can call it.
He then showed multi-agent systems designing a telescope’s optics and mounts, a bipod flexure, and a full CubeSat concept from a single paragraph of text.
Read that playbook again as an analyst. Nothing in it is about AI. It is about knowing your process well enough to write it down. The teams that benefit are the ones that already have discipline.
Airbus: from four to six weeks to one day
Patrick Kunert leads cost and value engineering at Airbus Aerostructures, and he started his career in design and stress. That background showed.
His team did not start with engineering. They started with the call-for-tender process in procurement, to learn the platform and connect their data. Then they moved to design-to-cost. Previously, taking an idea for a cheaper part to an approved change took four to six weeks, mostly communication and back-and-forth. His example was a titanium clip machined from a solid block. The automated workflow loops through costing, stress checks, and design changes, while fixed constraints, such as a minimum factor above one, cannot be touched.
The lead time dropped to one day. But Patrick insisted on a second benefit: the maturity of the decision. Instead of the engineer’s best guess at a better design, the team now chooses among hundreds of analyzed options.
When the remaining day turned out to be mostly meetings, they added a multi-agent system for change evaluation, with agents for data, stress analysis, costing, and tooling checks. The architecture matters: deterministic workflows sit underneath and handle what is known, and agents work on top where optimization is needed.
The analyst’s questions
The Q&A raised the questions I would have asked.
How do you know it works? Ryan’s answer was reassuring in its simplicity. NASA already has processes to catch human mistakes: simulation standards, testing at component, subassembly, and assembly level, and design reviews. The same processes catch agent mistakes.
What about determinism? Give the same problem to ten engineers and you get ten designs. Give it to the same engineer on Wednesday morning and Friday afternoon and you get two. Ryan accepts some non-determinism, as long as the result is validated.
What about fatigue? “If you can simulate it, you can automate it.” The requirement must simply be written in a form a computer can evaluate.
What about certification? Airbus currently automates only the steps upstream of regulated decisions, keeps a human at each critical checkpoint, and works step by step with its regulatory functions. Ryan added that many design rules, such as a minimum edge distance of 1.5 fastener diameters, can be written directly into the code, so compliance is built in rather than checked afterward.
Here is my own reading. “If you can simulate it, you can automate it” is true. The corollary is just as true: if your simulation is wrong, you will automate the error a hundred times an hour. The boundary conditions, the load cases, the material allowables, the failure criteria: these remain the analyst’s responsibility. Automation makes them more important, not less.
Coordination, not computation
Wallace Scott, who started his career as an FEA engineer, told a story many of you will recognize. He once worked on a topology optimization project with one expert for CAD, one for optimization, and one for FEA validation on another continent. The results were promising. The project died anyway, because it was impossible to get the right people in the room at the right time.
That is the real cost these tools attack. Not the solver time, but the handoffs.
At the end of the session, Wallace added a caution. If you optimize each step of a process in isolation, you can end up with a globally suboptimal result. Ryan replied that sometimes you find you do not need an agent at all, only a deterministic script, and AI helps you write it faster. It is the same discipline we apply in FEA: use the simplest model that answers the question.
What this means for you
Ryan’s advice to students applies to all of us: just start. Use the tools on work you already know well, so you can judge the output. Patrick said the same: know your process first, then see where AI changes it.
One remark from Wallace reframed the investment for me. Most engineering tools lose value over time. An agent built around a well-documented process gains value, because the models underneath keep improving. The knowledge you encode today is an appreciating asset.
And Ryan’s closing point on model choice deserves to be underlined. The models change every week. What makes an organization strong is its evaluations: the test cases with known answers that tell you whether a new tool, a new model, or a new workflow can be trusted. That is exactly the kind of verification work good analysts have always done.
Watch the recording
If you registered, the replay link is already in your inbox. If you did not register, you can still watch the full session here:
👉 Watch the recording: Time to First Article, NASA, Airbus & Agentic AI
Seeing the agents work step by step says more than any summary.
My thanks to Ryan, Patrick, Wallace, and Mike McClary of Aviation Week for an honest, practical session.