From Data Centers to Dyson Spheres: P-1 AI's Path to Hardware Engineering AGI

0:00Again, when I was asking the question over the last couple years of like, why isn't anybody working on AI for building the physical world, the answer was training data. Fundamentally, if you want an AI engineer that can help you design an airplane or modify an airplane, and you say, pay what happens if I change the wing on an A320 by 10 % increase the wing area by 10%. In order to be able to answer that, your model has to be trained on millions of airplane designs, ideally. And there just haven't been millions of airplanes designed since the Wright Brothers, even if you did magically have access to To all of them which you don't and if they were all modeled in a coherent Sort of semantically integrated way which they aren't right but even hypothetically you would be you would have maybe a thousand designs Right since since the birth of aviation and so nowhere near enough to train a large model

1:07Today we're excited to welcome Paul Airemango, CEO of P1AI. Paul was a director at DARPA and the youngest CTO of Airbus at age 35, and now he's getting to turn his science fiction dreams into reality at P1AI. P1AI is attempting to build engineering AGI for the physical world. So we already have fantastic companies like Anthropic, Cursor, and Devon that are transforming software engineering. But hardware engineering in the physical world, whether it's data center, quillers, or airplanes, has yet to be transformed radically by AI. We talked to Paul about the opportunity, the key bottlenecks in gathering data, and how he envisions their agent Archie evolving to help build the physical world around us from fighter jets to starships.

1:50Paul, thank you so much for joining us today and we're delighted to have both you and your Jack Russell, Terry or Beagle Mixley on the show. Welcome. Let's start off with, we just had our AI conference, AI Ascent, and at the conference, Jeff Dean was talking about the potential for vibe coding and how a 24 -7 junior software engineer is going to be possible through AI within the next year or so. So it seems like software engineering is really going through this vertical takeoff moment right now. What do you think is happening in the physical world as it pertains to physical engineering? So not a lot.

2:26Is the short answer. And one of the reasons we founded P1AI is because I grew up on hard sci -fi and I was promised AI that would help us build the physical world, the world around us and eventually starships and Dyson spheres. And when the kind of deep learning revolution really started to take off, I asked the question, well, who's building this stuff? Like, who is doing that AI that's going to help us build the physical world? And the answer was nobody was working on it. And it really wasn't even on the agenda of the kind of foundation labs. And some years later, today, 2025, it's still isn't.

3:05And so we asked the question of why that is. We can talk about why that is, maybe later in the podcast. And we think we have a solution to remedying some of the reasons, some of the challenges and actually bringing it to market. So I think, and Jeff, by the way, is very grateful to have him as an angel investor in the company. And I think the coding AI has been a long time coming. One of my co -founders, Sishman Jod, did his PhD in 2011 on program synthesis, right? So this is not a new technology, but it's just now, I think, finding that product market fit, right? The right packaging and the right business model, the right pricing models.

3:50I think physical AI, we have the benefit of standing on the shoulders of a lot of the coding AI work. So if you can have a programmatic representation of your physical system, you can use some of the program synthesis techniques to create physical designs. So we're not, you know, it's not going to take a decade or 15 years. We think that we can put the technology bricks together this year and hopefully start finding product market fit as early as next year. Can we, yeah, can we double click on that a little bit? What are those technology bricks? What pieces need to be in place for this to become a reality?

4:24Yeah, so the biggest one, right? And again, when I was asking the question over the last couple years of like, why isn't anybody working on AI for building the physical world, the answer was training data. Fundamentally, if you want an AI engineer that can help you design an airplane or modify an airplane and you say, pay what happens if I change the wing on an A320 by 10 % increase the wing area by 10%. In order to be able to answer that, your model has to be trained on millions of airplane designs, ideally. And there just haven't been millions of airplanes designed since the Wright brothers, even if you did magically have access to all of them, which you don't.

5:03And if they were all modeled in a coherent sort of semantically integrated way, which they aren't, right? But even hypothetically, you would have maybe a thousand designs, right? Since the birth of aviation. And so nowhere near enough to train a large model. And so the most sort of foundational technology break for us is creating this training data It is synthetic, that is physics -based and supply chain informed of hypothetical designs of in whatever physical product domain. So it could be airplanes, it could be something else. And making it large enough and making it interesting enough. So the design space for most physical products is almost infinitely large, right?

5:47It's huge. And so you can't randomly sample it, you can't evenly sample it, you have to very cleverly sample it. you want to sample kind of densely around dominant designs, but you want to sample sparsely around the corners and edges of the design space, because that teaches you something, even if that corner edge of the design space is not somewhere where you would ever want to go, it teaches your model something about why that is, right? And so creating these these datasets for training models, that was sort of the core of our approach. Then of course, Of course, if you just take, if you now have a millionaire plane designs and a performance vector for each one and you throw it at LLM in post training or even in pre -training, you're not going to magically get a good engineer, right?

6:34So then there is the question of what is the model architecture look like? And today we use a federated approach of a bunch of different models and we can talk more about them, the different parts of engineering reasoning. And then they're all orchestrated by kind of an orchestrator, Rezener, LLM that also acts as the interface to the user. Actually, can you say more about that? How do you get your models to be capable of doing the physics -based reasoning? And is this stuff done in kind of design software today? Is this stuff inside of a engineer's brain? And how do you kind of put that knowledge into a model?

7:09And can I add to that the supply chain informed piece of the equation? How does all that come into play? Sure, absolutely. So first let me maybe describe what the product actually is, right? Because I think that the help answer part of the question. So we are focused very narrowly in some ways on cognitive automation of what a human engineer does in designing physical systems. So what does a human engineer do? So humans are very good at taking a bunch of requirements and distilling what are the key design drivers that come out of those requirements, postulating one or more possible solutions that meet those design drivers.

7:46Doing first order sizing of what is the answer look like roughly, right? And what is the relevant phenomenology in that in doing that sizing and by phenomenology? I mean, like what are the different physics? Because it's not just about geometry, right? These are multi -physics systems. So they have electrical and thermal and vibrations and and electromagnetic interference. And sometimes those matter sometimes they don't, right? and humans are very good at good engineers, right? Are very good at selecting which modalities matter in doing this first order sizing, and is this really going to close, and is this really going to be a viable design?

8:18And then humans are very good at knowing what tools there are for detailed design and analysis, what is the range of applicability of those tools, and how do you use them, how do you set up the problem for those tools? And that's exactly what we're trying to tackle. Is that cognitive automation? So the first product is called Archie. So if I refer to Archie, that's not Lee. Archie is the agent. And a really important consequence of this focus on cognitive automation is that we are not trying to play the tools layer. There are existing detailed design and analysis and simulation tools. And we want Archie to know how to use those tools, the same way that a human knows how to use them.

8:54But we don't try to replace the tool. We don't try to make it better. We don't try to compete with it. We don't try to supplant it in any way. Right. We just learn that they are there. and how with their range of validity and... Right on top, just like a human, that's right. Yeah. So your question was around, so what are the different models, right? And how do you do the engineering reasoning? And basically, all of the things that I just described, distilling requirements, picking key design drivers, sizing, etc. They all simplify to a couple of primitive operations. And the operations are design evaluation, right?

9:32So if you have a particular design, what is the performance of that design? Again, modeling the relevant phenomenology that's in the design. Another one is design synthesis. So if I have a specified performance or a specified requirements vector, what is the design? Right? And a third class is a little more complicated, which is finding errors and infilling inside a design. But basically any engineering query, any engineering task that a human engineer does reduces to some sequence of these operations. And so what we then have to do is, first of all, have a reason or orchestrator that's good at taking tasking from humans in an organization and decomposing them into the right sequence of primitive operations.

10:22And then some models are neural and some don't need to be neural that are actually good than carrying out those operations. And so some of the things that are behind the orchestrator reason are, for instance, a graph neural network that's just very good at being a physics -based surrogate model over the performance space. That's one example. Another one is a geometric reasoner model that allows you to answer questions about relative positioning and packing and interference and things like that. Some of those geometric reasoning operations are very easy to do just algorithmically, like software 1 .0 style, right?

10:59You don't need neural capability. Some of the more complex ones you can do with VLMs. I think that there is yet another category of physical reasoning operations that we don't yet know how to solve. And I think that there will be a generation of AI models that's coming that are physical world models that will have better intuition for some of the more complex higher order spatial reasoning tasks. And then you have physics reasoning, right? You have sort of your multi -physics reasoning. There's a few different, again, approaches. Some of them software 1 .0, some of them are neural. One example is we have what I call a lobotomized LLM, which is an LLM.

11:45It's no longer good at English, but it is very good at doing programmatic representations of multi -physics representations of physical system designs and reasoning over those. So that's kind of a federated assembly of models that are all orchestrated by an LLM reasener that is also the interface to the user. What is Archie capable of doing today? How does that compare to your average hardware systems engineer today and what's ahead for Archie? Yeah, that's a great question. So what we've done today, so we're about nine months old as a company. What we did in our precede is basically a toy demo around residential cooling systems, right?

12:28So there's air conditioning units, those kinds of things. And the reason we chose that is because it's a fairly multifysics domain. So you have fluid flows, you have air flows, you have thermal interactions, you have electrical systems, right? So it's rich, But the number of components in a system is not very large. And a lot of the physics phenomenologies pretty linearizable, right? Like you can simplify it. So it's kind of rich enough to be convincing, but not so complex that we're bogged down in data generation, for instance, right? Or the supply chain piece, which I want to come back to, getting that right.

13:08And so that demo exists. We've put it out publicly. And the question, of course, is, so what is, like, how good is it? And there is no other than a vibe test, right, where you have a human interact with it, and you're like, oh, that's pretty good. There isn't really a good answer today. And so one of the things that we've invested quite a bit of energy into is eVals for physical, physical system AIs, for physical engineering AIs. And by the time this air is, I think, we'll have an archive paper out that describes our approach to eVALs. We call it Archie IQ. And the goal is to administer the eVALs to humans.

13:53So an entry -level human engineer, average human engineer, expert -level human engineer, and to Archie. And for us to have a closed loop process of improving Archie to move up that IQ scale. Do you think you'll keep pushing on residential cooling systems and you'll have a residential cooling system agent? There'll eventually be an airplane design agent, a starship design agent. Is that the right way to think about this? Or is it a single agent that you're building? No, I think it's the right way to think about it is at least initially we have to create distinct training data sets for each product domain, for each product vertical.

14:28How do you guys think about that map? If the map starts with the residential cooling systems, how does it progress from there? like what does that overall map look like to get to the point of, you know, engineering AGI for the physical world? What's on that map? Yeah, so first of all, residential for us was just kind of a toy problem that we chose. Our first market where we plan to deploy with a customer, with a design partner, is actually data center cooling systems, which are still thermodynamic engines, right? So they're not that different from residential HVAC, but they are an order of magnitude more complex, obviously much larger and a very interesting market because they're having trouble coping with demand from data center customers and we're at a point where cooling systems are like the long lead item, right, pacing data center development, which is kind of wild.

15:17So it is an acute pain point. It is in many ways the delivery of those systems is in many ways limited by engineering bandwidth of being able to deliver sort of semi -custom solutions to each data center. And so we have a very enthusiastic customer base for that early deployment. And these systems are, these are now order 1 ,000 unique parts in the system. The physics domains are quite rich, but the physics again are still pretty linearizable. So from a synthetic data generation perspective, it's a fairly manageable problem, which is why we like it as a first vertical. And then we progress, and I think we progress principally on the basis of synthetic training data, the physics -based synthetic training data complexity.

16:04And so our expectation is that we will go roughly in order of magnitude up in product complexity every year. Okay. So the second vertical is probably industrial systems. So things that go into a factory from material handling, industrial robots, mills, lades, right? those kinds of things, then we move into mobility domains, which could be automotive, it could be agriculture mining equipment, those could be automotive and heavy machinery, and then aerospace and defense. But just to give you sort of the order of magnitude progression, data center cooling systems, roughly a thousand unique parts, airplane, roughly a million unique parts.

16:43So three orders of magnitude between them, and we think based on sort of our current projections, is roughly one year for each order of magnitude. How much of the data that's required to train the system comes from the usage of the system, such that the simple use cases start to bootstrap the more complex use cases. How much of it is fed to the system from some other training data generation technique that you have? So we think we can train our Chi to be at the level of an entry level engineer, So like college educated, but not particularly savvy in a specific company's products or some of the in -depth processes and practices, or a lot of the detailed supply chain, you know, cost data, that's not something you learn in college.

17:29Right? So we think we can do that just based on non -proprietary synthetic data that we produce, meaning non -proprietary to a customer. And so the goal is get Archie hired as an entry -level engineer, right? Get him in the door. We then have a relationship with the customer. We have a data sharing agreement and all of those things sorted. Then Archie can start learning on the things behind the firewall. Yeah. Obviously subject to the customer who's acquiescence. But we can then ingest their PLM system. We can ingest all of their model -based tools and models. We can ingest a lot of the real world performance of that system.

18:11quality escapes, right? There is a bunch of stuff there. And so we think that Archie can move up the expertise scale fairly rapidly from entry level to kind of average to expert engineer on the basis of a lot of that real -world data. And of course improvements in the AI models as well. And do you have a definition when you talk about engineering AGI? We haven't found sort of a generally agreed upon definition of AGI. What's your definition of AGI and how does it fit into the test of someday when you have an engineering AGI, how will you know you have it? Yeah, so back to the eVals, we have adopted what's called Blooms' Taxonomy, which is a cognitive knowledge taxonomy for human learning, developed in the 50s and has been applied to LLMs in recent years.

18:59We have adapted it kind of to the engineering task and so the taxonomy has kind of a pyramid, the lowest level you have just recall of information, that's relatively straightforward, then you have semantic understanding of the design. So in addition to recall, like what does this part do? Then you have the ability to evaluate a design or a change to a design. So what is the performance impact of changing this component, for instance, or resizing something? Then there is the ability to find mistakes in a design. So this is the error correction and infilling. than to synthesize a brand new design or a significant change to an existing design.

19:38And then kind of the highest, the pinnacle, which we call E -AGI, engineering AGI, is reflection, which is some degree of self -awareness of what process did I just use to do the preceding five levels in this hierarchy? What process did I use? What are the limitations of that process? Is there an alternative process? Where could I have gone wrong? These are the kinds of things that actually most engineers in the field don't do very well and is reserved for kind of the senior levels, the experts or the technical fellows in large industrial companies. And so to us, that is certainly the pinnacle of human engineering intelligence, is the self -awareness of your own limitations of the engineering process.

20:23And then there is a different dimension which is can it generalize across domains without us having to train it on the domain? So I would say those are the two axes and you could argue that you can accomplish sort of a GI on one axis a GI on the other axis or a GI on both axes Pick your poison We hope to do both What do you think it's going to take to be able to solve you know systems of the current order of magnitude of parts complexity all the way up to airplanes and more in terms of the number of parts. Is it simply a matter of scaling laws and the LLMs will get better, you're going to be able to generate more synthetic data and more data, more compute, bigger models, you're going to be able to kind of solve these much more complex systems in the future?

21:07Or do you think there's going to be research breakthroughs that I needed to get there? No research breakthroughs needed. I think we operate squarely in the kind of applied research domain, right of where we take existing research that the frontier labs are doing and applying it to our very specific problem. We don't see, I mean, so obviously there are limitations in scaling in terms of compute right to generate, so there's CPU compute to generate this synthetic data because that's a lot of simulation and sampling and things like that and then there's GPU compute to a trained GPU compute for inference.

21:45And all of those today, I don't think we could do for a million part system. Because if you think about it, and maybe to tie back to your question pad about, where does this have been coming? Yeah, I think I'm in. So how do we create these synthetic data sets? So if you have a million unique parts in a system, in order to compose, to kind of span the design space, and create a very large number of adjacent systems, and some far away systems, you need a catalog of components, a catalog of component models, and some rules by which you can compose those components into systems. And your component catalog needs to be a couple orders, managed to bigger than a typical system design.

22:30So if you have a million unique parts in a system, your component catalog maybe needs to be a hundred million or a billion parts. And so A, you need to create that component catalog. Okay. Today we do it manually. We are building a lot of automation and a lot of actually AI tools to help us build that component catalog of component models. Then you have to intelligently assemble those components. So it's not a tornado flying through a junkyard and assembling a 747, right? But you actually have some method for creating it. And then you have to simulate each of those and get a performance vector, right?

23:07That's the training data set. And so it's supply chain informed because in theory all of the components in your catalog either reflect a real component in the supply chain Or you can introduce hypothetical components, right? Because sometimes innovation is not just assembling things that exist But saying, hey, I need a new motor. I need a new compressor. I need a new this new that yeah, right? And so you can introduce new components that don't exist But you know what those are and and how you plan to get them. Yes, right? So that's what we mean by supply chain informed and physics -based means that the rules of composing those components model all of the relevant modalities of interaction that you care about the phenomenology of how they interact and the designs that are produced are in fact realizable designs.

23:53I'd love to hear the customer back perspective. So you were previously, you know, you've been the customer before, notably you were the CTO of Airbus. Maybe can you can you just walk us through for those of us that haven't been inside the belly of the beast of an industrial heavyweight. What is the process like to design a new airplane or what are all the engineers at these companies doing and what does their life look like before and after engineering AGI? Yeah, it's a very good question. So I think I gave you a reasonable abstraction of what an engineer does, which is they operate with some set of requirements.

24:29They may not be system level requirements, right? the engineer may be working on a subsystem or an assembly or a widget, but they still have requirements. They still need to pick the key design drivers from those requirements, figure out what are the solutions, do first order sizing, and then do the detailed analysis. That workflow gets replicated in a fractal way throughout the system and throughout the engineering organization, which is designed to mirror roughly the product that you're building. right? And and and one of the reasons that we position Archie as both an agent, meaning that it's he's fairly autonomous, so it's not an assistant.

25:08He's really designed to augment a team versus helping an individual, right? So you we are trying to position Archie as an as an employee that joins a team. One of our sort of mission statements is an Archie on every team in every major industrial company in the world. And Archie joins the team and the goal is to sell work not software to these companies. It's very, very difficult to sell software, engineering software to a company like Airbus. There are hundreds, if not thousands, of engineering tools in the ecosystem. And they are connected in various intricate, to put it politely. Right, sometimes in elegant kind of glue wear ways, and introducing a new tool into that ecosystem is very, very complex.

25:58On top of it, the labor budget for these companies is much bigger than the methods and tools, sort of software budget. So you want to tackle the labor piece, not the tools piece. And so Archie is really designed to show up on the team and be a remote engineer. So obviously there's no embodiment, but he shows up on Slack or on Teams or whatever, collaboration tool you're using, and you task him as you would a junior engineer who happens to be maybe at an offshore engineering center. And you interact with him that way. So there is really minimal friction to introducing, introducing an archie into the organization.

26:33You don't need to do anything differently. You don't need to change your processes. You just have this lower cost entity that shows up. Archie will probably be better at some things, maybe worse at other things, but the goal is to position him as a worker. Why Archie? Where did the name come from? Well, so it's letter A, so it allows us to have a Bob and a Charlotte and a Daniel right down the road. Archimedes architect. All of those are, I think, connotations that are relevant to what we're doing. What sorts of problems do you think Archie will be tackling? and how do you expect that changes with the human engineers on the team are doing?

27:16So in the data center application, which is the first one that we expect to pilot this year, we think that the probably most promising, but also the most applicable use case for our chief, as we bring him to other domains, is doing basically product customization. So semi -custom, they call it specials in the data center cooling world. And this is taking an existing product platform and customizing it for a specific customer's use case. And so to meet architectural requirements, right, to meet functional requirements, to meet building codes, et cetera. And that tends to be different and fairly bespoke on a case -by -case basis.