Securing Agents · Going Further

Going Further

By now you have built an agent loop from scratch, put it behind a kernel-level sandbox, and measured the blast radius the policy leaves.

A real deployment adds its own data and users. You now need to choose where to deploy it, how to bring in your own knowledge, and which open problems matter once the basics hold.

Deploy what you built

Moving the exercises onto a real runtime

The in-browser exercises were sized for learning, with proxied endpoints and sessions that reset between runs. Taking the same work to a persistent deployment means choosing a runtime, an inference provider, and an operating model for long-running sessions. Hosted endpoints require no learner-managed GPU; local inference requirements depend on the selected provider and model.

Carry the interface forward

The browser artifact is a transferable agent surface

Each course page is both a lesson and a small application. The interface exposes state, controls, intermediate results, and approval points; JavaScript runs the local orchestration. That combination works well when the audience has a browser but no prepared development environment. It can explain a system interactively, drive a dynamic workflow, or provide a focused front end for general scripting over loaded data and allowed services.

Transfer the interface contract, then adapt the environment. HTML, CSS, JavaScript, visible state, and approval controls travel well. Authentication, cross-origin access, persistence, filesystem reach, backend tools, and host UI bridges do not. Keep those dependencies behind narrow adapters so the workflow can move without pretending every host grants the same authority.

Agent products now expose this form directly. Anthropic describes Cowork live artifacts as persistent interactive HTML pages that can refresh from connected apps and local files. OpenAI's preview Apps SDK lets an MCP-backed app define its chat behavior and interactive interface together. A static page, a hosted artifact, and an in-chat app use different host contracts, but all can present the same workflow as inspectable state plus bounded actions.

Add new knowledge

Bringing your data in

The Index Agent in Module 2b ran against a small in-page corpus. A production deployment needs more work and considerations, so the following references may be of interest.

Applied · NextChoose the next production axis to deepen?
Where to push next

Where production work diverges

Production projects usually deepen one of these areas:

  • The knowledge layer. Production-grade retrieval: structural chunking, page-image retrieval, faithfulness eval on real heterogeneous corpora. NeMo Retriever and the RAG AI Blueprints are where this gets built for real.
  • The substrate. Wire-format protocols (MCP, the Responses API, OTel GenAI conventions, A2A) that keep tool capabilities portable across providers and frameworks.
  • Fleet dynamics and containment. What changes when N agents run in parallel: each agent redundantly re-discovers the same context (rediscovery cost), topologies with too many hops lose coherence, and an agent grading a peer's output can shift its verdicts based on social context rather than content. How to bound any single agent in the fleet with kernel-level containment (Landlock, seccomp, network namespaces) when prompt rules and guardrails are not enough to limit blast radius.

Pick the axis that matches the problem your current project keeps running into. The NVIDIA Developer Blog tracks the latest reference work across them.

NVIDIA Developer Blog →
Deep · SourcesOpen the full module-by-module reading list?
References hub

Reading list, organised by module

This hub gathers every source the modules' "References" tails point back to, and every entry is freely available through arxiv or the org's own docs and GitHub repositories.

The topic groups follow this course first, then extend into fleet and evaluation work.

Module 1 · Model and agent foundations

Module 1 · ReAct, tool use, and structured outputs

Module 2 · Workflow, retrieval, and deep research

Module 3 · Persistent runtimes and CLI agents

Module 4 · Evaluation and containment

Beyond this course: the final group extends the same design questions to fleets and model adaptation.

Going further · Multi-agent systems and adaptation

Learning path

Continue with the NVIDIA Agentic AI Learning Path

This course is the hands-on companion to Lesson 6 of NVIDIA's Agentic AI Learning Path, How to Build a Safer Autonomous Agent using OpenClaw. The full path begins with building a first agent and ends at the safety work this course covers in depth. In between it moves through retrieval, evaluation, model customization, and deep agents that delegate and persist memory. Each lesson below pairs a concept you met here with the place the path develops it further.

Lesson 1 · How to Build an AI Agent

The plan-act-observe loop you built from scratch in Module 1, here assembled with NVIDIA Nemotron models and LangGraph into a report-generation agent.

Start →

Lesson 2 · How to Build an Agentic RAG Application

The retrieval agent from Module 2b, scaled up: dense and sparse search, reranking, and a vector store wired into a ReAct agent that plans its own queries.

Start →

Lesson 3 · How to Evaluate AI Agents

The verification half of the loop. Measuring task success, tool-use quality, and trajectory efficiency with RAGAS metrics and LLM-as-judge pipelines, the discipline behind every reliability decision in this course.

Start →

Lesson 4 · How to Customize AI Agents

When prompting and skills hit their limit, this lesson writes domain knowledge into the weights themselves: synthetic data with NeMo Data Designer, then fine-tuning Nemotron with GRPO and LoRA.

Start →

Lesson 5 · How to Build Deep AI Agents

The planner, sub-agent delegation, and virtual-filesystem memory you hand-rolled in Module 2c, built here with LangChain's deepagents library and the NVIDIA AI-Q Blueprint.

Start →

Lesson 6 · How to Build a Safer Autonomous Agent using OpenClaw

This course. The containment work from Modules 3 and 4: deny-by-default network, Landlock filesystem, seccomp hardening, credential isolation, and continuous safety evaluation on a long-running claw.

Start →

Helper articles worth reading

What you actually built

The course built a harness around a swappable model

The model never changed across these modules. The same frozen and stateless model that filled the reasoning slot in Module 1 is the one running under the deep agent, the OpenClaw persona, and the sandboxed claw.

Everything else you wrote is the harness, the system that wraps a raw model and makes it useful for sustained, autonomous work. Each module added one layer of it.

Your engineering accumulates in these layers rather than in the model itself. A stronger model drops into the same harness with little rework, so you carry these layers forward across upgrades.

When an agent keeps failing the same way, the gap is usually a layer you have not built yet, and a check enforced beneath it fixes the failure more durably than another pass at the prompt. The patterns below show what that work looks like in practice.

Lessons for deployment

What to remember when you ship one of these

Keep the Course Assistant with you

The Course Assistant behind the button is available on every English lesson, so this page no longer mounts a second capstone chat. It preloads the current page. When a question crosses modules, the assistant can inspect the course map, search the lessons, and read the relevant pages. Browser-local persistence means sessions stay in this browser: return to one after navigating or reloading, or create another for a clean line of inquiry. As a session grows, the assistant compacts older turns into durable memory, keeps the recent exchange verbatim, and starts a fresh bounded agent thread from that state.

The shape you built runs in production. The OpenClaw agent you drove in Modules 3 and 4 is built on the Pi agent runtime which OpenClaw leverages behind its agent gateway. Looking at this core, you'll see that under all of these layers is the same perceive-reason-act loop, tool calls, and growing message history you relied on in Module 1.

← Module 4b: Modern CLIs