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

Again, when I was asking the question over the last couple of years of like, why isn't anybody working on AI for building the physical world? The answer was training data, right? Fundamentally, if you want an AI engineer that can help you design an airplane or modify an airplane and you say, hey, 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.

Today, we're excited to welcome Paul Eremenko, 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 coolers 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. Paul, thank you so much for joining us today. And we're delighted to have both you and your Jack Russell terrier Beag Eagle Mix Lee on the show. Welcome. Let's start off with. We just had our AI conference, AI Ascent. And you know, at the conference, Jeff Dean was talking about, you know, the, the potential for vibe coding and how, you know, a 247 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 is 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 of, 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 still isn't right. And 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, we're very grateful to have him as an angel investor in the company. And I think the, you know, coding AI has been a long time coming. One of my co founders, Sushmit jad, 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, I 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 type techniques to create physical designs. So 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?

Yeah. 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. Right. Fundamentally, if you want an AI engineer that can help you design an airplane or modify an airplane, and you say, hey, 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, and 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. 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 set. It is synthetic, that is physics based and supply chain informed of hypothetical designs in whatever physical product domain. So it could be airplanes, could be something else, and making it large enough and make it interesting enough. So the design space for most physical products is almost infinitely large. Right? Like it'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, so creating these, these data sets for, for training models, that's, that was sort of the, the core of, of our approach. Then of course, if you just take, if you now have a million airplane designs and a performance vector for each one and you throw it at LLM in post training or, or even in pre training, you're not going to magically get a good engineer. Right. So then there is the question of what does 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 that do different parts of engineering reasoning and then they're all orchestrated by kind of an orchestrator reasoner 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 a, you know, a engineer's brain? And how do you kind of put that knowledge into a model?

And 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'll 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. And 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, doing first order sizing of what is the, what does 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 multiphysics systems. So they have electrical and thermal and vibrations and electromagnetic interference. And sometimes those matter, sometimes they don't. And humans are very good at, good engineers 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? And 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 at 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. But 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 learned that they are there and their range of validity 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. So 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 reasoner orchestrator that's good at taking tasking from humans in an organization and decomposing them into the right sequence of primitive operations. And then models, some models are neural and some don't need to be neural. That are actually good at then carrying out those operations. And so some of the things that are behind the orchestrator reasoner are for instance a graph neural network that's just very good at being a physics based surrogate model over the performance space. Right? Like 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. You don't need neural capability. Some of the more complex ones you can do with VLMs. I think that there are, there, there is yet another category of, of physical reasoning operations that we, we don't yet know how to solve. And I think that there will be a generation of, of AI models that's coming that are, that are physical world models that will have better intuition for spatial, for some of the more complex higher order spatial reasoning tasks. And then you have physics reasoning, right? You have sort of your, your multiphysics 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. It's no longer good at English, but it is very good at doing programmatic representations of multiphysics 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 reasoner that is also the interface to the user.

What is ARCHI capable of doing today? How does that compare to your average hardware systems engineer today? And what's ahead for archi?

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 pre seed is basically a toy demo around residential cooling systems. So there's like air conditioning units, those kinds of things. And the reason we chose that is because it's a fairly multi physics domain. So you have fluid flows, you have air flows, you have thermal interactions, you have electrical systems. Right. So, so it's rich, but the number of components in a system is not very large. And a lot of the, the physics phenomenology is pretty linearizable. Right. Like you can, you can simplify it. So it's kind of rich enough to, to be convincing but not so complex that we're bogged down in, in data generation, for instance.

Right.

Or the supply chain piece, which I want to come back to getting that right. And 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's no other than a vibe test 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 system AIs, for physical engineering AIs. And by the time this airs, 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. So 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, 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 this 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, for each product domain, for each product vertical.

How do you guys think about that map? You know, 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. So first of all, residential for us was just kind of a toy problem that we chose. Our first market where, where we plan to deploy with a customer, with a design partner is actually data center cooling systems. Okay. Which are still thermodynamic engines. Right. So they're not. They' that different from residential H Vac, but they're 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 pacing data center development, which is kind of wild. So 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 1000 unique parts in the system. The physics domains are quite rich, but the physics Again are still pretty linearizable. Right. 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, this physics based synthetic training data complexity. And so our expectation is that we will go roughly an order of magnitude up in product complexity every year. So the second vertical is probably industrial systems. So things that go into a factory from material handling, industrial robots, mills, lathes. Right, those kinds of things. Then we move into mobility domains which could be automotive, it could be agriculture, mining equipment, those kind of 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 1,000 unique parts, airplane, roughly a million unique parts. Right. So three orders of magnitude between them. And we think based on sort of our current projections, this 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 ARCHI 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 cost data. That's not something you learn in college. 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, 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 and then Archie can start learning on the things behind the firewall, obviously subject to the customer'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. Quality escapes. Right? Those, there's, there is a bunch of stuff there. And, and, 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, in, 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 Bloom's Taxonomy, which is a cognitive knowledge taxonomy for human learning developed in the 50s and has been applied to LLMs in recent years. We have adapted it kind of to the engineering task. And so the taxonomy has kind of a pyramid, right? The lowest level you have just recalled 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. And then kind of the highest, the pinnacle, which we call EAGI 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 and your own limitations of the engineering process. And 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 AGI on one axis, AGI on the other axis, or AGI 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 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 you know, more data, more computes, bigger models. You're going to be able to kind of solve these much more complex systems in the future? Or do you think there's going to be research breakthroughs that are 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, 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 the synthetic data, because that's a lot of simulation and sampling and things like that. And then there is GPU compute to train GPU compute for inference and all of those today I don't think we could do for a million part system. Right? Because if you think about it, and maybe to tie back to your question Pat, about where does the supply chain come in? So how do we create these synthetic data 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 faraway 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 of magnitude bigger than a typical system design. So if you have a million unique parts in a system, your component catalog maybe needs to be 100 million or a billion parts. And so a, you need to create that component catalog. 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 junk, going through a junkyard and assembling a 747. Right. But you actually have some, some method for creating it. And then you have to simulate each of those and get a performance vector. Right? That'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 or 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 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 that the designs that are produced are in fact realizable designs.

I'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, you know, 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. I think I gave you a reasonable abstraction of what an engineer does, which is they operate with some set of requirements. They may not be system level requirements. 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 kind of 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 one of the reasons that we position Archie as both an agent, meaning that he's fairly autonomous, so it's not an assistant. He's really designed to augment a team versus helping an individual. Right. So we are trying to position Archie 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 is 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, sometimes inelegant kind of glueware ways. And introducing a new tool into that ecosystem is very, very complex. On top of it, the labor budget of 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 an Archie into the organization. You 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 what the human engineers on the team are doing?

So 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 Archie 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. And that's where most of the engineering hours go. And so that's the problem that we're tackling first with archi, but that problem translates to other domains pretty well. Airbus for instance, very seldom does a clean sheet airplane design, but does a lot of derivatives or a lot of what's called head of variants, which are a particular product for an airline, Right. With a specific cabin, specific in flight configuration, in flight entertainment configuration, specific cockpit requirements, et cetera. Right. So that's what most engineers at most industrial companies do is semi custom, sort of semi customization.

If we go to like 2030, 2040, some long term time horizon, and there are millions and millions and millions of Archies and maybe Bobs and Charlottes and Daniels out there in the world and you've achieved engineering AGI for the physical world, how will sort of the average person feel the impact of that? Like how will they notice that their life is different as a result of engineering AGI becoming a thing?

So I think, I think it's a time horizon question. Right? And I am hesitant to predict anything that's more than like three years out, especially in these steeply exponential times. But I think the, I think in the first instance where Archie shows up on engineering teams and makes the team more productive and maybe helps the team do things more efficiently, one use case that we've Talked about is if you have an Archie on every team, can the Archies coordinate amongst themselves better than the humans between the teams and sort of speak their own shorthand and do those kinds of things? So that's really about improving the, the efficiency and the efficacy of existing engineering organizations. So for the average person, the impact is lower cost goods. Right. And products.

So you're saying I can buy an airplane?

Perhaps, Perhaps. I think the really interesting stuff starts when Archie can design things that we can't. Right. And that's kind of the super intelligence part, where it's not just about efficiencies of existing organizations or increasing the bandwidth of existing organizations, but really designing the stuff that was promised to us in the sci fi books. So the starships and Dyson spheres and Matryoshka brains and those kinds of things. So ultimately I'm a dreamer. That's why I started this company and that's the future that I want and that's squarely the North Star that guides us. But of course we want to build a pragmatic and profitable business in the.

Meantime, our partner Konstantin has this term the stochastic mindset, which is if you think about working with computers in the past it was predetermined. You ask for this, you get this back. Versus with models, there's a stochastic part of the nature by definition. How do you think about managing around that in your domain? Because if I think about it, I can vibe code a web app, and it's okay if it breaks, not great. If I vibe code an airplane and it breaks. Right. That's disastrous. And so how do you think about managing around the stochastic nature for the physical world?

Well, humans are pretty stochastic as well.

Right.

So if you have a junior engineer working on a task, they'll make mistakes, they may not do the right thing, they may not be repeatable. So I think the question that we need to quantify, and we expect expect to quantify in our pilot later this year is what is the error rate coming out of archi? And if that error rate is comparable to human engineers, then there are a lot of checks and balances built into the existing engineering organizations to ensure that a mistake that a junior engineer makes doesn't bring down an airplane. So there's layers of review, there's milestones, there's tests, there's a lot of those layers. And so if ARCHI has a comparable error rate or better error rate, then it should be a pretty seamless slotting into the existing processes.

What does the Engineering org of the future look like? Do you think we'll have one person, Airbus equivalents in the future?

So again, I'm reluctant to forecast the future beyond sort of three years out. And I think in the next couple of years our goal is again, an Archie on every team. So 10% of the workforce is Archies. They do the work that humans maybe find boring, dull, right. Repetitive, and maybe there's additional value adds like into Archie's coordination and things like that. And then I can imagine a super intelligence where you tell it, I want you to start building a Dyson sphere and it starts building the Dyson sphere. The what's in between? Difficult to forecast.

Okay, lightning round, I'll go first. What application or application category do you think will break out this year?

So I think we're getting close to physical AIs, not in the sense that we're talking about them, but in the sense of robotics as well as foundation models for ingesting real world sensor data. And I think both of those are actually quite important, important building blocks to what we're trying to build. And I think they're very, very close.

Humanoids, yes or no?

Yeah, I think humanoids, yes. Humanoids, yes. On the same basis that we are trying to build an agent that slots into existing teams. I think humanoid robots can slot into existing, existing environments much more easily, even if they're not the optimal sort of the optimal configuration.

What one piece of content should AI people consume?

I think everybody should read or go reread Asimov's Robot series. Ah, good one. Because I think the laws of robotics were very carefully thought out and are a lot of what actually needs to be built somehow very deeply into these models to ensure alignment.

Very good one.

What other startups do you admire?

I think that a lot of the work that is being done on models for ingesting physical world data I think are kind of unsung, but are incredibly important. And the reason, if you don't mind a slightly longer answer to the question, the reason I think they're important is, look, we don't know why neural networks work fundamentally, but we have a vague neuromorphic, anthropomorphic kind of, of a view that, oh, we're trying to kind of replicate what a human neuron does and then you do enough of them and you get these wonderful emergent properties. But then if you take that further and you say, well, how do humans acquire knowledge like a human baby? The very first thing they do is touch, right? The taste, hearing, eventually vision, then language, then higher Order, engineering reasoning, spatial reasoning, those kinds of things that are maybe built on top of language or maybe built on top of some of the other perception and sensory models that they have. With LLM or with deep learning, we've replicated the neural structure to some approximation, but then we said because of data availability, we're going to go language first and we're going to scrape the whole Internet and then we're also going to do imagery, so vision. But we've skipped touch, taste, hearing, etc. Right. And touch, I think is particularly important for building a sense of perception. And I keep coming back to spatial reasoning and the ability to abstractly think about three dimensional, three dimensional objects and three dimensional structures. And so I'm very bullish on. There's a number of companies. One archetype is a good example, founded by one of my former colleagues at Google, that's working on a foundation model for ingesting sensor data. And that foundation model has actually demonstrated that it can infer some of the physics underlying that data, which I think is immensely cool. And I think all of those building blocks ultimately may need to be there for the engineering AGI to happen, that just language and vision is not enough.

All right, last question. What AI app is your personal favorite to use?

The less interesting answer would be like ChatGPT and Cursor, which are both there. The perhaps more interesting answer is we just recently, you know, as we were coming out of stealth, we wanted to produce a video that kind of shows that North Star vision that we've been talking about of ultimately engineering AGI and the path to get there. So we, we worked with a studio called Imix, which is an Israeli LA kind of kind of thing. They did the, the Trump Gaza video, if you guys know, the went viral maybe a month or so ago and they did a fully AI generated kind of two minute Archie biopic clip, which is on our, people can see it on our website. And it was completely AI generated. It was done in two weeks and it was done at about, I would say a 50th of the cost of what a comparable piece of content would have been without AI. But everything, voice, video, music, everything in that, in that short film is completely AI generated using a variety of models, some of which are their own, many of which they stitch together from the ecosystem. But to me, I was absolutely blown away. Very cool.

Wonderful. Paul Lee, thank you so much for joining us today to share more about your vision for the future of engineering AGI for the physical world. We're excited for the day where you bring down the cost of buying an airplane. And in the meantime, excited to see what Archie can do.

It's our pleasure. Thanks for inviting us.

Thank you.

Sam.