Agent Architecture
NVIDIA NemoClaw Shows How Self-Evolving Agents Need to Be Split Apart
Published June 03, 2026 by Dillip Chowdary
NVIDIA NemoClaw and Hermes Agent are useful because they make a concrete architecture visible. The June 2 NVIDIA post describes a research agent that can use internal sources such as Outlook, Slack, and GitHub while also reading public developer forums.
The key pattern is separation. NVIDIA frames the system as a model for reasoning, a harness for skills, sessions, memory, and bridges, and a runtime for filesystem policy, network policy, provider injection, and credential brokering. That split is the minimum viable architecture for agents that can learn and act over time.
Why Memory Changes the Risk Model
Self-evolving agents can preserve preferences, write skills, and carry context between sessions. That is powerful for research workflows, but it also creates new persistence risk. A bad instruction, poisoned source, or over-broad credential can survive beyond a single prompt if memory and skill writes are not governed.
OpenShell-style runtime controls are therefore not decoration. Filesystem policy, network egress limits, host-side mirrors, and credential brokering decide whether an agent can safely join private and public data without exposing secrets.
What Builders Should Borrow
Builders should borrow the three-layer pattern even if they do not use this exact stack. Keep the model replaceable, make the harness auditable, and put sensitive access in a runtime that can enforce policy independently of model intent.
The operational test is simple: if an incident happens, can the team answer what the agent read, which tool it invoked, which credential was brokered, what memory changed, and whether network egress was blocked or allowed?