The OpenClaw Agent
Module 3a connected the browser to a persistent runtime. OpenClaw is the agent harness inside that NemoClaw stack: it combines a model and tools with a server-side session and a file-backed workspace.
NemoClaw supplies the blueprint that packages this harness with OpenShell and deployment policy. OpenClaw, rather than a separate Python orchestrator, drives each turn and reads its workspace files into the active context. You will inspect those files, compare two message instructions, and verify file memory from a fresh conversation.
The workspace, from the agent's point of view
Each file in that folder feeds a different slice of the prompt. The mapping is stable, so you can predict which behaviour an edit will move before you make it.
Memory comes in two tiers. The agent appends raw notes to a dated file
under memory/ as it works, then distils the parts that
should persist into its curated long-term store, MEMORY.md.
By default, MEMORY.md is included in the main session context and omitted
from shared or group prompts. This context choice does not restrict access to the file.
You will read both straight off the live sandbox a few steps down.
- which persona rules are active,
- what is on its tool list,
- or what it remembers about you.
Step 1 · Ask the agent to describe itself
In one turn the cell below asks OpenClaw to list its own workspace files and explain what each one does. Its answer reflects whatever the harness includes in its prompt and what its tools read. After editing a file, compare the new report with an operator readback.
Same runtime as Kickstart. These cells reuse the launchable
connected in 3a. The course exposes its gateway rather than the internal
/v1/chat/completions route. If a cell fails or stalls, run Health check and inspect its evidence before choosing a recovery action. A local deployment can use the
NemoClaw setup playbook
and the same gateway contract.
Verify the workspace from the operator plane?
Step 1b · Read the workspace yourself
Step 1 asked the agent to describe its files, and you do not have to take its word for it. Until now your only channel has been the gateway that carries your messages to the agent.
The launchable also exposes an operator terminal, a shell on the host
outside the agent's sandbox. The helpers.terminal() helper opens that shell
straight from this page through two entry points:
helpers.terminal("bash")opens the host VM shell, where you can runopenshell sandbox list.helpers.terminal("openshell sandbox connect <agent>")drops you inside the sandbox the agent runs in, where the workspace lives.
OpenShell is the kernel-level sandbox that holds the agent. For now you can
treat it as the boundary between operator and agent that Module 4 goes on to
define in full and to test directly. The agent's name in the connect command
comes from GET /api/agent, the same call the Kickstart page made
to discover your launchable.
The cell below connects into the sandbox and reads three files off the running instance: SOUL.md alongside the daily memory and the curated MEMORY.md. Edit the command list and re-run to poke at anything you like.
Step 2 · Compare message instructions
Ask the same review question in two fresh sessions. The second request explicitly asks for an auditor's evidence checks. Inspect both prompts and compare the replies. This changes message instructions; it does not edit SOUL.md or route to another persona file.
Step 3 · The agent edits its own context
Ask the agent to append a uniquely labeled preference to MEMORY.md. An operator read verifies the saved reference before a new conversation asks the agent to read it. Acknowledging a save is insufficient evidence. The appended note remains available for inspection.
- the host filesystem,
- the wider network,
- or a neighbouring agent's workspace.
You will see that boundary tested directly in the next module, where a deliberately over-privileged agent tries to cross it.
References
- NVIDIA, How to Build a Safer Autonomous Agent using OpenClaw. The course companion reference for OpenClaw, OpenShell, and the sandboxed-agent shape used here.
- Anthropic, Claude Skills (docs). The file-as-context pattern OpenClaw uses: a markdown file the runtime folds into the system prompt becomes a callable agent capability.
- Claude Code. The production CLI agent; live reference for how a workspace directory, persistent memory, and a tool surface fit together at scale.
- Packer et al., MemGPT: Towards LLMs as Operating Systems (2023). The explicit-memory hierarchy behind the MEMORY.md write-and-recall loop on this page.
- Model Context Protocol (MCP). The cross-vendor wire format CLI agents use to discover tools at runtime instead of hard-coded registration.
- Landlock LSM. The kernel filesystem-sandbox primitive that bounds the blast radius when the agent writes its own context.
- seccomp (man 2). The syscall-filtering layer in the kernel sandbox you meet in Module 4.
Comprehensive list at Going Further · References.
Try it · chat with your live agent
Use the chat to inspect one workspace file. Compare the answer with the operator read and inspect any tool calls. You can ask the agent to:
- describe its workspace,
- read a file,
- or run a command.
After editing a file, start a fresh session and check which content the agent uses.