Learning NemoClaw — Index

A conceptual walkthrough of three related projects that together let you run a general‑purpose personal AI assistant under enterprise‑grade guardrails.

The three projects, in one line each

Think of it as: OpenClaw is the app, OpenShell is the jail, NemoClaw is the jailer that knows how to put OpenClaw into that jail correctly.

Read in this order (reordered by relevance)

The docs are ordered so the most practically useful material comes first — fast orientation, then the unified mental picture, then the command and policy reference you'll actually use day-to-day. The per-project deep dives come after, for when you need to look up a specific knob.

Tier 1 — orient, then operate

1. 01-nemoclaw-user-overview.md — Start here. The official NVIDIA framing: what each project is, NemoClaw path vs OpenShell path, what NemoClaw adds on top, when to use which. Now includes a beginner-friendly three-scenario walkthrough with side-by-side comparison tables.
2. 02-mental-model.md — The unified stack picture and an end-to-end trace of a real Telegram → LLM → reply request through every component. Who enforces what, where credentials live, what is static vs hot-reloadable.
3. 03-command-map.md — "I know the OpenClaw command — what do I type in NemoClaw?" Direct translation table, lifecycle cheat-sheet, and a six-question decision checklist.
4. 04-policies-and-guardrails.md — The concrete YAML policies: baseline filesystem/process/network rules, the default allowlist (Anthropic, NVIDIA, ClawHub, npm, etc.), presets, and the decision tree for opening a new egress path.

Tier 2 — per-project deep dives

5. 05-nemoclaw.md — NemoClaw internals: plugin + blueprint architecture, what nemoclaw onboard actually does step-by-step, blueprint lifecycle (resolve → verify → plan → apply → status), host-side state, hardening beyond the community sandbox.
6. 06-openshell.md — OpenShell internals: gateway, sandbox, policy engine, providers, inference routing, the four protection layers, and the openshell CLI surface.
7. 07-openclaw.md — OpenClaw internals: the standalone Gateway/Pi-agent model, sessions, channels, tools, nodes — i.e. how OpenClaw would run if NemoClaw and OpenShell didn't exist.

Tier 2b — enterprise customization

11. 11-adding-tools-and-policies.md — Adding tools and policies. How to install custom binaries (SSH, Ansible, kubectl, etc.), write network policy presets, handle the backup→recreate→restore lifecycle for existing sandboxes, and binary pinning decisions.

Tier 3 — operational reference (from the NemoClaw user skills)

8. 08-inference-options.md — Provider matrix, same-provider hot-swap vs cross-family recreate, and local inference recipes (Ollama, OpenAI-compatible, vLLM, NIM). Includes the Linux+Docker Ollama host-binding gotcha.
9. 09-application-layer-defenses.md — The other half of security: what OpenClaw itself does inside the sandbox (prompt injection filtering, tool deny list, env var blocklist, openclaw security audit, skill supply-chain scanning). The one command every noob should memorize: openclaw security audit.
10. 10-workspace-files.md — The agent's persistent self: SOUL.md, USER.md, IDENTITY.md, AGENTS.md, MEMORY.md, memory/*. What they control, when they survive (restart = yes, destroy = no), and how to back them up before any destructive operation.

The core insight

When you run OpenClaw standalone, you are the root of trust — it runs on your laptop with your network, your files, and your credentials. When you run it through NemoClaw, everything still works the same from the assistant's point of view, but:

• The assistant lives inside a container with a read‑only filesystem, dropped capabilities, and a process user that isn't you.
• All its network traffic passes through OpenShell's L7 proxy, which enforces a declarative YAML allowlist.
• Its model calls go to inference.local — a fake endpoint the OpenShell gateway exposes — and the gateway re‑signs them with real credentials the sandbox never sees.
• Its channel tokens (Telegram, Slack, Discord) are placeholders; the real tokens live in host‑side OpenShell providers.

So the learning goal is: "what knob did OpenClaw expose, and where is the equivalent knob in a NemoClaw world — is it still on OpenClaw, or did it move to NemoClaw onboarding, or into a YAML policy file?" That is exactly what docs 03 and 04 answer; docs 05–07 are the deep reference for when you need to dig.