Nous Research's Hermes Agent Trained a Real Robot From a Single Prompt
Nous Research's open-source Hermes Agent anchored Jensen Huang's GTC Berlin finale, orchestrating a full sim-to-real training pipeline for a Microduck robot on an RTX Spark laptop.
- Jensen Huang closed his GTC Berlin 2026 keynote with a live Hermes Agent demo on RTX Spark.
- Hermes installed and configured itself from a single prompt, then orchestrated the full workflow.
- It used Nemotron to plan an obstacle course and GPT-6 Astra to build it in FreeCAD, Omniverse, Blender, Newton and Isaac Lab.
- Thousands of simulated Microducks trained in parallel before the validated policy deployed to the real robot.
- Hermes Agent is MIT-licensed, self-hosted, with persistent memory and self-written skills.
- Runs on Nemotron 3.5 Bolt 74B, a 9B-active MoE packed into 24GB via 2-bit quantization.
Jensen Huang closed his GTC Berlin 2026 keynote by using Hermes Agent, Nous Research’s MIT-licensed agent harness, to build and run a robotics workflow. With a single prompt, he installed and configured a customized Hermes instance, then assigned it a harder task: train a bipedal robot to navigate an obstacle course it had never encountered.
Huang’s demonstration showed an agent creating the course, constructing a simulation in NVIDIA Isaac Sim, submitting training jobs to cloud GPUs, evaluating the resulting policy locally and deploying it to Hugging Face’s Microduck robot. Four Microducks then joined him onstage and responded to commands to sit, stand and lie down.
The orchestration ran locally on an NVIDIA RTX Spark laptop. Cloud infrastructure supplied the parallel training compute, while the local system managed the models, tools, artifacts and final evaluation. That split explains how a laptop-class device could control a reinforcement-learning pipeline involving thousands of simulated trials.
Hermes ran the toolchain
Hermes coordinated several models and engineering tools, assigning each stage to the component suited to it. According to the keynote demonstration, the workflow followed this sequence:
| Stage | Component | Job |
|---|---|---|
| Agent setup | Hermes Agent | Installed and configured the persistent agent environment. |
| Course planning | Nemotron | Planned the obstacle course and the work required to build it. |
| CAD and scene generation | GPT-6 Astra, FreeCAD, Blender and Omniverse libraries | Created geometry and assembled the simulated environment. |
| Physics and training | Newton, Isaac Sim and Isaac Lab | Ran physics simulations and parallel reinforcement-learning rollouts. |
| Local evaluation | RTX Spark | Loaded and tested the trained policy before deployment. |
| Robot deployment | ONNX and SSH | Exported the policy and transferred it to Microduck. |
Hugging Face and NVIDIA’s public Microduck recipe provides the technical details. The policy receives a 61-value observation vector representing the robot’s state and produces 14 target joint positions. Training on rough terrain with simulated backlash, which models slack in the robot’s joints, can reach 1.25 million simulation steps per second.
Training against varied terrain and mechanical imperfections helps the policy survive the shift from simulation to hardware, commonly called the sim-to-real gap. Reproducing the workflow still requires compatible assets, reward functions, robot calibration and matching software versions. The final policy is exported in ONNX format and copied to the robot over SSH.
Local control, cloud burst
RTX Spark kept the agent, language model and tool orchestration on the device. Cloud GPUs handled the compute-intensive training phase, after which the resulting model returned to the laptop for testing and deployment. This architecture can keep project files and routine inference local while reserving hosted compute for workloads that exceed the device’s capacity.
Nemotron 3.5 Bolt contains 74 billion parameters but activates about 9 billion for each token. That mixture-of-experts design selects a subset of the model for each inference step, reducing compute requirements. NVIDIA uses 2-bit quantization with quantization-aware training to fit the model into 24GB of memory while limiting the quality loss associated with lower-precision weights.
NVIDIA listed llama.cpp, vLLM, Ollama, Unsloth and LM Studio as supported local runtimes at launch. Hermes and OpenClaw can also use the model through their agent interfaces, allowing developers to replace the inference runtime without redesigning the broader workflow.
Hermes supplies the agent layer
Hermes wraps a chosen language model with the capabilities needed for persistent automation. The self-hosted service connects to Telegram, Discord and Slack, retains memory across sessions, schedules unattended work, executes commands in a sandbox and stores reusable skills generated during previous tasks.
- Self-generated skills: After completing multi-step work, Hermes can write reusable
SKILL.mdfiles and load them for later tasks. - Broad model support: Hermes supports more than 300 models through Nous Portal, OpenAI, Anthropic, OpenRouter and custom or self-hosted endpoints.
- Hybrid routing: NVIDIA’s open-source Switchyard router can assign routine work to local models and send selected requests to cloud models.
- Sandboxed execution: Approval tiers, destructive-command blocklists and isolated subagents place boundaries around command execution and parallel tasks.
- Open-source licensing: Hermes Agent is available under the MIT license. Model APIs, cloud GPUs and optional hosted services carry separate costs.
Generated skills and persistent memory expand the system’s attack surface because they influence future sessions. Teams should review SKILL.md files as executable code, restrict filesystem and network access, isolate credentials, log tool calls and require approval before commands can affect production systems or physical equipment.
A modular robotics stack
The GTC workflow combined local inference, cloud training, multiple model providers, open-source agent software and NVIDIA’s simulation stack. Each component exposed an interface that Hermes could invoke, allowing the agent to move files and instructions between tools that already had command-line interfaces or SDKs.
That modularity gives developers several practical options: change the planning model, replace the CAD tool, move training to another compute provider or keep sensitive stages on premises. The integration boundaries also create failure points around file formats, credentials, model outputs, tool versions and recovery from partially completed jobs.
The keynote established that these components can be connected in a working demonstration. Teams evaluating the stack still need repeatability measurements, task-level success rates, cost and latency data, failure-recovery tests and logs showing which model or tool produced each artifact.
Where Hermes fits
Hermes fits engineering environments where an agent must coordinate long-running work across models, command-line tools and external services. The strongest use cases include:
- Local-first automation: Persistent memory, scheduled jobs and tool use can run without sending every request to a hosted model API.
- Hybrid inference: Local models can handle routine planning while selected tasks use larger cloud models.
- Robotics and simulation: The agent can coordinate CAD software, physics simulators, training frameworks and deployment scripts.
- Research workflows: Reusable skills can automate environment setup, experiment execution and artifact collection across sessions.
- On-premises deployments: NVIDIA said enterprise users will be able to run agents based on Hermes Agent, Perplexity or Aible within their own environments. Availability and support terms require verification for each product.
Production use needs stronger guardrails
Customer-facing and safety-sensitive deployments require controls beyond Hermes’ default sandbox and command blocklists. Production teams need deterministic audit logs, scoped credentials, model and prompt versioning, artifact provenance, rollback procedures, confidence checks and human approval for consequential actions.
Physical systems add further requirements because a bad command can damage hardware or create safety risks. Simulation gates, joint and velocity limits, emergency stops, signed deployment artifacts and supervised hardware tests should sit between an agent-generated policy and autonomous operation.
For internal engineering, research and robotics, the Microduck demonstration offers a concrete pattern: keep orchestration close to the developer, burst expensive training to cloud GPUs and move the resulting policy back to local hardware for evaluation and deployment. Hermes provides the persistent agent layer that connects those stages.