Specialized AI brains for physical industry

Her case lives on the supply side, meaning the customer’s data, and it has three parts. Industrial data is fragmented across legacy systems of record: in manufacturing alone a customer might run an ERP, an MES and a PLM, some of them on the company’s own servers, alongside piles of PDFs in SharePoint and email. The data is conceptually related but not practically linked. It is also unstructured, and unstructured in two different ways. Maintenance logs and similar text actually suit language models well, but blueprints, schematics, diagrams and 3D models look nothing like what the big models were trained on. And it is private, sitting on the customer’s cloud or on-premise rather than in the public domain, which is why she thinks general models read a technical drawing poorly: they have not seen enough of them. One scope qualifier is easy to lose here. Kann asked whether this is special to physical industries or true everywhere, and her answer was that there is probably some of it everywhere but more of it here, a difference of degree rather than kind, with the tooling older because there has barely been a category-defining product built for hardware engineers since the 1990s.

The catch is that the wall keeping the big labs out also keeps the startup out. Kann presses this hard: if the training data is private, you have to train on your customers’ data, they will not like that, and if you cannot get past it you never build a product that scales or improves. Smith-Eppsteiner says she thinks that is likely true, and her supporting evidence is commercial rather than technical. A founder she knows wrote training rights into every master services agreement from the start, found it very hard to get signed at first and now finds it boilerplate, and regards that clause as what made the product both performant and defensible. So the moat and the barrier to entry are the same object, and the defensibility argument is only as strong as a young company’s ability to win a contract term.

The demand-side leg is weaker, and she says so herself, calling the data points the main thrust. Her demand argument is the great crew change: experienced field engineers and technicians are retiring faster than they are being replaced, so the same work must be done by fewer people and the expertise sitting in their heads needs capturing. Kann’s objection is that this is a genuine macro driver that plays out over decades, a slow-release painkiller with no urgency behind it. She concedes it is a long-term trend and counters with customer sentiment rather than purchasing behavior: in oil and gas, customers described it to her as a major pain point and a real fear. On whether a specialized product can be built economically, she reports founders getting to roughly 70% to 90% of required performance on prompt engineering alone, leaving open whether that is sufficient or whether a person fills the remaining gap. Past that the approaches scatter. She hears that embedding works poorly on non-textual data, that fine-tuning is the natural next step, and that some teams intend to build their own models, and she describes the field as very early innings.

The last turn is economic, and it is where Kann is most skeptical. Plenty of these applications are obviously useful without being large; his example is siting optimization for energy developers, which he thinks is genuinely valuable and not a venture-scale business by itself. Her answer is about stickiness and expansion rather than proof. Upstream work like siting and permitting runs on third-party external data, and when they talked to customers those customers sounded ready to switch tools, whereas a product deeply integrated with a customer’s own data, with a model trained on it, is much harder to leave. Expansion comes from embedding into the transaction layer sitting above the workflow, her example being the fines for missed delivery appointments in trucking. Underneath sits a business model choice with real consequences: sell the technology like traditional software, or sell the work and absorb the AI cost yourself, which she finds most attractive where the customer already outsources that function. Either way inference cost is not trivial, so she expects gross margins in the 40% to 70% range rather than the 90% of classic software, and layering services on top lowers margin further while raising the dollar value of the contract. The prize she names is a budget shift: industrial companies have limited willingness to pay for software but spend heavily on labor, so a product sold as labor augmentation reaches a much larger pool. Whether that actually happens, she says, is still to be seen.