… …
Module 3 · Part B of 3

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 files supply context. After an edit, compare the next answer with the saved file.

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.

.openclaw/workspace/ SOUL.md persona, boundaries, tone, values AGENTS.md operating instructions and rules IDENTITY.md name, creature, vibe, emoji USER.md who the human is, preferences TOOLS.md per-tool usage notes HEARTBEAT.md periodic autonomous-task checklist memory/ daily logs, one file per day 2026-06-11.md raw notes the agent appends as it works MEMORY.md curated long-term memory (loaded in the main session only) skills/ per-skill markdown bundles (next page)

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.

Check self-report against the files. Ask the agent what its prompt contains, then compare the answer with the live workspace in Step 1b:

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.

Compare the agent’s account of its context with the workspace readback. A changed file alone does not establish what a reply used.

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 run openshell 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.

The launchable has two planes of authority. The first is the terminal, which runs as the operator above the sandbox boundary and can inspect files permitted to that operator account and list its sandboxes. The agent occupies the second plane. It shares the machine with the terminal but runs under the narrower OpenShell policy tested in Module 4.

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.

This split matters directly for safety. An agent that can rewrite workspace context can influence later runs. The configured filesystem and network rules determine which other resources it can reach. Inspect the live policy for access to:

You will see that boundary tested directly in the next module, where a deliberately over-privileged agent tries to cross it.

References

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:

After editing a file, start a fresh session and check which content the agent uses.

← Module 3a: Connect NemoClaw