In June 2026, Bloomberg broke the news that Ford has been rehiring “gray beards” for the past three years to fix quality problems its automated systems could not. A surge of headlines followed, bluntly stating that AI failed. Much of the news coverage emphasized how the company leaned too heavily on automation and positioned the technology as the source of failure.
However, as with many AI implementation projects, the challenge had less to do with the technology and more to do with clearly identifying the use case and business value, evaluating data and process readiness, and applying a solution to match the objective and capabilities.
Design World recently interviewed Ram Seetharaman, head of AI at Synera, to better understand this challenge and share knowledge with all of you. This latest episode of The Control Room includes that conversation to provide insight and help engineering teams make more informed decisions.
Watch or listen to the following video or read the transcript below (edited for clarity and length).
Design World: Ram, if you don’t mind, introduce yourself and give us a quick background on you.
Ram Seetharaman: Yeah, absolutely. My name is Ram. I’m the head of AI at Synera, so I lead our AI strategy in terms of what comes in the product, what kind of problems we solve with AI, and also how AI is deployed at our customers. So, I own the loop around: what problem do we solve, how do we solve it, how does the deployment affect the next engineering iteration?
I have a background in computational mechanics. I have also been a hardware engineer. I worked in Formula teams; I worked in the eVTOL industry. I was always trying to be a hardware engineer, but the world of simulation and AI really caught my eye seven years back, ever since I was a student, and ever since then I have worked at the intersection of AI and engineering. Started with physics-informed learning and then went on to more industrial applications. Right now I lead our agentic product, primarily in the sense of what do we know, what is the impact, what kind of metrics do we want to track, and so on. I also work closely with every other senior leader in Synera in shaping up the product and the strategy.
DW: I have a couple of questions related to the Ford stories and some questions that tie in that IMS Gear case study. The story goes: Ford brought back their 350 veteran engineers because they lost their tribal knowledge that never made it into the AI system. Of course, the headlines shouted that AI failed, but that’s not really the case, is it? What did you see as the primary issues, or potentially major causes, that could have led up to that decision, where they had to bring back human experts because their AI system wasn’t doing what they wanted it to do?
RS: When we look at this technology from outside, it’s very easy to assume the success in one domain carries over to another domain. One way these models are created is: right now, all these frontier companies use the model to make the model. So that means there is a high tendency that more and more of software engineering is the primary use case. And while that also falls under the umbrella of engineering, it’s very easy to look at it and say, “Okay, coding is definitely getting disrupted; that means essentially other domains of engineering should also get disrupted.” But the key technical fact is that these models, these open or public LLMs, have been trained on a lot of software engineering data that was available in public. Probably there is no central repository for companies in the industrial engineering space, even to themselves. Therefore, I think the first bias happens when looking at one domain versus others.
Engineering is pretty unique compared to software engineering because a huge portion of the data is not text-based. It’s usually in the 3D world; it’s in the geometry world, which the current LLMs are not yet capable of fully perceiving. There are a lot of efforts in this direction.
So I think the first major way I see it is, like you mentioned, the technology really didn’t fail. It was as it was supposed to. The understanding of the application domain and the way it was applied probably was a mismatch. So it really depends on what kind of use case or problem you pick, and how you want to apply these technologies to it.
DW: What you said is kind of a response for any engineering problem. Anytime I ask an engineer, “Why did you choose that solution, or why did you choose that component?” it’s about problem-solution fit. But maybe we’re in this brand new, exciting world of AI with endless possibilities, and maybe we jumped the gun, got too excited about it, and just wanted to fire something off instead of really going back and thinking, “Is this the right problem-solution fit?”
RS: Also, as I see it, if I had to explain it to someone very new to this domain: a lot of mechanical engineering, or engineering, relies on the power of human eyes. The way you zoom into an automotive part, and your eyes are kind of a four-hundred-million-year-old technology, and not a lot of data is available. Therefore, we are not yet at a pace or at a stage where an AI model can reliably look at a 3D model or simulation data and process it at a speed that the human eye and the brain can process. So that’s why we see a lot of this bottled-up knowledge in enterprises, especially in engineering. They are somehow linked to geometry or an engineering data type that’s not yet LLM-friendly. So that’s also one way I see it.
DW: Related to data, in the stories about Ford, Charles Poon mentioned that AI is only as good as the information you use to train it. That’s another one of those fundamental things, and not to demean his statement or the company at all, but the phrase “garbage in, garbage out” has always been taught, similarly to problem-solution fit. These are fundamental things that we learn in engineering school. And when we’re trying to solve industrial problems, and focusing more on how technology advancement runs in parallel to, say, evolving business strategies, especially with advanced digital tools, to put it plainly, how do they miss that? How did they not scrutinize their data early on and recognize that?
RS: It’s hard to speak on really what happened in this particular situation, but a common pattern I see happening is what kind of tasks you give to this AI. It’s true that a lot of the power of AI depends on what it was trained on. I would also say there is a second class of effect where it depends on what data you have, in the sense that it doesn’t need to have been in the training process with these big labs.
But just that you, as a company, what is the data cleanliness that you have, that you can at least expose to these agents? And therefore the mismatch is essentially: what kind of problems are you asking the AI to solve? Are you asking it to solve novel problems that humans themselves couldn’t solve before? Or are you just asking it to act like a digital coworker, where it just kind of clones your best engineer?
These are two different problems. In the first case, I’m essentially going to the AI and asking it to create a car that beats all of human engineering. In the second case, I’m asking it, “Provide me ten designs so that I can engineer faster.” A typical mismatch happens when we think, “Apply AI to novel problems,” and miss out on these repetitive, well-documented tasks for which a lot of data is available. So it’s very common that the hype kind of carries it, and you want to try something that excites you. But essentially, as a business leader, you have to ground it to something that will, at the end of the day, execute and really have a business impact. So one of the ways to judge is: how much data do I have within my organization stemming from a very repetitive task? Usually, it should work really well because you have a lot of data available that the AI can refer to.
DW: You said previously it was a focus issue too. Can we talk more about how focusing is important? And I know from moderating the Future of Engineering Summit, one of the key themes there was scaling. How scaling is hard, and how most projects don’t move past their prototype, possibly because they’re not focused. They try to roll it out to everything, or they try to bite off more than they can chew. Can we get into that a little bit?
RS: Absolutely. I also spoke about this framework that I carry in my mind, and also that we use at Synera, in a public webinar a couple of weeks ago. Focus is a broad term, so probably we need more clarity on what the practical way is to now execute focus. Non-focused work would be just “spray and pray.” You just spray AI everywhere, and then you believe that it will work somewhere. For me, this is not a focused approach.
A focused approach looks something like this: You take a very business-critical process. You think about the process for a couple of days. This is how this business-critical process works at my company today. You talk to the stakeholders about what is happening around this business-critical process. You try to then extract workflows out of that process, in the sense of what department is involved where, when, and how many times. And then you take that workflow and break it into tasks, in the sense of: Is it using a tool? Is it making a judgment? Is it making another document? Is it talking to an external supplier? So you break it down into tasks. And when you then start to build technical solutions, you could even break it into what I call micro tasks. Those are essentially what part of your system does what.
And the beauty about micro tasks is not everything needs to be solved with AI. For example, me having to rotate a 3D model, or me having to contact, let’s say you, it has to be a different interface. It necessarily doesn’t have to be an AI. And then when you put all these micro tasks together, now with the places where AI would make sense, you could then assemble all these things back. This is, for me, a very focused approach, where in a sprint, you take a big business-critical process, you break it down, you break it down to an extent where you can possibly apply AI, or use a new tool, or a new way of working, and then you assemble things back together. Oftentimes the focus appears as a lack of focus, but I would assume, or I think, that lack of focus is very closely linked to lack of clarity. And that is what I mean, that when you think about a business-critical process, you’re crystal clear into what I want to do, then that translates into focus.
DW: That’s a good segue into the IMS Gear case study on your website. IMS Gear is a tier-one automotive supplier that wanted to expedite quoting for their customers. So they were trying to expedite the time it takes to receive a request for quotation, an RFQ, and get their quote to the customer. It used to take them weeks, and now it takes them ten minutes. That’s a business problem solved using technology and seems to solve a knowledge disparity problem.
RS: I can’t speak on behalf of IMS, but in general we work with the suppliers, automotive suppliers. Tying back to this focus framework I shared, a request for quotes is a business-critical process. The more elegant and the more efficient you are as a supplier in the RFQ process, the better the probability of your business growth.
So that’s why a lot of our most successful implementations have been around RFQ, because it’s a business-critical process for the supplier industry. If you do it well, you will usually get a lot of successful quotes going out, more business coming in. Typically what we do there is, like I mentioned, we take that big RFQ process, we map out these workflows, and this is exactly where what you mentioned as this knowledge problem kicks in. And it also ties to: are you giving AI a problem that is very repetitive? Because usually a lot of knowledge just gets undocumented.
Surprisingly, a lot of boost comes from just documenting something that you just didn’t document. That’s what agents are very good at. They can look at very unstructured dots on a map, and they can connect them. Okay, you responded to this quote in this way because you didn’t have this material in your company, so it makes sense. That is essentially what agents or AI can do very well. When you present to it enough context that stems from a lot of human-generated work, then AI has enough context to operate based on that.
In the case of novel problems, or cases where none of it is documented, throwing just AI at it cannot really work. And in the case that you mentioned, and also a lot of others that we see in this industry, this is a very repetitive process. These supplier companies execute quotes every week, almost every day, even a bunch of them. So there is a very standard, repetitive process. And now what you can do as a business leader is just look at where the information or knowledge is leakier, and what is the best way that I capture this knowledge. And then you give it to an AI system, and then it’s usually acting like a digital coworker. In principle, that is what is happening. We are not throwing a very novel challenge at AI. We are introducing AI into a business-critical process that needs to work. And we just created, let’s say, ways so that AI can act more efficiently instead of other solutions.
DW: That clarifies the problem a lot better, so that you can determine what makes sense as far as even a custom solution. In the case study, you mentioned three distinct layers. You have the data layer, the workflow layer, and then the agentic AI layer. Can we briefly discuss the purpose of the layered structure, and then maybe how many AI agents were used, to give people a sense of scale, if it’s one, if it’s multiple, and then, of course, where do humans fall in that particular process?
RS: I really love that question. It’s so well observed. And the answer lies in abstraction. Abstraction is essentially how you want to stop things so that it doesn’t get overcomplicated.
Enterprises are essentially a big ship. Any enterprise is a big ship with its own intricate mechanisms. And not everything is ready to be exposed to AI. As I mentioned, when you present a bit of chaotic information to AI, in any kind of AI, it usually can figure out these patterns. But what we observe in reality is that for a multi- or international engineering business that operates across time zones, across products, it’s not that easy to just introduce AI into every part of the system and then everything just works.
That is why we have this layered approach. Every layer is kind of building up, or abstracting, what will become useful for the next layer. So when we take the data layer, we try to get the data types, maybe. We don’t really get, for example, too many details about what the math behind it is, what the algorithm behind it is. We just are interested in data. Now this data directly connects to the workflow layer. Again, in the workflow layer, it’s one way of connecting to these legacy IT stacks. We essentially want to figure out, if I create an agent, let’s say in this case, it has to somehow reach back into the system. How do I make it happen? So now I have this workflow layer which I can connect to multiple systems. So you get data from one system; in a workflow, you get data from different systems. And now the agent or the AI has a very elegant way to reach back into the system, because we have the second layer. And then we have the third layer, which is the AI or agentic AI itself.
We are essentially making a building here. We have some foundations in place so that you could put decor, or you can really make the interior design the way you want, but you want some foundation that probably, when there is a new wave of models that arise in two years, then probably you need to have this foundation so that you can swap the AI layer fast. That is kind of the principle of why we have this layered approach, because each of them is modular. So you can swap out your data if, in case, you want to switch there. You can even change your workflows in case you want to switch there, or you can also change the AI layer, depending on how this whole field emerges. So this is kind of a very flexible way to set up your organization so that you’re prepared for both the past, present, and future.
DW: With this layered approach, when you scale, you create organizational change, or a whole organizational AI strategy, where you’re taking one business use case and then potentially adapting or plugging in more data, more various workflows, more systems, and adding more agentic AI layers to it. Is that correct?
RS: That is true. Organizations are inherently big, so you probably have to create small changes for a bit of an extended period of time. At least that’s how we view it at Synera. We want to really redefine how these industrial products are made. But we also recognize that this change is happening at multiple levels. A big part of the success of any agentic success, or AI success, also has a big component of people and processes. We cannot take it out of the equation at all. I think the technology component of that equation really changed now with AI, but I think that people-process part of the equation still remains. So I fully agree with you.
DW: And the people part, AI doesn’t replace the people. As we say, it’s important to keep the human above the loop, where the human still remains the final decision maker, just a more informed decision maker. But are there instances where the AI system can make decisions, or maybe in what applications is it okay to kind of give it a little bit more authority?
RS: Absolutely. When I talk to engineers every day, multiple meetings, there are some tasks that absolutely have to be automated. Imagine a big part of your job is just copying files from one folder to another. And after a two-year extensive analysis, nobody enjoys it, including myself. So that’s a no-brainer; people want that task gone. Sometimes, of course, you have to capture which files to copy from which folder, where to put it. Maybe there is some knowledge around it. Once you capture that into an agent, probably that is a task you want to give away.
There are some tasks that nobody wants to give away. For example, what kind of change do I make to this design that goes into a crash analysis of a car? That is something we don’t want to give away. But the spectrum in between is definitely more modular, in the sense, depending on the organization’s data readiness, on their change of speed, it’s a spectrum of tasks. So therefore I would agree that even when we do a lot of implementations and deployments for customers, these kinds of tasks, or we call them monkey tasks, really have no sense. You just do it because there is no other way.
All monkey tasks, or these kinds of low-value tasks, nobody wants to do them, and it’s quite a significant double-digit percentage in every company. It’s not one or two percent. It sits probably between twenty and twenty-five percent, surprisingly. So that is a very quick win. That’s where we, at Synera, go from this automation approach, or we have this automation lens, because, yeah, that’s a very quick win for everyone, in terms of business impact.
DW: You mentioned data readiness again, and I was going to ask a question about that earlier too. Is there a data readiness component to your engagement when you’re building a solution for a customer? Is there a cleansing process that companies need to go through, or can the system have a tolerance of certain data quality in order to work well?
RS: By data readiness, what I also mean is having digitized processes as potential data. A lot of engineering, especially, example, in the automotive, aerospace, is still non-digitized. There is not even a digital document available for certain processes. A big part of our work goes into this. So we go into an organization, and we see if it belongs to a business-critical process. If it remains undigitized or undocumented, then we like to make sure that this is done. There is a certain group of AI for which you need thousands and millions of data points. That really is not the case for agents or LLMs. The reason why agentic AI is so impactful, also in engineering, especially for the work that we do, is because these LLMs come with a lot of pre-built intelligence. So exposing even one or two prompts is enough to handle a complex task. So by data readiness I really mean: do we have these digitized pieces of work? Is the legacy tool that an organization uses even accessible by another system? Those are cleanliness stuff that we also typically do and see are super critical for agentic AI to be successful.
DW: Going back to Ford’s story a little bit, in everything that you shared today, could Ford’s specific application use a similar approach, that layered approach, or what are some of the underlying principles in those situations that could make that kind of application and use case more successful?
RS: I would also see what domain of application it really belongs to. I think there is one angle where you could definitely have this IT work done, which is essentially, you know, have these terms in place, have these integrations in place, and so on. The other aspect is those expert human engineers: were they ever able to document their work or transfer their judgment to someone else?
One big learning I had is that I once had an opportunity to go to one of our customers, and they took me on a tour of their manufacturing plant. It was super big. And I had a full tour of every machine there, like what is happening, what happens after the things that were designed in Synera came out, and so on. And there was one engineer operating a machine who knew, by the smell of the part coming out, whether it would work or not. This was mind-blowing for me. That part of judgment was still part of this big organization; the smell and the color of the metal’s heat were factors in the judgment. So the reason I’m saying this, sharing the story, is because probably these kinds of things you should try not to replace. As I mentioned, these kinds of decision judgments are probably in the head, and probably only accessible to the human brain. Everything else, digital, software, all of those things, probably is a quick win.
So therefore, my first curious question in this case study that you mentioned is: what kind of tasks were there, or were those engineers asked to leave? Because it looks like when you take out those tasks where no other potential solution is available other than human judgment, then of course you have to come back to human judgment. I think it also depends on, let’s say that was not the case; it was still a software task, then I could definitely think of, you know, if there was any kind of technology adoption program in place. Usually business leaders, they need to have a very strong operational team who knows the technology well. I mean the three Ps: the product, process, and people. Having that operational team is also very key, because if you go to these engineers with a completely new interface or a new way of working, they are right to oppose it, because trust is usually very gradual, especially in industrial engineering. So I would also maybe say that, okay, then there needs to have been a process that needs to have been executed well. The technology is only one part, but probably there should have also been a transformation there.
DW: Any final thoughts or best practices, or things that you think that engineers should keep in mind when they’re either using systems or when teams are considering implementing AI? What kind of best practices or guidance could you leave them with?
RS: As an engineer, the way I see it is that for any engineer, this is a great opportunity to both accelerate the domain but also accelerate yourself in a way. Even now, what I do every day, or what I see in the best organizations, I have the fortune of being in the Bay Area very often nowadays. The hardware engineering there is kind of very experimental. I asked a hardware engineer there, “Why don’t you have so many processes?” And they said it is intentional, that we leave a lot of room for people to experiment. So I would, I think the first thing I would say is, even if you’re a hardware engineer, just experiment with these new models, whatever is available on your workstation.
The second big thing, let’s say the second big learning, or what I could share, is once you know that you want to take things to production, do not go with the same confidence of you building the MVP into the production system. Production is a different beast to tackle. You probably need a lot of buy-in; you need this whole organization to believe in that problem and then change it. And then all the things that we talked about — gaps in terms of knowledge, process, and technology readiness — it’s a two-fold best practice, as I see it. So the best organizations, they experiment a lot, but they also know, okay, the moment I have to take something into production, I need a different framework to execute. I need a different infrastructure to scale this so that it’s very impactful. Oftentimes it’s very easy to mix them both, saying that “I work in an enterprise environment so I can’t experiment,” or saying that “I built an MVP so I can push it to production.” So these are two common things that I also learned from our customers and partners.
Let’s keep the conversation going
Connect with Rachael Pasini and Ram Seetharaman on LinkedIn with follow-up questions, additional insight, perspectives, suggestions, and key takeaways.
Also, if you haven’t already, be sure to:
Thanks for tuning in to The Control Room, a Design World hub helping you make engineering decisions. ‘Til next time.
Filed Under: AI Engineering Collective, AI • machine learning, PODCASTS
