Most startups pitching at TechCrunch Disrupt’s Startup Battlefield are burning money to chase scale. Laplace Intelligence showed up profitable. That contrast says something about where physical AI actually is right now, and it’s not the part of the story that usually gets the headline.
The Ann Arbor company, a University of Michigan spinout, builds automated red-teaming for robots and self-driving vehicles. Red-teaming here means what it means in security work: you deliberately try to make the system fail. Laplace pairs AI agents with interactive, high-fidelity simulation to hunt for the conditions where a robot or a vehicle falls over, then hands those conditions back to the team that built it. The company is also working with partners including T-Mobile and Nvidia on smart city projects and warehouse robotics.
I build bots for a living. Small ones, mostly, nothing that could flatten a pedestrian. And the thing that makes me pay attention to Laplace isn’t the simulation tech, impressive as that sounds. It’s that someone found a way to charge money for the least glamorous task in the entire discipline.
Why Nobody Wants to Build This Themselves
Here is the pattern I’ve watched over and over in bot projects, at every scale. You write the happy path. It works. You demo it, people clap, and then you spend the next six months discovering that your system has opinions about edge cases you never considered. Someone plugs in a different sensor. A warehouse aisle has a pallet two inches out of position. A pedestrian does something a pedestrian would absolutely do but your test suite never imagined.
Writing adversarial tests is tedious in a specific way that human engineers are bad at. You have to think against your own design. You built the thing, so your brain keeps producing the inputs you already handle. Real failure modes come from somewhere outside your assumptions, which is exactly where you cannot look.
That’s the structural case for automated red-teaming with AI agents. An agent exploring a simulated environment doesn’t share your blind spots. It doesn’t know which scenarios are “unfair.” It just pokes until something breaks, and then it pokes harder in that direction.
The Simulation Part Is the Hard Part
If you’ve ever tried to test a bot in simulation, you know the trap. Your sim is a simplification. Your bot learns the simplification. Then reality shows up with friction, latency, noise, and lighting conditions your renderer never modeled, and your beautifully validated system face-plants.
High-fidelity interactive simulation is the expensive answer to that problem. Interactive matters as much as high-fidelity: the environment has to respond to what the system under test does, not just replay a fixed scenario. A self-driving stack that merges aggressively should produce different behavior from surrounding traffic than one that creeps. Static scenario playback cannot capture that. The Nvidia collaboration makes sense in this light, given how much of the current simulation stack for robotics and autonomous vehicles runs on their hardware and tooling.
For those of us building smaller systems, the lesson transfers down. If your bot’s test environment never pushes back, you are testing a monologue.
Projects Versus Products
The business detail I keep turning over is Laplace’s stated goal of converting project-based contracts into recurring revenue. That’s the quiet hard problem in every technical services company, and it’s worth understanding why.
Project work is how you get credible. A robotics company hires you, you red-team their system, you find the failures, they pay the invoice. Great engagement, nothing repeatable. Recurring revenue means the red-teaming has to run continuously — every code change, every new model, every fleet update, automatically tested against an adversarial agent that keeps evolving.
That’s not a sales reframe. It’s an architecture requirement. To sell testing as a subscription, the testing has to be infrastructure: always on, integrated into the customer’s development loop, producing value between human conversations. Anyone who has tried to turn a clever script into a service knows the gap between those two states is most of the actual work.
What I’d Steal From This
You do not need a Michigan spinout’s funding to apply the idea. A few things I’ve started doing differently:
- Write an adversary, not just tests. A small script whose job is to generate inputs designed to break your bot will out-find any fixed test suite you hand-author.
- Make the environment react. If you simulate, make the simulation respond to your bot’s choices rather than playing back a script.
- Log the failures, not the passes. Your passing runs tell you nothing you didn’t already assume.
- Run it on every change. Adversarial testing that happens once is a report. Running continuously makes it a safety net.
Physical AI is moving the human further out of the loop, which means the loop itself has to get far more suspicious of its own output. Laplace is betting that suspicion is a product category. Based on every bot I’ve shipped, that seems like a reasonable bet.
🕒 Published: