NVIDIA JetPack 7.2 makes Jetson more agent-ready with NemoClaw deployment, Jetson agent skills, MIG support on Jetson Thor, Yocto support, and Super Mode
What JetPack 7.2 changes for Jetson developers
JetPack 7.2 is oriented around a specific idea: putting agentic AI workloads directly on Jetson hardware rather than treating the edge device as a thin client for a remote model. The release bundles the runtime pieces needed to deploy, run, and manage models that plan and act locally, so a Jetson board can host an agent loop instead of only forwarding sensor data upstream. For teams building robots, cameras, and embedded appliances, that shifts more of the decision-making onto the device itself.
The practical draw here is latency and autonomy. An agent that reasons on-device keeps working when the network is slow or absent, and it avoids shipping raw data off the box. JetPack 7.2 leans into that pattern by making the deployment and orchestration steps first-class rather than something you assemble by hand.
NemoClaw deployment and Jetson agent skills
Two of the headline additions work together. NemoClaw deployment gives you a supported path for getting agent-capable models onto Jetson, so the model-serving layer is part of the platform rather than a bespoke integration. On top of that, Jetson agent skills provide a structured way to give an agent concrete capabilities — the discrete actions or tools it can call to sense, decide, and respond within its environment.
Thinking in terms of skills is useful because it keeps agent behavior modular. Rather than one monolithic prompt-and-model blob, you compose an agent from capabilities you can test, swap, and reason about independently. When you plan a deployment, it helps to sketch what the agent needs to do before choosing a model:
- Define the discrete skills the agent must perform, and what inputs and outputs each one needs.
- Decide which skills run fully on-device versus which may still call out to a larger service.
- Establish how the agent's actions are logged and constrained so its behavior stays observable.
MIG on Jetson Thor and resource partitioning
MIG support on Jetson Thor brings hardware partitioning to the edge. Multi-Instance GPU lets you carve the accelerator into isolated slices, so several workloads can share one board without contending for the whole GPU. On an embedded device that often runs more than one job at once — perception, an agent loop, and background inference — that isolation matters for predictability.
The tradeoff to weigh is throughput versus isolation. Partitioning guarantees each workload a reserved share and prevents a noisy neighbor from starving the others, but it also caps how much any single job can burst to. When you size partitions, match them to each workload's steady-state need rather than its peak, and leave the most latency-sensitive task enough headroom.
Yocto support and Super Mode
Yocto support speaks to teams that build their own embedded Linux images instead of shipping a stock distribution. Integrating Jetson into a Yocto workflow lets you produce a lean, reproducible, purpose-built OS layer — including only the packages a product actually needs — which helps with maintainability, security review, and long-term image control across a device fleet.
Super Mode targets the other end of the spectrum: extracting more performance from the same hardware when a workload demands it. The practical approach is to treat it as a deliberate operating point rather than a default. Enable it where the extra performance genuinely helps your agent or inference path, and validate the resulting thermal and power behavior for your enclosure before committing it to production.