One YAML, Three Computers: Your Physical AI Pipeline Loses Its Glue Scripts

Nvidia just open-sourced OSMO, and the entire control plane runs on a single workstation with KIND. One YAML file now describes a pipeline that used to be three toolchains held together by glue scripts nobody wants to own.

Here is the thesis, stated plainly. Physical AI is a three computer problem. Training happens on data center GPUs. Simulation, physics, and sensor rendering happen on workstation class RTX hardware. Hardware-in-the-loop testing happens on edge devices such as Jetson AGX Thor, usually on a bench or a factory floor. Each tier grew its own scheduler, its own storage conventions, and its own glue. The failures accumulate at the handoffs between them.

OSMO's real contribution is not the scheduler. It is the abstraction. Your workflow names a platform, not a cluster, and the orchestrator decides which machine provides that capability. PhantomByte has spent months arguing that the harness and the runtime decide more than the model does, in the evaluation harness piece and the execution boundary piece. This is that same argument wearing steel and silicon.

THE THREE COMPUTER PROBLEM, NAMED

Nvidia frames physical AI as a three computer problem, and the framing is the most useful thing in the release.

Tier	Hardware	What it does
Tier one, training	GB200 or H100 class hardware	Deep learning and reinforcement learning, running in a cloud data center
Tier two, simulation	RTX workstation class hardware, L40 and RTX Pro	Physics and sensor rendering, producing synthetic data and validating a policy before it ever touches metal
Tier three, the edge	Jetson AGX Thor class hardware, typically on premises	Hardware-in-the-loop testing on the actual robot, running the actual system software

Three tiers. Three schedulers. Three sets of credentials, three storage conventions, and three people who each own a piece of the pipeline and none of the handoffs.

Now learn to see the glue in your own repository. Here is the test I use, and it is an opinion built from watching this pattern repeat: any script in your repo that exists only to move artifacts between two schedulers is a future outage with a filename. Not a tool. Not a platform component. An outage that has not happened yet.

You know the ones. The Python file that copies a checkpoint out of a training cluster and into a simulation box. The shell script that stages a policy onto a test device. The cron job that reconciles two different ideas of what a dataset is. Nobody assigned that work. It accreted, and now it is load bearing.

WHAT OSMO ACTUALLY DOES

OSMO is a Kubernetes-native workflow orchestrator. Each compute tier is a Kubernetes cluster registered through the CLI as a backend. Workflows never name a cluster. They name a platform, and OSMO routes the task to a pool that offers it.

The canonical example in the repository is three tasks chained by data. A simulation task runs an Isaac Sim container on rtx-pro-6000. A train-policy task runs a PyTorch container on gb200 with 8 GPUs and takes the simulation task's output as input. An evaluate-thor task runs a ROS application on jetson-agx-thor, consumes the trained policy, and writes the benchmark to object storage.

Dependencies come from inputs. Persistence comes from outputs. Placement comes from platform. That is the whole contract, and the entire pipeline is one file.

The practical details matter, so here they are. OSMO is Apache-2.0 licensed. It ships Helm charts and containers on NGC. The local quickstart runs the full control plane on a workstation with KIND, and the same YAML also runs on EKS, AKS, GKE, on-premise, or air-gapped clusters. Scheduling defaults to the NVIDIA KAI Scheduler, with NVLink topology aware placement for multi-GPU tasks. Per group timeouts mean a stalled simulation group no longer kills its sibling training groups. There is an RBAC authorization sidecar, OAuth2 device-code login, and cloud workload identity so services stop mounting storage keys as Kubernetes secrets.

None of that is the point, but all of it is why this is deployable today instead of someday.

Name the rule and keep it: the Platform-Named Workflow rule. Describe what capability you need, and let the orchestrator decide which machine provides it. That inverts the usual setup, where your pipeline knows its own hardware and breaks the moment the hardware changes. If your workflow names a cluster, you have a snowflake. If it names a platform, you have a pipeline.

There is a second layer worth naming, because it is the same lesson the harness crowd learned this year. Context engineering inside an agent harness moved the fixes for context overflow and goal loss into the harness layer, where the thresholds from LangChain Deep Agents, Claude Code, Manus, OpenAI Codex, and Amazon Bedrock AgentCore actually live. OSMO is that argument for physical infrastructure. The fix for a fragile pipeline lives in the orchestration layer, not in a better script inside the fragile part. That is not a metaphor. A software harness sets where an agent can read and write, and a physical pipeline sets where a job can build, simulate, and run. Both are execution boundaries, so the leap from software agent execution boundaries to physical runtime boundaries is a change of substrate, not a change of argument.

THE PLATFORM-NAMED WORKSHEET

Here is the Three Computer Audit. It runs in an afternoon, and you can run it before you install anything.

1. List every tier your pipeline touches. Training, simulation, edge test, and anything else you have invented along the way.
2. At every boundary, name the script that moves artifacts across. Write the filename down. That list is your fragility list.
3. For each script, ask one question. Does this exist because of a capability requirement, or because two schedulers refuse to talk to each other? Capability requirements are legitimate design. Scheduler diplomacy is debt.
4. Rewrite one boundary as a platform-named workflow step and count how much code dies. Pick the ugliest boundary, not the easiest one. The number you get is the argument you take to your own team.

Repeat the audit whenever a tier changes hardware. The abstraction is the asset. The YAML is disposable.

THE SAME PATTERN EVERYWHERE ELSE

The week's other physical AI news is the same lesson wearing different clothes, and it is worth reading as one story instead of three.

Universal Robots launched Gen 7 at IMTS in Chicago. The CB7 Core controller delivers about 40 percent more compute in a 30 percent smaller footprint, and the platform runs on the PolyScope X operating system with open APIs and ROS2 communication. The press release calls the platform out-of-the-box AI-ready, and the pitch is deployment rather than peak capability. That distinction is the whole business argument. A controller that is smaller, lighter, and easier to integrate is a controller you can put in a factory next quarter. Deployment, not peak capability, decides the factory floor.

Skild AI's S1 robot foundation model learns tasks from video demonstrations rather than hand-coded routines. The Next Web, citing Bloomberg reports Skild reached a 100 million dollar recurring revenue run rate ten months after its first commercial deployment, with software running on hundreds of robots at more than 60 companies, up from eight earlier this year. The company puts S1 at 96 percent on tasks it has seen and 66 percent on tasks it has not. The open question is the one nobody has answered yet, and it is a genuinely open question rather than a rhetorical one: does a video-trained policy survive a new site, or does it need retraining per customer? The plausible breakdown point is spatial domain shift, where a new floor plan, a different camera rig, or unfamiliar lighting moves the visual distribution away from the training video, and the related one is tactile re-calibration, where a new gripper, a new payload, or a new surface changes the contact dynamics the policy never saw. Either way, that question is a pipeline question. It is about how fast you can get a model onto new hardware in a new building.

Shanghai AI Laboratory released Intern Physical World Model W0 for force and tactile robotics, per Pandaily. Contact is where manipulation fails. Vision alone cannot tell a gripper how hard to press or whether an object is slipping, so a model that predicts contact outcomes is the missing layer between a plan and an actuator command.

Read all three together and the thread is obvious. The bottleneck moved from the model to the pipeline that gets the model onto hardware. A better controller, a policy that learns from one video, and a world model that understands touch are all useless if the last mile is a shell script that a person named Dave updates by hand.

This is also where the timeout piece and the CPU inference piece come back around. Durable execution, checkpoint, resume, verify. Those are orchestration properties, and they apply to a robot policy moving through three tiers exactly as they apply to an agent moving through three tools. The runtime decides. The hardware tier is just another runtime boundary.

WHAT TO DO TODAY

1. Clone the OSMO quickstart and run the control plane on your workstation with KIND. It is Apache-2.0, so there is no sales call and no procurement ticket between you and a running pipeline.
2. Write down every script in your repository that exists only to bridge two schedulers. Read the list out loud. That is your outage schedule.
3. Pick one training-to-simulation handoff and rewrite it as a single platform-named YAML workflow. One boundary. Do not try to migrate everything at once.
4. Audit your edge tier. Name the device, name the scheduler, name the glue. Then kill one of the three.
5. Re-run the Three Computer Audit whenever a tier changes hardware. The abstraction is the asset and the YAML is disposable, so expect to throw the YAML away.

THE UNCOMFORTABLE QUESTION

If your pipeline breaks every time hardware changes, and Nvidia just gave away the abstraction that makes hardware swappable, how much of your complexity is actually just glue you are emotionally attached to because you wrote it?

The teams that win physical AI will not be the ones with the best model. They will be the ones whose model reaches the robot on the same day it reaches a benchmark.