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 persona configurations, and save memory that survives beyond the model call.

The directory layout is the configuration, so editing one file changes how the next turn reads.

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. The runtime loads MEMORY.md in the main session and leaves it out of any shared or group context, so personal notes stay private. You will read both straight off the live sandbox a few steps down.

Treat self-report as evidence. Ask the agent what its prompt contains, then compare the answer with the live workspace in Step 1b:

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 folds into its prompt together with whatever its tools can see, so editing a file and re-running changes the report.

Because the gateway folds the folder into the prompt before every turn, editing a file changes the next reply.

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 logs ⚠ DEGRADED or stalls, run Recover once for that fresh instance. A local deployment can use the NemoClaw setup playbook and the same gateway contract.

Applied · OperatorVerify 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 above the agent's sandbox that Cloudflare puts in front of every launchable. 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 therefore read every file and list the 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 · Two scenarios, side by side

Because the persona is just a file, swapping the SOUL definition changes the agent's voice. The real mechanic behind that swap is writing the file itself, where you save a new persona definition and the next turn picks it up on its own.

A real edit is slow to watch, so the cell below fakes the swap. It sends two tagged sessions and your launchable maps each session key to a pre-built SOUL variant that it keeps on hand. The upshot is one question answered by two configurations with no editing on your part.

The session-key routing here is a lab affordance. NemoClaw's image ships a stash of pre-built SOUL variants and wires a session-key suffix to one of them, only so this page can show two voices in one click. Outside the lab the gateway has no such stash, so two session keys would read the one SOUL.md you have and return two identical replies. In production you change the persona by editing SOUL.md.

Scenario A · Default SOUL.md

Stock OpenClaw: friendly, terse, and willing to use any tool the policy permits, which makes it a good fit for development.

Asking it to summarise a doc gets you a tight summary plus a note about what tools it would reach for next.

Scenario B · "Auditor" SOUL.md

A persona slotted in for code review: it refuses to run code until it has named the risk surface, and it cites the file it is reviewing on every claim.

Asking it to summarise the same doc gets you a risk list plus pointed questions about what's not in the doc.

The voice is in the file. Both replies differ because the runtime folded a different SOUL definition into each prompt. To change the persona for real you edit that file or add a skill bundle and the next turn sees the change. Step 1b already had you read the live SOUL.md off the sandbox, so editing it runs that same path in reverse.

Step 3 · The agent edits its own context

Ask the agent to write a preference to MEMORY.md, then ask it back on the next turn. The model itself has no persistent state, so the second turn can only answer because the runtime carried the preference forward through the session history it holds and through the MEMORY.md the agent saved.

Those stores differ in reach. Session history belongs to its session. MEMORY.md can carry a saved fact into a new session whose transcript starts empty.

This split matters directly for safety. Because the agent can rewrite its own context, the containment layer beneath it has to stop any bad write from doing real harm. OpenClaw freely modifies the markdown in its own workspace, while the OpenShell sandbox beneath it blocks that same write from ever reaching:

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

Everything on this page collapses into one panel: a real conversation with the OpenClaw agent running on your launchable. Ask it to do any of the following and watch the tool chips fire as it works:

describe its workspace,
read a file,
or run a command.

Edit a workspace file, and the agent's next reply changes.

← Module 3a: Connect NemoClaw Module 3c: Always-On →