Village Global Podcast - The AI Engineer Every Industrial Company Will Need _ Paul Eremenko _P-1 AI_ _ Jeff Immelt _NEA_
Summary
本期播客由Village Global主持,嘉宾是P1 AI创始人兼CEO Paul Aromenko和NEA风险合伙人、前GE董事长兼CEO Jeff Immelt,主题是为物理世界打造AI工程师。P1的旗舰产品Archie是一位AI机械与电气工程师,像初级工程师一样使用相同的工具与人类工程师协作,帮助工业公司在工程人才短缺的时代加速研发。Paul解释了核心难题:与代码不同,飞机等复杂系统缺乏海量训练数据,因此P1用基于模型的工程方法生成“半合成”高质量设计数据来训练定制模型。P1的商业模式很独特——不卖软件而是卖“劳动力”,按固定薪资收费,把Archie定位成一名远程初级工程师同事,从而切入远大于软件预算的人力预算并降低变更管理成本。他们强调数据隔离与IP保护,客户数据仅服务于该客户,并提供云端、私有云和完全本地化气隙部署等多种方案。Jeff从工业领袖视角给出建议:企业要建立能力、明确投资优先级、讲好故事,并警惕停留在概念验证而无法进入真正创造价值的商业化阶段。两人都认为AI主要带来劳动力增强而非替代,如放射科因成本下降反而岗位增多,同时行业需在ROI和叙事上做得更好。最后Paul谈到“奇点”临近,抱持技术乐观主义,希望参与引导人类走向美好的未来,而Jeff指出企业和工具都需要被根本性地重新设计才能真正拥抱这波浪潮。
Highlights
-
The F-35 is the most expensive thing that human civilization has ever built with or without taking inflation into account. And it has the biggest cost variance since, you might argue, since the Gothic cathedrals.
F-35是人类文明有史以来建造的最昂贵的东西,无论是否考虑通胀都一样。而且它的成本波动之大,可以说是自哥特式大教堂以来最严重的。
Striking, memorable claim that frames the entire cost-complexity problem -
If 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 Wright Brothers. It's like order hundreds to thousands and they're not really readily available or accessible.
如果你想让AI成为一名优秀的航空航天工程师,它需要看过数百万架飞机。而自莱特兄弟以来,根本就没有数百万种飞机设计,数量只有几百到几千,而且这些数据也并不容易获取或使用。
Crisply explains the core data-scarcity insight behind the whole company -
The second way to sell to them is labor. And 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. We charge a salary. We don't charge for compute. We don't do consumption pricing. It's a h ...
第二种向他们销售的方式是卖劳动力。在大型工业企业里,这是一项比软件支出大一个数量级、有时甚至大两个数量级的预算项目。我们收取薪资,不按算力收费,也不做用量计价——对他们来说这就是一个人头编制。
Counterintuitive go-to-market strategy: sell an FTE, not software -
My Twitter bio for a long time was like, I hope to be around for the singularity. That's no longer my Twitter bio because I'm pretty sure I'll be around for the singularity. And the question is, are we 24 months, 48 months, or five years away from it?
很长一段时间我的推特简介都是'希望能活到见证奇点'。现在这不再是我的简介了,因为我相当确定我会活着见证奇点。问题只在于,我们距离它是24个月、48个月,还是五年。
Bold personal conviction that the singularity is imminent within years -
The companies need to be fundamentally redesigned. Your customers need to be fundamentally redesigned to use the tool. The tools have to be democratized. Human resources has to be redesigned in order to get people aligned with what the capability of these tools are.
公司需要被根本性地重新设计。你的客户也需要被根本性地重新设计才能用好这个工具。工具必须被民主化。人力资源也必须重新设计,才能让人们与这些工具的能力对齐。
A veteran industrial CEO's blunt warning that org transformation, not just tech, is the real challenge
Full transcript
If 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. Welcome. I'm Ann Dwayne 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. But wait, there's more.
Jeff Immelt, venture partner at NEA, is joining P1AI'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 Dextotop Metal, Form Labs, 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 has spent a career leading and transforming engineering organizations at global scale. We're going to talk today about why mechanical and electrical engineering is ripe for AI leverage for Marchi, 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 if somebody who actually wrote the book or who's behind that. But he never seemed to have written anything else. But this book came out in the 70s. And it's 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. Great. 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 so 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.
The biggest part of the human experience is the physical world around us, but 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 powder, 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. Doesn't matter. And it has the biggest cost variance since, you might argue, since the Gothic cathedrals. So here it may come in because they picked the wrong engine. It was the mean issue. You have 35. We'll leave that debate for another day.
Yeah, thanks, Jeff. For the listeners who may not get the jab, it's a Pratt and Whitney engine. And I used to be a chief technology officer at United Technologies, which was the parent of Pratt and 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? Is 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.
semiconductor design. And 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
And 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 P1AI 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 know, you have 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. And they're just haven't been millions of airplane designs since our 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, can we
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've 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.
right? 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 that hark back to, you know, 15 years ago at DARPA for creating these semi synthetic training data sets and physical in physical product domains. And that was one of the core founding ideas of the company. 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 semisynthetic 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, and even for an expert human user doesn't converge most of the time. And then you got a troubleshoot part of this, 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. The 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. There 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. So behind that piece of data. Another part of that part of that harness is things like structured representation. So what is the actual design? You know, when you when you have a coding agent, and it is reasoning on a piece of code, that code is 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? Is it a bill of materials, which is just a list of parts? Is it a schematic? Is it a 3D model of that system? 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 agentic 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.
And 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 the, in various facilities in the Agenda Carnus. The last thing I'll mention.
about sort of 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. These are companies like United Technologies, Airbus Boeing, et cetera. And selling into these companies, you can do it one of two ways. You can either sell them a piece of software, 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. 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. And here you're competing, and I'll use the word competing in air quotes, 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 been 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. And 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. So we really try to fit this form factor and minimize the amount of change management that you have to do on the customer side. And we think that's a big unlock in terms of selling into this industrial OEM.
Oh, yeah, market. So those are the three, the three big ways that that I think Archie's unique. And Jeff, did you ever think that teams in companies you were working with would have these kinds of employees? You know, and 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 I've been at NEA for about eight years. I do about half health care, about half tech. But in tech, I really hang around the enterprise and industrial applications. And that's really what interested me in P1. 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. Those two things are 90% of the value of your company.
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. If you're going to design a new jet engine, you probably have to use 2,000 engineers, Paul, to do that and maybe 10% or 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 attracting the end to P1. These are the companies that interest me because I think they add the most value. And what I like about policy now is the use case. You know, in other words, you don't want to founder to walk in and say, you guys are idiots and you move too slowly, OK? That's the way it comes in. When I was in your chair, When I was in your chair, this is what I thought about. And I think that's how change has to happen. 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. 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. So there's many phases of the engineering lifecycle. 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 pre-sales and sales to conceptual design, preliminary design, detailed design, and verification and validation.
Archie can, in principle, work in all of these. So 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 detail design. And most of them are engineering change orders. So this is a read. Once you've done the initial decomposition of the system, you're optimizing the individual piece parts as those piece parts come.
come together, you discover a lot of interactions and incompatibilities and you have to do, you have to do redesign. And that redesign is usually codified as engineering change orders, which is the equivalent of a software ticket, right? The biggest opportunity for Archie is cranking through engineering change orders, cranking through CEOs, but Archie is fully capable of doing other things. For instance, some of our existing customers do a lot of engineer to order.
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 Archie, we've made sure that Archie is particularly well tuned to those particular use cases. But he is not designed as workflow automation. He's really designed as a general spectrum, as a general spectrum engineering intelligence. 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. Archie is anthropomorphized. And what are some of the tips you would have for companies thinking about bringing in agent technology like P1?
Well, I think, and you did ask earlier also about how customers think about ROI of the product, right? And 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, you know, I think Jeff's estimate of 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 kind of low hanging fruit for Archie that are really pure value accretion for the enterprise and just makes
everybody's lives better from 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 because Archie's 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, you know, our positioning is start with one Archie per team. And so this is notably different than some of the software coding agents and like cognitions. Devin is a big inspiration for us. And I think Scott is like, Hey, a human, a human software engineer should supervise like 10 devins or 20 devins or whatever. So we don't 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 kind of 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? And if so, can that coordination because inter-team coordination is one of the big friction points right 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 measureably increase the clock speed of the organization. So that's a pretty interesting kind of ROI use case that we're actively working on. And 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. Create 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, 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? I 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. 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 yeah absolutely absolutely so i think i think one of the really big insights or consequences i'll even say of the of the anthropomorphic model is who's your customer within within these big companies right because the company is not monolithic there's lots of stakeholders And to your point, Ann, about getting trapped in the innovation part of the company and never actually making it into the PNL, right? That moves the needle for the company is a really big failure mode because 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 engineering BKP, the head of engineering. And the topic of security came up. And I think both Alex Karp recently and Satyan Nadella talked a little bit about, especially in technology-driven companies with IP, How is the IP protected? And so Paul, can you think a little bit how you address that? And I probably should say the IP that the company has plus importantly the learning over time because Archie's getting smarter with the team.
Exactly, exactly. So we make a commitment to all of our customers that to the extent that Archie ingests their data, or we as a company ingest their data, whether through Archie or through other means, that data stays with them and is exclusively for their benefit. This obviously is a limitation for us, right? Because if we could cross train on everybody's data, that would be phenomenal. But particularly for our customer base and our types of use cases, this is a non-starter.
So the custom models that I mentioned earlier in our conversation, those custom models we train on our own data sets, on our own semi-synthetic data sets, and those are available to all of our customers. Obviously, they're specific to a product domain or to specific engineering tools, right? So to the extent that the customer is in that domain and uses those tools.
they're welcome to use and benefit from our custom models. We generally do not do custom models on customer data. So that customer data is ingested at the harness level and either creates memories or creates skills. Maybe eventually it'll get burnt into weights, but if it does get burnt into weights, those weights stay with that customer. And that's a hard rule that I think we are unlikely to have the technology to transcend that for some time. So for now, that is a core principle.
under which we operate. We do have multiple deployment models, right? So we do have a model where we host from our cloud. Archie does need to be able to use the customer's tools and data sources the same way as a junior engineer, right? So then we have to create avenues for Archie to be able to get through their firewall and access there.
SharePoint and PLM system and ERP system and particular engineering tools. The second model is we deploy in their virtual private cloud. right? And then they maintain, I mean, it's all the same cloud, right? It's either Azure or GCP or something like that, right? But within that cloud, you can be either an hour perimeter or their perimeter, and we're flexible. And we certainly have mechanisms for doing both of those. And the third one is a fully on-prem deployment. And I think this is what Alex Karp and I think our Jeff, your friends on the All In podcast, we're talking about just recently about the fact that self-hosting, right? And kind of like having an air gap deployment.
may be the future. And so to the extent that there is a segment of the customer base, and for sure national security customers require this, we have the capability to do a fully on-prem deployment with an open weights foundation model. Can you talk a little bit about what you're seeing in compute costs for projects like yours? Well, compute costs are supposed to follow Moore's law, right? And they really aren't.
which is certainly a point that we have to grapple with. I do think that over the medium term... you know, I always reluctant to use the word long term in the AI world, right? It's like long term is like six months, right? So I do think that in the in the reasonable in the human chronological medium term, right, which is over the course of the next few years, I do expect that the compute cost will actually start following Moore's law again. I think we're in a weird place right now where they're flat to rising, which obviously, obviously creates some some cogs consternation for us and for many other players in the space. But I
I think that's a transient effect. I think it's an interesting, not to veer off, but I don't worry about AI in the context of labor replacement. I think we're going to figure that out. I worry about it in terms of ROI.
And I hear more concerns in the world that I come from really about ROI, token optimization, things like that. So I think the more that the whole sector can keep its head around, how do we tell the right stories about the benefits it brings? But how does it drive kind of economic differentiation and performance to the customer base? That's where we need to kind of do better storytelling, I think it's an industry. Well, and I think Paul, you've said 40% of many engineers jobs is repetitive tasks. You know, we can elevate not the people's and deploy their talents, you know, higher order of things. Absolutely. And on the cost reduction front, right? I mean, there's compute costs. But to Jeff's point, there is also the question of model efficiency. And, and I do think again, this is where the agent to Karnas layer of the value chain is a great place to be.
because we have all the flexibility in the world to allocate different types of functionality to different types of models. And we can use smaller models for a lot of things. You don't have to use the biggest trillion parameter or 10 trillion now, right, parameter model. For most of the tasks, there are some unique things that maybe that model can unlock, certain types of reasoning.
But for more mundane things, you can use smaller models. And even for our custom models, which we train, we're actively looking at, can we distill them into smaller ones that are faster and more token efficient?
So we have a lot of levers at the harness level for doing inference cost optimization. I mean, I think that's the advantage of kind of a last mile company, you know, and you you see the whole panorama of companies, but I like the last mile companies because I think they can differentiate value better at the point of attack. And so I think I think whether it's an industry vertical or a functional vertical like what Paul's doing, those are super intriguing to me about about where.
you know, the whole space goes next. Right. And we certainly see patterns in software development, but in mechanical and electrical engineering, for example, right? It seems like it's open field running versus others. So let's talk a little bit about hiring and how you're building your team, because there's some buzz now about the one person billion dollar company, but you're certainly focused on adding amazing talent. And so what kind of talents do you need? And then how do you build a company differently today than maybe you did three years ago or five years ago?
Yeah, that's a really interesting question. Certainly in terms of talent that we need today, as we are embarking on our Series A phase, a lot of it is about revenue scaling and scaling Archie deployments across many customers in multiple verticals. I think I mentioned briefly data centers, our next forays into automotive, and then shortly on the heels of that into aerospace and defense. So the job that's probably most in demand for us right now is this job and we borrow the term from shamelessly from Palantir, the term forward deployed engineer, FDE, which are engineers that go into a customer, make sure that we understand.
the customer's principal use cases, make sure that Archie is really good at those. Again, he's a general spectrum engineer, but even a general spectrum engineer needs some specialized training. And so we make sure that Archie gets that. We make sure that Archie can talk to all of the enterprise systems and has licenses for all of those systems. And that's the job of the FD. And so that's probably the most in-demand role for us right now. We're always hiring AI engineers. And these are people who work on the harness or people who train the small custom models that we do.
course, we hire software engineers and that's where the job has really changed, I think quite dramatically. Jeff, as you were talking a little bit about giving context and narrative to the humans as we're adopting AI, it's such a great point because we talk a lot about context for agents and not enough about what is the context and the harness, if you will, right for the humans that are going to be adopting and engaging with these technologies. So I'm on the board of a company called Radiology Partners. It's 4,500 radiologists and the only future of the industry really is AI enabled.
There's not enough doctors, et cetera, et cetera. And it's all about workflow. It's all about engaging the physicians to better utilize the tools that can produce better outcomes for the patients. And I think that's just a microcosm of what's going to take place as we roll out these tools. I'm 70, right, Ann? So it's hard for me to think too far. But as I think about the next decade of artificial intelligence, it's mainly going to be workforce enhancement.
So how do people to engage how they interact with the tools to provide better outcomes and do it in a way that makes it engaging and not threatening? It's not gonna be the case for everybody, but certainly in the industrial markets, a lot of it's gonna work that way. Well, and I think even in radiology, the data is clear that people thought there would be fewer radiologist jobs, but actually there are more because the cost of scans went down.
and accessibility of scans for many things went up. So it's actually more people employed in radiology and more job openings than in work. In a profound shortage, right? Yes. A profound shortage. So you're really solving problems with technology. And that's the storytelling that basically we need to embrace so that we're not stopping this amazing technology before it starts. And I think that's something we all have to do just a better job of. Well, that's a good segue because, Paul, you've said maybe the singularity is nigh coming soon or whatever. And so first describe the singularity as you see it, but then also what's just the future you're seeing because you're operating at kind of at the edges of innovations?
Yeah. Well, so first I'll say I'm, I'm, you know, a hard sci, hard sci fi purist, right? So, so I'll go, I'll go to the source in terms of defining, defining the singularity, which is Werner, Werner, Vinci. And I think he had a short, short column in Omni magazine and then wrote a longer essay in the early nineties, I think 1993, maybe on the technological singularity. And I think, you know, obviously it is when technology accelerates so quickly that there's a point beyond which we can no longer foresee or predict.
or anticipate what will happen. And I think the reason he calls that the singularity is because singularities like black holes have an event horizon, right? And you can't see past the event horizon. And so I think we are, I think we are, uh, and by the way, I wouldn't have said this 10 years ago, right? Maybe, maybe even five years ago I would have been like, yeah, I don't know that, uh, will I see the singularity in my lifetime? My Twitter bio for a long time was like, I hope to be around for the singularity. That's no longer my Twitter bio because I'm pretty sure I'll be around for the singularity. And the question is, are we
you know, are we 24 months, 48 months, right, or, or, or five years away from it from it. But we certainly do see that tech acceleration. And, and, and that's not a qualitative statement, right? If you look at many, many metrics, right? They're they're very clearly ever ever more steeply exponential. But I think the sort of the key point, again, in this singularity construct is that it's very sensitive to initial conditions, right? And so you can't, you know, the decisions that we make today, we have no way of seeing what are the consequences of those decisions past the kind of event horizon. But I do think but that doesn't mean that we don't have control over it because we're there for the journey and we can make constant course corrections and we can steer it through the through the event horizon, right? This is where maybe the analogy with the black hole starts to fray because
probably pretty painful to cross across a black hole event horizon. But conceptually, right, we can we can steer and make course adjustments. And this is one of the reasons I started this company is because I want to be part of making it happen and part of steering it to make sure that whatever is the future on the other side of the event horizon is a is a is a good future for us.
It's a future in which humans continue to thrive, maybe in a slightly different form, maybe in a substantially different form. But I'm a techno-optimist, and I want to be part of shaping the trajectory of how we get there. And P1AI is really shaping the physical world, how that's built. So on our way to Starships and Dyson Spheres, is there anything that leaders in...
industrial OEMs today should think about, like, how do they really both embrace this or prepare for this kind of exponential? Look, we try to make it very easy for them to adopt AI, right? To kind of, to Jeff's point where he had the four things, we try to answer those four things, make it very easy for them to answer those four things. Let's put it that way, right? And say, hey, You know, it's an AI worker. He's part of the workforce. He's part of the team. You don't need to treat him any differently, but you get all of the benefits of sort of riding this wave. So in a way, we're trying to make the answer to that question really as simple as possible. I think that gets you pretty far, but only so far, right? And I'll be the first to concede.
that certainly today we're talking about augmenting the workforce and helping reshore engineering jobs and those kinds of things. At some point, AI, and we hope to enable this future, because I think, again, this future is going to be wonderful and bright, and I'm very optimistic about it. But the AI will be able to build things that we don't know how to build today. And how you manage a physical, industrial engineering organization with AIs that can build things that transcend human capability to build them or even maybe to understand them. That is an interesting question and I am here for it and I hope to be able to shape the answer to that question. But I'm more inclose to this. What are the next five years going to look like? And I think the challenge for all of
The companies you invest in are the companies that are being spawned in this great ecosystem we're in. Is the companies need to be fundamentally redesigned? Your customers need to be fundamentally redesigned to use the tool, okay? So if you look at most of the modeling tools, they come in through a CIO. The CIO feeds the engineering manager like a child.
You know, like, I'll give you so much money this year. If you blah, blah, blah, blah, blah, that's all going to change. The tools have to be democratized. The engineering leader for aviation companies or defense companies have to be sharper technically to be able to utilize the tools and embrace them and get them into the workflow. Human resources has to be redesigned in order to get people aligned with what the capability of these tools are. So we're going to at least go through this.
where we're really making the things we do today better, faster, more economical, safer, all the things we can do. And then I'll retire and Paul can drive towards the black hole. He can. No, no startups are going to keep us young and fix longevity. That's right. But it is interesting that our tools now use tools in their generative, right? Archie is.
you know, a colleague that's learning and using tools and reasoning over and innovating in a sense. So it's super exciting. A couple of my students in Stanford started insurance.
AI company, native company. And they put up the product roadmap and it's agents managing agents. It's like developing products. It's so interesting and cool to look at, you know, what it looks like, you know? Yeah, we'll see. We'll see. Engineers doing what 30 would have done in a day gone by. And what we love about P1 AI is it's not just insurance claims.
Nothing against insurance claims, but it's also more just amazing things in the physical world. So Paul and Jeff, thank you so much for making time and we're excited for the next chapter. Thank you. Thanks very much. And this was a lot of fun. Hey, this is Ben Keznoka, co-founder of Village Global. Thanks so much for tuning into the Village Global podcast, where we go deep on all of the biggest topics in tech. If you enjoyed this conversation, please subscribe to our YouTube channel. You can check us out on Spotify, Apple, wherever you get your podcasts. We'd love to see you for the next one.