Neural networks can solve physical simulations much faster than the numerical solvers engineers have relied on for decades. That is exciting for a lot of reasons, some of which I wrote about previously here.

But neural solvers can be much less accurate than classical ones. And they’re only fast once they’re trained.

In order to train neural solvers, someone has to generate training data (usually by running the very classical solver the model hopes to replace), then train, tune, and validate it. Those costs might be worth it if speed matters. But maybe not.

So when does paying the upfront cost become worth it?

That’s the question Mikhail (Misha) Khodak, together with Yijing Zhang, Nicholas Roberts, and Tanya Marwah, set out to answer in Breakeven Complexity: A New Perspective on Neural Partial Differential Equation Solvers.

Last week, I sat down with Misha, an assistant professor of computer sciences at UW-Madison, where he's been working on specialized foundation models and folding AI tools into algorithm design and scientific computing. In our conversation, we unpacked the research, the motivation behind it, and the impact he hopes it will have on the broader industry.

“It’s not really a case of ‘we’re just going to replace all the classical solvers with deep learning’” he told me, “There are stages of many processes where different things will be useful.”

The pessimism that started it

In 2024 McGreivy and Hakim from Princeton published a paper that landed hard on the field. “They went through many deep learning papers, mostly ones applying deep learning to fluid simulations,” Misha told me. “They found that in a lot of these papers, the comparisons are mainly against fairly weak baselines. The solvers being used aren’t the ones an actual practitioner would use.”

Those papers were overlooking a knob every numerical solver has, which is resolution. You can always make a classical solver faster by down-resolving. “In practice you can set a lower resolution for your solver,” Misha said. “The speed is determined by how many time steps you take and how fine your mesh is. And they often don’t compare to that.”

A neural network that’s “faster” than a high-resolution classical solver, in other words, hasn’t necessarily won anything, because the honest comparison is on speed against a cheap classical solver tuned to the same accuracy.

That paper, Misha said, “caused a lot of pessimism at the time among the scientific computing community.”

Despite the paper, the field kept building. “I was trying to reconcile this issue where we were still developing these ML methods and some people seemed optimistic,” he told me, “but others, especially in the physics community, would tell you to just down-resolve to get a faster solver.”

Counting solves until you break even

The paper proposes breakeven complexity, a metric that counts the numbers of runs before a learned solver is cost-effective relative to an error-equivalent traditional solver. Error-equivalent here means the classical solver has been down-resolved to the same accuracy as the neural one.

A neural solver only becomes economical when its upfront cost can be amortized. Unlike a classical solver, which pays its computational cost every time you run it, a trained neural network can be reused across every subsequent solve. This is important because most real-world engineering isn’t solving one equation once. As Misha explained it to me, “You are trying to optimize some engineering object. And to do that you have to solve many, many similar partial differential equations.” In practice that means optimizing a design, which requires repeatedly evaluating slightly different geometries, boundary conditions, or material properties. (The paper sets aside real-time applications, where neural networks already have an obvious speed advantage.)

The question then becomes: how many times do you have to run the model before the time you save at inference outweighs the time you spent generating data and training?

The answer, they found, depends a lot on the type of problem you’re solving.

At one end are toy problems, which are simplified academic test cases. “If you want to solve these toy 2D Navier-Stokes with periodic boundary conditions,” Misha said, “you have to perform hundreds of thousands of inference calls before your data generation and optimization cost pays off.” The reason is that for easy problems, the classical solver is very hard to beat even after you degrade its resolution. “For these toy problems there are extremely fast solvers. Even scaling down your resolution, you’ll still end up with a fast solver that is pretty good. So a neural network is just not going to beat it anytime soon. You really need to perform millions of inference calls.”

But as the team moved to harder problems, that changed. As you move to harder problems you require less inference calls in order to make training this neural network worth it. “What happens if instead of Navier-Stokes with periodic boundary conditions you have more regular inlet-outlet boundary conditions, and maybe you throw some blocks in there. Put some obstacles into your fluid flow,” Misha said. “Suddenly that solver becomes very expensive. And scaling down that solver doesn’t just speed it up. The tradeoff becomes much worse. It will be faster but much less accurate.”

On hard problems, down-resolving the classical solver degrades its accuracy, while the neural network holds its speed advantage at comparable quality. The team confirmed the pattern along several axes of difficulty: scaling a chaotic system from 1D to 2D to 3D, predicting further into the future, and pushing fluids toward turbulence.

Model size and scaling laws for training

Breakeven also depends heavily on which model you use. One of the paper’s more surprising findings is that some of the leading foundation models for physics, such as Poseidon and Walrus, don’t always come out ahead. “In some cases the latest large models are actually too expensive to run, at least on the simulations we tried,” Misha told me. “When I say too expensive, I mean more expensive than a reasonably down-resolved classical solver. So it’s not even worth it to run them.” In several cases, well-tuned, smaller neural operators outperformed the larger transformer-based models, suggesting that “it’s worth it to pre-train very efficient models rather than very large models.”

That same philosophy extends to training itself. Rather than simply throwing more compute at the problem, the team uses scaling laws to determine how a fixed compute budget should be divided between generating training data with expensive classical solvers and training the neural network. As Misha put it, “You can very nicely and consistently predict what is the optimal tradeoff as your computation budget increases.”

Even then, “a practitioner should view this as the upper bound on the performance of a neural network for their problem,” Misha said, “because we are training and testing on the same distribution.” Real-world engineering systems inevitably drift into scenarios the model never saw during training, so neural networks degrade in ways classical solvers generally don’t. Therefore, Misha sees this more as a screening test: if a neural solver can’t outperform a classical solver under these idealized conditions, it’s unlikely to do so in production. If it does clear that bar, it’s probably worth trying on your actual problem.

A funnel, not a replacement

Towards the end of our conversation, I asked Misha what he was most surprised by from this research. “I’m more optimistic now than I was before I started this,” he said. “I actually was maybe more skeptical of neural solvers when I came in. And that’s why I wanted to figure it out.”

Misha also described the future he sees with neural and classical solvers as a pipeline. He referenced the illustration from Periodic Labs, a Zetta portfolio company. “The idea was, with these physical simulations, there’s an agent trying to optimize some material or protein or drug. They’re first going to see what heuristics say is a good candidate, then narrow down. Then they’ll try a neural surrogate and narrow down a bit more. Then they’ll try high-fidelity classical solvers and narrow down a bit more. And then they’ll actually have to go to the lab and build the thing.”

A funnel, in other words where we use cheap heuristics at the wide mouth, fast neural surrogates next, expensive high-fidelity solvers after that, and physical experiment at the narrow end. Each stage tuned to a different point on the speed-accuracy curve.

“There’s room for all of these things,” he said. “It’s not really a case of replacing all the classical solvers with deep learning. There are stages of many processes where different approaches will be useful.”

It’s not a question of whether neural solvers beat the classical way, but rather where each one outperforms vis-a-vis the other. The breakeven paper is the first attempt to answer that question with real numbers.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

At this point, most companies and individuals are using a relatively baseline level of AI models’ capabilities. Which means we don’t see huge benefits from each new model release. And yet, AI is still failing across many enterprise deployments. Why?

I think it’s because most enterprise AI conversations focus on the wrong question: what part of our budget can we put towards AI? For example, should we use our existing software like NetSuite or throw AI at it and move to a new AI-native ERP?

Whereas the right question is something more fundamental and not related to AI at all: what are our existing processes and where do they break down?

“You will not transform your company without rebuilding operations from the ground up,” Vas Moza, founder of Varick Agents, told me. Varick is an applied AI company that goes into large enterprise organizations to help them transform from the inside out with AI.

Rebuilding operations from the ground up means knowing what to automate deterministically, what to give to an agent, and what to leave to a human. This isn’t a model or agent engineering question. It’s a process engineering one. “That sort of process reengineering,” Vas said, “is what makes AI 100 times more effective.”

Not every workflow needs an agent

Knowing what not to agentify is the first question to answer when it comes to enterprise deployments – because not every workflow deserves an agent. My mental model for this is:

Deterministic automation is for rules.
If the inputs are structured and the desired behavior can be specified, you probably do not need an agent. You need software. These are for tasks like routing an invoice, syncing a CRM field, checking whether required documents are present. These workflows are valuable, but they don’t need open-ended reasoning.

Agents are for judgment under context.
Agents make sense when the work requires interpreting inputs, pulling context across systems, or executing a multi-step process where the path changes depending on what the agent discovers. The agent is useful where deterministic automation breaks down.

Humans are for accountability, ambiguity, and trust.
Some work should remain human. This might be because the consequences or relationships are too important, or the organization doesn’t yet know what “good” looks like. In these cases, the right AI product might be a copilot, reviewer, researcher, or QA layer.

Then, even once you know an agent is the right fit, you still have to decide whether it’s worth building. That’s a separate evaluation across dimensions like manual hour displacement, key-person risk, cycle-time reduction, revenue uplift, time and cost to build, and, most importantly, expected ROI. “A workflow with a 10x ROI should get prioritized,” Vas said. “A workflow with a 2x ROI maybe, maybe not. And a workflow with a sub 1x ROI should be left alone.”

The decision of where an agent belongs is downstream of all these diagnoses. Crucially, the most painful workflow isn’t necessarily the most valuable one to automate.

The deployment is the product

In many companies, the workflow lives in people, who sometimes can’t actually articulate what it is they’re doing. This is the tribal knowledge problem.

Before I was an investor, I built a company in the manufacturing and supply chain space. I remember trying to understand factory workflows by asking people what they did. They could always show me, but they rarely could explain it.

Vas sees the same thing in enterprise operations. The people doing the work aren’t usually used to narrating the work. They may have done it for fifteen years and know which exceptions are important to document versus which aren’t, but they may not have language for why.

And not all of that knowledge is worth capturing. Ahmad Kakar, CEO of Euclid, which builds agentic systems for trucking and logistics, told me, “The catch with tribal knowledge is that a considerable portion isn’t true expertise – it’s workarounds people built for non-existent or broken systems over the years. If you just capture it and encode it into the agent, you’ve automated the dysfunction. The work is pulling it out of people’s heads and then deciding what was real judgment versus scar tissue.”

The process is also a delicate one because the person whose knowledge you’re asking for often assumes their job is at risk. “We want to make sure they don’t feel like they’re having their entire job replaced,” Vas said, “because most of the time that isn’t the case. There’s a lot of work to be done at growing organizations.”

Troy Shen, co-founder of Cervo, an AI platform for customs brokers, frames the same dynamic as a sales problem. “Successful AI adoption takes two sales, not one,” he told me. “You’re selling an outcome to the executive and a dramatically better workday to the operator who’ll actually use the agents.” And without operator buy-in, the deployment will fail.

I spoke with Bihan Jiang, the Director of Product at Decagon, last year about this topic and she told me that a big chunk of her job is internal change management for customers, not just technical implementation. “There’s often a board-level directive to ‘bring AI into CX,’ which creates top-down momentum and we often end up being a part of many vibrant, cross-functional conversations on the customer’s side because there’s a lot of trust and alignment going into a decision this transformative.”

Suril Kantaria, co-founder of Adaptional, which builds agentic AI for insurance claims, frames the capture process as an apprenticeship. “In many enterprises, work is an apprenticeship model,” he told me. “This is a simple but key insight from deploying into some of the largest insurance companies. To succeed, we onboard like eager new hires — learn how the best adjusters handle claims, make decisions, ensure compliance, and keep up with internal policy. Core to the ‘product’ is both a deep understanding of our domain (insurance claims) and an ability to handle the contours of every customer’s claims process.”

This is what makes the deployment process partly technical, partly anthropological, and partly political. As Troy put it, “Deploy for a Fortune 500 and you’re rolling out across multiple offices, each with its own history, procedures, politics, and attitude toward AI. That navigation takes a rare mix of emotional intelligence, improvisation, and stakeholder management.”

The goal is to create a map of the knowledge tree within a company – things like workflow maps, decision rules, exception taxonomies, escalation paths, eval sets, access policies, approval thresholds, and edge-case libraries. This creates structured logic for an organization that can be inspected and, over time, improved.

Modernization does not mean migration

I’ve argued before that legacy modernization is an important wedge in enterprise AI. This means translating old code into new code and requires a full-system modernization. While this is true, it’s worth noting that sometimes the best first move is to modernize the work around a piece of software rather than the software itself. “We’re not going to force you to migrate off your systems of record, which is the enterprise reality for most companies,” Vas said. “They’re very married to their ERP or their CRM.”

These systems hold years of process and integrations so sometimes it’s easier (and better) to build on top of them. This means connecting them and then extracting the process logic between them. Then give agents the context to execute work across them. “We build on top wherever possible,” Vas said “because there is still so much work to be done that exists on top of these platforms and by interconnecting these systems.”

This approach has limits if the underlying architecture is brittle. This might mean the data isn’t clean, or permissions are broken, and so building on top of these problems means you end up automating around dysfunction instead of fixing it.

The best enterprise AI deployments I’ve seen do some combination. They build on top where possible, then let the agent deployment show what actually needs to be rebuilt. Modernization used to mean making legacy software usable by modern developers. These days, modernization means making legacy operations legible to agents.

The pattern library

Each deployment in services-heavy AI companies looks bespoke. However, there are patterns to be learned in the deployment expertise itself, which makes repeatability across customers easier over time.

For example, after multiple finance department deployments, a company can start to learn patterns around how finance departments run and where they break. Importantly, this compounding doesn’t depend on moving client data around. “We allow our agents to have a higher baseline accuracy,” Vas said, “not because we extract data from our clients, but because we have the methodology and practices best suited for the right-tail edge cases we’ve seen across deployments.” The data from one client does not necessarily need to be copied into another client’s system for the next deployment to improve.

This means you start to learn the workflow archetypes, questions to ask, evaluation harnesses, governance models, etc. Clemens Komorek, CEO of Zalion, which builds AI procurement agents for industrial buyers, sees the value of this at the transaction level. “Every transaction teaches the system something about supplier relationships and negotiation levers,” he told me. “And because supply chains keep shifting, the system has to adapt as outcomes change. This is how localized expertise becomes something repeatable.”

What remains bespoke is the business-specific context. “That part is not repeatable,” Vas said, “because every single business is different. Pretending otherwise is why most AI projects fail.”

The accumulated knowledge is what creates a pattern library and this is the moat. It’s knowing where autonomy belongs and how to turn processes into structured operational logic, built up across deployment after deployment.

Why neither the labs nor the incumbents own this

It is tempting to assume the labs will eventually own enterprise AI deployments because if the models keep getting better, why not just build the agents? And yes, the labs will own a lot of the horizontal intelligence infrastructure, but there’s a difference between selling intelligence versus selling operational transformation.

The labs are optimized for scalable intelligence whereas enterprise transformation is not cleanly scalable. Plus, no enterprise wants its entire company dependent on just one or two model providers because it would make them highly vulnerable.

So there’s still a need for a layer that decides which model belongs where, how to route work, how to control cost, and how to ensure the workflow continues even when the model layer shifts underneath. This is something I wrote about last year – the shift from models to systems.

Consulting firms and legacy systems integrators are the other candidates to own enterprise transformation. They’ve shepherded companies through past technology shifts, and they know how to navigate large organizations. The question is whether they can build and continuously upgrade production AI systems fast enough.

AI moves quickly. Best practices from six months ago are practically obsolete now. “The inertia required to move a large behemoth organization like a McKinsey to become AI-native themselves,” Vas argues, “is insurmountable.” A firm with tens of thousands of employees and decades of internal process inertia may struggle to become AI-native quickly enough to deliver the kind of systems customers actually need.

This is not to say the incumbents will not participate. They will. They already are. But there is an opening for a new category of company that combines consulting-grade process understanding with software-grade deployment velocity. These can be horizontal companies or vertical-specific solutions.

The agent is the mechanism

A company transforms when the relationship across its people, its processes and its outputs change. “Rebuilding a company around AI,” Vas said towards the end of our conversation, “means starting to understand where the processes themselves break down. It’s not about slapping AI on top of operations that aren’t yet designed for it.”

In many cases, this means rebuilding the operating model from the ground up. And in that new model, plenty of work still belongs to humans or to deterministic automation – not to agents. Where an agent actually belongs is something you discover through the deployment process itself. And that’s what compounds – the accumulated knowledge of where autonomy works and how to deploy it.

After all, enterprises aren’t looking to buy an agent. They’re looking to enable their business to be better than it is today, either with more efficiency or with greater outcomes than they could reach before. The agent is just one mechanism.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

We can read every weight in a large language model and still can’t really say what the model is doing. Why then would tracing every connection in a brain, a far harder problem, tell us anything we couldn’t get more cheaply somewhere else? It sounds like a reason not to bother mapping brains at all.

Adam Marblestone thinks it’s the opposite. runs Convergent Research, a nonprofit that incubates what it calls Focused Research Organizations (FROs), mid-scale science projects that are too capital-intensive and engineering-heavy for an academic lab but too far from a product at the start for venture capital.

“When many AI people or computer scientists hear ‘map the connectome,’” he told me, “I think they hear ‘we’re going to map the weight matrix. We’re going to know all these weights.’” That, he thinks, is the wrong way to picture it because the weights are not where the interesting information is. “The weights are just as much a function of what you trained it on as it is anything about the architecture of that system. So I actually don’t really care about the specific weights. What I care about is the architecture.”

Outside the trained weights

To understand why Adam doesn’t care about the weights, it helps to look at how an AI system actually gets built. When you train a neural network, the decisions about the architecture, the goal it’s optimizing for, the data it learns from all live in the code the researcher writes.

“I have some PyTorch code that sets up the architecture of the network. I write in code what the loss function is. I feed it data. And then in the end I end up with a weight matrix that lives inside this box.” As he puts it, “a bunch of the interesting stuff about what the researchers actually did isn’t in the weight matrix.”

But the brain doesn’t work that way. There’s no separate code, it has to build everything out of neurons: “The learning signals are neurons. The basic architecture is how the neurons are initialized and how they’re connected. The cost functions are specific neurons that deliver whatever that reward signal is. Everything has to do with neurons. It doesn’t have a separate programmer.”

In an AI system, the design sits in the code itself, outside the trained weights. In a brain there’s no such thing as “outside the trained weights,” so all of the design has to be built physically into the cells and their connections.

Adam develops this further in his paper, The Sweet Lesson of Neuroscience. In it, he references Steve Byrnes’ work, which recasts the entire brain as two interacting systems: a learning subsystem and a steering subsystem. The first learns from experience during the animal’s lifetime. The second is mostly hardwired and sets the goals, priorities, and reward signals that shape that learning. The learning subsystem is what learns. The steering subsystem is what decides what’s worth learning. For more on this, here is another good overview on the two subsystems.

The steering subsystem’s circuits aren’t a record of anything learned. They are the design, hardwired by evolution, with the reward signals written directly into the cell types and their wiring. That is why Adam cares about reading out the steering subsystem and not the learned weights of the cortex. The cortex’s wiring is mostly a snapshot of values it acquired through experience. The steering subsystem’s wiring is the genome’s specification itself. wrote a good piece that dives deeper into Adam’s thinking on this.

Fei Chen and Evan Macosko, the PIs from the Broad Institute who published one of the original whole-mouse-brain transcriptomes, find evidence of this in their work, Cellular Scaling Laws in the Mammalian Brain. The largest number of distinct, bespoke neuron types sits in the old deep structures, the hypothalamus and brainstem. These regions have far fewer neurons overall but a much wider variety of them. The cortex is the reverse. It is large, but built from many copies of a few repeating templates.

This fits what the framework predicts. The cortex works like a neural network, so it can learn almost anything and doesn’t need specialized hardware. It just needs many copies of the same flexible units. The steering subsystem has the opposite job. It encodes specific, hardwired goals: hunger, thirst, fear, the drive to mate, the urge to breathe. Each is something the genome has to specify in advance, because an animal can’t afford to learn them by trial and error. So if the steering subsystem really is the brain’s hardwired reward function, the bespoke cell-type diversity should pile up there too, in those deep structures rather than the cortex. And that is what the research shows.

A thread of work that Adam began a decade ago along with at MIT helped start the use of expansion microscopy and in-situ sequencing to read out neural wiring. Adam later helped popularize FROs as a way to fund this kind of infrastructure-heavy science. The mapping itself is now being pushed by E11 Bio, the first FRO spun out of his Convergent Research, which is trying to drop the cost of a mouse-brain connectome from billions of dollars to low tens of millions. The hope is that mapping at high enough resolution would expose the brain’s design: not the trained values, but what specifically produced them. “Once we’ve done that, I don’t actually care that much about the specific weights,” he said.

Mapping the reward functions

A detailed enough map, the thinking goes, would expose the machinery that computes internal rewards. “It might be that the infant is trying to first establish eye contact, or it’s trying to find and pay attention to novel stimuli or something like that versus boring stimuli,” Adam said. “Am I making eye contact with the parent? Am I finding novelty? Am I controlling my environment? These are all things that the brain probably has to have some way of detecting and rewarding.”

On the podcast, Adam argued that the field has tended to neglect the role of these very specific reward functions. Machine learning gravitates toward mathematically simple objectives, like predicting the next token. His hunch is that evolution did the opposite, building a lot of complexity into the brain’s reward functions: many different ones for different regions, switched on at different stages of development. If he’s right, those reward functions in the brain would each be a group of cells you could in principle point to.

A detailed map is the starting point, but what Adam really wants isn’t the frozen snapshot so much as the process that generates it: “I want to understand the drivers... how it starts out and then how it learns within the lifetime.” He acknowledges that the translation from a static map to a complete description of “what is it trying to do” will be hard. “Will you be able to actually translate between a map and that information? Maybe,” he said. “But if not, I still think that having the maps is going to be a multiplier on the rate of overall neuroscience progress.” So even in the pessimistic case, where the wiring doesn’t hand you the algorithm, the map still accelerates everything else.

Why the mapping is so hard

In October 2024, the FlyWire consortium, which includes Greg Jefferis’ group and collaborators at Cambridge University, Princeton and the University of Vermont, published the first complete wiring diagram of an adult fruit fly brain: roughly 140,000 neurons and more than 54 million synapses. Producing it required slicing a single fly brain into thousands of ultrathin sections, imaging each with electron microscopes, and using machine learning to stitch the images back into a 3D reconstruction. A fruit fly has on the order of 100,000 neurons. A human has something closer to 100 billion.

To address this, E11 Bio is making comprehensive static circuit maps more scalable. The core bet is a shift in imaging physics: “The traditional way of doing static circuit mapping all the way down to the neuron and synapse level is the electron microscopes, which are extremely precise in what they can see spatially, but they are not easily scalable... If you can switch that to using a light-based microscope rather than an electron-based microscope, it’s much easier to have thick pieces of tissue that you can sort of see through and are much easier to handle.”

Light-based methods bring a second advantage: they can read out molecules. “It also gives you the advantage of being able to see molecules kind of overlaid — so what are the specific receptors and transmitters that are used by the synapses?” This is important because the brain’s connections are not uniform in the way an artificial network’s are.

“Unlike in a computer, where there’s maybe a few types of connections, there’s actually many different types of connections in an actual brain,” Marblestone said. Excitatory or inhibitory, but also varying in their time scales and in how they adapt and learn. A wiring diagram that only records which neuron connects to which, with no read-out of the receptors and transmitters at each synapse, would miss most of what tells those connection types apart. And thus, much of what distinguishes one learning rule from another.

This is the focus of a second FRO Adam is helping to catalyze, Meridial, which pushes from static snapshots toward dynamic maps. Meridial is not expected to be as comprehensive as static mapping, but the goal is to observe a subset of connections changing over time and thus to understand the rules for how synapses change. “You won’t get every connection. But even if you just look at a subset of connections, being able to understand the rules for how they change, I think that’s super AI relevant,” he said.

Training models from brain data

If the wiring encodes the design, then there could be a path whereby you could train AI systems directly on brain activity. This would mean a model learns to represent the world the way a brain does rather than only the way labeled data does. “There are some companies starting to do brain-data-based training,” Adam told me.

The question, he says, is whether brain data tells a model anything it couldn’t already figure out on its own. “What’s the delta? What’s the difference between having that information and having just the information about the world that we train on now? Are there things in that neural activity that we can’t already predict from the data that it’s seeing?” If a model can already infer how a brain would respond to an image just from the image, the recording adds nothing. Brain data is only worth collecting if it carries something we can’t get from other types of data.

A line of work on representational alignment has shown measurable gains from nudging artificial networks toward neural data. Aligning vision models to human EEG can make their representations more brain-like and more robust. Fine-tuning speech models on fMRI recordings of people listening to stories, a method Mariya Toneva and colleagues call brain-tuning, improves their downstream performance, with the largest gains on tasks that require semantic understanding. And a 2025 study found that aligning auditory models to individual fMRI recordings improved performance on downstream tasks, especially where training data was scarce.

There’s signal that brain data contains something AI can’t already extract from the world, but there are still a lot of open questions. As Adam put it, “It’s one of these things that needs to be tried.”

Why this paradigm got skipped

If reading every weight in a language model can’t explain it, why expect a brain map to do better? The objection assumes you’d be staring at its weights. But Adam believes you’d be staring at something an LLM never had: the design itself.

Adam was on the neuroscience team at Google DeepMind from roughly 2018 to 2020, when the field’s brain-inspired instincts were near their peak. “What I was working on was memory architectures, we were focused on questions like ‘what does the hippocampus do as a memory system?’ ‘Does it have some way of compressing information?’” The leading research programs leaned on reinforcement learning, training systems through reward and trial-and-error in an elaborate, brain-inspired form, full of what Adam calls “bells and whistles.”

Then LLMs took off and bypassed most of it. LLMs use a stripped-down form of reinforcement learning: reward the good outputs, adjust, repeat. They have no internal model of the world. Whereas the brain is thought to do something richer. “The way that large language models do reinforcement learning and post-training is in some ways kind of like the simplest or most brute-force way to do RL,” Adam said, “whereas people believe that the brain does model-based RL,” which is focused on building a model of how the world works and planning against it.

Model-based RL gives the brain a set of faculties that LLMs don’t have built in. “The brain has more innately built systems,” Adam said, “to predict what’s going to happen in the future, or simulate different possible events. Or to go back to different memories to use that memory to make a prediction.” The brain also has ways of working out which actions deserve credit for a reward that only comes later, the problem of temporal credit assignment, as well as value functions that estimate how good a situation is likely to turn out. “These are things that are pretty clearly built into the mammalian brain,” he said, “that LLMs don’t have a built-in architectural solution for.”

With today’s LLMs, “you’re not really building in things like a hippocampus or prefrontal cortex or a striatum or some of the brain areas that we know we have,” he noted. These systems may approximate some of those functions as emergent byproducts of training, but they don’t have them as architectural commitments.

The brain does, and that is the argument for going to look at it. Every faculty the brain has, it had to build into the structure itself, where it can in principle be found and read. Adam is not alone in believing that intelligence needs a kind of built-in cognitive structure, rather than expecting it to emerge from scale alone. Emmanuel Dupoux, Yann LeCun, and Jitendra Malik argue that today's models are missing an architecture inspired by human and animal cognition. They analyze how autonomous learning works in living organisms and propose a roadmap for reproducing it in artificial systems.

As Adam put it, “Having the maps is going to be this multiplier on the rate of overall neuroscience progress. It will help us understand the truth of how humans do it.” That truth isn’t in the weights. The learned weights of the brain’s learning subsystem are tuned over a single lifetime, particular to one brain. The thing worth reading is the wiring: the architecture and the reward circuitry built into the structure itself.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

Voice AI has gotten really good, really fast. Google’s Gemini 3.1 Flash Live and OpenAI’s GPT-Realtime-2 can now reason over a live conversation and pick up on tone, not just words. AI is starting to hear not only what we say but how we say it.

But only up to a point. Three things are still in the way. The first is what these systems do with how you sound: they hear it, then mostly go with your words. The second is who gets heard at all: the models that come closest are closed, and work best in English and a few high-resource languages, leaving most of the world behind. And third, when AI clones a voice, even the best cloning models we have today flatten vocal identity rather than preserving it, pulling every voice toward the same center.

Martijn Bartelds, a speech researcher at Together AI who did his postdoc at Stanford, has spent most of his career studying voice AI, across multilingual models, endangered-language ASR, and voice synthesis. “The human voice is so rich,” he told me. “And I think that makes human-to-human communication also so special.” I sat down with him this week to talk through where voice AI falls short and what it will take to fix it.

The architectural problem

The standard way voice AI is built is itself the first place it falls short. Traditionally, voice AI models transcribe speech to text first, then reason over the text. This architecture keeps the words and discards nearly everything else. “If you do the transcription process, of course the only thing that you keep is just an orthographic representation. So the text only. You abstract away from everything else,” Martijn explained. “But if you want to let the model deeply understand paralinguistic information – everything that is captured in the speech signal that makes up for all the things other than just the words – you need a vastly different approach.”

In our conversation, Martijn referenced a 2025 ACL survey of speech language models that also discusses the problem with current voice AI model architecture. The survey describes the problems as threefold:

1. Information loss during modality conversion

2. Latency from chaining three systems (speech-to-text (ASR) → language model (LLM) → text-to-speech (TTS))

3. Errors that accumulate across them

Another architectural path some voice AI models choose to take is to use an audio-encoder-plus-LLM. Here a speech encoder is attached to an LLM so the model consumes a representation of the audio. But this approach has an alignment problem: “You have to somehow align the representations of the speech encoder model and the large language model.”

With both paths the audio is treated as a second-class citizen, either discarded for text or bolted on after the fact. Martijn wants a third option: a single model that treats speech and text as equals from the start, so nothing has to be translated away or stitched together. “Having the ability to really reason about the audio is something that seems crucial to me,” he said.

Building toward a unified model

Having a single model that keeps meaning and paralinguistic content together is also the architecture that the 2025 ACL paper proposes. With no conversion to text, nothing is lost in translation. And collapsing three chained systems (ASR, LLM and TTS) into one removes both the latency and the accumulating error.

“I see the model being one complete engine, so to speak,” Martijn told me. “It should handle the text and the audio… they should be of equal importance.” In other words, he’s imagining one embedding space where it no longer matters whether a piece of understanding arrived as speech or as text, where reasoning about the audio is as native to the model as reasoning about text.

This is the architecture the frontier has now largely adopted. Google’s Gemini 3.1 Flash Live processes raw audio natively in a single real-time model, which lets it read tone and emotion along with the words. OpenAI’s GPT-Realtime-2, released in May 2026, works the same way, reasoning through a live conversation without the round trip to a separate text model older pipelines required.

However, while these models are very good now at expressive output and voice generation, they are still not very good at fully understanding and acting upon the information present in the input (i.e. the details in the user’s incoming voice).

The data problem

LLMs got good fast in large part because they had a lot of data from the web to train on. Audio doesn’t have an equivalent to the web that is readily available. High-quality speech data has to be manufactured, which means cleaning recordings, aligning words to audio, labeling speakers and languages, filtering noise. Of these steps, Martijn says alignment is probably the hardest part: “For some approaches, you need a careful alignment between the words and the actual text. So you need the data to be transcribed in the first place.”

For well-resourced languages, commercial incentives justify the work needed to get and clean data; and there’s more raw data available in the first place. But for many of the world’s languages, such incentives often don’t exist. “For some of the digitally underrepresented languages I worked with, like the Dutch dialects or Australian Aboriginal languages, only a couple of hours are available. There is nothing else there,” he said. “This means you have to be creative. It’s about figuring out how we can get the most out of the data.”

And for Martijn, being creative means working on the model and the data together, rather than treating them as separate problems solved in sequence. During his postdoc, Martijn built a multilingual training algorithm that left the dataset fixed but made the model aware, mid-training, of which languages were lagging. This let it shift more weight toward them and lifted performance across the set without a single new hour of audio. The data question and the modeling question, as he puts it, go hand in hand.

The voice cloning distortion

Toward the end of our conversation, Martijn and I talked about the third problem: voice cloning, an increasingly prominent use of voice AI, where even with the best models we have today, the richness of a voice is getting lost on the way out.

“Voice cloning” implies fidelity and it’s easy to assume the output of this technology is an exact copy of a speaker’s voice. But in Voice “Cloning” is Style Transfer, Martijn and his collaborators found the opposite. Listeners consistently rated the cloned voices as more customer-service-like, authoritative, and warm than the originals. “These models don’t really faithfully clone someone’s voice, but more or less transfer this style of how someone speaks,” Martijn said.

The fear with cloning is impersonation (deepfakes, fraud, etc). But Martijn’s work sheds light on another risk: that voice AI actually reshapes how we sound. His study found cloning flattens vocal identity rather than preserves it, nudging every voice toward the same optimized center.

The same pattern is showing up in text. In How LLMs Distort Our Written Language, Natasha Jaques and her collaborators found that LLM edits move essays farther than human edits do (even when asked for minimal changes) and in a consistent direction.

When AI mediates human expression, it optimizes away the irregularities that make communication personal. Whether the medium is writing or voice, AI pulls us toward a common mean such that we all begin to sound and write the same.

What it means to be heard

What these systems can hear and who gets heard both come down to whether we treat voice as something richer than text. The frontier models are finally starting to hear the how and not just the what. But these systems that do it best are closed, and they still work best in English and a handful of high-resource languages. “I would just love to see more people working on trying to create these multimodal audio-text language models end to end and making them open source,” Martijn said. “Having a very strong open-source competitor in that space would be fantastic,” especially, he notes, one that also serves speakers of digitally underrepresented languages.

Martijn envisions a model that understands us more fully when we speak, and leaves us sounding like ourselves. “If we say the exact same content, but you have more hesitation in your voice, you should get a different answer than me,” he said.

To get there, voice has to be treated as something fundamentally different from text. Language is not its transcript. And being heard is not the same as being transcribed. “The words, your pitch, your tone. This is so broad and so rich, but it’s everything,” Martijn said. “The model should go beyond the words.”

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

The Mag Seven’s 2026 capex guidance is larger than the Apollo moon program, the transcontinental railroad, and the interstate highway system combined.

I sat down last week with Brexton Pham, Global Co-Head of Compute Infrastructure at Cantor Fitzgerald to talk about this buildout and where he sees the opportunity. Brexton has a unique perspective because his mandate spans the trifecta of power, land, and capital. As Brexton put it, they’re set up for “tackling humanity’s largest ever infrastructure efforts.”

And we’re still very early. By his count, worldwide internet penetration sits at around 75%, while worldwide AI penetration is “maybe 15% if I’m being really generous. And that 15% is also primarily the layman’s ChatGPT usage.”

The buildout is enormous and has barely started. The hyperscalers and the nation-states are committing tens of billions to capex. As the buildout progresses, it is increasingly opening up new categories of opportunity.

The wrong filter, and the right one

“We are entering this world where verticalization matters more than ever and anybody can build anything much faster,” Brexton said. In other words, it’s very hard to predict what the hyperscalers will and won’t do, and it’s only getting harder.

Anything that looks like an unguarded seam today can be swallowed tomorrow. “You should assume your competitors can verticalize overnight,” he said. Behind-the-meter power, nuclear, on-site generation all looked non-core to a hyperscaler a few years ago, but they are now moving directly into these categories.

“When OpenAI and Anthropic first came out, everyone, including myself, assumed that they were AWS-shaped. They were platform-shaped, in that they would never cannibalize their own customers. And boy were we wrong,” Brexton said. “We have never seen customer cannibalization to this scale before. But that’s on the software side. Physics is much harder.”

“The decision to own physical assets,” he said, “to own land, to own a building, to maintain it, to build equipment, to sell equipment. It is significantly harder than software.” These physical seams create differentiation and durability over time. They are more resistant to verticalization because the constraint is physics and time.

And as AI infrastructure scales, the economics of these physical seams change as well. Data centers themselves were considered low-margin, Brexton pointed out, until AI data centers came along: “AI data centers are extremely high margin; inference is very high margin.” Whether that holds across every workload is debatable, and margins vary by model and use case. But the reflexive belief that owning physical assets means accepting thin margins is, in his view, a holdover from the pre-AI world.

So if physical difficulty is the moat, here’s my rough map of where the non-hyperscaler opportunities are the most compelling:

Opportunity 1: Energy Aggregation

Power is one of the binding constraints on the entire buildout. “It doesn’t matter how many chips you have if you don’t have the literal powered land for it,” Brexton said. The hyperscalers know this, which is why they’re now investing directly in generation via nuclear restarts, SMR offtake deals, on-site power.

But there’s a difference between owning the power and assembling it. “If I’m a hyperscaler, do I actually want to do the work of aggregating behind-the-meter power? Probably not,” Brexton said. Hyperscalers obviously care a lot about power, but the aggregation work itself to get that power requires sourcing and permitting on-site generation, wiring in storage, negotiating with landowners and local utilities, etc. These are all areas that hyperscalers would rather buy the result than build the capability.

There are companies that are already running at this: American Terawatt on the behind-the-meter side; and Aalo Atomics, Valar Atomics, and Blue Energy on the nuclear side. “Obviously the hyperscalers aren’t tackling nuclear” at the build level, Brexton said. “Why would they?”

Aggregating distributed power, siting and operating reactors, and building generation are bound by interconnection queues, regulatory timelines, and physical construction. These are hard physical problems and thus the solutions for them are more defensible.

Opportunity 2: Resilience Infrastructure

The supply chain underneath AI is fragile. And during the recent Iran war when multiple Azure and AWS data centers in the Gulf states were attacked, we got a glimpse at just how fragile it actually is. The analogy here is the cybersecurity build-out of the 2010s. Before Stuxnet, essentially nobody was paying for OT security. The Iran data center strikes may be a similar inflection point.

As Brexton put it: “We have clearly entered a world of asymmetric economic warfare. They were able to counter our multi-million dollar rockets with drones that cost maybe $10,000. We’re supposed to have the most powerful military on earth, but they were throwing toys at our missiles.”

And the exposure isn’t confined to the data centers themselves. Our vulnerabilities stretch around the globe:

• Rare earths, which power semis, are basically monopolized by China today.

• ASML, the only company on earth that makes EUV lithography machines, is in the Netherlands.

• TSMC is in Taiwan. “If Taiwan got invaded tomorrow,” Brexton said, “it would be a very, very scary thing.”

• Intercontinental sea cables carry trillions of dollars of data packets every day. “Cut them, and you cripple economies overnight,” Brexton said.

• The Strait of Hormuz, where roughly a third of seaborne oil passes. “We were wildly exposed with the Strait of Hormuz,” he said. “And we still are.” And there are other choke points like the Strait of Malacca, Bab el-Mandeb and the Suez, the Taiwan Strait, the Panama Canal and the Turkish Straits.

Each one of these is a single point of failure that no operator can fix on their own. Therefore, hardening AI infrastructure is equally as important as building it in the first place. Some of sub-categories here include:

• Redundancy and failover software for compute and data pipelines

• Alternative routing infrastructure for when sea cables get cut or regions go down

• Supply chain visibility tools so operators can see, in real time, which inputs are getting squeezed

• Physical site monitoring and threat intelligence designed for industrial-scale AI facilities

• Insurance products and financial instruments that let operators hedge geopolitical risk in their compute supply chains. This is a category that didn’t really exist five years ago and is now being underwritten by Lloyd’s and a handful of specialty carriers

The buyer profile here is broader than the other categories because nearly every AI company needs resilience tooling.

Opportunity 3: Space

The commercial case for moving data centers off Earth comes down to escaping the constraints throttling terrestrial build-outs: land, grid, permitting, and politics. Ben Thompson had a great piece the other day about data centers in space. Two points from that article stand out. First, data centers in space can look wildly different from data centers on Earth. They can be satellite-sized compute racks interconnected with lasers, each with its own solar power and radiator arrays. Some examples of companies building here are Starcloud (formerly Lumen Orbit), which has already flown an Nvidia GPU in orbit, and Kepler Communications, which is operating what’s currently the largest in-orbit compute cluster, a handful of edge processors linked by laser.

Second, and more importantly, Thompson points out that agentic workloads don’t need the low latency that human-facing inference requires. This makes them uniquely well-suited to orbit, where round-trip latency is higher but land, grid, and permitting constraints basically disappear. Cooling doesn’t disappear, though and constrains how big these systems get. In vacuum there’s no air to carry heat away; you can only radiate it. An example of a company trying to solve this is Sophia Space, which is building thin tile-shaped satellites that sit processors against a passive heat sink to kill the need for active cooling.

Beyond the commercial cases for space, there’s also a national-security one. “If you buy into the belief that a lot of the supply chain will be considered critical infrastructure,” Brexton said, “then you can also imagine that we will move more critical infrastructure into space as a consequence of our desire to enhance national security.” From there, “the argument for space data centers becomes very compelling, the argument for in-orbit manufacturing and in-orbit refueling becomes very interesting.”

Examples of companies in this servicing layer are Starfish Space, which is building a satellite servicing vehicle, and Infinite Orbits, which is focused on satellite life-extension and inspection. Assembling, refueling, and repairing orbital infrastructure is a hard physical engineering problem with long lead times.

Opportunity 4: Labor

One of the top reasons build-outs get delayed is that, in Brexton’s words, “we straight up don’t have enough electricians and data center operators.” As I wrote about a few weeks ago in my conversation with Ben Pouladian, Jensen Huang has said the same thing: the bottleneck he’s most worried about is the shortage of plumbers and electricians.

There are really two constraints here. The first is raw supply: there aren’t enough skilled people, and training them takes years. The second is location: even where the people exist, they’re rarely near the build sites. “Abilene, Texas for example has a lot of powered land and is a very obvious place for large industrial build-outs,” Brexton said. “But it’s in the middle of nowhere. So you’re asking families to relocate to a place that doesn’t have affordable housing or much of a residential area.” This is an issue of proximity to some extent and it exists across the entire supply chain: “If I break a part this afternoon, I can get a new part the next morning in Shenzhen, whereas in the US I’m waiting six weeks,” he said.

In my conversation with Saman Farid of Formic we talked about this same problem. He framed US industrial weakness as a utilization problem: a typical US factory runs far fewer of its available production hours versus a Chinese one, so the same building and equipment yields a fraction of the output. The problem is we can’t just solve this with more labor because we don’t have access to more labor.

So the opportunities split across doing more with the workers you have, and reducing how dependent a site is on workers being nearby:

• Robotics and automation to enable on-site construction, electrical work, and manufacturing

• Workforce creation via accelerated credentialing, apprenticeship-to-placement pipelines, and staffing built specifically for data center construction

• Remote operations and lights-out facility management that reduce how many people a remote site needs on the ground

Each of these is a way to solve the physical constraints around the labor problem.

The Foundation of the Intelligence Economy

There’s one constraint that we haven’t talked about yet, but it gates all of the categories above: public sentiment. Municipality pushback is already causing build-out delays, and it’s only increasing. “The average American,” Brexton argues, “is meaningfully more anxious about AI than excited, and Silicon Valley keeps underestimating that anxiety.”

Some of that anxiety is misinformation. He traces the water-usage panic to a figure in Karen Hao’s Empire of AI that overstated data-center water use by a large factor and was later revised, “but the damage was already done.” Some of it isn’t. Either way it exists, and it’s yet another hurdle to confront as the buildout proceeds.

This hurdle further stymies the physical buildout, which Brexton believes we’re still “severely underestimating in order to power 24/7 demand of intelligence.”

The easy conclusion is that this entire map will be drawn by giants: hyperscalers, nation-states, utilities, and the capital providers large enough to finance the buildout. Or, on the other side, that public backlash will slow the whole thing down before a new startup ecosystem can form around it.

I don’t buy either. The hyperscalers will define much of the demand, and public sentiment will shape where and how fast the buildout happens. But neither eliminates the startup opportunities, which I believe are largely physical and can’t be verticalized overnight. And while some of these opportunities may look like narrow seams today, over time, they will become part of the foundation that the intelligence economy depends on.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

I really liked this Stratechery interview of United CEO Scott Kirby from January, in which Kirby describes how, starting in 2016, he committed United to spending several hundred million dollars rewriting SHARES, the airline’s Fortran-based reservation system originally written in the 1960s, onto modern cloud infrastructure. The project still isn’t finished, the last cutover is scheduled for next year. All of United’s recent customer-facing differentiation sits on top of this new infrastructure. And while United is far from a perfect airline, the widening profitability gap between United and the rest of the industry is largely a consequence of their decision to get off the legacy mainframe. Kirby noted in the interview that United and Delta will collectively account for 100% of industry profitability this year. “You can’t do what we do unless you do [the modernization] first,” Kirby said. “It was a key unlock.”

McKinsey research estimates that roughly 70% of Fortune 500 software was built more than twenty years ago. And according to IBM, there are still an estimated 250 billion lines of COBOL in production. At the same time, BCG recently put out a report that says “agentic AI will ultimately expand the total addressable market for technology services, unlocking up to $200 billion in net new value pools in the next five years.”

Most of the revenue in this market is currently captured by Accenture, TCS, Infosys, Cognizant, Wipro, and Capgemini. They’ve used an offshore-labor-arbitrage model, which is most exposed to AI-native delivery.

As a result, there are unsurprisingly a lot of companies going after this space now: Mechanical Orchard, 8090, Tessara, Moderne, among others. But there are still opportunities for new entrants. And what I find most exciting about this category is that modernization is just a wedge into a much larger custom development relationship, on stacks built natively to be modernized again.

Why Now

My thesis around this category is based on four observations about how the market is changing:

1. Enterprises will continue to outsource, not insource. United is the exception that proves the rule. Kirby explicitly notes that no other airline has done what United did, “certainly not to the extent that we’ve done it. They’re still on old legacies, because it’s hard.” The historical outsourcing model priced labor arbitrage. AI agents collapse the labor cost, which means the model has to change, but the structural preference for outsourcing the work isn’t going to. We’re now seeing evidence of this in lots of consulting firms partnering with AI labs including EY’s April 2026 partnership with 8090.

2. The business logic buried in legacy code is the asset. The business rules encoded in the mainframe logics represent decades of institutional knowledge. I like Mechanical Orchard’s framing that “the system in action is the specification.” In other words, the value is around extracting and verifying the behavioral specification inside these systems. That extraction is the foundation of everything else a modernization platform can do.

3. Modernization is the wedge into bigger opportunities around new development. Once a system is modernized, companies can unlock a lot of new capabilities that they previously weren’t able to. After spending hundreds of millions rewriting its 1960s-era SHARES reservation system, United was able to build differentiated customer-facing products. None of that new development would have been possible without the modernization first. It also gives companies that modernize an edge in a crowded, otherwise undifferentiated, market. “We’re doing all this and no one’s copying the things that matter, which is great,” Kirby said in the Stratechery interview.

4. Capability, security, and the talent cliff are converging. Three vectors are converging simultaneously, answering the why now question. AI models can now read, translate, and validate legacy code at scale. When Anthropic published a blog post in February about Claude Code reading COBOL, IBM lost ~$40B in market cap in a single day. Security exposure has also become untenable: the global average breach cost is $4.4M and 97% of organizations reported an AI-related security incident and lacked proper AI access controls. And the third vector is talent: according to some sources, the average COBOL programmer is 55, with roughly 10% retiring annually and 60% expected to retire within five years.

The White Space

It’s useful to place the existing players on two axes: modernize what’s there versus build what’s next, and platform/product versus services-wrapped delivery.

The established players mentioned in the image above have collectively staked out mainframe, ERP, agent tooling, and regulated-enterprise software factories. But there is still whitespace for new entrants. Below are some areas I’m particularly bullish about.

Post-mainframe, pre-cloud enterprise systems. Two decades of custom enterprise software built on Microsoft, Oracle, and open-source stacks. These systems run inventory, claims, distributor management, financial modules, and a long tail of back-office workflows at Fortune 500-1000 companies. The opportunity is around a full-system modernization that addresses application logic, the data layer (stored procedures, ETL, batch jobs), and integrations.

Vertical-specific modernization where deep regulatory expertise is needed, such as in healthcare, defense, manufacturing OT/IT convergence, energy, and telecom. Each has its own legacy stack and compliance requirements, so domain depth is important.

The mid-market tier, where projects run $150K–$2M rather than tens of millions, is large, fragmented, and underserved. AI changes the unit economics enough that a product-led motion could work well here.

Continuous-modernization platforms. United’s modernization efforts started in 2016, and they’re still not done a decade later. These initiatives can now happen much faster than before, but even a new system will become outdated within a certain number of years. A platform built for continuous modernization is more interesting than one built for a single mainframe-to-cloud migration. In other words, this is like an always-on layer that maintains a living map of the enterprise’s business logic, which can be re-translated onto whatever stack comes next.

Non-code legacy systems like ETL pipelines, EDI integrations, batch schedules, message queues, and undocumented processes. Most modernization efforts are around application code, but that’s just one layer of a legacy system. The infrastructure that actually encodes business logic is equally important and has often been overlooked. Curie is a good example of a company going after this layer – their agents handle MuleSoft integration migration, management, and the transition from APIs to agents. AI is uniquely suited to help here.

The only way you grow

In the Stratechery interview, Scott Kirby said: “The biggest mistake most people make in their careers is never making big mistakes. It’s the only way you grow. You have to decide, and not deciding on the status quo is a decision in itself.”

For a decade, the status quo on modernization (aka do nothing) was defensible because the alternative was an expensive, decade-long overhaul with no clear ROI. AI has changed that.

The companies that do nothing now are still making a decision, they just may not realize it yet. There’s an opportunity to build the platform that helps them see it, and gives them a credible path forward.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

A few weeks ago, I listened to Dwarkesh Patel’s interview with Jensen Huang. It’s a great interview and one I recommend listening to if you haven’t already. In it, Jensen said chip-side bottlenecks will be resolved in two or three years. The bottleneck he’s more worried about is energy, and specifically he calls out his concern over the shortage of plumbers and electricians.

This was on my mind when I sat down the other week with , founder of BEP Research, an independent research shop covering GPUs, memory, optical interconnects, and data center power as one converging system. His work has become required reading for hedge funds, asset managers, and the engineers building the stack, and has been cited everywhere from the WSJ to sell-side research desks.

Most of the AI infrastructure conversation right now is about GPUs. Who has them and who can get them. But GPUs are just one ingredient in a much more complex supply chain, and I don’t think they’re the most urgent constraint.

“The biggest constraints are energy or electricity, finding powered land,” Ben told me. “And then once you find that powered land, finding the people and the money to help build that data center.”

This is a physical problem, and it’s slower and more operationally complex than buying chips. But if AI is going to scale anything close to what current capex commitments imply, there’s a massive opportunity in building the physical stack underneath it and the software and hardware layers that coordinate it.

The bottleneck is a chain, not a point

PJM, the grid operator covering 67 million people across the mid-Atlantic, just came out with a report about rising demand and constrained supply where they say “we are facing a possible decade-long structural reality where demand growth will continually threaten to outpace supply additions.”

The GPU shortage is an important part of the story, but it isn’t the full story. AI infrastructure comes online as a sequence, not a single event. So the idea that the constraint is a single choke point oversimplifies how the stack actually gets built.

In fact, one of the last things that goes into the data center is the compute hardware. “First, you need to actually build the thing and make sure there’s power and it works,” Ben said.

And even once the GPUs arrive, the bottleneck just moves one layer deeper to memory architecture. Things like High Bandwidth Memory and the KV cache that holds an inference in working memory gate how much intelligence you can extract per watt. A GPU starved of memory bandwidth draws full power but delivers a fraction of the output. So the constraint is also around getting the right memory onto the silicon once it’s in the data center.

Working backwards, this means you need software orchestration, racks, chips, cooling and electrical, construction, community acceptance, permitting, grid interconnection, powered land, and electricity.

Each of these layers has a different production timeline. As Ben put it: “Chips are scarce this quarter. Power is scarce this decade.” Interconnection queues are years long, and grid capacity is already under pressure from electrification, EV charging, and manufacturing reshoring. On top of that, permitting is slow and depends heavily on the speed of local politics.

And then there is the issue of labor. Tradespeople take decades to train. “It’s purely physical, human, blue-collar labor,” Ben said. “You can’t spin it up like an AWS instance.” This is what Jensen meant when he said plumbers and electricians are the most challenging bottleneck right now.

Manufacturing intelligence

Ben kept using the phrases “AI factory“ and “token factory,” borrowing a framing that Jensen Huang has used many times when describing the next generation of data centers.

Traditional data centers hosted software; they stored data and ran enterprise workloads. AI data centers are production plants; they turn energy and data into tokens. “The modern factory is not making metal,” Ben said. “It’s making intelligence.”

And although the output is tokens instead of parts, the production-system questions are the same as any factory: throughput, yield, energy efficiency, utilization, predictive maintenance. The units of output are metrics like tokens per watt or tokens per dollar of capex. These are financial metrics. Every watt of power and every dollar of capex now has a token-denominated yield attached to it. As inference workloads grow faster than training workloads, these questions become more acute.

The need to efficiently convert watts into intelligence becomes even more urgent.

This drives what kind of opportunities need to be built next. Traditional factories spawned entirely new categories of software and hardware. AI factories will need the equivalents, but for tokens-as-output. Almost none of that exists yet.

The opportunity is at the seams

Production systems are complex, and coordination between the layers is mostly manual or opaque. There’s a massive labor shortage on top of that. Wherever coordination is fragmented, slow, or expensive, there’s room for new companies. Software, hardware, and everything in between.

Starting at the bottom of the stack is the need to find viable powered land. And once you find it, the procurement process is often painful. Tapestry, which spun out of Alphabet’s X moonshot factory, is essentially building Google Maps for the grid. It’s a knowledge graph that helps developers and utilities operate at a much higher speed and resolution than they can today.

As an aside, there are bets trying to escape these constraints entirely by moving data centers to space. Google’s Project Suncatcher and the recent SpaceX talks are the most visible. They sidestep some of the problems (land, grid interconnection) but not all of them. Most coverage focuses on launch costs, which would need to fall by an order of magnitude before any of this is viable at scale. But the harder constraint is thermal. In vacuum there’s no air to carry heat away (you can only radiate it) and that physics is what really gates the architecture.

Once you have powered land, the factory itself needs to be built and operated. This is the layer Jensen was pointing at when he talked about plumbers and electricians. Scheduling tradespeople, sequencing trades on site, managing lead times are all still very manual processes. As mentioned earlier and as I’ve written about previously, such as in my conversation with Saman Farid, the founder of Formic, we have a massive labor shortage. Training tradespeople takes decades. We don’t have decades. There’s an opportunity to leverage robotics to do a lot of the manual work that humans have historically done. Companies like Watney Robotics are examples of types of companies I’m very excited about here.

Crusoe is an example of what a vertically integrated AI factory company looks like. They source their own energy, build their own modular data centers, manufacture them in their own facility, and run a cloud layer on top. Every layer of the stack (power, building envelope, cooling, hardware, software) is something they’re either building or coordinating.

Once the factory is running, routing power matters because every watt matters. Power routed to cooling is power not routed to compute. As power becomes the binding constraint, there’s an opportunity to optimize the thermal and electrical envelope in real time.

Above the silicon, the orchestration layer is just as early. GPUs sit idle for a meaningful share of their lives. AMP, an Alphabet-affiliated public benefit corporation, is pooling compute across independent AI labs to smooth utilization across the field. So when one lab is in a training run and another is in deployment mode, the aggregate demand curve is much smoother than any individual workload.

And above the orchestration layer, sits the financial layer. Compute is becoming the most important commodity of the decade. Like oil, we need market infrastructure to enable a liquid market for buyers and sellers of compute to transact. This means we need tooling for GPU pricing, hedging, and financing. As I wrote about here, compute will eventually become a more liquid market where capacity is procured on demand rather than primarily through long-dated bilateral contracts. Ornn is one company I’m excited about that is building in this space.

“The investment surface around power is deep,” Ben said, “and the layers on top of it are almost entirely greenfield.”

Why this matters

This buildout isn’t going to stop next year. “We spent 15 years building regular data centers with CPUs to run regular websites,” Ben said. “This is not the same thing.”

The stack is more physical, more tightly coupled across layers, and built around producing something rather than hosting it. Some of the most important companies of the last generation were born during the cloud buildout. The next generation is getting built now.

The opportunities are in the seams between power and compute, between construction and capital, between watts and tokens.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

Are today’s language models the path towards machine intelligence, or are they just a commercially viable local maximum?

Yann LeCun is one of the clearest and most consistent voices arguing for the latter. In his view, LLMs are not intelligent, however useful they may be. Systems trained to predict sequences of discrete tokens don’t have an understanding of the world, which is a fundamental building block of intelligence.

I sat down with Yann a couple weeks ago to explore this idea and his vision for the future.

“There’s one question of whether the models we have today are useful? Is there a market for them? Yes.” But on the bigger question, “Will these models take us to human-level intelligence or something similar to it? Absolutely no.”

Yann recently founded AMI Labs, a Zetta portfolio company, to build what he thinks the alternative will look like: world models that can understand the physical world and predict the consequences of actions.

Why language isn’t intelligence

“Much of human knowledge and thought has nothing to do with language,” Yann said. And yet we credit anything that speaks fluently with understanding. “We’re biased towards attributing intelligence to things that can express themselves through language.”

He walked me through a calculation he’s done before. A four-year-old has been awake for roughly 16,000 hours. The optic nerve carries about one byte per second per fiber, with roughly a million fibers per eye. If you multiply it out, you get something on the order of 10^14 bytes of visual data reaching the brain in the first four years of life, roughly the same order of magnitude as the entire text corpus used to pretrain a modern LLM.

“It would take any of us something like 400,000 years to read through that,” he said. In other words, a small child has already absorbed, through vision alone, about as much raw information as the largest language models see in training. “We’re never going to get to human-level AI by just training on text. It’s just not going to happen.”

What LLMs do have is an ability to accumulate and retrieve declarative knowledge. This means they look smarter over time without developing deeper models of reality. They simply become more familiar with the kinds of questions people ask.

“If you want a system to act intelligently,” he said, “it has to be able to predict the consequences of its actions. And LLMs are completely incapable of doing this.”

Yann believes in language models for two specific domains: coding and math. “The reason why it works so well in these two domains is because these are domains where the mere manipulation of symbols is actually kind of the substrate of reasoning.” But these are narrow cases. “For everyday things that require a little bit of common sense reasoning and certainly planning, they’re just never going to get there.”

What the alternative looks like

The alternative is what Yann has been working toward for over 15 years. It’s a system that learns how the world evolves, and can predict what the consequence of a sequence of actions is going to be.

“This is the only way to build an agentic system that is reliable,” he said. “I do not understand how people can even think of building agentic systems that do not have this ability of predicting the consequences of their actions before they do them.”

The hard part is learning such a model from real-world data. Next-token prediction works because symbols are discrete and compressible. The physical world is not. “I’ve been working on this for over 15 years, and essentially failing the first 10 years, because I was using generative architectures trying to predict what’s going to happen in the video at the pixel level. This kind of data is just not predictable.”

He gave the example of a pen balanced on your hand. If you let go, you can predict that it will fall. But you can’t predict the exact direction it will fall, or the precise configuration of every pixel in the next frame. If you train a system to predict all of those details, you’re forcing it to model noise and contingency as though they were the essence of intelligence. “When you try to train a system to predict every detail in a situation, you kind of kill it because you try to train it to do something that’s impossible.”

His proposed alternative is Joint Embedding Predictive Architecture (JEPA). Rather than predicting every pixel, the system learns an abstract representation of the world and makes its predictions there. “All the details about the input that are not predictable, all the noise, all the complexities of it are basically going to be eliminated from the representation so that the prediction can be reliable.” You learn the latent state that matters for planning, even if you can’t regenerate a photorealistic frame from it.

Once you have an abstract world model, reasoning becomes search through that model. That’s what LLMs can’t do, because they don’t have a model to search through. “The idea that reasoning is a kind of search is really fundamental,” he said. “LLMs don’t do this. They don’t have any ability to really search for an answer. They just produce an answer, a token.” Chain-of-thought, in his view, is a workaround: “a very, very inefficient way of coercing autoregressive prediction systems to basically approach reasoning.” Real reasoning, he argues, is internal simulation. This means manipulating mental models, running counterfactuals, planning hierarchically the way a human plans a trip to Paris (aka not at the level of muscle commands, but refining subgoals from the top down).

This is why he prefers the term Superhuman Adaptable Intelligence to AGI. “The true property of intelligence is to solve new problems you’ve not been trained to solve.”

AMI Labs and World Models

That thesis is now Yann’s company: AMI Labs, Advanced Machine Intelligence, (pronounced “ah-mee,” just like the French word for friend).

AMI is building AI for the real world. “A lot of industry is just running things, right? Like physical things. And this is where current AI technology falls short,” he told me. The company’s stated focus is industrial process control, automation, wearable devices, robotics, and healthcare.

A huge portion of the economy depends on running physical systems (factories, supply chains, power grids, biological systems, transportation networks). These are environments where text is often the interface around the work, but not the work itself. “AMI is building generic foundation models that can be applied to any situation where you need an intelligent system to run something physical,” Yann said.

The physical-economy layer of AI will be built on a different stack from what most companies are using today. Rather than predicting the next token, this is about predicting the next state.

There are a number of other companies also trying to build versions of world models. The approaches differ on what the model tries to predict: pixels and geometry versus abstract state.

Fei-Fei Li’s World Labs is building, according to their website, “world models that can perceive, generate, reason, and interact with the 3D world.” Their first product, Marble, turns text, images, or video into 3D environments that designers can open in different creative tools. Google DeepMind’s Genie 3 takes a different approach to a similar problem, generating interactive worlds in real time that users can navigate frame by frame.

1X and Generalist are building video-pretrained world models specifically for humanoid robotics. 1X‘s model learns from internet video first, then from footage shot from a human’s point of view, and uses a second model to turn its predictions of “what should happen next” into robot movements. Generalist combines ideas from world models and VLAs, training on roughly 500,000 hours of real-world physical interaction data collected from wearables worn by humans doing everyday tasks.

NVIDIA’s Cosmos is building a platform to “help developers build customized world models for their Physical AI setups.” Meanwhile, Tesla is building a single AI model that can drive cars and control humanoid robots, treating both as different bodies running the same underlying intelligence.

What distinguishes AMI is the architectural bet around JEPA-style abstract representation rather than pixel-level generation. Pixel-perfect prediction is computationally expensive and, as Yann argued for years before the field caught up, trying to predict the unpredictable actively degrades the model’s grip on what matters. Abstract representation preserves the causally relevant structure while removing the noise. If it works, it’s both a better model of physics and a cheaper one to deploy.

Why this matters

For robotics specifically, the implications are significant. The dominant approach today, vision-language-action models that map observations directly to motor commands, runs into two well-understood ceilings.

The first is data. Teleoperated robot data is the highest-quality source but doesn’t parallelize. It’s bounded by the number of robots you own and the hours skilled operators can work. Researchers have developed workarounds: hand-held grippers like UMI that let humans collect demos without a robot, wearable rigs that record everyday activity, cross-embodiment datasets that pool data across robot types, and simulation pipelines. But there is an embodiment gap for each that has to be bridged. Meanwhile, the largest available corpus by far, human video on the internet, is hard to exploit directly because the actions aren’t labeled. Recent work on inverse dynamics and latent action models is starting to unlock it, which is part of why world models have gained momentum.

The second is embodiment lock-in. Observation-to-action mapping tends to couple learned knowledge to a specific robot body. Transfer across embodiments is possible but imperfect. A policy trained on one arm typically needs significant adaptation to work on another. Knowledge ends up captured at the level of “how this robot should move in this specific setting” rather than “what should happen in the world.”

World models attack both problems at once. If you learn an abstract representation of how the world evolves (how objects fall, how contact propagates, how liquids behave), you’ve learned something that is true regardless of which body is acting in it. That knowledge can be absorbed from video without action labels, because the goal isn’t to predict the next motor command but to predict the next state. A model that understands physics can then be adapted to whatever embodiment is available, with calibration rather than retraining.

The opportunity extends well beyond robotics. “There are tons and tons of applications of this type,” Yann told me. “You want to control anything in the real world: manufacturing plant, turbojet engine, chemical process. A human cell. You want to plan a sequence of treatment for a patient to, I don’t know, control blood sugar. If you have a good predictive model of at least some aspect of the state of the patient, you might be able to do this kind of planning on a personalized basis.”

A system that thinks

It’s easy, in a moment like this one, to mistake the shape of the market for the shape of the problem. LLMs are producing extraordinary value, and they will keep doing so in cases where symbolic manipulation is the actual work.

But most of the economy doesn’t run on words and symbols. It runs on physical systems, environments where text serves as a wrapper, but isn’t the work itself. The systems capable of operating in those environments will need something current models don’t have: a base-level understanding of the world, the ability to predict the consequences of actions, and the capacity to adapt to problems they weren’t trained on.

Intelligence is much more than language. Future AI systems will still use language, but language will no longer be their only substrate.

As Yann put it, “language will serve as an interface to a system that thinks.”

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

When the iPhone app store launched, it wasn’t clear at the time how or even why hundreds of thousands of apps would get built. After all, phones were for calls. But it turned out that the platform created an economy in which anyone who had a problem could build an app to solve it. These apps addressed markets that were often too small to justify a company, but still many people found value using them.

That same dynamic is starting to happen in physical AI.

DJI alone supposedly has more than 100,000 developers building applications on its drones, mostly in China and on problems that no large company would pick up. The DJI ecosystem exists despite DJI not really making it easy. The hardware is largely closed. Onboard AI compute is minimal. Developer experience is an afterthought. The fact that 100,000 developers built on it anyway tells you what the latent demand looks like.

If that’s what is possible on closed hardware with poor tooling, imagine what happens when the platform is actually built for it. The ceiling on who gets to solve physical-world problems moves.

I recently sat down with Jason Lu, the founder of Flyby Robotics, to explore why this shift is happening and what opportunities this now unlocks.

The old market structure was a tax on distance

Physical-world problems have always been solved by whoever could afford to solve them, which mostly meant whoever could justify the cost of solving them at scale.

At the top, megacorps like DJI, Skydio, and Anduril picked off the problems large enough to move a multi-billion-dollar needle. Below them, venture-backed startups went after problems big enough to justify raising their next round of funding. Below them, smaller specialized companies went after the problems too narrow for the tier above. And below all of them sat people who actually lived the problems day-to-day, but got to solve essentially nothing.

Jason says this is because “the juice wasn’t worth the squeeze” for the people with the resources to solve them. Every layer of distance between the problems and the person with the authority to solve them acts as a filter. As Jason put it, “If you’re the 1,000th employee at Skydio, it’s unlikely you’re going to really care about these ‘small’ problems, like offshore oil rig corrosion or crop yield boosting 20% with multispectral imagery.”

Problems that aren’t big enough or profitable enough don’t get solved. This doesn’t mean those problems aren’t worth solving, it’s just that the unit economics of solving them has required a scale that most physical-world problems can’t reach.

This asymmetry has defined digital versus physical for a long time. Software ate the world. At first, it was mostly the parts of the world where one solution could be sold to millions of customers. But eventually with the app store and now vibe coding, anyone can build a piece of software to enable whatever problem they have, no matter how small.

This hasn’t yet been feasible for the physical world, but that is changing

Three things became true at the same time

What’s changing is that three independent curves are crossing at roughly the same time.

The first is compute on the edge. Until recently, you couldn’t put a lot of processing power on a small flying robot. “Imagine you’re trying to solve this for coding, but there are no computers. There are no servers. There’s no mouse,” Jason said. The drones Flyby Robotics are bringing to market carry 150 to 300 trillion operations per second of onboard compute, and in some cases even more. RAM is going from 2 gigabytes to 16 to, eventually, 128 or more.

Drawing on the iPhone analogy again, Jason said “the iPhone could only have happened because of advancements in RAM technology, in microprocessors, and in touchscreen technology. Those applications built on top of the iPhone were possible because these technical unlocks happened. That same transition is happening in the physical AI space.”

The second is abstraction over hardware. Controlling a gimbal or routing camera data into a model or deploying that model efficiently on a GPU – all of that used to require a specialist. There was no equivalent of an OS for physical AI, but that’s finally starting to change. Flyby for example is building the layer that lets a developer move a camera or a drone without ever touching the underlying SDK.

The third curve is coding agents. Claude Code, Codex, Cursor, and the broader category of AI-assisted development have dropped the skill floor for software work by an order of magnitude. Now everyone is empowered to describe what they want to build in natural language and AI will write the code for it.

Any one of these shifts on their own wouldn’t be enough. But the combination of capable hardware, accessible abstractions, and AI coding makes this possible for the first time.

The Opportunity

This changes what gets built.

The opportunity I’m most excited about is the platform that makes the long tail possible. This is both the hardware, and the developer layer that sits on top of it.

Right now you mostly can’t buy a drone or a robot with enough onboard compute to run a model that’s also open enough to add your own software. Solving this is a hardware problem that requires having the right chips, sensors, batteries, airframes, manufacturing lines, supply chains, and firmware.

Sitting on top of that hardware is the platform layer, which includes the abstractions, the developer experience, the model deployment tooling, the integration with coding agents. Without this platform, only specialists can use the hardware, and the ecosystem stays small. But with this platform, thousands of hyper-specific applications can get built by people closest to the problems.

This is the vision Flyby is pursuing in aerial robotics, and I suspect we’ll see others take on adjacent pieces of the work in different physical domains such as ground robots, underwater systems, manipulation, sensing. The shape of the opportunity is the same in each case: build the full stack that lets the people closest to a problem actually solve it, and capture value across the entire ecosystem of solutions that emerges on top of you.

The interesting thing about the App Store, in retrospect, wasn’t any single app. It was that the platform created the conditions for problems to get solved by the people who had them. Physical AI is approaching its version of that moment. The substrate is starting to come together and the distance between a problem and the person who can solve it is collapsing.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

Every time I go on X, I inevitably see someone talking about how unproductive they feel if they’re not running 5 agents in parallel while they’re in a meeting. “Token maxxing” has become a stand-in for productivity, where the metric is consumption rather than output.

There’s no apparent ceiling on how productive we can now be. The tools are built to help us execute more.

But are these tools really building to our specifications? Or are they in fact changing our specifications? At what point does AI execution swerve from its intended path? Smoothing our judgment, nudging our thinking, and changing what we meant to build in the first place? And as more of this execution moves into shared workflows, whose judgment is actually in the system? Are we still the ones doing the building, or are the tools building us, and the teams around us?

I sat down this week with Stefania (Stef) Druga to unpack this. Stef is a research scientist at Sakana AI in Tokyo, and previously worked on multimodal Gemini applications at Google DeepMind. Before that, she studied at the MIT Media Lab and earned her PhD at the University of Washington. She has spent roughly a decade studying how humans learn to work with AI and how that learning shapes, or fails to shape, the work itself.

The tools are changing what we mean

A recent paper from Natasha Jacques opens with this insight: “Large language models (LLMs) are used by over a billion people globally, most often to assist with writing. In this work, we demonstrate that LLMs not only alter the voice and tone of human writing, but also consistently alter the intended meaning.”

Stef, who was a colleague with Jacques previously, put it more bluntly: “When you’re working with AI for co-writing, there’s a huge semantic drift, much more than with a human editor. Using AI to give you feedback or help you write is actually changing the meaning and the direction.”

You sit down to say one thing, accept a few suggestions that sound cleaner, and walk away having said something slightly different, without necessarily even noticing the drift.

Part of what makes this possible is that most of us haven’t developed the literacy to notice. In our conversation, Stef defined AI literacy as “the ability to read and write with AI and develop critical thinking and understanding of AI capabilities in very concrete terms.” In a paper she co-authored, she and her collaborators propose a framework for family AI literacy organized around four dimensions: ask, adapt, author, and analyze.

You build this kind of literacy the same way you build any craft: by trying to solve something, hitting the limits of the tool, learning what to trust, learning what not to trust, and developing an intuition for where delegation helps versus where it hurts the work.

The skill underneath all of this is operational agency: knowing, in the moment, whether the machine is sharpening your thinking or smoothing it into something that sounds like you but isn’t.

Most of us haven’t built this skill yet, because the tools make it hard to do so. Accepting a suggestion is one keystroke versus pushing back requires slowing down and actually thinking.

Seeing your own work clearly

Stef argues that most people reach for AI before they’ve done the work of seeing their own work clearly. “How do I keep track of everything that I’m referencing and doing, both the inputs and the outputs? Once I can visualize that, how much time am I spending on executing? Things like coding or running experiments. Versus how much time am I spending on thinking?”

You can’t notice the tool changing your meaning or intention if you weren’t clear on your meaning or intention to begin with. You can’t tell whether delegation is helping if you can’t see what you delegated. Making your own work legible (through a personal wiki, a structured desktop, whatever form works) is what gives you something to compare the output against. Without it, the tool’s version of your thinking is the only version you have.

“There’s real merit and value in us having clear thinking and clear ideas and clear directions, clear questions before going to the most powerful LLM to do stuff for us.”

Stef pointed to Andrej Karpathy’s popularization of personal knowledge bases, but noted it’s really a rediscovery of older ideas from human-computer interaction and knowledge organization: make the work visible, structure the context, then use the machine to help navigate it.

Seeing each other’s work clearly

If it’s hard for individuals to stay legible to themselves, it’s exponentially harder for teams to stay legible to each other.

“The bottleneck right now is us, the humans,” Stef said. “We keep talking about the model alignment to humans, but we’re not talking about the human alignment.”

The moment a company starts layering agents into shared workflows, it has to answer questions most teams don’t have good answers for. What is the process? Who owns what? Which rules take precedence? What happens when one person’s agent conflicts with another’s?

“Let’s say we have a code base where everyone has their agents and their agents’ rules, but then there are conflicts between those agents’ rules. How do you negotiate that? That’s the future: agent-to-agent coordination, agent-to-human coordination, human-to-human coordination and everything in between.”

In other words, this is the same agency problem at the individual level, but scaled up. At the individual level, you lose agency when you can’t see your own context clearly enough to notice AI reshaping it. At the team level, you lose agency when nobody can see the shared context clearly enough to notice the agents reshaping it.

And automation only amplifies the underlying illegibility.

“Oftentimes we try to throw automation at things thinking that these problems are going to go away,” Stef said. “But actually, they’re only going to get worse.”

Thinking is the work

Execution is getting cheaper, so the valuable work has to be somewhere else. If automation amplifies whatever you point it at, then the quality of what you point it at matters more than ever.

Stef described it as a pyramid: “You start with a question or a project spec or a hypothesis, then you can automate a lot downstream. But if the initial starting point (the specification, the questions you ask, the hypothesis) are bad, then the errors and biases that trickle down get exponentially worse.”

The highest-leverage work is therefore shifting upstream: framing the problem, specifying the task, defining what good looks like, deciding what gets delegated, and preserving the judgment to know when the machine is helping versus when it’s distorting.

“It’s never been about duration or how many hours you put in, but more about the quality,” Stef said. As a side note, this is why I think teams boasting about their 996 cultures are missing something fundamental about how the best work actually gets done. More hours of execution don’t necessarily produce better outputs. In fact, they often produce more of the wrong thing, faster.

“What’s hard to do is ask the right questions. Have the right aesthetics, the good taste,” Stef said toward the end of our conversation.

Taste, judgment, and good questions are slow skills. They’re built over time by doing the work and paying attention; by noticing when something is off and caring enough to fix it. These slow skills don’t scale the same way execution does, and we’re most at risk of losing them if we mistake output acceleration for craft.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

We’re still living in a supply constrained market for compute. But my belief is that compute will become a commodity, just like oil.

And just like oil, we need market infrastructure to enable a liquid market for buyers and sellers of compute to transact. If you want to understand what a mature compute market could look like, look at what every other commodity market became.

ICE and CME, two of the world’s most important exchange operators, are worth approximately $91 billion and $104 billion respectively today. S&P Global, whose Platts business helps provide benchmark pricing across commodity markets, is worth about $134 billion. MSCI, which built a powerful index licensing business around becoming a benchmark layer for public markets, is worth about $42 billion.

I recently sat down with Wayne Nelms, the CTO of Ornn, to talk about where he sees the future headed for compute. “Turning a megawatt into a token is very hard. It’s not very efficient,” he told me. That inefficiency is the path from raw infrastructure to useful AI output. It’s a wild west. And wild wests, historically, have been where the most valuable financial infrastructure gets built, bringing order to chaos.

The current market

The chain to compute starts with whoever owns the land. Then the data center builder. Then the lenders, who provide the capital that makes the build possible. Then the neocloud tenants who lease the facility. Then cloud service providers who resell to enterprises. Then the AI companies that turn that compute into tokens. Each link in the chain is looking at the one next to it and asking: can I trust this end user to actually pay?

“It’s like in commercial real estate, the person who builds the apartment building is leasing it to a landlord, and the landlord has some operational exposure. The landlord only cares about the creditworthiness of the end resident,” Wayne said. “The problem is that (for AI infrastructure) most of the residents are new.”

“We have all these companies that aren’t even a year old that have huge computing needs. They’re effectively the equivalent of a new grad in New York looking to rent an apartment without a guarantor.”

The only way anyone gets a data center built today is if a hyperscaler steps in as the guarantor. They’re the parents co-signing the lease.

This doesn’t scale, and it’s also becoming more and more fragile.

Hyperscaler balance sheets are not infinite, and they are not aligned with the rest of the ecosystem. These companies have their own agendas. They’re selfish, as they should be. And as some of them approach public markets or manage investor expectations around capex, the pressure to throttle their guarantor role is intensifying.

“Private credit firms are becoming more particular about the loans they give, even to some of the most well known AI companies.” And if that’s happening at the top of the food chain, imagine what’s happening below it.

“If smaller players go to a data center, they’re just going to get laughed at. They don’t have enough money on their balance sheet or creditworthiness.” Not to mention, there aren’t options to rent just for one year so most have to lock in for 3-5 years, which is basically impossible for these new entrants.

The structural mismatch

The market today has a structural mismatch: there are essentially two tranches that can’t meet each other.

On one side, you have investment-grade supply (hyperscaler-backed data centers) fighting over a tiny pool of investment-grade buyers. Every major data center developer is trying to lower their rates to win deals with the same handful of hyperscalers. “Everyone is asking, how can I make my rates more attractive so Google will buy? So, Google has huge pricing power right now,” Wayne said.

On the other side, you have non-investment-grade everyone else. Smaller data centers who can’t get tenants because no one trusts them. Smaller AI companies who can’t get capacity because they can’t sign five-year offtakes.

“None of these buyers trust these sellers, and vice versa; the only thing the low-tier demand wants is the high-tier supply,” Wayne summarized.

Two paths to a market

There are two ways to close this gap, and any mature commodity market has both of them.

The first path is to make the long tail of demand creditworthy. You can do this by aggregating demand, rating it, packaging it into diversified baskets that as a whole look financeable even if individual buyers don’t. This is the securitization playbook: take something that doesn’t qualify for capital on its own and structure it into something that does.

The second path is to institute hedges. Build an on-demand market, publish reference prices, launch futures and derivatives so that data centers, neoclouds, and lenders can protect themselves against adverse price movements. This is the commodities playbook: if you can’t eliminate the risk, you can at least price it and transfer it.

Today compute has neither path available at scale.

Building trust through risk mitigation

To create these paths, compute needs risk mitigation tools: benchmarks, futures, residual value guarantees, and credit enhancement via aggregation. These are the same things that turned oil and equities from illiquid, bilateral markets into the deepest, most efficient markets in the world.

“It’s all about trust. We have to make it a safer investment. And how do you do that? You have to provide risk mitigation tools,” Wayne said.

One objection I hear when I talk to people about this opportunity is that GPUs aren’t fungible enough to benchmark. Every cluster is unique due to different hardware generation, different networking fabric, different power density, different location, different reliability. How can you publish a single reference price for something that varies so much?

But this is no different from any other commodity. “Oil, Silver and gold, wheat. They all have different grades. Of course GPUs are arguably more different, more like a snowflake, so to speak, than any other commodity class,” Wayne said. But that just means you define minimum specs and index within those bands.

“We don’t have to worry about making it the most granular index in the world. We just want to make a good enough one,” Wayne said. Adding that, “this might sound counterintuitive, but it just needs to be good enough to facilitate any risk mitigation and management.”

In other words, the goal is to build a reference point against which two counterparties with different exposures can transact.

There’s an alternative approach some are trying, which is to force fungibility by abstracting away all the granularity (aka treating every H100 as interchangeable regardless of where it sits or what it’s connected to). I don’t think this is the right approach because you abstract away too many details such that buyers can’t specify their actual needs.

What the end state looks like

There are, of course, companies doing variations of this today. Nvidia is the most obvious one: through its guarantor role, it’s effectively underwriting the market. But they aren’t the long-term solution. The infrastructure layer in any commodity market has to be neutral. A compute market owned by Nvidia would never be trusted by AMD, just like a benchmark owned by a hyperscaler would never be trusted by the neoclouds it competes with. And as for the incumbents like S&P and MSCI, they don’t have the data, the neocloud relationships, or the transaction flow. I think they’ll eventually acquire their way in, but they’re not going to build this from scratch.

There is thus an opportunity to build neutral market infrastructure for compute, which will follow a similar path as other commodity markets.

Compute will eventually become a more liquid market where capacity is procured on demand rather than primarily through long-dated bilateral contracts. Reference prices will be published continuously. Secondary markets will emerge for unused reservations. Credit-enhanced baskets will help smaller AI companies access top-tier supply.

According to Wayne, to make this happen, “it’s ultimately about building trust in the market.”

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

A lot of industrial AI is framed around visible tasks. Can a system inspect a part, sort an item, move an object, classify a defect, or complete a step that a human used to do manually?

These are exciting opportunities, but they are just a fraction of what’s possible. Some of the most important industrial problems are not visible from the outside.

This past week, I explored this idea with Angus Muffatti, one of the founders of Gradient Robotics. On the surface, Gradient looks like a welding robotics company. But Angus describes the company differently: “We’re trying to build metallurgy AI rather than welding AI. The goal is to understand the material behavior in order to know whether the welding process actually worked.”

To understand the material behavior, you need to understand the interaction between material, heat, geometry, and execution. This requires learning to model the hidden structure of the process.

Binary vs. Continuous Problems

Angus framed this as the difference between binary problems and continuous ones.

Some industrial tasks have outcomes that are binary. Did you put the product in the box? Yes or no. The success criteria is easy to verify. A system either completed the task or it did not.

But welding is not like that. “It’s a continuous problem where there’s an infinite range of how good a job was done between zero and one,” Angus said. “A weld can look acceptable on the surface, but actually be terrible.” The success criteria are buried in the interaction between different properties of the material.

“A human welder is inferring what’s happening inside the material they’re putting together. They are interpreting signals and making adjustments based on things they usually can’t observe directly,” Angus told me.

In other words, surface appearance isn’t enough.

This idea extends beyond welding. A part may pass a visual check and still fail under certain stress. A polishing process might hit the target finish while thinning the material too aggressively. A machining process might maintain throughput while accelerating tool wear and increasing variation over time. A welding system might produce seams that look acceptable to the eye while weakening fatigue life or introducing defects that only show up later. In each case, the visible output can look correct even if the underlying process drifts away from what actually matters.

“A lot of the near-term excitement in industrial AI clusters around the binary problems. But some of the deeper opportunities are around solving the continuous problems,” Angus believes. This requires learning what is happening inside a process well enough to intervene intelligently.

Why Welding Is a Useful Test Case

Welding is a good lens because it concentrates many of the core challenges of industrial AI in one place. It is labor-constrained, skill-constrained, quality-sensitive, and tightly tied to production outcomes in many industries. The cost of getting it wrong is high.

As Angus told me, “Welding makes up something like 2% of skilled trades, but around 30% of the shortage. Every year, there’s a gap of about 80,000 welders. Attrition is responsible for about half of this, and then increase in demand is responsible for the other half.” According to the American Welding Society, there is currently a welder shortage of over 400,000 people (source). That makes automation in welding different from the labor automation caricature people sometimes have in mind. The challenge is if and how the industry can maintain output in the face of a shrinking labor base. “If our robotic systems can just keep up with the gaps in this skilled trade, that would barely be enough.”

At the same time, the economic tolerance for quality slippage is extremely low. “If your scrap rates on 100 parts are higher than two, you start to mess with the ROI calculation.”

And because the quality data is hidden inside the physical material, the data mandate looks very different from digital AI. “The data mandate is 10 to 100 times harder,” Angus told me. In digital systems, the signal is often already captured in logs or text. In continuous industrial systems, the relevant signal is hidden inside a physical process or physical material.

That changes what “data collection” means. It may involve thermal cameras tracking heat distribution during welding, machine-vision systems monitoring the weld pool geometry, current and voltage traces from the power supply, force, torque, vibration, or acoustic signatures from the process itself, and downstream inspection data such as X-ray, ultrasound, CT scans, metallography, tensile testing, hardness measurements, or chemical and microstructural assays. And in some workflows, the highest-value signal appears only after the part is run in the field.

This makes the data problem hard. Data collection is slower and getting the ground truth may require destructive testing or long feedback cycles. Labeling is harder too because “good” isn’t usually a single binary outcome. The target itself can also be contested: are you optimizing for immediate yield, cosmetic quality, structural integrity, throughput, or lifetime performance in the field?

Even simulation is less useful than outsiders assume. “The simulation fidelity isn’t good enough yet, and traditional FEA approaches are insanely expensive and too slow to run in a production environment. They also assume idealized materials, whereas the real world is much more complex,” Angus told me. “However, this is something we’re actively working on solving.”

By comparison, some categories of robotics look much easier to get off the ground. “Pick and place is the kind of thing you could probably train in an afternoon.” Here, the prototype path is shorter and progress is easier to show versus in continuous problem categories where progress tends to be slower and harder to visualize.

“But once you can do it, it becomes a significant moat,” Angus believes.

This is a pattern that shows up across AI more broadly. The most defensible opportunities are often the ones where the learning loop is hardest to build and the ground truth is hardest to extract.

Participating in Judgment Before Replacing It

That also helps explain why autonomy in these environments usually has to be earned gradually.

“We didn’t get in the car and take our hands off the steering wheel on day one,” Angus said. “Similarly, we’re not going in and promising the end-to-end complete process.”

Part of that is technical. Part of it is cultural. In many manufacturing environments, systems like welding are tightly tied to product quality, customer trust, and institutional identity. “For a lot of manufacturing businesses, welding is their core competency or a part of their core competency.”

That makes full abstraction emotionally and operationally difficult. “A company coming in and saying, forget about your core competency, let us take care of that, generates an allergic reaction,” Angus said. And in many cases that reaction is rational. “They want to be in control of the quality output of their products because that’s their reputation.”

So the better model is staged deployment. Start with something useful. Help the operator. Improve consistency. Improve quality. Preserve the ability for a human to intervene, correct, and shape the process. “Fundamentally our job is to just make a better machine. Don’t remove the ability of the operator to correct and edit things. This also makes the system better because you learn from those corrections.” Over time, the product gets better and trust builds – and eventually, more of the system can become automated.

The AlphaFold Parallel

There is a precedent for this kind of shift in other fields. In bio, one of the biggest leaps came when systems got better at inferring underlying structure. AlphaFold predicted the three-dimensional structure of proteins from their amino acid sequences, which helped researchers infer a property that had previously been difficult and expensive to determine experimentally. This changed what kinds of questions researchers could even ask, and unlocked enormous downstream value by accelerating the discovery of new medicines and treatments.

Industrial AI may require a similar move. In many industrial processes, the important variables are buried in material behavior, process dynamics, tolerances, and physical interactions that operators learn to infer through experience. In those environments, there’s an opportunity to recover the hidden state of the system well enough to understand why outcomes happen and what to change. That, in turn, has the potential to unlock significant downstream value.

“More focus should be paid to these really deep problems by understanding the physical nature of reality within that specific process,” Angus said. “This means doing the hard work to extract that data, then training models on top of that.”

It may be a slower path, but that is often how the deepest technical understanding gets built.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

Some of the most important AI opportunities in manufacturing will come from AI-native industrial companies built around the workflow itself. In many cases, these businesses may look less like traditional software companies and more like operators: suppliers, service centers, manufacturers, and logistics businesses whose advantage comes from embedding intelligence directly into the physical system.

At my last company, we were effectively trying to build this future, but we did it with a great deal of manual labor. What feels different now is that the technology is finally catching up. We may be reaching a point where building the product itself and using AI to produce it better, faster, and more intelligently is a more durable model than simply selling software to those who do.

I sat down this week with Zane Hengsperger, founder of Nox Metals, to talk about what that future could look like. Nox is an AI-powered metals supplier and modern metal service center. The company sits between mills and machine shops, cuts metal to the sizes customers need, and is building software to optimize pricing, inventory selection, nesting, scheduling, and fulfillment. Nox sells metal at the end of the day, but it uses AI to drive prediction and optimization throughout the operation.

“Software companies are important, but vertically integrated factories are 10x more important,” Zane told me.

In manufacturing, and industrials more broadly, there’s an opportunity to build entirely new forms of capacity.

Prediction, Optimization, and Capacity

One reason manufacturing is such fertile ground for AI is that so much of the industry still runs on fragmented systems and manual workflows.

At its core, manufacturing is made up of a bunch of physical processes. Material comes in, parts go out. But each process in between requires thousands of decisions that determine whether a factory can scale profitably.

How long will this job take? Which piece of inventory should we use? How should this sheet be cut? What should we quote? Can we promise this lead time? Should we take this order or say no? Which machine should run what, in what sequence, at what margin, with what downstream impact on the rest of the schedule?

These decisions drive throughput, yield, utilization, and working capital.

“How do you get metals at the cheapest price and the fastest speed? How do you supply every factory in America in 24 hours at the best price for any of their metal needs? If American manufacturers are going to move faster, they can’t keep waiting so long for metals.” Zane said. “And they can’t keep getting overcharged.”

This is about building supply chain infrastructure, which is a set of prediction and optimization problems embedded inside a physical business.

Some of the highest-value problems are prediction problems: quote accuracy, lead time forecasting, time estimation, and demand prediction. Others are optimization problems: nesting, cut-path generation, scheduling, inventory allocation, and job sequencing.

“Nox is learning from every decision we make on the factory floor. How long something takes. How we decide to cut a piece of metal. What piece of inventory we choose.” Those learnings are key for Nox to improve its own outcomes.

A more accurate estimate means more optimal capacity planning, which means more accepted work, better utilization, lower idle time, better pricing, and faster delivery. “Afterall, capacity determines price in manufacturing,” Zane said. “If you schedule a job for four hours but it actually only takes three, you’ve effectively lost an hour of capacity. That can mean turning down other work or leaving the machine idle just because your time estimate was wrong.”

Controlling the Workflow

These prediction and optimization gains only compound if you actually control the process where they happen. The question is how. There’s been a lot written about the value of finding your wedge – finding one narrow but economically central piece of the stack to own. In manufacturing, this may matter more than almost anywhere else because the right wedge gives you control over the workflow itself. I learned this the hard way at my last company.

In Nox’s case, that wedge is metals supply and processing.

“We sit in between a mill,” Zane said, “and someone who has a CNC machine who is going to make a part.” Nox cuts metal to a specific size for the machinist. And unlike a purely software business, it also holds inventory. “We do hold it on our balance sheet,” he told me. “The inventory is really important so you can move fast.”

In many industrial settings, speed and reliability come from ownership and physical readiness. You cannot compress lead times if the material is not there. You cannot promise speed if you do not control the schedule. You cannot build a learning loop if the important decisions are still happening outside your system.

That is part of what Zane means by vertical integration. “Vertically integrated means you’re building technology internally and applying that to a process,” he said. “That allows you to learn from the data, which is so important.”

I think that is directionally right, especially in industrial markets where the best data is generated from repeated execution of a physical workflow. In these cases, the moat is the operating environment that produces the model’s feedback loop.

Industrial moats do not always look like software moats. In traditional SaaS, investors often look for product differentiation, switching costs, or proprietary data. But in industrials, the moat can be something more physical and cumulative: inventory position, throughput density, process knowledge, and the ability to learn from every job run through the system. This is one reason I am generally skeptical of industrial AI companies that position themselves as thin intelligence layers above the workflow. Some will work. But in many categories, the value actually accrues to whoever controls enough of the underlying system to continuously improve it.

Not every industrial AI company should build a vertically integrated operation. There will be excellent software-only businesses, and companies that sit somewhere in the middle: software plus services, software plus orchestration, software plus selective ownership of the workflow. But I do think the next generation of industrial companies will usually be some sort of hybrid. They will use AI to capture work and reshape it. They will sit close enough to the process to build genuine compounding loops. And they will pick narrow enough wedges that their learning actually transfers and deepens over time.

One thing I have come to appreciate from my own time building in manufacturing is that breadth can dilute learning if a company expands across too many different processes too early. The key is to start with a specific bottleneck where the data and workflows reinforce each other. As Zane put it, “What is the thing that you’re going to get really, really good at before you go and do something else?”

The Limits of Retrofitting

Even if you know the right approach, most existing operators aren’t in a position to execute it. Retrofitting existing factories can be brutally difficult. The data is fragmented. The workflows live partly in software, partly in spreadsheets, partly in whiteboards, partly in the heads of a few experienced operators. The machinery is old. The adoption hurdle is high. And culturally, many factories are not eager to remake themselves around new software, much less AI.

“I don’t think the people that own these factories are going to want to do it,” Zane said, referring to making legacy shops truly AI-native. “You just can’t convince someone of AI. They’re kind of stuck in their ways.”

Technology adoption is thus constrained not just by technical feasibility but by organizational willingness. And that is one reason I suspect a disproportionate amount of value will accrue to new entrants.

“I think these new firms that are like startup manufacturers will just steamroll everyone,” Zane said.

I would probably say it a bit more cautiously, but I think the core idea is right. The future may not be that every legacy factory gradually becomes AI-enabled. It may be that a relatively small number of AI-native operators become so much more responsive, efficient, and reliable that they take disproportionate share.

When I asked Zane what American manufacturing might look like in five to ten years, he said, “You’ll see like 2% of firms doing 30%-50% of the work.”

Once a system becomes meaningfully better at making decisions, it compounds. Better quoting drives more volume. More volume drives more data. More data drives better scheduling, pricing, and fulfillment. Better service drives more customer concentration, which drives better density, which improves economics and response times again.

The Layers of Reindustrialization

This is also, I think, how reindustrialization actually gets built – not top-down, but through operators like this getting faster and denser at every layer of the supply chain. There is a lot of dialogue around rebuilding American industrial capacity. And the conversation often centers on the visible tip of the pyramid: rockets, defense systems, chips, cars. Those categories matter, but industrial capacity depends on a much broader web of upstream systems: raw materials, mills, service centers, processing layers, component suppliers, logistics infrastructure, etc.

When I asked Zane about the biggest bottlenecks to US self-sufficiency, he started with missing or fragile layers of supply. “More companies in the early part of the supply chain,” he said. “Mining companies. Materials. Wire harnesses. We need better capacity.”

Better capacity means more responsive, more automated, more intelligent, and more resilient.

One example he gave was around stainless steel. “One customer we work with had to delay a launch just because they can’t get this one piece of stainless steel. You can get that in China in two weeks. America takes six months.”

Rebuilding American industrialization means solving for this supply chain fragility, rethinking and rebuilding the connective tissue itself.

The Next Generation of Factories

“For every software task startup in manufacturing, there should be 50 factory-first startups,” Zane told me towards the end of our conversation.

Some of those startups will be service centers. Some will be manufacturers. Some will be upstream supply chain businesses. Some will be logistics layers. Some will sit in categories that tech has mostly ignored because they were too operationally difficult or too asset-heavy.

Regardless, the moat in many cases will be the capacity the model helps create - that is the promise of the AI-native manufacturer.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

Much of the conversation around AI focuses on what agents will do to jobs as they automate a growing share of workflows. Just as important is what happens to markets once those workflows are handled by agents acting on behalf of both people and companies.

What changes when software becomes the buyer, recommender, negotiator, reviewer, scheduler, and gatekeeper?

I recently sat down with Andrey Fradkin, an economist who studies digital markets and the economics of AI. He is also the co-host of the Justified Posteriors Podcast. A lot of his work is focused on not only how AI changes productivity inside firms, but also how it changes the structure of markets themselves.

Our conversation explored what happens when agents lower the cost of search, bargaining, matching, and representation – and how that could reshape firm boundaries, market design, and where value accrues.

AI as a transaction-cost shock

In “The Nature of the Firm,” Ronald Coase argued that firms exist in part because they reduce transaction costs: the frictions involved in searching for information, negotiating agreements, and enforcing them. As Andrey put it, “firms are islands of dictatorship in the middle of a market economy.”

Coordinating through markets is costly. Search is costly. Contracting is costly. Negotiation is costly. Monitoring is costly. Representation is costly.

“We have firms in the first place because there are transaction costs,” Andrey said.

But AI is beginning to rewrite those transaction costs.

Agents automate tasks. And in doing so, agents lower the cost of coordination between people, firms, and systems. When that happens, the boundary between what gets done inside a firm and what gets done through the market can start to shift.

“We might see firms – I don’t want to say dissolving – but how they’re organized might be very different,” Andrey said. In other words, if agents really reduce the cost of search, matching, bargaining, and representation, they make new market structures possible.

Representation may get cheaper too

One implication of this is that forms of representation that used to be too expensive may move downmarket.

Historically, many people only got access to agents or intermediaries in very high-value transactions. A Hollywood agent. A sports agent. A high-end recruiter. A broker. A trusted negotiator. Someone who knew the market better than you did and could represent you inside it.

“What is the purpose of those people,” Andrey said, “is that they’re experts in doing a particular transaction, and they have a lot of information.”

The reason we do not all have those services for every market interaction is because they are expensive.

“They’re only worthwhile for big enough things,” he said.

But if the cost of that representation falls dramatically, the economics change.

“Now maybe everyone can have a professional AI labor agent,” Andrey said. “They would scout for all the job openings, prep you for your first round interview, represent you to the employer agent in the correct way, and help you negotiate a salary.”

You can extend that idea well beyond labor markets. Procurement. Insurance. Logistics. Vendor discovery. Expert matching. Commercial negotiations. Many industries still depend on human intermediaries because the work of navigating the market is still fragmented, contextual, and full of small frictions.

Agents may compress a lot of that.

Lower friction creates efficiency, but also breaks signals

Lower transaction costs mean less friction. But many markets also depended on that friction.

As Andrey put it, “a lot of society has worked so well because of transaction costs.”

Costly effort used to be a signal. A thoughtful outreach email. A carefully tailored application. A detailed explanation. Even if these things were imperfect, they often served as evidence of intent.

“If I wrote you a very thoughtful email about why it would be worthwhile having a conversation,” Andrey said, “then you might say, well, this person really has a good reason to meet with me. But that signal has now gotten destroyed.”

AI can now generate the appearance of effort at essentially zero marginal cost.

The old filters thus stop working. Outreach gets cheaper, but congestion rises. Representation gets easier, but trust falls. Coordination gets faster, but attention gets harder to allocate.

I think this is why so much discourse online collapses into “I don’t want to read your AI slop.” People are reacting to the breakdown of effort as a signal.

In a world where polished output is abundant, what becomes scarce is credible intent.

The next layer of value may sit in trust infrastructure

So if effort is cheap, markets need new ways to establish credibility.

If agents act on behalf of users, they need to know preferences, know when they are uncertain, and know when to ask for more information.

If AI systems interact with each other, they need stronger identity, verification, and reputation systems.

“The agent doesn’t know your preferences. And a lot of agent failures are because of this,” Andrey said. They are failures of representation. The system does not know what you value, where the threshold is, what tradeoff you would make, or when it should escalate uncertainty back to you.

He also pointed to a deeper technical issue: currently agents are really bad at knowing what they truly know or don’t know.

“You can ask an agent in a lot of cases, ‘How confident are you in this answer?’ and they’ll give you a number that’s really poorly calibrated.”

This is what makes the trust and governance stack around agents so important. This could mean identity and proof-of-humanity infrastructure. It could mean AI-native reputation systems. It could mean software that helps agents learn and represent user preferences more faithfully. It could mean calibration layers, confidence estimation, escalation logic, compliance rails, or vertical systems that become the default authority on what “good” looks like.

Some old market mechanisms may come back

Ironically, AI agents may in fact make certain outdated market designs viable once again.

For example, “we may want to use auctions a lot more,” Andrey told me. While auctions can often allocate supply and demand more efficiently, many markets still rely on simpler mechanisms because they are less cognitively demanding for humans. “The reason we don’t use auctions today is that for normal consumers, it’s a pain to participate in auctions. You have to monitor them.”

But agents don’t care about that. They can monitor and wait as long as needed. They can participate in hundreds or thousands of processes at once. They have, in effect, infinite patience.

And if agents absorb that complexity, some markets may move back toward more efficient pricing mechanisms: auctions, dynamic pricing, more granular negotiation, and continuous matching.

I suspect that will matter most in fragmented B2B markets: procurement, freight, insurance, industrial sourcing, bespoke quoting, and anywhere else that still runs on manual back-and-forth.

Redesigning markets, not just workflows

As agents proliferate across enterprise and consumer workflows, there will be many opportunities to redesign the institutions and market mechanisms that intelligence plugs into.

“AI is a technology that’s drastically reshaping transaction costs,” Andrey said toward the end of our conversation, “and that may end up reshaping markets too.”

Lowering transaction costs doesn’t automatically make firms simpler or markets cleaner. In many cases, it may actually create new forms of congestion and fragmentation. But it also opens the door to new ways of matching supply and demand, allocating attention, establishing trust, and coordinating work. If software becomes the buyer, negotiator, scheduler, recommender, and gatekeeper, then market design becomes a product surface.

Andrey Fradkin is on-leave working on economics of AI topics at Amazon, but these quotes represent his views and not those of Amazon.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

AI physics simulation has the potential to make simulations 10,000x faster.

As I wrote about previously here and here, simulation has always been expensive, slow, and confined to a relatively small set of experts. So the idea that AI could accelerate it – and perhaps even democratize it – is compelling.

However, I recently spoke with Ben Savinson, a PhD student at ETH Zürich who is applying physics-based ML methods to manufacturing. “Speed is valuable, but it’s not always the bottleneck,” he told me. “Often the real value is unlocked by improvements in accuracy.”

In a production environment, simulation doesn’t happen in isolation. It sits inside a much larger process with physical steps, machine setup, tool changes, parallel operations, and sometimes long feedback loops. “If the manufacturing process is not compute-limited, companies really don’t care how long the simulation takes,” he told me. In other words, if the rest of the workflow is gated by days or weeks of physical production time, making one piece of software faster may not materially change the economic outcome.

Simulation speed in manufacturing

In many manufacturing settings, simulation is already fast enough to fit inside production cycle times. Speeding it up further often does not make a material difference.

That does not mean speed is irrelevant. In some cases, it matters a lot. Ben pointed to semiconductor manufacturing, where the problem of correcting masks for wafer printing has become genuinely compute constrained. In a context like that, reducing simulation time can unlock enormous value because the factory is literally waiting on the computation.

But those cases are somewhat narrow. “The assumption that if you make something faster, it always provides a lot of value is not necessarily true,” Ben said.

Manufacturing companies don’t care about simulation time on its own. They care about throughput, yield, scrap, downtime, and output. As Ben put it, “They care about the metric of whatever they’re producing.”

Modeling failures at the tail

If AI in manufacturing simulation is not just about making existing simulations faster, the question becomes what it means to make them better. And in manufacturing, the hardest version of “better” is also the most valuable: modeling failures at the tail. The failures that matter most are often not the average cases. They are the rare ones.

“In manufacturing, you mainly care about tail and extreme events,” Ben told me.

Most ML is very good at interpolation – it learns patterns from historical examples and makes predictions on cases that look similar to what it’s seen before. But in manufacturing, the most economically important outcomes are usually the anomalies – the one-in-a-thousand failures, the edge cases, the defects that destroy yield or cause catastrophic downstream consequences.

“The events you really want to capture are exactly the events that boilerplate AI is pretty poor at capturing,” he said.

This makes the opportunity both exciting and challenging. On the one hand, there is clearly value in better modeling these processes. On the other hand, the specific cases customers care about most are precisely the ones that data-driven systems struggle with because they are underrepresented in the training distribution.

This is why Ben is skeptical that AI will simply replace the physics stack.

“If anyone tells you we’re going to completely replace the physics stack, I don’t think it’s going to work,” he said.

When you need to extrapolate, physics still matters. “Physical laws, by definition, extrapolate beyond the observed distribution,” he said. Maxwell’s equations do not stop working when conditions become extreme. Navier-Stokes does not cease to apply because the environment gets more difficult. The equations are useful precisely because they encode structure that generalizes beyond the available dataset.

This doesn’t mean the physics model is sufficient on its own. Ben’s point is that it often is not. But it does mean that the best systems are likely to be hybrid.

“You need to bake as much physics into the model as possible,” he said, “to make sure the model has a prior to capture these extreme events. And it’s not just interpolating.”

The gap between simulation and reality

So if AI is not going to replace the physics stack, where does it add the most value?

Ben’s view is that it might be in closing the gap between simulation and reality. “It isn’t just making physics solvers much faster,” he said, “but enhancing them and closing the gap to real-world data.”

In many industrial processes, the physics model is principled but incomplete. It captures the known structure of the system, but not everything that actually happens on the factory floor. Materials behave differently than expected. Machines wear down. Environmental conditions shift. Unknown interactions emerge between tools and processes. There is usually a gap between what the simulator predicts and what you actually see.

“Oftentimes the physical simulation is quite far away from what you see in experiment,” Ben said. The opportunity is therefore to use real process data to bring simulations closer to reality – not just to run faster but to capture what purely physics-based models miss.“By combining data-driven approaches with the underlying physical framework, you can actually have a better simulation as opposed to only a faster one,” Ben said.

Ben pointed to weather as a useful analogy. One reason AI has worked so well there is that you have two things at once: a physics-based framework and a large amount of real-world data. “There’s a physical model that is principled, but it doesn’t really capture everything in the accuracy you would want,” he said. “And you have a huge amount of data.” The governing equations provide structure, but the system itself is chaotic, only partially observable, and difficult to model perfectly. That is where AI helps because it can learn the gap between theory and reality.

Certain manufacturing processes may eventually look similar. You have an underlying physics stack, but also a large amount of measured output data from the process itself. You can observe what comes out the other side. You can see the defects, the drift, the variability, the errors, etc. In the right settings, this creates the conditions for AI to sit on top of the physics layer and improve the model.

This is also a much stronger value proposition. Manufacturers do not buy on solver speed alone; they buy when it moves a production metric.

“The metrics you want to push upwards are throughput and yield,” Ben said. If you can model the process more accurately, you can tune it more effectively. You can reduce defects, tighten variability, and throw away fewer parts. In semiconductor manufacturing, that means fewer broken transistors and fewer unusable chips. In other industrial settings, it could mean fewer failed runs, fewer rejected components, or more stable performance across production lines. Either way, the value accrues because the model improves the process, not just the speed of the simulation.

This is why the opportunity for AI in manufacturing simulation may be less about replacing physics than extending it. In manufacturing, value comes from using AI to close the gap between first-principles models and real-world production data — and in doing so, improve outcomes on the factory floor. After all, the goal is not faster simulation — it’s better manufacturing.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

The dream in robotics is a robot that can do everything a human can do. And that “generalist robotics” dream shapes much of the field today.

Many companies are pursuing a generalist approach, with the implicit belief that if you gather enough multimodal data, train on enough tasks, and scale the model far enough, generality will emerge.

But that has not really panned out in production. For example, researchers at Stanford and Google DeepMind recently ran 1,600+ real-world robot trials across 14 axes of generalization and found that state-of-the-art generalist manipulation policies still struggle with small perturbations, from a changed camera angle to a rephrased instruction or shifts in object properties. The gap between promising research results and real-world deployability remains large.

Generality may come eventually, but it’s unlikely to be the near-term commercial unlock.

I sat down with Ken Goldberg, professor of Robotics and Automation at UC Berkeley, to talk about this tension and how we can bridge the gap. “I do think we’ll get to full generality at a certain point,” Ken told me, “but I don’t think that’s going to happen in the next few years.”

Generalist Dream vs. Specialist Reality

The questions we ask in research are different from the questions that matter in a commercial environment.

In research, the focus is often on generalization: Can the system handle more scenarios? Can it adapt across environments? Can it learn broad capabilities from diverse data?

In a commercial context, the questions are much more concrete: Does it work? Does it keep working? What is the throughput? What is the uptime? Does it integrate into an existing workflow? Does it save money?

“You never think about uptime when you’re doing research, but if the robot is going down even once a week, your customers are going to give you a lot of grief and maybe walk away.” Ken said.

That is one of the central divides in robotics right now. Academic and frontier-model discussions are often driven by the pursuit of generality. Buyers are evaluating against an entirely different standard.

“It can be the most advanced technology on the planet, but if it’s not doing something really useful and reliable, customers aren’t going to want it.”

What “Good Old-Fashioned Engineering” Means

This is where Ken’s notion of “good old-fashioned engineering” comes in. If the goal is to make robots actually work in production, then why not use every available tool, including those that have been used for decades, to improve reliability?

There is a common attitude that thinks it’s “cheating” to include mathematical functions like inverse kinematics or low-pass filters into a robot system. Their aspiration is to build systems that infer everything end-to-end, rather than building on well-established engineering.

“The generalists don’t want to use any tools that we know work in specialist scenarios. There’s a “purist” attitude that can be very dogmatic.”

But in production, that framing is counterproductive. “This kind of purism in the academic setting does push science forward,” Ken said, “but it also can be to the detriment of actually getting systems to work.”

Ken talks a lot about “good old-fashioned engineering,” (GOFE, which rhymes with Sophie) which basically means using whatever tools are available to make the system work reliably in the real world. If you know the height of the table, why not add a rule so the gripper never dips below that threshold and crashes? If you know something about the geometry of the workspace or the boundaries of the environment, why ignore that?

“GOFE is viewed as a crutch, something you’re encouraged to stay away from at all costs. But GOFE can be extremely helpful to get robots to work reliably in real environments so they can collect data,” Ken told me.

In practice, many of the best robotics companies are probably already doing exactly this. “They are quietly inserting GOFE into their systems. They are constraining environments, adding fallback logic, layering software, and shaping the workflow around the model.”

They’re just not always talking about it.

“I wish the field were more flexible about how to get real systems to work reliably. GOFE isn’t cheating. It can be extremely helpful to move systems toward generality. If you make it more explicit, then you have many more options.”

The Opportunities

The assumption has been: just collect data on everything out there and throw it all together, and it will suddenly start to become general. That has not panned out, and that’s not what customers are looking for.

Even if generalist systems improve, most customers aren’t looking for a robot that might eventually do many things. As I wrote about here, many want a robot that can at least do one thing really well, over and over again. “Most successes in robotics require 99.99% uptime,” Saman Farid, CEO of Formic, told me. “Most people underestimate how hard that bar is to hit.” Not to mention, real deployments are also incredibly complex, as I wrote about here.

That’s why the best near-term opportunities are probably in specialist systems. “I’m very excited about accelerating the process to get robots to reliably perform specialized tasks,” Ken said. “These systems don’t require full general intelligence. They require bounded generality inside a specific workflow. A robot may just need to sort packages, or complete one assembly step. In many cases, that is enough to create value.”

GOFE can help get the first system working. And it often determines whether the second and third deployments get easier, or whether the company ends up rebuilding everything customer by customer.

As Ken explained, “You get it into production, and then you start selling systems and collecting more data. You’re collecting data around functionality, not generality. Once you’ve collected a large dataset for a specialized robot, you can use that to learn adjacent skills.”

In other words, the path is to start with a specialized use case, get into production, start a data avalanche, and expand outward from there.

Don’t Expect Miracles

If the goal is to move robotics into production, the near-term opportunities aren’t about building pure generalizable robots. They’re about leveraging GOFE to build systems that customers can actually trust.

“It’s time for the community to come off its high horse a little bit,” Ken told me towards the end of our conversation. “Let’s use GOFE when helpful to get robots into production.”

The dream of general robotics is still alive. And I’m sure one day we will get there.

But in the meantime, Ken emphasizes the importance of getting things to work reliably in production: “Building great technology is one thing. Finding how to please customers is the next big step.”

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

In Part 1, I focused on the what. What are PINNs, neural operators, and the future of simulation – the idea that AI can learn mappings from geometry, materials, and boundary conditions to predict system behavior.

This post is mostly about the where and the how. Where the near-term opportunities are and how to actually move these methods into the hands of engineers.

However, before diving into this, some people reached out to me after I posted Part 1 to tell me that they think I missed some things, so I want to address that first.

What I Missed in Part 1

After publishing Part 1, I got some helpful pushback from a few people who work in this space. Specifically, I implied it was a “short jump” from neural operators to foundation models for physics. That undersells how hard the jump actually is, and I want to correct that here.

The first thing I underappreciated is how sensitive some physical systems can be to small changes in setup. Chaos theory tells us that you can write your initial conditions to the fifth decimal place, evolve the system forward, and get one answer. However, if you write them to the sixth decimal, the solutions will diverge completely. Everything is deterministic, but tiny differences in precision cascade over time. This shows up across fluid dynamics (Navier-Stokes, for example), structural mechanics, and many other domains engineers care about. It means that even a perfect model can produce wildly different outputs based on very small changes in how the problem is set up. This makes generalization hard.

The second thing I over-simplified was how I framed the Fourier Neural Operator (FNO). I presented it as a promising early step toward generalization – which it is, in narrow settings. But I didn’t adequately convey how narrow those settings are. FNO works best when the underlying problem has clean, regular structure. Once the boundary conditions get messy or the geometry loses that regularity, the approach starts to break down. For example, airflow through a smooth, rectangular channel is where FNO does well. But airflow through a machine part with holes, bends, sharp corners, and different materials is much less clean. The geometry is irregular, and what happens at the edges matters much more. FNO has a harder time here.

More broadly, I underestimated the degree to which physics modeling is an art, not just a science. The same governing equations, implemented on different computer architectures with operations ordered slightly differently, can produce different numerical results. One person I spoke with pointed to jet engine design as an example: some of the code still in use dates back to the 1970s, and firms are extremely reluctant to touch it. The reason isn’t that no one can rewrite Fortran 77 in C or Python. It’s that the full stack (the models, the numerics, the implementation, and the validation history around them) has already been vetted by the FAA. As a result, design changes made using that code are often approved without having to rerun physical experiments. Reimplementing this would mean reopening lots of questions that would require FAA approval each time: did anything change in the physics, the numerics, the code path, or the approval basis built around them? In that sense, some of the hardest barriers here are not purely technical. They’re also about trust and how deeply a tool is embedded in an existing engineering workflow.

None of this means the work on PINNs or neural operators isn’t an important step for the field. But it does mean the path to deployment is narrower and more domain-constrained than I implied in Part 1. At least in the near term, the opportunity is unlikely to be a single model that can handle all physics across all settings. More likely, progress will come from systems that start in specific domains. In some cases, that may look like specialized surrogate models built on top of expensive simulations. In other cases, that may look like a narrow initial wedge that expands into solver acceleration or a broader physics intelligence layer. That is where I want to focus the rest of this post.

Where the Opportunities Are Today

There seem to be at least two paths emerging in AI-driven simulation. One uses AI to learn surrogate models that approximate expensive simulations and accelerate design exploration. The other focuses on accelerating the physics computation itself while remaining grounded in the governing equations.

The opportunities I’m most excited about do not all sit neatly in one camp, but they tend to share the same traits: physics that is constrained enough to model today, relatively structured workflows, and some path to verification against either trusted simulations or real-world test data.

Thermal simulation as an early wedge

Thermal is one of the cleanest early wedges because the physics is relatively well understood, the governing equations are well established, and validation data exists across many hardware domains. In many hardware systems – whether it be semiconductors, batteries, power electronics, or industrial equipment – heat is an important constraint to understand. Teams need to know where and when temperatures rise, how materials behave under thermal stress, and how this impacts performance and manufacturability.

It’s also a useful place to start for workflow reasons. In many organizations, thermal analysis is still done by specialized people using specialized tools, and it often happens relatively late in the process, after much of the design has already been set. If you can make thermal analysis faster, easier to access, and easier to use without giving up fidelity, you can change when physics shows up in the design process and who can realistically use it.

A close friend, Dr. Hardik Kabaria, founded Vinci, which started with thermal problems in semiconductor electronics. That narrow starting point meant that they could build and ship a product fast. “We did not want to spend eight years building a model before shipping a product,” Hardik told me.

The broader ambition, though, is not to build a different model for every industry. Vinci is already working with customers across semiconductors, electronics, batteries, defense, and other hardware-heavy domains. As Hardik put it, “What gives us confidence in the breadth is that the underlying physics is the same. Heat transfer in a robotic arm, a PCB, or a semiconductor is still governed by the same equations, so the ambition is one model, not a different model for every industry.”

From there, the plan is to keep adding more physical phenomena to the same foundation model, starting with thermo-mechanical coupling. So even though the entry point is narrow, the system itself is unified (one model, one codebase) and over time a broader set of physics capabilities can be added on top.

AI-powered surrogate modeling

In the physics world, engineers already work with a hierarchy of models: there are simple, fast ones for early design, and expensive, granular ones (think full finite element simulations) for detailed analysis. The process of taking those granular models and building cheaper simplified versions takes deep expertise, and the results vary a lot depending on who does it.

AI could automate a meaningful chunk of this by running the expensive simulations, collecting the outputs, and then using that data (along with physics constraints) to build faster surrogate models. By integrating these surrogate models into their workflows, engineers wouldn’t have to query the expensive model as often, and they’d get a more accurate simplified model than what they’d typically build by hand.

This is one place where techniques like PINNs and neural operators could be helpful today as tools for building better surrogates. That said, surrogate modeling is not the only path emerging. A lot of the academic work around PINNs and neural operators naturally lends itself to surrogate construction, since these models learn mappings from inputs to outputs based on training data. But there is also another line of work focused on accelerating the physics computation itself, rather than learning an approximation of it.

In those systems, the goal isn’t to replace simulation with a trained model, but to build architectures that remain rooted in the governing physics while also dramatically reducing computational cost. This matters because many engineering organizations still require solver-grade determinism and traceability for design decisions, which can make purely learned surrogates harder to deploy in production workflows.

Surrogates will likely play an important role in early design exploration, but there may also be a parallel path where AI helps make full-fidelity physics computation much more accessible and scalable.

Reducing setup time and lowering the expertise barrier

In a lot of multi-physics work, the bottleneck is the pre-solve. Engineers spend hours cleaning up geometry, figuring out how to mesh it, choosing boundary conditions, and chasing missing material properties. This is basically all the work required to turn a CAD file into something you can actually simulate.

If you can shrink that setup time, simulation becomes something teams can use while they’re designing. This not only makes simulation faster, but it also changes who can realistically use it. When the setup process becomes automated or significantly simplified, simulation stops being something only specialized analysts can run. It becomes something design engineers or small hardware teams can use during iteration, while they’re still exploring the design.

Initially, you still have to show up where engineers already work: inside CAD/CAE, or at least one click away from it. If it’s a separate tool with a new file format and a whole new workflow, it won’t become a habit. But if AI can remove enough of the pre-solve burden, physics can start showing up earlier in the design loop rather than only during validation.

There is an even bigger opportunity here, too: lowering the expertise threshold required to ask a physics question in the first place, without lowering the quality of the answer. As Hardik put it to me, “the goal is to reduce the bar for access, but not at the cost of reducing accuracy.”

A lot of AI tooling can make experts somewhat faster. The bigger unlock would be making solver-grade physics accessible to design engineers, manufacturing teams, and other adjacent functions that currently have to wait on specialized analysts.

Material property prediction

Every time something is manufactured, the material properties shift slightly, and it’s very hard to know exactly what changed. Engineers deal with this through uncertainty analysis: they physically test samples, use those measurements to estimate a realistic range for the material properties, and then run analyses across that range. You can almost never know the material properties at every point in the part with complete precision.

For non-safety-critical parts with high tolerance for variation, rough bounds are often fine. But for a turbine blade or a chip going onto a satellite, the simulation has to be reliable, which means the material inputs have to be reliable too.

AI could help here in two ways. One is by improving material prediction itself: narrowing the uncertainty, flagging anomalies, or learning patterns across manufacturing runs. The other is by making uncertainty analysis more tractable. In many workflows today, engineers run parameter sweeps across ranges of material properties to understand how sensitive a design is to variation, but those analyses can be computationally expensive, which limits how thoroughly teams can explore the uncertainty space.

If simulation becomes cheaper or easier to run, engineers can evaluate far more combinations of parameters and get a better picture of the reliability envelope of a design. In that sense, AI may help not just by predicting material properties more accurately, but by helping teams reason about the consequences of uncertainty much more efficiently.

Experimental validation and parameter sweeps

Between simulation and manufacturing, there is usually a validation phase where engineers test whether the simulated results hold up in the real world. For example: does this design still work when the temperature is higher or lower? What if the material comes in at the low end of tolerance? To build confidence in the design, teams build prototypes or use test rigs, run parameter sweeps across different conditions, and iterate as needed.

This process is usually slow and expensive because teams have to test many different configurations to understand where the design holds and where it breaks.

AI could be useful here as an experiment-planning layer: helping teams decide which tests to run first, which parameter combinations are most informative, and how to reduce the total number of physical experiments needed to reach confidence. If you can cut a validation campaign from 200 runs to 50 without missing the important failure modes, the ROI is obvious.

AI may also be helpful here by shifting more of the exploration into simulation before experiments begin. In many engineering workflows today, teams run a relatively small number of simulations and then rely heavily on physical testing to explore the parameter space. If simulation becomes significantly cheaper or easier to run, engineers can evaluate far more conditions computationally before committing to physical prototypes.

In that world, the role of experiments changes slightly. Instead of mapping out the full parameter space, experiments become a way to validate the most critical regions of a design space that has already been explored in simulation. AI-driven experiment planning is clearly promising, but the combination of large-scale simulation exploration plus targeted validation experiments may be just as important for reducing overall development time.

And unlike simulation itself, this is often a less established workflow, with fewer incumbent software vendors to displace.

The Business Model Problem & How it Evolves

Because the CAD/CAE stack is already so entrenched, one seemingly obvious path for a startup is integration. Ship a plugin and live inside the existing ecosystem.

But being a plugin is a trap. The same incumbents you rely on for distribution control the chokepoints. They can see your downloads, pricing, and usage. As Matthew told me last week: “You build a plugin and distribute it through their app store, and in return, they get perfect visibility into your pricing and revenue. If it starts working, they show up with an ‘acquisition offer’ that’s really a veiled threat: nice business you’ve got… would be a shame if anything happened to your app store access.”

Then there’s the consulting trap. If every deployment requires building bespoke models for a specific customer or domain, it becomes difficult to scale the business beyond services. That challenge is made worse by the fact that domain specialization still seems hard to avoid, at least for now. You can’t take a model built for HVAC systems and use it to design a jet engine. The governing equations may be similar at a high level, but as discussed above, that is not enough. In practice, this market is still a collection of narrow verticals.

However, there may be a third path emerging between those two extremes. Instead of positioning as a plugin or bespoke modeling shop, some companies may try to build independent physics computation platforms that sit alongside existing design tools and can be called from multiple workflows (design, verification, manufacturing, or reliability analysis) without being tightly coupled to a single CAD or CAE system. Here, the product becomes a kind of physics infrastructure that can serve multiple parts of the engineering stack.

Vinci is an example of this idea. They’re not just focused on faster simulation, but rather on broader access: can physics become accessible, usable, and easy for a much wider set of people in the design workflow? As Hardik put it to me, “the product is a physics intelligence layer that can be available to everybody. It’s not just for the thermal engineer. If I’m doing a manufacturability check, physics is accessible to me too.”

That shift in who can use the product also shifts the economic model around it. If the goal is to put physics into the hands of more people, traditional seat-based pricing is probably not the right model. Hardik believes that once physics becomes broadly accessible across an engineering organization, the bottleneck shifts from expert labor to system throughput. “Where a thermal engineer might previously run 10 to 100 simulations a day at best, Vinci’s system is already enabling thousands,” he told me. In that world, pricing starts to look more like compute- or usage-based.

Then, if simulation becomes cheaper and easier to run, the value may shift away from selling individual solver runs and toward providing reliable physics computation as a service across the engineering stack. That approach may help avoid both the plugin dependency problem and the consulting trap, though it introduces its own challenges around integration, trust, and workflow adoption.

From Simulation to Continuous Physics

It seems unlikely that AI will broadly replace engineering simulation in the near term, especially for the hardest multi-physics problems with complex geometries and uncertain inputs. Inference is too expensive for always-on use in many settings. The talent pool is small. And the data requirements are enormous: as I mentioned last week, Matthew’s back-of-the-envelope is ~2 million points per time step in 3D, multiplied across thousands of time steps.

But the gap between what is possible in AI-physics research and what’s getting deployed in engineering workflows is closing.

“The impact of AI is less about replacing the solver and more about making physics computation cheaper and more accessible so that it becomes a continuous part of engineering decision-making,” Hardik told me toward the end of our conversation. That shift could move physics simulation from a specialized validation step into a continuous layer of engineering decision-making across the design process. And that may ultimately be the bigger opportunity for physics foundation models.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

A lot of engineering work is about solving the math of how physical systems behave – for example, stress, heat, airflow, diffusion, vibration. Engineers run simulations (in SolidWorks / ANSYS / COMSOL) to try to turn these real world variables into a solvable numerical problem.

If AI can learn the rules behind this (aka “here’s the geometry, materials, and boundary conditions” and output “here’s what happens”), then iteration gets a lot cheaper and faster. You can explore more of the design space, more often, with fewer specialist bottlenecks. And over time, simulation starts to be embedded inside the design workflow. CAD and CAE begin to blur into one.

One of the most helpful conversations for me around this topic was with my friend Matthew Tamayo-Rios, a PhD student in applied math at ETH Zürich working with Prof. Siddhartha Mishra’s group, which is well known for scientific machine learning (ML for PDEs (Partial Differential Equations) / physics-informed methods).

Below is part one of what I’ve learned since starting to research this space, including some highlights from my conversation with Matthew.

What Is a PINN?

Physics-informed neural networks (PINNs) were introduced in 2017 by Maziar Raissi, Paris Perdikaris, and George Em Karniadakis in a two-part series (Part I and Part II), later consolidated in a 2019 Journal of Computational Physics paper. A PINN is, at its core, an attempt to train a neural network that respects the laws of physics. It’s trained to match the data, but also to respect the physics by adding a penalty to the loss whenever the model violates the PDE. “You want to encode the physics by setting it up as a minimization problem and letting the neural network learn how to solve it,” Matthew told me.

A PINN is basically a function you can query. For example, give it a location inside an object and a time, and it tells you the temperature there. The key is how it’s trained. You’re grading it on two things at once: 1) does it match the measurements you have, and 2) does it obey the basic rules of heat flow, including what has to be true at the boundaries? If it matches the data but breaks the rules, it gets a worse score. Over time, training pushes it toward temperature maps that fit without breaking the laws of physics.

In a traditional simulation, the computer can’t solve the physics at every point inside a solid or fluid, so it breaks the geometry into lots of tiny elements, known as a mesh, and solves the equations at those discrete points. However, meshes are painful because the quality of your answer depends a lot on how you mesh. “Your mesh determines the granularity of your simulation… and in between your mesh nodes, you only have an approximation,” Matthew said. If the mesh is too rough, you miss the sharp, important effects. If it’s too fine, the simulation gets slow and expensive. And if the design changes, you often have to rebuild the mesh and start over.

In a PINN, even though you still have discretized sampling, you don’t need meshes because the neural net is a continuous solution function. The neural net acts like a smooth map you can query at any point. During training, you compute the quantities you need to check the physics for (like rates of change) directly from the model, then penalize it whenever the physics doesn’t balance. The amount by which it fails the equation is the PDE residual.

Why PINNs Seemed So Promising

Most real-world engineering starts with partial signals and a lot of unknowns. You can measure some things, but not all of them (material properties, exact loads, what’s really happening at the boundaries, where the heat is actually coming from, what’s going on between a handful of noisy sensors). You’re basically working backwards from what you can observe to what’s happening underneath.

PINNs let you do physics modeling without needing a ton of labeled datasets. They’re a way to take whatever data you do have and train a model that’s also constrained by the rules of physics. They are often a good way to build approximations when you already know the governing structure and you’re willing to tailor the setup to a specific system. As Matthew put it, they can be “relatively easy to setup as neural surrogates for a specific system.”

That’s why they seemed so promising initially.

Why PINNs Struggle

“PINNs have a bunch of failure modes,” Matthew told me. One big one is that neural nets tend to learn the smooth, easy patterns first, and struggle with the sharp, rapid variations. In other words, they’ll often get the overall shape right but miss certain important details like thin boundary layers or turbulence.

The other issue is that training can be hard. You’re asking the model to do a few things at once: match whatever data you have, follow the governing equation, and satisfy boundary conditions. Those pieces can fight each other. The model can “cheat” by satisfying the easy parts and still getting the physics wrong, especially in stiff or chaotic systems.

That’s why the straightforward version of PINNs aren’t reliably robust enough in the real-world regimes we care about.

Neural Operators: A Shift in Thinking

With neural operators, the idea is that instead of training a model to predict the solution for one specific setup, you try to learn the mapping from a problem description to the full solution. You feed in what defines the problem (e.g. the boundary conditions, the initial conditions, the parameters) and then the model outputs the entire solution field. Matthew’s work is focused here. As he put it, “I’m aiming for a physics-informed operator learning model that is mesh-free.”

Matthew defined “operator learning” as “something that takes any input function or field and maps it to a solution function or field. You give it boundary conditions, initial conditions, and the PDE and it maps it to the e solution over time.” You’re learning the mapping from the setup to the full answer.

One of the best-known examples is the Fourier Neural Operator (FNO). The idea is that it learns the solution operator, which is a mapping from boundary/initial conditions to the full solution, in a way that can transfer across resolutions more gracefully than traditional surrogate models, which are typically tied to a specific mesh or grid. FNO-style models have shown strong results on standard PDE benchmarks, and in some cases a model trained at one resolution can be evaluated at a finer resolution without retraining, aka zero-shot super-resolution.

It’s not a guarantee it will hold in every messy real-world regime and you often don’t truly know the exact parameters of the PDE you’re solving. But it’s the first time this starts to feel like pretraining: “you spend a lot of time training it the first time, and then you can apply it to different types of problems,” Matthew told me.

Foundation Models for Physics

From there, it’s a short jump to foundation models for physics: pretrain over broad families of PDEs or physical systems, then fine-tune for downstream tasks. You see early versions of this in the climate space (for example, ClimaX) and in newer operator-learning efforts aimed at being more general-purpose.

Matthew pointed to Poseidon as one of the early attempts in this direction. “It’s one of the first foundation models that generalizes to unseen physics, and is easy to transfer to new geometries and new parameter regimes.” However, Matthew did caveat this by saying “it still assumes structured grids, requires a ton of data, takes forever to train… and where the physics gets tricky, it starts struggling.”

Those caveats point to the two problems that keep coming up for physics foundation models. First, they demand a huge amount of data, especially in 3D. Matthew’s back-of-the-envelope: sample a 3D volume at 128 points per dimension and you’re already at ~2 million points per time step. Run that over thousands of time steps and the dataset grows very large very fast.

The other big issue is that “in real-world scenarios, you don’t know what the PDE you’re solving is” Matthew told me. You may know the general form, but key parameters are unknown, and it’s unclear which physical regime you’re in. In other words, you’re not just solving for a solution given a PDE. You’re actually trying to solve for a solution given partial physics, unknown coefficients, operating condition ambiguities, and noisy data. That’s what makes deployment so hard.

Put together, these two constraints around data and unknown variables explain why there’s still a gap between research and production. Shipping these models into live environments requires knowing when the models are right, when they’re wrong, and how to calibrate them. It also means embedding these models into the tools engineers already use, which is no small feat in an ecosystem dominated by just a handful of incumbents.

In next week’s post, I’ll explore what it takes to close this gap, which use cases are practical today, and where the ROI is. Trust, calibration loops, workflow ownership, and integration into the tools engineers already use are a few of the topics I plan to cover.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

Most of these arguments distill down to a question of where you sit in the value chain, what you control once the model itself is no longer the differentiator.

I think there are two positions that matter more than everything else for durable defensibility. First: owning the moment data is created, something I call the mint position. This means not just reading what’s already in the system of record, but being in the flow when an action turns into structured data. Second: owning the accountability position, which means being responsible if/when things go wrong. This forces you into the systems and relationships that create the record, the audit trail, and the outcome itself.

In a world where models get cheaper and better, these are the two places where moats still form.

Owning the Mint Position

Sitting on top of company data and/or being the system of record are important, but will not alone create a durable moat. You need to take it one step further and own what I call the mint position: being the system that stamps work into official records at the moment it happens. It’s the difference between being where the data gets logged versus actually defining how, when and where data is created. A vault stores value, a ledger records it, but a mint creates it.

Sometimes hardware matters because it makes it easier to capture the moment right where the work happens. Sometimes owning the transaction matters because it makes you the layer that records the actual state change: the thing that moves money, inventory, liability, or authorization through the system. Either way, the key is occupying the mint position so you capture the data as it’s born, not after the fact.

For example, a lot of warehouse software has the data because it sits on top of the Warehouse Management System (WMS) and pulls inventory records. But the inventory record is often wrong because the real truth gets created in the receiving aisle: partial shipments, swapped SKUs, damaged cartons, mislabeled lots. Owning the mint position means capturing the discrepancy the moment it happens via a photo, video, voice note, which then writes the state change into the WMS immediately. Quarantine this lot, split the receipt, adjust inventory, trigger a supplier chargeback or claim. You’re creating the inventory truth and the transaction trail the business runs on.

Once you own the mint position, three things happen:

1. You’re now generating the labeled ground truth data.

2. That ground truth data becomes the way teams make decisions and report on those decisions.

3. Switching costs become higher the more decisions and reports you enable.

Owning the Accountability Position

Owning the accountability position means that if something goes wrong, you are responsible (even if in a bounded way). This is similar to outcome-based pricing, but takes it a step further because you don’t just price on outcomes, you underwrite them. You stand behind a specific promise (accuracy, timeliness, compliance, recovery, reconciliation), and so if/when something breaks, you’re the party that has to fix it, pay for it, and prove what happened. That forces you into the transaction path and makes your system the authoritative record.

Regulatory environments are inherently defensible, and many of the recent essays are right to emphasize it. In this sense, it’s about becoming the compliance surface presented to institutions. It means your records are the ones regulators and auditors accept as the authoritative trail.

Freight forwarding and customs is a good example of this. The entries and supporting documentation you assemble and file are what enable (or delay) clearance: classification, valuation, origin, PGA requirements, and the full document packet. It’s much harder to replace the system that generates and maintains that audit-ready record than it is to build an assistant that drafts notes an actual broker still has to translate into a compliant filing.

But you don’t need a regulator in the loop for this to matter. Outside of regulated industries, you can create the same kind of defensibility by absorbing the downside on a defined slice. When you’re the party that guarantees resolution, you naturally then become the system that creates the record, the transaction, and the audit trail.

Position > Model

Foundation models will only keep improving. Workflows are visible, which means they can be reverse engineered. Deployed engineering is a service line that is sometimes necessary, but never sufficient to create durable moats.

If your product sits on top of someone else’s database (reading from it, writing back into it), you are, by definition, not the canonical layer. You can be valuable. You can even become sticky for a while. But you’re still displaceable the moment a better model or a cheaper competitor or incumbent offers “good enough” workflow assistance.

The companies I’m most excited about own where and how the data gets created, and they own the downside. They’re building the record. And over time, they’re shaping the ontology the industry uses to describe itself.

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.

Look at a single automotive plant and you’ll find roughly 4,000 suppliers feeding that one facility. In aerospace, it can be closer to 20,000. Even in simpler categories, the ratio might be 5:1 or 10:1. That long tail is where most manufacturing actually happens, and it’s where innovation has lagged the most.

“The US is trying to rebuild manufacturing by over-investing in the tip of the pyramid, without rebuilding the middle that makes the tip possible,” Saman Farid, the founder and CEO of Formic, told me. “We’re reasoning backward from chips and EVs as if the supply chain between here and there is already solved. It isn’t.”

China’s Supply Chain Density

China’s manufacturing ecosystem was built over decades from the bottom up. Raw materials. Then steel. Then simple assemblies (toys are a classic example). Then gradually more complex work up the chain, until the supply base became both broad and dense.

If you’ve ever worked with Chinese manufacturers, you feel that density immediately. At my last company, we both competed with and partnered with Chinese suppliers. When we competed, we were often an order of magnitude more expensive, and lead times were longer in ways that surprised people. Even quoting moved at a different speed: Chinese manufacturers could turn around complex quotes within 24 hours. In many other markets, including the US, that same process can take weeks.

I saw the same dynamic when I flew to a customer’s headquarters to present to a room full of their Chinese suppliers on what it would take to set up factories in Mexico to navigate tariffs and take advantage of USMCA and IMMEX. When I shared timelines for building a factory from the ground up, there were audible gasps. Some thought I was joking. In China, many of these teams are used to going from breaking ground to first production run in months.

Saman told a similar story from his time building plants in China. His team walked a facility at 6pm, flagged several changes, including adding a staircase, went back to the hotel, and returned at 8am to find it done. Including the staircase.

China’s supply chain density means compressed distance and coordination costs. Parts, labor, contractors, and owners are all nearby. The whole system moves together.

Subsidies As An Investment

A common explanation for China’s manufacturing dominance is that the government “propped it up” with subsidies. Saman sees it differently. “Subsidies are an investment,” he told me. “It comes down to how many dollars you put in for how many dollars you get out.” China subsidizes selectively to build specific capabilities and capture downstream value.

In practice, this looks less like handing out jobs and more like engineering demand and lowering the cost of capacity through procurement, cheap credit, subsidized land and power, and coordinated supplier buildouts designed to keep factories utilized. When an industrial park comes online with subsidized land and power – and local financing makes equipment easier to purchase – it becomes faster to spin up production, and easier to scale it. High utilization then compounds: factories run more hours, quote faster, learn faster, and reinvest faster.

And China isn’t uniquely subsidy-heavy. “People ascribe too much importance to subsidies in China,” Saman said. “The reality is most factories in the US are also subsidized.” The difference is that American subsidies often show up indirectly through tax abatements, accelerated depreciation, low-interest loans, programs like SBIR and the SBA. Both countries use subsidies, but China paired them with a long-term, bottom-up effort to build capability at every layer of the supply chain. As Saman put it: “Supply chain density, labor density, skilled labor, and breadth of suppliers matter. Those take many years to build.”

In the US, all of this has thinned out. Some categories offshored. Others consolidated. Supplier bases fractured across geographies. Now we’re trying to rebuild, but we’re still over-allocating attention to the top of the pyramid without rebuilding the connective tissue that makes the top possible.

The Utilization Problem

Manufacturing competitiveness is a messy bundle of variables – wages, training, materials, regulation, energy, logistics, the cost of capital. But a lot of it ultimately comes down to utilization. In the US, plants don’t run nearly as many hours as they could.

“A typical US factory might run around 2,000 hours per year out of roughly 8,600 possible production hours, whereas factories in China often run 6,000 - 7,000 hours annually,” Saman said. “With the exact same building and the same category of equipment, one factory has triple the output. So of course it’s going to be cheaper.”

So when we talk about strengthening US manufacturing, is the answer really to build another 400,000 factories? Or to help the existing base run 2x more? “The latter is obviously much easier,” Saman said.

Reliable Labor at Scale

Increasing utilization, in many cases, means increasing labor. One of Formic’s customers is a family-owned business that packages walnuts for major retailers. It’s a ~$150M/year operation in a small town where the factory employs something like 60% of the local population. They’d happily take on more orders, but they can’t – not because demand isn’t there, but because the local labor pool is fully tapped out.

One way to address the labor problem is to make robots easier to access and deploy.

But robotics doesn’t scale like software. “People are hoping there’s going to be a ChatGPT moment for robotics, but that’s a mistake,” Saman told me. “The hard part is the operational complexity. How do you evaluate the factory? How do you install the robot? How do you manage and maintain it? How do you keep it running 24 hours a day?”

Most factories don’t want to become experts in integration, maintenance schedules, spare parts, uptime monitoring, and safety audits. They want output. So Formic is focused on making robotics feel less like one-off integration projects and more like dependable industrial equipment. This means systems that run continuously without babysitting, handle variance in inputs, withstand different factory conditions, can be repaired quickly when something breaks (because everything breaks), and operate safely around humans at realistic payloads and speeds, or what Formic refers to as “Full Service Automation.”

“There are a lot of people who are trying to make robots smarter,” Saman said. “And I think that’s a good thing. It’s necessary, but it’s not sufficient.” What matters is making robots intelligent enough that you can plug them into any part of the production line and they just start working.

A Narrow Focus for 99.99% Uptime

“Most successes in robotics require 99.99% uptime,” Saman told me. “Most people underestimate how hard that bar is to hit.” He pointed to self-driving as an analog: it took two years to get to 80% performance, then another 15 years to approach 99%. And it’s still constrained by context. For example, Waymo only works in a couple of cities. You can’t drop it in Zimbabwe and expect it to work.

So what parts of robotics can we realistically push toward 99% and deploy in the next few years? Not general-purpose everything, Saman argues. More often, it’s narrow tasks with clear performance requirements and strong ROI, the kinds of jobs where you can standardize the environment and measure success.

That’s why Formic has focused on a relatively narrow set of use cases that repeat across many factories. Packaging is a good example: every CPG company has to package product. It’s a broad category of work, but still bounded enough to design around. The robots Formic builds can’t do everything, “you can’t take that same robot that’s doing case packing and expect it to fold your laundry,” Saman said. But most factories aren’t asking for a robot that can do a thousand unrelated tasks. They’re asking for one task done extremely reliably, day after day.

Form Factor Tradeoffs

Optimizing for reliability also shapes how Saman thinks about form factors. He argued against humanoids as the default factory robot, largely on straightforward engineering tradeoffs: a humanoid has far more actuators than an industrial arm, which means more failure modes, more downtime, and more maintenance.

He sees a place for humanoids in the future, especially for low-utilization, flexible work that hops between short tasks. But he doesn’t think they’ll dominate industrial deployments. “Why insist on two arms when a specialized machine could have six? Why insist on legs when wheels are faster and simpler?” he said. “A human on a bicycle is the fastest animal in the world. And a human on legs is one of the slowest. If we’re not able to leverage some of our creativity to find better ways to do things, it will be a big missed opportunity.”

The “Dirty Work” Opportunities

When I asked Saman what opportunities he’s most excited about, he cautioned that “there are a lot of opportunities to grift right now. It’s very seductive to believe we’re right around the corner from robots being everywhere, and it can be hard to draw a clear dividing line.”

At the same time, he sees massive opportunity in what he called “the dirty work around robotics” – aka, the infrastructure needed to ensure dependable uptime. Some examples we discussed:

• Maintenance at scale: Someone needs to build a modern, nationwide robot maintenance network – the equivalent of what exists for heavy equipment or fleets. This includes managing lubrication, gearbox swaps, motor replacements, cleaning sensors, managing spare parts logistics, and more.

• Data collection that transfers: There are creative approaches emerging (such as collecting motion data with gloves), but generalization is still hard. Collecting enough real-world data across environments and hardware types is a much bigger problem than people expect.

• Financial tooling that makes adoption easy: A lot of small and midsize manufacturers don’t want to buy a complex system that they may not be able to maintain. They want a clear monthly cost and a reliable outcome. Financing models and bundling are important parts of the overall infrastructure needed to usher in adoption.

• Compliance for robots: Safety and compliance are still deeply under-appreciated. In factories, robots have to operate inside rules designed to prevent injury when (not if) something goes wrong. Speed and payload determine risk, and risk determines how close humans are allowed to be. As Saman put it: “If you’re operating at X speed with Y payload, what’s the closest that a human is allowed to be near that robot before you have to shut it off?” That distance is calculated based on stopping time, motion profile, payload, and worst-case failure modes. And while safety rules likely need to be modernized, the reality is that a surprising number of robotics companies are effectively ignoring these constraints today, though that will likely change as robots become more prevalent.

These are just a few of the ideas we discussed, but they point to what Saman is most excited about, which is the unglamorous work required to deploy robots effectively at scale.

The Substrate For Abundance

US manufacturing dominance is about rebuilding the connective tissue underneath our supply chains. Higher utilization of the factories we already have, automation accessible to the long tail of plants that don’t have in-house robotics teams, maintenance networks and deployments that work across messy environments. Getting more hours out of what’s already there.

For what it’s worth, I don’t think everything should or even can come back to the US from a pure resilience standpoint. Global supply chains exist for a reason, and “China+1” may remain the right answer for many categories. But from an economic standpoint, manufacturing is the substrate for abundance: it determines how quickly a country can turn ideas into physical reality, how much it can produce per worker hour, and how resilient its industrial base is when conditions change. As Saman put it, “manufacturing is the foundation for human civilization.”

Author’s note: An LLM was used for light copy editing only (spelling, grammar, and clarity). Content, meaning, tone, and structure remain unchanged.