NemoClaw non è un agente: è uno stack che devi saper verificare

Quando una demo di un agente AI funziona, vediamo il risultato: una richiesta, qualche tool, un file modificato, magari un report finale. Quello che non vediamo è il sistema che ha reso possibile quell’esecuzione. Dove sono finite le credenziali? Chi ha autorizzato la chiamata? Che cosa succede se cambia il modello, se il tool non risponde o se la memoria suggerisce un’azione vietata? Sono domande meno spettacolari del video dimostrativo. Sono anche quelle che separano un esperimento da un software che può restare acceso.

Il 30 ottobre 2026 NVIDIA ha pubblicato una descrizione tecnica di NemoClaw che merita di essere letta senza trasformarla nell’ennesima gara tra framework. Il punto interessante non è un nuovo chatbot e nemmeno un modello miracoloso: è il tentativo di consegnare una distinta base operativa di un sistema agentico, con componenti differenti e responsabilità che dovrebbero restare separabili.

Questa distinzione conta soprattutto per chi sviluppa. Scaricare uno stack aperto non equivale a possederne il controllo. Il controllo comincia quando posso sostituire un componente, ricostruire una decisione, misurare un errore e verificare che un limite continui a valere anche se il modello propone di superarlo.

NemoClaw non sostituisce OpenClaw, Hermes o Deep Agents

NVIDIA è esplicita su un punto spesso perso nei titoli: NemoClaw non è un harness concorrente e non è, da solo, il runtime. È una raccolta di blueprint che assembla uno stack attorno a un harness scelto. Gli esempi citati comprendono OpenClaw, Hermes Agent di Nous Research e LangChain Deep Agents. Ognuno conserva la propria logica di orchestrazione, strumenti, memoria e gestione delle attività.

Attorno a quel livello, il blueprint integra modelli aperti Nemotron, strumenti NeMo per ottimizzazione e osservabilità, e OpenShell per applicare policy all’esecuzione. NeMo Relay, dove previsto, aggiunge tracce delle sessioni e delle chiamate. Il repository pubblico di NemoClaw rende ispezionabile il progetto; non prova, da solo, che ogni combinazione o ambiente di produzione sia equivalente o già validato.

La differenza fra harness e blueprint sembra terminologica soltanto finché tutto funziona. Quando il modello richiede un tool che l’harness espone ma il runtime vieta, serve sapere quale componente è responsabile del rifiuto. Quando una sessione riparte, serve sapere chi conserva il contesto e chi decide che il lavoro è davvero terminato. Se chiamiamo tutto indistintamente “agente”, perdiamo la possibilità di fare diagnosi.

Cinque contratti che dovrebbero essere verificabili

Un blueprint è utile se chiarisce i confini tra componenti. Per valutare uno stack come NemoClaw, più che contare i modelli disponibili, proverei a verificare cinque contratti operativi:

• Modello e harness. Quale formato hanno tool, errori, contesto e risultati? Una modifica al modello cambia il comportamento dei retry o il modo in cui viene dichiarato il completamento?
• Harness e strumenti. Le chiamate sono tipizzate, idempotenti quando necessario e riconducibili a un task? Un timeout produce uno stato recuperabile oppure una risposta che sembra un successo?
• Strumenti e runtime. I permessi vengono applicati a filesystem, rete, processi e credenziali indipendentemente da ciò che il modello scrive o ricorda?
• Runtime e identità. Dove risiedono i segreti, chi li distribuisce e per quanto tempo? Revocare un’autorizzazione interrompe davvero le operazioni successive?
• Esecuzione e osservabilità. È possibile ricostruire quali tool sono stati invocati, con quali esiti e quali decisioni di policy hanno consentito o negato le azioni?

Questa non è una checklist promozionale di NemoClaw. È un insieme di verifiche che dovrebbe valere per qualunque infrastruttura agentica. La documentazione NVIDIA descrive OpenShell come un runtime che governa file, rete, credenziali e tool fuori dal processo dell’agente; la documentazione OpenShell descrive sandbox, gateway, supervisor e policy. Sono meccanismi concreti, ma vanno configurati, osservati e testati nel contesto reale.

Un blueprint diventa architettura quando i confini tra i componenti non sono soltanto disegnati: possono essere messi alla prova.

La prova più utile: cambiare un pezzo senza perdere il sistema

La promessa di uno stack aperto è interessante, ma la parola “open” non garantisce automaticamente portabilità. Una licenza permette di studiare e modificare il codice. Non garantisce che il profilo di un modello, il formato delle skill, la memoria di un harness o il tracciamento delle sessioni siano intercambiabili senza adattamenti.

Farei quindi un test semplice da descrivere e abbastanza scomodo da eseguire: stesso task, stessi strumenti, stessi dati di ingresso, stessa policy di accesso. Prima eseguo con la combinazione prevista dal blueprint. Poi sostituisco un elemento, per esempio il modello o l’harness, e confronto non solo la risposta finale, ma il comportamento operativo. Sono rimasti uguali gli esiti delle chiamate? I permessi? I log? Il consumo di risorse? La possibilità di riprendere dopo un’interruzione?

Non mi aspetterei risultati identici: un harness diverso può organizzare diversamente i passi, e un modello diverso può scegliere percorsi differenti. Mi aspetterei invece invarianti espliciti: nessuna credenziale in output, nessuna chiamata fuori policy, nessun completamento dichiarato senza evidenza, nessun doppio effetto collaterale dopo un retry. È lì che la portabilità smette di essere uno slogan e diventa un test.

Sul rapporto fra modello e harness esiste già una discussione che va oltre NVIDIA. Ne ho affrontato un aspetto nell’articolo su perché la prestazione degli agenti dipende dalla coppia modello-harness. NemoClaw aggiunge un livello di domanda: non basta misurare quella coppia; bisogna verificare anche l’ambiente in cui può agire.

Policy fuori dal modello non significa sicurezza automatica

Il valore di un runtime separato è chiaro: non chiediamo al modello di essere contemporaneamente esecutore e garante dei propri limiti. Ma trasformare questo principio in un’etichetta “secure” sarebbe un errore. La sicurezza reale dipende dalla superficie consentita, dalle eccezioni, dalle dipendenze e dalle vie alternative con cui una capacità può essere raggiunta.

Uno studio indipendente pubblicato nell’ottobre 2026, HarnessSecurity-Bench, ha valutato meccanismi di sicurezza di diversi coding agent harness. Non è una prova specifica contro NemoClaw o OpenShell, e non va presentata come tale. Mostra però un problema generale: i controlli possono avere compromessi tra utilità e sicurezza, e una restrizione apparentemente efficace può lasciare percorsi alternativi. Per questo un test che verifica soltanto che una chiamata venga negata non basta: bisogna verificare che lo stesso effetto non sia ottenibile tramite un’altra capacità consentita.

Su questo tema esiste già una riflessione più ampia sulla sicurezza degli agenti fuori dal prompt. Qui il passo successivo è pratico: trattare ogni policy come una proprietà da testare dopo gli aggiornamenti di modello, harness, plugin, runtime e configurazione, non come una spunta definitiva in fase di installazione.

Il costo di un agente non è il prezzo del token

NVIDIA cita un lavoro di ottimizzazione di LangChain Deep Agents per Nemotron 3 Ultra, ottenuto intervenendo su prompt, tool e middleware senza riaddestrare il modello. Nel suo articolo parla di prestazioni vicine a quelle dei modelli frontier e di un costo per esecuzione circa dieci volte inferiore rispetto a modelli chiusi di riferimento. È una dichiarazione del fornitore riferita a una specifica configurazione, non un risultato indipendente che possiamo estendere a qualunque workload.

Per un sistema che deve lavorare ogni giorno, il conto comprende anche fallimenti, retry, tracciamento, storage delle sessioni, manutenzione dei connettori, aggiornamenti delle policy e tempo necessario a diagnosticare un incidente. Una run economica che produce un effetto duplicato su un gestionale può diventare costosissima. Una run leggermente più cara ma verificabile può essere un investimento migliore.

Misurerei quindi almeno costo per task completato e verificato, numero di tentativi, interventi umani, violazioni di policy, tempo di recupero e differenze fra risultato dichiarato e stato reale. Sono metriche più noiose di una classifica di modelli. Sono anche quelle che permettono di decidere se lo stack è davvero sostenibile.

Possedere lo stack vuol dire poterne rispondere

Il merito di NemoClaw, per come viene presentato da NVIDIA, è rendere visibile una separazione che molte demo nascondono: il modello ragiona, l’harness organizza, gli strumenti agiscono, il runtime impone confini, l’osservabilità consente di ricostruire ciò che è successo. Non sono cinque nomi da mettere in un diagramma: sono cinque responsabilità che devono avere un proprietario, un contratto e un modo di fallire senza mentire.

Il rischio è scambiare la disponibilità di un blueprint per una garanzia di maturità. Un repository aperto è un ottimo punto di partenza, non una verifica di produzione. Se il giorno dopo un aggiornamento non sappiamo spiegare perché un agente ha perso lo stato, aggirato un controllo o ripetuto una scrittura, non abbiamo davvero il controllo della piattaforma, anche se tutti i componenti girano su una macchina nostra.

La domanda che farei prima di adottare NemoClaw, o qualsiasi altra piattaforma agentica, non è “quanti agenti posso avviare?”. È: quale componente posso sostituire, quale confine posso dimostrare e quale errore posso ricostruire? Il resto è una demo.