NemoClaw provides onboarding, lifecycle management, and Hermes operations within OpenShell containers.
Use the nemohermes CLI alias when you work from the Hermes agent guide; it is equivalent to nemoclaw with the Hermes agent pre-selected.
This page describes how the ecosystem is formed across projects, where NemoClaw sits relative to OpenShell and Hermes, and how to choose between NemoHermes and OpenShell alone.
There are three pieces in a NemoClaw for Hermes deployment: Hermes, OpenShell, and NemoClaw, each with a distinct scope. The following diagram shows how they fit together.
NemoClaw sits above OpenShell in the operator workflow.
It drives OpenShell APIs and CLI to create and configure the sandbox that runs Hermes.
Models and endpoints sit behind OpenShell’s inference routing.
NemoClaw onboarding wires provider choice into that routing, including the Hermes Provider route when you onboard through nemohermes.
The following table shows the scope of each component in the stack.
Both paths assume OpenShell can sandbox a workload. The difference is who owns the integration work.
You can run Hermes inside OpenShell without NemoClaw by building your own image, writing policy YAML, registering providers, and wiring inference routes yourself. That path is valid when you need full control over the container layout.
NemoClaw builds on OpenShell with additional security hardening, automation, and lifecycle tooling for Hermes.
The following table compares DIY OpenShell integration with nemohermes onboard.
Use the following table to decide when to use NemoHermes versus OpenShell alone.