Claude Code Agent View: è arrivato il cockpit multi-agente

Claude Code Agent View è il segnale più chiaro che gli agenti di coding stanno passando da sessioni terminal intelligenti a operazioni engineering gestibili. La domanda non è più “un agente può scrivere codice?” ma “un team può vedere stato, blocchi, costi e condizioni di completamento prima che agenti paralleli tocchino lavoro di produzione?”

Anthropic ha rilasciato Claude Code v2.1.139 l’11 maggio 2026. Il changelog ufficiale di Claude Code elenca Agent View, il comando /goal, overlay dei token, dettagli sui costi dei plugin, argomenti di esecuzione degli hook e miglioramenti continueOnBlock nella stessa versione. Il registro npm mostra anche @anthropic-ai/claude-code versione 2.1.139 come tag latest e next, pubblicato il 2026-05-11T18:09:28Z.

Questo pacchetto conta perché collega tre problemi prima separati: visibilità multi-agente, linee di arrivo esplicite e controllo dei costi. Per i leader engineering, Claude Code Agent View non è solo una UI gradevole. È un’anteprima del sistema operativo di cui avranno bisogno i workflow seri di AI coding.

Cosa cambia con Claude Code Agent View

La documentazione di Agent View descrive una research preview che si apre con claude agents e mostra in una sola schermata le sessioni Claude Code in background. Indica quali sessioni stanno lavorando, quali aspettano input e quali sono finite. L’operatore può sbirciare una sessione, rispondere senza lasciare la tabella, collegarsi alla conversazione completa o staccarsi mentre il lavoro continua.

Sembra poco finché non lo si confronta con l’uso normale degli agenti di coding. Uno sviluppatore apre più terminali: un agente corregge un bug, un altro ispeziona log, un terzo aggiorna test. Dopo venti minuti, l’umano deve ricordare quale terminale aveva quale compito, quale agente è bloccato e quale diff può essere fidato. Più gli agenti diventano veloci, più l’umano diventa gestore della coda.

Claude Code Agent View rende visibile quella coda. Il coding parallelo passa da archeologia di terminali a loop operativo: avviare, osservare, interrompere, ispezionare, collegarsi, fare merge. È lo stesso principio di Reviewmaxxing: il protocollo per le PR degli agenti: l’output dell’agente è utile solo quando la revisione umana ha un sistema.

La scelta della supervisione locale è importante. Le sessioni in background sono ospitate da un processo supervisore per utente, continuano quando il terminale è staccato e salvano lo stato nella directory di configurazione Claude. Gli amministratori possono disattivare la funzione con una managed setting. È la postura iniziale corretta: potente per workflow reali, controllabile per team con policy.

Il cockpit mostra stato, blocchi e lavoro in background

Agent View è utile perché risponde a tre domande: cosa sta girando, cosa è bloccato e dove esiste prova di completamento. Senza queste risposte, il multi-agent coding diventa autonomia rumorosa. Con esse, i team possono trattare gli agenti come lavoratori dentro una corsia di delivery osservabile.

La documentazione descrive interazioni concrete. Una riga mostra lo stato della sessione. Space apre un pannello di anteprima. Enter collega alla sessione. La freccia sinistra stacca senza fermare il lavoro. claude --bg "prompt" avvia una sessione in background direttamente dalla shell. La documentazione avverte anche che i rate limit restano validi: dieci sessioni in background possono consumare circa dieci volte la quota di una sola sessione.

Questo avviso non è un dettaglio. È il costo operativo del parallelismo. Se cinque agenti passano trenta minuti ciascuno a esplorare lo stesso errore di dipendenza, il team non ha guadagnato cinque lavoratori. Ha comprato cinque copie della stessa confusione. Un cockpit aiuta solo se il team definisce responsabilità: un agente legge i log, uno scrive la patch minima, uno aggiorna i test, uno rivede il diff.

Claude Code Agent View si collega quindi al trend dei control plane. Lo abbiamo scritto anche in Hermes Web Dashboard: il prossimo salto di produttività non nasce dal nascondere lo stato degli agenti. Nasce dal renderlo abbastanza ispezionabile da permettere intervento umano precoce.

Per team di produzione, il cockpit dovrebbe mostrare almeno sei campi prima del merge: owner del task, repository o worktree, stato attuale, ultimo blocco, spesa in token e prova richiesta. Claude Code consegna diverse primitive dentro la CLI. Il resto dovrebbe stare nel template PR, nei commenti CI o nell’issue tracker.

I goals trasformano i prompt in contratti di completamento

Il comando /goal è il secondo pezzo importante della release. La documentazione Claude Code sui goal dice che /goal imposta una condizione di completamento e mantiene Claude al lavoro per più turni finché la condizione è soddisfatta o cancellata. Funziona in modalità interattiva, in modalità non interattiva -p e tramite Remote Control.

Questo cambia la forma del prompt. Un prompt normale dice: “Correggi i test auth.” Un goal utile dice: “npm test -- test/auth termina con 0, nessun file fuori da src/auth e test/auth viene modificato, e la risposta finale include il nome del test fallito e il comando che passa, oppure ferma dopo 12 turni.” La seconda versione definisce risultato, prova, limite e regola di stop.

La documentazione chiarisce un limite sano: l’evaluator giudica ciò che Claude ha reso visibile nella conversazione. Non esegue comandi né legge file in modo indipendente. Questa limitazione costringe l’agente principale a mostrare prove nel transcript e dà agli umani una traccia da controllare. La condizione può arrivare a 4.000 caratteri, abbastanza per vincoli utili senza creare un documento legale per ogni task.

È la differenza tra teatro dell’autonomia e autonomia operativa. L’agente non deve continuare perché il prompt suona ambizioso. Deve continuare perché il team ha definito una condizione misurabile. Lo stesso principio è in Usare Codex in sicurezza: sandbox, approvazioni, policy di rete, credenziali e telemetria funzionano solo se il sistema sa cosa deve provare.

Un buon contratto di completamento ha cinque parti:

• Risultato: lo stato finale tecnico o business, come test verdi o report di migrazione.
• Prova: comando, diff, screenshot o riga di log che dimostra il risultato.
• Limite: file, sistemi, secret o servizi che l’agente non deve toccare.
• Budget: limite di token, turni o tempo prima che l’agente si fermi e chieda.
• Revisione: controllo umano o secondo agente prima del merge.

Il comando /goal dà ai team un punto nativo per esprimere questo contratto. Il valore non è un evaluator magico. Il valore è rendere visibile la linea di arrivo.

La telemetria dei costi rende governabile il coding parallelo

La release aggiunge anche tempo trascorso, turni e token in un overlay per i goal. Aggiunge claude plugin details <name> per mostrare inventario dei componenti e costo token previsto per sessione. Sono funzioni poco appariscenti. Proprio per questo contano.

Lo sviluppo agentico fallisce in silenzio quando i costi sono invisibili. Un team vede una PR mergiata e celebra l’ora umana risparmiata. Non vede otto tentativi dell’agente, caricamenti di contesto ripetuti, ricerche duplicate e tempo di review per ripulire l’output. La visibilità dei token trasforma quella spesa nascosta in una variabile engineering.

Un team pratico dovrebbe tracciare tre rapporti: token per linea di diff accettata, turni agente per test verde e minuti di review umana per merge. Questi numeri non devono essere perfetti. Servono a dirigere. Se il costo token raddoppia mentre la qualità accettata resta piatta, il workflow ha bisogno di un goal più stretto o di task più piccoli.

Agent View può anche evitare incentivi sbagliati. Se i manager contano solo throughput degli agenti, il team creerà più branch, più PR e più carico di review. Se vede blocchi e costi, può capire quando fermare, dividere o riassegnare una task. È anche la lezione di Vercel deepsec: il valore di sicurezza nasce da controlli ripetibili, non dalla fiducia dell’agente.

C’è una seconda dimensione di costo: plugin e hook. Claude Code v2.1.139 mostra il costo token previsto per plugin e aggiunge args: string[] agli hook, così i comandi possono partire direttamente senza quoting shell. Per team enterprise, la combinazione conta. I plugin espandono capacità, gli hook aggiungono controllo, e entrambi vanno messi a budget.

Checklist di rollout per team engineering

Claude Code Agent View è una research preview, quindi i team non dovrebbero abilitarlo ovunque e considerare concluso il rollout. La scelta migliore è un pilot controllato con corsie esplicite.

Partite da lavoro non sovrapposto: analisi log, riparazione test, documentazione, analisi impatto dipendenze e bug isolati. I primi casi sbagliati sono cambi architetturali trasversali, migrazioni senza rollback, codice payment, policy auth e qualsiasi cosa tocchi secret di produzione.

Definite una corsia di review prima di lanciare gli agenti. Ogni sessione background deve avere owner, branch o worktree, acceptance check e limite “non toccare”. L’operatore ispeziona i blocchi da Agent View, ma il merge finale richiede ancora test e code review. Se il team ha già un protocollo reviewmaxxing, Agent View diventa la board di stato che lo alimenta.

Usate i goal per task dimostrabili, non per esplorazioni vaghe. “Trova tre cause probabili e cita le righe di log” è un goal utile. “Migliora performance” non lo è. Per l’esplorazione, chiedete prima un breve report investigativo, poi create un secondo goal per la patch. Separare discovery e implementazione rende leggibile la spesa token.

Definite infine un kill switch. La documentazione cita disableAgentView come managed setting e una variabile d’ambiente per disattivare gli agenti background. Le aziende dovrebbero documentare chi può abilitare Agent View, quali repository sono ammessi, quali dati sono esclusi e quali audit log sono richiesti.

Per chi valuta partner di sviluppo AI, questo è il vero segnale. I team maturi non chiedono se gli agenti possono produrre codice. Chiedono se il sistema di delivery può governare molti tentativi, respingere output deboli e mostrare prove. Context Studios costruisce sistemi software AI-native con governance degli agenti, review gate e telemetria di delivery integrati dall’inizio.

Il punto finale è semplice: gli agenti di coding paralleli hanno bisogno di meno hype e più cockpit. Claude Code Agent View offre un’anteprima nativa di quel cockpit, e /goal dà una linea di arrivo. Vinceranno le organizzazioni che strumentano stato, costo, prove e review umana prima di scalare la flotta di agenti.

FAQ

Che cos’è Claude Code Agent View?

Claude Code Agent View è un cockpit in research preview per gestire più sessioni Claude Code in background da una sola schermata. Si apre con claude agents e mostra sessioni in esecuzione, bloccate o concluse.

La funzione serve per più task di coding indipendenti. Permette di lanciare sessioni, guardarle, rispondere, collegarsi alla conversazione completa e staccarsi mentre il lavoro continua.

Cosa è cambiato in Claude Code v2.1.139?

Claude Code v2.1.139 ha aggiunto Agent View, il comando /goal, overlay token per i goal, dettagli di componenti e costi dei plugin, navigazione transcript e argomenti hook più sicuri. Anthropic indica l’11 maggio 2026 come data di release.

Il registro npm mostra la versione 2.1.139 come latest e next per @anthropic-ai/claude-code, con metadati di pubblicazione al 2026-05-11T18:09:28Z.

In cosa /goal è diverso da un prompt normale?

Un prompt normale chiede lavoro; /goal definisce una condizione di completamento e mantiene Claude al lavoro finché è soddisfatta o cancellata. La vista di stato mostra tempo trascorso, turni valutati, token spesi e ultima ragione dell’evaluator.

I buoni goal includono uno stato finale misurabile, una prova, limiti e una regola di stop. Sono contratti di completamento, non slogan motivazionali.

Perché gli overlay token contano per i team?

Gli overlay token rendono visibile il costo del lavoro dell’agente durante l’esecuzione. I team possono fermare esplorazioni duplicate, dividere task troppo grandi e confrontare costi con qualità del codice accettato.

Senza visibilità sui token, il coding parallelo può sembrare produttivo mentre moltiplica quota, carico di review e letture ripetute di contesto.

Le aziende dovrebbero abilitare subito Agent View?

Le aziende dovrebbero pilotare Agent View in repository controllati prima di un rollout ampio. I primi casi migliori sono fix isolati, analisi log, riparazione test e documentazione con acceptance check chiari.

Payment, auth, secret e migrazioni multi-repository sono cattivi punti di partenza. Repository ammessi, review gate, esclusioni dati e kill switch devono essere definiti prima dell’uso diffuso.