Anthropic ha rilasciato Claude Code versione 2.1.139, introducendo il comando /goal, una funzionalità che cambia in modo sostanziale il modello di interazione tra sviluppatore e agente AI. Fino a questo aggiornamento, qualsiasi sessione di lavoro con Claude Code seguiva un ciclo prompt-risposta-approvazione che richiedeva intervento umano a ogni turno: l’agente completava un’azione, si fermava, e aspettava l’input successivo. Con /goal, il ciclo si chiude diversamente: il developer definisce una condizione di completamento — non un’istruzione, ma uno stato finale verificabile — e l’agente continua a lavorare in autonomia, turno dopo turno, finché quella condizione non viene soddisfatta o il budget di token viene esaurito.
Il meccanismo tecnico sottostante è progettato per evitare un problema classico dell’automazione agente: il modello che “decide” autonomamente di aver finito il lavoro basandosi sulla propria valutazione, che può essere distorta dal fatto di essere lo stesso modello che ha svolto il task. Anthropic ha risolto questo con un’architettura a supervisore separato: dopo ogni turno di esecuzione, un secondo modello — più piccolo, più veloce, indipendente rispetto all’agente principale — valuta se la condizione di completamento è stata raggiunta. Se la risposta è no, il loop riparte. Se è sì, il controllo torna al developer. La separazione tra chi esegue e chi verifica è una scelta architetturale deliberata che aumenta l’affidabilità del sistema, perché il verificatore non ha interesse nel dichiarare completato ciò che non lo è.
Praticamente, /goal funziona in tre modalità: interattiva, tramite il flag -p, e in Remote Control, che consente di far girare sessioni Claude Code come processi in background gestibili da remoto. Quest’ultima modalità è particolarmente rilevante per team che vogliono orchestrare più agenti in parallelo, ognuno con il proprio obiettivo autonomo, senza dover presidiare un terminale per ciascuno. La stessa release 2.1.139 introduce infatti Agent View, una dashboard unificata che mostra lo stato in tempo reale di tutte le sessioni attive — in esecuzione, bloccate in attesa di approvazione umana, o completate — un’interfaccia che diventa necessaria nel momento in cui si lavora con fleet di agenti piuttosto che con una singola istanza.
La condizione di completamento è il punto critico dell’intera funzionalità: /goal produce risultati affidabili quando il criterio di fine è oggettivo, testabile e verificabile nel contesto della conversazione — per esempio “tutti i test passano”, “tutti i call site del modulo migrato compilano senza errori”, “il README copre installazione, esecuzione, test e architettura con comandi funzionanti”. Diventa meno utile quando la condizione è vaga o richiede un giudizio che non può essere espresso in modo deterministico. Questa è la distinzione reale tra workflow agentici affidabili e loop che girano a vuoto consumando token: non la capacità del modello di essere autonomo, ma la precisione con cui viene definito il punto di arresto.
Per ragioni di sicurezza, /goal è disponibile solo in workspace dove il trust dialog è stato esplicitamente accettato, ed è disabilitato se la policy disableAllHooks è attiva nell’ambiente gestito. Questo perché la funzionalità è trattata architetturalmente come parte del sistema di hooks di Claude Code — non come una feature separata, ma come un’estensione del meccanismo di controllo del flusso, il che spiega anche come interagisce con le altre modalità autonome già esistenti. /loop fa girare un task su intervallo temporale fisso; auto mode approva automaticamente le tool call all’interno di un singolo turno senza avviarne di nuovi; /goal è l’unica delle tre che mantiene la sessione attiva attraverso turni multipli finché una condizione esterna viene soddisfatta. Le tre modalità sono complementari e progettate per coprire casistiche distinte di automazione.
Il contesto competitivo non è irrilevante: OpenAI aveva già introdotto /goal in Codex CLI come feature sperimentale nelle settimane precedenti, e Nous Research lo aveva integrato in Hermes. L’adozione della stessa convenzione di naming da parte di più laboratori non è casuale — è l’industria che converge su un’interfaccia condivisa per un primitivo specifico: un agente che gira in loop chiuso verso uno stato finale misurabile, senza richiedere approvazione a ogni step. Che questo primitivo stia diventando standard simultaneamente su più piattaforme segnala qualcosa di più ampio: il passaggio da AI come strumento di completamento a AI come sistema di esecuzione di obiettivi, un cambiamento nel ruolo del developer da “chi scrive il codice” a “chi definisce e verifica il risultato atteso”.