The AI Engineer Every Industrial Company Will Need | Paul Eremenko (P-1 AI) & Jeff Immelt (NEA)

0:00If you want an AI to be a good aerospace engineer, it needs to see millions of airplanes. And there just haven't been millions of airplane designs since the Red Brothers, right? It's like order hundreds to thousands and they're not really readily available or accessible. Very little of the effort and the investment is going into building AI to help build that physical world and make that physical world better. How do you avoid getting stuck in the proof of concept phase versus the commercialization phase? I have a nose for that.

0:31Welcome.

0:33Anne Dwane:I'm Anne Duane from Village Global, and today we're joined by Paul Aromenko, founder and CEO of P1 AI, a company building AI engineers for the physical world. P1's flagship product is Archie, an AI mechanical and electrical engineer that works alongside human engineers using the very same tools they do. Think of Archie as a capable junior engineer that helps industrial companies move faster at a time when engineering talent is scarce and when there's enormous demand to build everything from factories to robots to energy infrastructure and data centers. It's an exciting moment for P1 because their momentum has culminated in them raising a$50 million Series A led by NEA.

1:13Anne Dwane:But wait, there's more. Jeff Immelt, venture partner at NEA, is joining P1 AI's board of directors, and he's here with us today. Before NEA, Jeff spent 16 years as chairman and CEO of GE, leading one of the world's largest industrial companies through a period of extraordinary technological and organizational transformation. Today, he serves on the boards of companies like Bloom Energy, Twilio, and NEA portfolio companies, including Desktop Metal, Formlabs, and Radiology Partners, and many more. Paul and Jeff bring two remarkably complementary perspectives, one building the future of engineering with AI, and one who spent a career leading and transforming engineering organizations at global scale.

1:55Anne Dwane:We're going to talk today about why mechanical and electrical engineering is ripe for AI leverage from Archie, what it takes to build trusted AI teammates, how to lead companies in the age of AI, and what's ahead for the next generation of industrial innovation. So welcome both of you. And Paul, let's start first with the name of the company. What is the origin of the name? I'm so glad you asked. So there's a very much underappreciated piece of early AI sci-fi literature called The Adolescence of P1 by Thomas Ryan. And actually, I don't think a lot is known about Thomas Ryan. So we're not sure if it's a pseudonym or who actually wrote the book or who's behind that.

2:40And he never seemed to have written anything else. But this book came out in the 70s and is one of the earliest depictions of AI really gaining sentience. And it doesn't go well in the book. I don't want to spoil it. But it's certainly an homage to early sci-fi literature, which I think has inspired a lot of the leaders of the AI field today. But also a bit of a cautionary tale that we certainly keep in mind as we build our product and company.

3:06Anne Dwane:Great. Right. Well, and it sounds like some of the seeds of P1 were actually sown back when you were at DARPA and that you were thinking about Joint Strike Fighter and other complex projects. So can you tell a little bit about that era and maybe the genesis? Yeah, absolutely. I would actually say that the seeds of the company were sown much earlier and have their roots in hard sci-fi. Right. When AI comes, the first impact of AI is supposed to be on helping us build the built world. Right. We are still physical creatures, for better or worse. Our the biggest part of the human experience is the physical world around us.

3:43But very little of the effort, certainly going into the early days of this current wave of AI in the early 2020s. But even still today, very little of the effort and the investment is going into building AI to help build that physical world and make that physical world better. So I think the early seeds lie there. But to your question about DARPA, yeah, you're absolutely right. So I went to DARPA in 2008, kind of 2012 timeframe. And this was right on the heels of the joint strike fighter, the F-35 being fielded. And the F-35 is the most expensive thing that human civilization has ever built, with or without taking inflation into account.

4:21Doesn't matter. And it has the biggest cost variance since, you might argue, since the Gothic Cathedral. So here it may come in. Mainly because they picked the wrong engine, as the main issue of the F-35. But we'll leave that to be for another day. Yeah, thanks, Jeff. For the listeners who may not get the jab, it's a Pratt & Whitney engine. And I used to be a chief technology officer at United Technologies, which was the parent of Pratt & Whitney. So competitor to GE Engine. But be that as it may, on the heels of the JSF, I went to DARPA and the big question in the Pentagon was breaking the cost curve, right?

4:57Is how do we afford the next fighter jet? The cost trend from the F-16 to the F-22 to the F-35 was a very steep exponential. And a lot of that is, you know, some of it may be driven by procurement decisions. Some of it may be driven by red tape, but a lot of it is driven by just the innate complexity and increase in complexity of the product. And so I came with the thesis of let's figure out a new generation of design tools and design methodologies to help manage that complexity better. And the inspiration really came from VLSI design, which is the techniques that were pioneered in the 80s for semiconductor design.

5:30And a lot has been done in sort of what's called electronic design automation or EDA to basically help manage the complexity, the transistor and gate count increases that have spanned many, many orders of magnitude, seven or eight orders of magnitude, right? And without really noticeably increasing chip development times. And so why can't we do that for these much bigger, much more heterogeneous, much more complex systems like an airplane? And so DARPA invested quite a bit into this. It was like a half billion dollar investment over four years. It was one of the biggest things that DARPA did in that period of time.

6:02And I'm proud to say that I think we laid the foundation for modern model-based engineering. And a lot of the techniques, DARPA ended up open sourcing. A lot of the big tool vendors were part of that program. And it's really permeated how we build large complex systems. But the relevance to P1 AI and building AI for the physical world is the reason we have chatbots and cat video generators and coding agents is because there's a lot of training data. And particularly for coding, you have trillions of lines of code available open source software that you can scrape and you can train on. If you want an AI to be a good aerospace engineer, it needs to see millions of airplanes.

6:42And there just haven't been millions of airplane designs since the Wright brothers, right? It's like order hundreds to thousands, and they're not really readily available or accessible. And so how do you get the training data? The idea that we had was, hey, we've been working on this model-based engineering to design one airplane. Can we use that with enough compute and a clever sampling strategy? Can we sample millions of airplanes in the design space? You got to pick the right ones. And based on that training data set, the model will learn the underlying engineering principles and the underlying physics.

7:12Right. And so we call that semi-synthetic training data because these are designs that have never been built, may never be built, but they're designs that could be built. So they have to be high quality designs. This can't be AI slop. So that's why we call them semi-synthetic. And so we adapted a lot of these techniques that hark back to 15 years ago at DARPA for creating these semi-synthetic training data sets in physical product domains. And that was one of the core founding ideas of the company.

7:36Anne Dwane:Amazing. Okay, so let's fast forward to today. And what does P1 do with customers today? I would probably break it down into three things, right? So one is that we train custom models on data sets such as the ones that I just described, the semi-synthetic data sets and product domains. There's a second type of model that we train for tool use, for using very complex engineering tools that have very lengthy orchestration flows. Like if you want to run a finite element solver, for instance. It requires a very complicated process. You start with the geometry, you have to de-feature it, you have to build a mesh, you have to adapt the mesh, you set boundary condition solver parameters.

8:14And even for an expert human user, it doesn't converge most of the time. And then you got to troubleshoot parts of this workflow and figure out what went wrong and try again. And so, today's frontier models, the text-based, vision-based models that we have, they can't do these kinds of orchestration flows, partially because this is not in their pre-training data corpus. And so we train our own custom models to do complex engineering tool orchestration. And we also create, again, semi-synthetic training data sets for doing that. So that's sort of thing number one, is we build small custom models for very specific engineering tasks.

8:49The second thing that we do is we build an agentic harness that goes around a frontier model, and we try to be agnostic to the specific model. They come out frequently. We benchmark them as they come out and we try to be as modular as possible in terms of being able to put in the best one of the day or one according to customer preference. And then that harness also contains our custom models. And it also contains a lot of anti-hallucination features, right? Because engineering reasoning is different than other kinds of reasoning. And so we do things like citations, for instance, any piece of data that Archie uses as part of its engineering reasoning process has to be cited to a source.

9:29There are rare cases where Archie has to make up a piece of data out of weights, in which case it has to very clearly indicate that and document its assumptions behind that piece of data. Another part of that harness is things like structured representation. So what is the actual design? When you have a coding agent and it is reasoning on a piece of code, that code is a very clearly defined artifact. It has syntax, rules of syntax, right? It has clear formal semantics. If you're reasoning about a physical system, what is it, right? Is it a bill of materials, which is just a list of parts? Is it a schematic?

10:04Is it a 3D model of that system, right? These are all different views of it. And so it's never really clear what is the artifact. And so we have to actually create what we call a structured design representation. And we've created a special modeling language that's very, very LLM friendly for representing these designs and all of the models in the agenda Harness reference the same structure design representation. And the third part of the Harness that I'll mention is learning. And this is a lot of the, I think, competitive advantage of Harness companies, is they are the most proximate to the customer, to the enterprise.

10:39And so all of the data capture that comes from people working with Archie and giving Archie tasks, giving Archie feedback and telling him, no, no, do it this way next time, all of that is incredibly valuable enterprise knowledge that is captured in various facilities in the Agenda Karnas. The last thing I'll mention about what's under the hood and what's special about Archie is the form factor. So our customers, if you want to build an AI engineer, your customers are the people that do most of the engineering in the physical world. And these are big industrial OEMs. These are companies like GE.

11:14These are companies like United Technologies, Airbus, Boeing, etc. And selling into these companies, you can do it one of two ways. You can either sell them a piece of software, right? And they buy a lot of engineering tools. But if you're selling them software, you're selling into the software budget and you're competing with incumbent tool vendors who have very strong lock-in effects on the enterprise. So you're elbowing your way into a budget that's relatively small. It's very crowded. The second way to sell to them is labor, right? And this is a spend, this is a budget item in big industrials that's an order of magnitude, or sometimes even two orders of magnitude bigger than the software spend.

11:50And here you're competing, and I'll use the word competing in air quotes, right? But you're competing with human engineers. And so the reason I say competing in air quotes is you're being benchmarked against the capabilities of human engineers. As a practical matter, we're not replacing human engineers because there is an acute talent shortage. And so what we're helping is really solve that talent shortage and reduce the amount of offshoring of engineering talent that happens out of the United States. But if you're selling into labor, you have to provide the product or the service actually in the form factor of human labor.

12:24And so this is everything about how Archie behaves and interacts. It's a remote junior engineer colleague. He shows up on Slack. He shows up in Microsoft Teams. You give him tasks, you can chat with him, or you can give him long horizon tasks as you would, again, with a junior engineer. We charge a salary. We don't charge for compute. We don't do consumption pricing. We charge a fixed salary so that the companies can just budget for an FTE, full-time equivalent. It's a headcount for them. Our contract looks like an engineering services outsourcing contract instead of a SaaS or AI contract. We really try to fit this form factor and minimize the amount of change management that you have to do on the customer side.

13:00And we think that's a big unlock in terms of selling into this industrial OEM market. So those are the three big ways that I think Archie is unique.

13:09Anne Dwane:And Jeff, did you ever think that teams in companies you were working with would have these kinds of employees? You know, Anne, I always was, even going back a decade or so, was super interested in where artificial intelligence would go and what the impact would be in the industrial world and with the enterprise. So, you know, I've been around, I've been at NEA for about eight years. I do about half healthcare, about half tech. But in tech, I really hang around the enterprise and industrial applications. And that's really what interested me in P1. You know, if you're an industrial CEO, you care about product-led growth and you care about how your customers are using the assets that they buy from you.

13:54Those two things are 90 % of the value of your company. So if you can engineer more products faster, more economically, that's a game changer for you as a company. So that's what attracted me to P1 is it's approaching a problem or an opportunity that I always felt like was in place. You know, if you're going to design a new engine, you probably have to use 2 ,000 engineers, Paul, to do that. And maybe 10 % are outsourced to engineering services firms. So it's a large scale enterprise where I could see Archie kind of fitting into the workflow of the company. So I was attracted to the end to P1.

14:36These are the companies that interest me because I think they add the most value. And what I like about Paul is he knows the use case. In other words, you don't want a founder to walk in and say, you guys are idiots and you move too slowly. Okay. When I was in your chair, when I was in your chair, this is what I thought about, you know, and I think that's, that's how change has to happen.

14:59Anne Dwane:Got it. Well, and that's a good segue. So Paul, can you talk specifically about the use cases that you're serving today and how ROI is measured? Absolutely. So we've made a conscious decision first to focus Archie on design engineering, right so this is as different from say manufacturing engineering where you're designing the industrial system versus designing the product or test engineering or field support engineering right so there's many phases of the engineering life cycle initially we decided to focus on design engineering this also happens to be where most of the world's engineers work is in the design phase of the product within design engineering of course you have the full spectrum from sort of pre-sales and sales to conceptual design preliminary design detail design and verification and validation Archie can, in principle, work in all of these, right?

15:45So there's nothing about the way that Archie is designed that prevents him from servicing use cases across the design engineering flow or the design engineering lifecycle. Most engineering hours are spent on detailed design, and most of them are engineering change orders, right? So once you've done sort of the initial decomposition of the system, you're optimizing the individual piece parts. As those piece parts come together, you discover a lot of interactions and incompatibilities, and you have to do redesign. And that redesign is usually codified as engineering change orders, which is the equivalent of a software ticket, right?

16:19The biggest opportunity for Archie is cranking through engineering change orders, cranking through ECOs. But Archie is fully capable of doing other things. For instance, some of our existing customers do a lot of engineer to order, right? Which is product customization. And this is particularly big in data centers. We have a couple of customers in the chiller space for data center cooling products. And engineer-to-order is what most of their engineers spend most of their hours doing. And so we've made sure that Archie is particularly well-tuned to those particular use cases. But he is not designed as workflow automation.

16:50He's really designed as a general spectrum engineering intelligence.

16:55Anne Dwane:A colleague. I love that. Well, and I've seen those use cases you talked about in data center power and data center cooling. And I always like to think that when Paul says he's chilling, he's actually working. We're cooling a data center somewhere, right? Exactly. So let's talk a little bit about what you've learned about adoption in the enterprise. So Archie is anthropomorphized. And what are some of the tips you would have for companies thinking about bringing in agentic technology like P1? Well, I think, and you did ask earlier also about how customers think about ROI of the product, right?

17:37And I think the ROI is exactly as Jeff put it, which is, it's really about expanding the bandwidth of an organization while keeping the headcount constant, right? Or maintaining whatever growth and headcount a company can attain, which is usually limited not by the company's appetite, but by just availability of talent, right? And so we try, I think Jeff's estimate on a jet engine program, the 10 % of the workforce might be outsourced. And another 10%, 15 % is pretty mundane, repetitive, entry-level type stuff. And so, we see that as those two pockets of value as the low-hanging fruit for Archie that are really pure value accretion for the enterprise and just makes everybody's lives better.

18:24From the individual contributor engineers up through the executives who own the P &L for that enterprise. So it's really about workforce augmentation and bandwidth expansion for teams. There is an interesting case to be made for speed, right? Because Archie is obviously faster doing a lot of things. We're cautious to make the claim that Archie makes her company faster because the speed of a junior engineer is usually not the thing that sets the overall clock speed of the enterprise. But there are some really interesting glimmers here where our positioning is start with one Archie per team. And so this is notably different than some of the software coding agents and like Cognition's Devin is a big inspiration for us.

19:08And I think Scott is like, hey, a human software engineer should supervise like 10 Devin's or 20 Devin's or whatever. So we don't say that. We position Archie as one Archie per team so that he gets the requisite level of work review, right? Human junior engineers make mistakes. those mistakes don't crash airplanes. Similarly, Archie occasionally makes mistakes and we expect that the existing work product review processes will catch those just fine, but we don't want teams entirely composed of Archies. I think that would break the minimal change management paradigm that we're trying to push. But if there is in fact one Archie per team, there is a very interesting use case for can those Archies coordinate amongst themselves?

19:48And if so, can that coordination, because inter-team coordination is one of the big friction points in an enterprise. In that case, I can actually make the case that having even just one Archie per team in a junior engineer role, but having those Archies communicate amongst themselves will actually measurably increase the clock speed of the organization. So that's a pretty interesting kind of ROI use case that we're actively exploring. So when I probably see five or 10 CEOs a month asking about artificial intelligence, and I always tell them to think about four things. Build proficiency in your organization.

20:22Create a mental model on what's the art of the possible. Like if I was going to redesign my company around artificial intelligence, what's possible? Have a belief system. So that's where you spend money. If you're going to spend$10 million, here's what the priority is going to be. Don't spread it every place. Have a real priority list. And then build a story. Have a story. If you're doing an all-employee meeting, what story are you going to tell about artificial intelligence? kind of own your story. And I try to track them through those four kind of things. And then when I work with people like Paul, or as Paul and I work together in the future, it's how do you avoid getting stuck in the proof of concept phase versus the commercialization phase?

21:05I have a nose for that. I know when you're inside the bowels of a big company, what the trap is like and who's going to trap you. And so I think it's marrying up what does the enterprise need with what can the founder do to be most beneficial to that company? That's how I try to work with these companies.

21:26Anne Dwane:Right. And avoid the corporate innovation theater or something like that. Yeah. And Paul, do you have any thoughts about that as you're seeing things move from pilots to production or scale? Yeah, absolutely. Absolutely. So I think one of the really big insights or consequences, I'll even say, of the anthropomorphic model is who is your customer within these big companies, right? Because the company is not monolithic. There's lots of stakeholders. And to your point, Anne, about getting trapped in the innovation part of the company and never actually making it into the P &L, right? That moves the needle for the company is a really big failure mode.

22:00Because we're selling labor effectively, we go straight to the to the VP of engineering and, and the, the executive who owns the engineering headcount and who is accountable for the productivity and throughput of the engineering organization. And we find that that's, that's the most powerful stakeholder. And, and if we are not selling software, then they don't actually have to do too much coordination. They have to do some, but much less so with others in the enterprise, like digital and cybersecurity, et cetera. We obviously have to jump through all of the cybersecurity hoops nonetheless. But the key decider, the key stakeholder, and the person who owns both the budget and the ROI from Archie is the head of engineering.