What problem does it solve?
NemoClaw User Overview solves the operator and platform-engineer pain of understanding how OpenClaw, OpenShell, and NemoClaw fit together and when to choose the NemoClaw reference stack versus integrating OpenShell and OpenClaw directly. It distills architecture, lifecycle, and operational responsibilities so teams can make informed decisions about onboarding, sandboxing, and inference routing. The document also explains what NemoClaw automates (blueprint-driven sandbox creation, provider wiring, and state migration) versus what remains an operator responsibility.
Core Features & Use Cases
- Stack relationship: Clear mapping of responsibilities between OpenClaw (assistant), OpenShell (sandbox/runtime/policy), and NemoClaw (blueprint, CLI, onboarding).
- Onboarding and orchestration: Describes
nemoclaw onboard, blueprint execution, and how the plugin and blueprint interact with the OpenShell CLI and gateway.
- Security and lifecycle: Summarizes protection layers (network, filesystem, process, inference), blueprint digest verification, and state migration patterns.
- Use Case: Operator wants a reproducible, hardened OpenClaw sandbox with routed inference and minimal custom integration; this page guides that choice and the steps involved.
Quick Start
Run the nemoclaw onboard command from your host to validate credentials, select a provider, and create a hardened OpenClaw sandbox configured with routed inference and default NemoClaw policies.
