NVIDIA used AI agents to generate a USD runtime from the spec

NVIDIA has published nanousd-labs, a project in which AI agents generated a working USD runtime by reading the OpenUSD specification and writing code against it. The result, nanousd, is an independent implementation of the USD runtime data model, written in C++ with a stable C ABI and an open C API that can be called from any language. It was built during an internal hackathon and ships under Omniverse Labs, NVIDIA's collection of open experimental projects. The argument underneath the code is bigger than the code: that a formal, machine-readable standard is a contract precise enough for agents to implement and for tests drawn from the same document to verify.

Until now, building your own USD implementation generally meant adapting a large existing codebase. That is awkward for teams that need a particular memory footprint, a different ABI or different performance characteristics, because they inherit decisions made for someone else's deployment. nanousd-labs proposes the opposite direction: generate the runtime from the standard.

OpenUSD is an open, extensible platform with a shared scene description language for physical AI, used to bring CAD data, simulation assets and real-world telemetry together in a single physically accurate representation. The systems that consume it are the ones running under hard constraints on memory, performance and language interop.

What makes generation possible is that USD is described in a formal, machine-readable specification. USD Core, developed by the Alliance for OpenUSD, is a versioned standard that defines how USD data is composed and resolved across layer stacks. Because the specification is an exact contract for humans and agents alike, a developer can direct agents to produce an implementation shaped for a specific workload. NVIDIA positions the method as a complement to adapting an existing codebase and to implementing the standard by hand, shortening the development cycle.

Under a developer's direction, the agents take the specification apart section by section, write code for each behavior and run it against a test suite derived from the same document. They implement and check the rules for composing, resolving and overriding scene data. The specification stops being documentation that a person reads once and interprets by hand, and becomes the thing both the implementation and its verification point at. Conformance is therefore a property of the method rather than of any particular codebase, and the runtime can be regenerated for a new workload without giving up compliance.

NVIDIA is specific about the limits. The input is the specification and the measure of success is conformance to it, which is neither full automation nor full coverage of the specification today. In building nanousd, the agents did the mechanical work of turning the specification into code: parsing data, composing scenes, determining value resolution between layers. Engineers owned performance, trade-offs and architectural decisions. The written standard supplies each task with a clear definition of a correct result that a test can check.

nanousd is a data layer, not a renderer. It parses, composes, queries and writes USD data and stops where pixels begin. It contains only what a given workload requires and exposes that through the stable C ABI. Existing OpenUSD toolsets keep working unchanged. The method is the thing meant to be adopted; the implementation is its worked example.

The Core specification says what a runtime must do and leaves memory, threading, ABI and language open. For nanousd the decision made so far is the stable C ABI; memory and performance characteristics are still being explored. Client code compiles against a fixed C API and loads the implementation at runtime, so the backend can be OpenUSD inside the Omniverse library or nanousd in its place, with no rewrite of the calling program. That arrangement also keeps measurement honest, since the same scenario runs through the same API while the implementation beneath it changes. NVIDIA explicitly declines to claim that one implementation is faster than the other.

The restraint is the most credible part of the release, and it is also where the gap shows. There is no performance figure, no memory figure and no statement of how much of the Core specification the generated runtime actually covers. A project whose entire premise is that conformance is machine-checkable does not publish a conformance number, and that number is the one a team deciding whether to try this would want first. The same applies to the economics: nothing here says how many engineer-hours the agent loop replaced, or how many it added in review.

The more interesting question is how far the method travels. It works on USD because AOUSD did the unglamorous work of turning the format into a versioned, machine-readable document with defined resolution semantics. Most of the standards a physical AI team touches are not written that way — they are prose, tribal knowledge, or a reference implementation that is the de facto spec. The transferable lesson is not that agents can write runtimes. It is that the precision of a standard now determines whether agents can implement it at all, which reprices a kind of specification work that has been thankless for decades.

For developers who want to try it, there are two entry points. The first is for teams that need a working implementation: clone and build nanousd, a compiled runtime with a C API callable from any language, ready to work against existing USD scenes. Most physical AI developers will start instead with nanousd-python, a Python package built on the nanousd C API. It needs no GPU, runs headless on any machine, and installs with one command. Opening a scene and walking its prims, the individual elements a USD scene is made of, takes a few lines.

From there an agent working from the Core specification handles creation and validation. It builds a scene, recomposes it through nanousd-labs to check that resolution is correct, then returns the structure of the composed scene and reports what it had to fix. The composed output lists each element, its type and how it was assembled — an Instanceable flag, for instance, means two wheels share a single definition in the scene rather than each carrying a full copy, which is how USD handles repeated elements economically. Validating an existing asset runs the same way: the agent composes the file, compares the result against the specification's rules and returns a precise answer about which part of the scene diverges from the standard, why, and what the correct result should be. The developer gets a clear compatibility signal instead of having to interpret one tool's behavior.

The second entry point is the method itself, and it is hands-on. The first time agents build an implementation directly from the Core specification, every instruction is written by hand. The skill graph converts those human instructions into reusable skills: structured recipes, queries and tests that describe how to produce specification-conformant behavior. A roughly ten-minute tutorial runs the skills to build a USD ASCII (USDA) parser that conforms to Core, leaving a developer with a working example and enough understanding of the method to start an implementation of their own. The graph does not yet build everything, and consistency across multiple parts remains unsolved. What it does provide is repeatability: the standard is the contract, and the workflow can be reused rather than reassembled for each implementation.

Developers can contribute new skills, language support and physical AI scenarios on GitHub, and AOUSD member organizations can change the standard itself through the Core Spec working group. That last sentence is where this points. If a specification is the interface agents implement against, then editing the specification is editing what every generated runtime does, and the working group that writes it becomes a considerably more consequential room than it was when the spec was something humans read.