Module 3 · Part A of 3 · live calls begin

Connect the NemoClaw Stack

In Modules 1 and 2, we kept orchestration in the browser, and each workflow ended when the page stopped carrying its messages, intermediate results, or branch state. Module 3 moves the same agent patterns into a NemoClaw Brev launchable.

The main functional components of this deployment are:

LLM endpoint. Turns prompts and tool results into semantic responses, but does not retain the agent's session state.
OpenClaw harness. Preserves session history, a file-backed workspace, and tool access.
OpenShell sandbox. Limits what the running agent can reach.
NemoClaw blueprint. Configures OpenClaw and OpenShell to work together.

In this lesson, you will connect the browser to the launchable, inspect its four connection paths, use one direct model call as a control, send a tool-using agent turn through the gateway, and prove that a sessionKey restores history the client did not resend.

Runtime roles in the NemoClaw blueprint, adapted from NVIDIA's NemoClaw for OpenClaw workflow.

Start the launchable

Open the NemoClaw launchable and sign in.
Open <launchable>/dashboard.
Find the running my-assistant card and select Chat with Agent.
Return here and enter the launchable URL. If this course is not served by the launchable, paste the launchable's browser access session too.

Copy the launchable access session when this page is hosted separately

The gateway token and the launchable access session authorize different things:

The gateway token authorizes JSON-RPC calls on /cli/gateway.
The access session, an _pomerium or CF_Authorization browser cookie, authorizes access to older launchables, and Skybridge launchables use __Host-skybridge-brev-prd for the same purpose.

When this course is not served by the launchable, copy that browser cookie into the Access session field below:

Keep the signed-in launchable tab open and use __Host-skybridge-brev-prd for a gobrev.dev host, _pomerium for an apps.run.brev.nvidia.com host or CF_Authorization for a brevlab.com host.
Chrome, Edge, or Brave: open Developer Tools, select Application → Storage → Cookies, then select the launchable origin.
Firefox: open Developer Tools, select Storage → Cookies, then select the launchable origin.
Safari: enable web-developer features in Settings → Advanced if necessary, open the Web Inspector, then select Storage → Cookies and the launchable origin.
Find the matching cookie name and copy only its complete Value. Do not copy the whole Cookie header or paste the value anywhere except the Access session field on this page.

If the NemoClaw check times out or returns a 502. Inspect the failed route, connection diagnostics, and launchable runtime logs before choosing a recovery step. A timeout or 502 alone does not identify the cause. If the gateway remains unavailable, inspect the Recover cell below and its reported checks before continuing.

Inspect all four connection routes

The connection check and exposed code share the normalized launchable connection and provider decision. Run the editable cell to test agent metadata, gateway, terminal, and health in order, then inspect its automatically rendered redacted result.

A Pomerium launchable keeps bootstrap and WebSocket traffic direct: HTTP checks run through its terminal loopback. Cloudflare sends HTTP checks through the approved relay; its WebSockets try the launchable first and can recover through the relay. The probe shows the route without displaying the session value.

Step 1 · Establish the model-only control

The launchable checks above prove that the running stack is reachable. Before sending an agent turn, make one direct Chat Completions request through the model route used in Modules 1 and 2. This control has no OpenClaw session or gateway tools, so Step 2 can show what the harness adds. It does not inspect or reconfigure the model inside your launchable.

Confirm the direct model connection

The settings card mirrors the course model route saved on the home page or in Module 1a. Change it only if the direct probe fails. The course model route and the launchable connection retain separate credentials and state.

Step 2 · Operate the agent through its gateway

Step 1 established the model-only control: one Chat Completions POST carried the model, messages, and caller authorization. OpenClaw calls its configured model inside the launchable, but this page operates the running agent through a different interface.

The diagram compares interfaces used at different layers, not one request path:

Three interfaces at different layers: bounded model HTTP, MCP tool integration inside the runtime, and the live WebSocket to the OpenClaw gateway.

REST (Representational State Transfer). The direct model control in Step 1 uses one bounded HTTP request and response. An API can still identify server-side state between calls.
Model Context Protocol (MCP). Inside an agent runtime, MCP standardizes tool and context discovery and invocation. It does not carry this browser's gateway traffic.
OpenClaw gateway. The exercise below and the Control UI use the same /cli/gateway WebSocket. It carries JSON-RPC events between the browser client and the running agent.

Authorize the gateway

Reaching the launchable and operating its gateway require separate credentials:

Launchable access. The browser session reaches the host.
Gateway authority. The gateway token authorizes JSON-RPC calls.

After launchable authentication, GET /api/agent returns the gateway token under agent.dashboardUrl. Leave the token field blank and let the probe fill it in.

That token carries operator.admin scope, the same authority the Control UI holds. With it you can:

models.list enumerates every model the runtime serves.
cron.add schedules work that runs without you.
chat.send with a sessionKey drops a message straight into the running agent's loop.

A chat.send request drives a loop inside the gateway, where the session key carries memory forward to the next call.

Check before changing runtime settings

Supported NemoClaw launchables normally report tools.toolSearch=false. A custom configuration can still enable it, so the health check reads the live value before Recover changes anything:

Symptom: you ask for a command, nothing comes back, the run stalls, and then it times out.
Cause: toolSearch lets the model reach its tools by writing code for a bridge (tool_search_code · “run bridge code”), and the model loops on that bridge instead of calling exec.
Recovery: run the health check. If toolSearch is on and the exec probe fails, Recover can turn it off with config.patch. Session clearing and restart remain opt-in.

The healthy path uses exec directly. Recover changes toolSearch only when the live check finds it enabled.

The three cells below connect to the gateway, list models and scheduled jobs, then send a chat turn and display its trace. Read the trace row by row:

Each ⚙️ row is a tool call with its input arguments.
Each ✓/✗ row is that tool's result.
The model's reasoning is not forwarded by the gateway, so this input/output trace is the deepest per-step view. When a run stalls with no result, the 📜 logs cell above tails the runtime instead.

If a chat fails or reaches its deadline, inspect its trace and run Health check. Use Recover only when those results identify a configuration or session problem.

Anyone who can read the launchable environment can read that token, and a reader of the token is an operator with everything above. Module 4 turns this from a convenience into the central security question.

Step 3 · Compare conversation history

Plant a fresh code, recall it without resending it, then reset that session and ask again. Reset removes conversation history; shared workspace files remain. These prompts ask the agent not to write the code to a file. Inspect the events before interpreting the result.

Cleanup removes only session IDs created by this flow. Re-run Recall on its own to ask again without replanting.

The session key is all the client sends to identify a conversation. From that one string the gateway resolves the full session server-side before every call, so the client never has to ship the transcript itself. Distinct session IDs separate conversations. The gateway may also accept aliases, such as a short key and its canonical agent:<agent-id>:<key> form, for the same conversation.

What's next

Module 3b opens the files that shape each OpenClaw turn. Module 3c adds skills and scheduled triggers, then Module 4 tests how OpenShell limits the actions those persistent instructions can start.

References

OpenAI Chat Completions API. The wire format the model endpoint speaks, including the finish_reason field this page surfaces.
NVIDIA build.nvidia.com. The model API behind the configured proxy. Check its authentication requirements before entering a bearer credential.
Anthropic, Claude Code (docs). The directory-as-session pattern that the next page edits to change what OpenClaw is.
Park et al., Generative Agents (2023). Establishes server-side memory plus identity as durable runtime structure, the model the session-key header implements.

Comprehensive list at Going Further · References.

Try it · talk to your launchable

Once the probe above is green, this artifact opens the same /cli/gateway WebSocket and lets you chat with your live OpenClaw agent. It streams the reply and shows a chip whenever the agent reaches for a tool. Every reply you see here came back over that live gateway connection.

← Module 2c: Deep Agents Module 3b: OpenClaw →