What it takes to make AI hold up in the physical world.
I write about questions I'm trying to untangle, things I've tried, and what I think now. Most of it is about physical AI: robot learning, simulation, digital twins, developer tools, and the work between a good demo and a dependable deployment.
Start here
Choose an interest area, then follow the reading path that fits what you came for.
Learning, deployment and commissioning
Two paths through the robot-training loop and the harder work around model capability: capture, validation and commissioning.
Simulation & Digital Twins · 3 reading paths · 12 notesFrom evidence to a usable twin
Three paths through camera reconstruction, the work of turning it into a usable visual twin, and the Omniverse platform changes behind interactive OpenUSD applications.
Agentic Systems · 1 reading path · 5 notesGrounding, harnesses and reliable execution
How context, workflow structure and deterministic control change what agents can do reliably.
Platform & Industrial Systems · 1 reading path · 11 notesFrom compute to operation
How hardware, Omniverse and shared models fit together, from the compute underneath physical AI to the industrial systems it is meant to improve.
Recent
Years of MES work taught me where automation stops: at tasks whose decisive state cannot be written down or seen. Tactile input earns its place when it reveals that missing state; contact alone is not enough.
Anchor stopped my agent from skipping declared steps. Ratchet came from the next question: after an interrupted or overlapping run, could I prove what happened and restart without making it worse?
A technical look at the small execution runtime I built for overlapping and interrupted agent workflows: ownership, effect recovery, verified completion and the limits of a local alpha.
A Gaussian splat can reproduce a place convincingly while knowing almost nothing about its identity, scale or behavior. This article separates reconstruction, visual readiness, operational readiness and simulation readiness—and defines the boundary SplatStage is designed to cross.
SplatStage turns a Gaussian reconstruction into a versioned editing workflow, exports the selected PLY as an OpenUSD Gaussian ParticleField, and composes it with replaceable engineered assets. The hardest bug was at the seam between editing and export.
One Garden scene made the promises and gaps in SplatStage measurable: 2.07 million Gaussians removed, an edited OpenUSD particle field, three composed assets, a dependency-complete stage—and no measured scale, colliders or external runtime proof.
Every digital twin needs a usable digital starting point. CAD, LiDAR, photogrammetry and Gaussian splatting preserve different kinds of truth, so the representation should follow the decision. Part 1 of a three-part series.
ReconStudio turns camera media into Gaussian splats and OpenUSD through a browser and job API. I built it to expose reconstruction stages, retain experiment evidence and test where on-demand GPU execution fits. Part 2 of a three-part series.
I built ReconStudio, then used 24 job records across six scenes to test its evidence. Metric bugs, repeated runs and paired-frame comparisons changed what I could claim about training, capture and GPU capacity. Part 3 of a three-part series.
A refinery valve operation shows why robot capture should begin with the task: preserve the motion, contact, timing and measurements the policy will need.
Robot foundation models are getting better at handling situations they were not shown. That makes the old commissioning questions more important: where is the model valid, how do I know it has left that range, and what happens next?
A robot can finish the task and still behave unsafely along the way. That distinction makes this benchmark worth reading.
A repeatable agent workflow kept skipping different steps on different runs. The fix wasn't a stronger prompt; it was moving the plan into a DAG and letting deterministic code control sequence and verification.
People keep asking me a version of the same question: what NVIDIA hardware should I be thinking about for a digital twin, from a developer build at my desk all the way to production? I always had an answer but no clean model behind it, just a pile of product names, three of which are confusingly all called DGX. So I built the model I wanted: NVIDIA develops one architecture family a year and expresses it across many kinds of computer, from a gaming card to a liquid-cooled rack. These are my rough notes, in case you're coming at it from the software side and asking the same thing.
A month ago I drew a five-stage loop for a robot training center and admitted most of it was an educated guess I hadn't tested. So I built the loop as a real, orchestrated pipeline on one GPU and carried two tasks around it — a pole that balances by trial and error, and a Franka arm that learns to stack cubes by copying demonstrations. This is the environment, the stack, the architecture, and what actually ran. Part 1 of two.
Running the training loop for real surfaced one concept the diagram doesn't capture: the same five stages take two different shapes depending on how the robot learns — by trial and error (reinforcement learning) or by copying demonstrations (imitation). This part is the mechanism behind that fork, grounded in the two tasks I ran, plus the open questions the build left unproven. Part 2 of two.
When a general-purpose LLM (or an agent built on it) doesn't fit the problem, the reflex is to fine-tune it. I think that's usually the third thing to try, not the first. There are three ways to close the gap: grounding context, harness optimization, and fine-tuning, and which one you reach for should depend on the need in front of you: domain knowledge, agent behavior, or raw performance.
MES was never really about running the machines. It was about improving the operation, and it was limited by how much had to be modeled by hand and decided by people. Physical and agentic AI can change that, but only if the plant's systems are joined through shared operational context.
The useful signal is not that world models are solved. It is that investors and research leaders increasingly see predictive models of physical dynamics as a distinct bottleneck worth funding.
A browser-based USD viewer, RTX-rendered server-side and streamed over WebRTC, built to see if the library-first pitch holds up under real interactivity.
We finally have models that can watch the physical world, reason about it, and predict what happens next. Walk a real automotive parts-kitting task through what they actually solve, and the thing still standing between a demo and a working line isn't a smarter model: it's the policy you have to train for your machine, and the system that keeps it trained.
Kit and libraries used to be the same choice for building on Omniverse. They're not anymore, and that's a bigger change than it looks, with a real before/after from a Kit extension I built.
Since May 2026, Omniverse is free for production, not just development. It's a clean, sensible change, but it landed quietly, and I keep meeting customers and partners who don't know it happened yet. The paid-production requirement is gone; the license and optional enterprise support remain.
Someone asked me how you'd build a training center for industrial robots from scratch, and my first reaction was that it isn't one project, it's ten. What untangled it was seeing that they aren't ten separate things at all. They're five stages of one loop that turns real work into robot skills and feeds what happens back in. This is where I've gotten so far, still learning, sharing it in case you're walking the same road.
From the industrial systems I know, rendering is only one part of Omniverse. The harder job is connecting source data, giving teams a shared context, and reusing it for visibility, simulation, optimization and Physical AI.