Chi cerca "claude code subagents" ha gia' notato la forma del problema: un agente che lavora un intero task dentro un'unica finestra di contesto finisce lo spazio, oppure perde il filo, oppure prova a fare ricerca e scrittura di codice nello stesso respiro. I subagent sono la risposta di Claude Code: delegare un pezzo del task a una sessione separata che torna con un solo risultato, non con tutto il suo ragionamento.
Cos'e' un subagent, e perche' i team li usano
Un subagent in Claude Code e' un'invocazione separata dell'agente, definita una volta (un nome, una descrizione di quando usarlo, un set di strumenti consentiti, opzionalmente un modello proprio) e poi delegata in automatico, quando la richiesta della sessione principale corrisponde alla descrizione del subagent, oppure in modo esplicito, quando una persona o uno script lo chiama per nome. Gira nel proprio contesto: nessuna cronologia della sessione principale, nessuno scambio accumulato, solo il task che gli e' stato assegnato e i file o strumenti che puo' toccare. Quando finisce, la sessione principale riceve un riassunto, non l'intera trascrizione.
I team lo adottano per un motivo semplice: una sessione lunga si degrada. Il contesto si riempie di esplorazioni finite in un vicolo cieco, il modello deve tenere a mente una pila crescente di passaggi precedenti, e un task che mescola ricerca ampia sul codebase e modifica mirata non fa bene ne' l'una ne' l'altra nella stessa finestra. Dividere la ricerca in un subagent e la modifica in un altro mantiene ogni pezzo focalizzato, e lascia pulito il contesto della sessione principale per le parti che devono davvero sopravvivere.
I tutorial che esistono oggi, e cosa danno per scontato
Quello che si trova oggi, documentazione ufficiale, un modulo di corso, un thread Reddit, una lista curata di definizioni di subagent su GitHub, copre sempre lo stesso terreno: come definire un subagent, a quali strumenti limitarlo, come scrivere una descrizione perche' l'agente principale scelga quello giusto in automatico, come incatenarne alcuni per un workflow piu' grande. E' il contenuto giusto per chi ne configura uno per la prima volta, e da per scontata una cosa senza dirlo: che una volta finito il lavoro del subagent e arrivato il riassunto nella sessione principale, la domanda di fondo, cosa ha effettivamente toccato e su quale autorizzazione, sia gia' risolta. Non viene posta, perche' i tutorial parlano di far funzionare la delega, non di cosa costa la delega una volta che funziona.
Cosa diventa piu' difficile da tracciare quando il lavoro viene delegato
Un agente singolo che lavora da solo lascia gia' una traccia difficile da ricostruire mesi dopo, lo stesso punto che la maggior parte delle rassegne di agenti di coding salta quando giudica uno strumento solo su cosa produce in una sessione. La delega aggrava lo stesso divario invece di chiuderlo. Una sessione con tre subagent eseguiti in sequenza significa tre contesti separati, ognuno con la propria visione di cosa era autorizzato a fare, ognuno che restituisce un riassunto che la sessione principale prende per buono. Se la modifica del secondo subagent va in conflitto con un'assunzione fatta dal primo, niente nel meccanismo forza quel conflitto a emergere, perche' nessuno dei due subagent vede il ragionamento dell'altro: solo la sessione principale vede entrambi i riassunti, a cose fatte.
E' una versione piu' difficile di una domanda che DETENT gia' pone su un singolo agente: chi ha effettivamente toccato questo file, su quale autorizzazione, e si puo' mostrarlo a chi non c'era. Con un agente solo, la risposta si trova almeno in un log, per quanto informale. Con la delega, le azioni sono sparse su tanti run di subagent quanti ne ha richiesti il task, e ricostruire "chi ha fatto cosa, in che ordine, in base a cosa" non e' un lavoro che nessuno strumento fa di default: e' una ricostruzione manuale a partire da riassunti scritti per informare il passo successivo, non per reggere un controllo.
Una sessione con subagent contro una sessione con un solo agente
La differenza non e' codice migliore o peggiore: la delega e' spesso il modo piu' disciplinato di condurre un task complesso, tenere separata una fase di ricerca da una di modifica ha un valore reale. La differenza e' cosa resta in piedi dopo. Un agente solo che lavora da solo lascia un unico filo di ragionamento, per quanto sottile, che una persona puo' almeno seguire dall'inizio alla fine. Una sessione che ha delegato tra piu' subagent lascia diversi fili che non sono mai stati pensati per essere letti insieme: il contesto di ogni subagent esisteva per portare quel subagent a un risultato, poi sparisce, e quello che resta e' solo il riassunto compresso che ognuno ha scelto di restituire.
Ed e' esattamente in quella compressione che la responsabilita' diventa fragile. Un subagent che ha eseguito un comando distruttivo come parte del suo lavoro, e poi ha riassunto l'esito senza ogni passaggio intermedio, consegna alla sessione principale un risultato dall'aspetto pulito. Se quel risultato sia davvero pulito, o solo descritto in modo pulito, non e' qualcosa a cui il riassunto da solo puo' rispondere.
Cosa dovrebbe restare visibile quando la catena di delega finisce
Niente di tutto questo e' un argomento contro i subagent: dividere un task in contesti isolati e' un modo ragionevole di tenere coerente una sessione complessa, ed e' un passo nella direzione giusta rispetto a un unico contesto enorme che prova a tenere tutto insieme, lo stesso istinto dietro gli hook che intercettano gli eventi grezzi mentre accadono invece di ricostruirli dopo. Quello che la delega non fornisce da sola e' un record che leghi le azioni di ogni subagent al task che le ha innescate, in un ordine che un revisore possa davvero seguire, con l'autorizzazione di ogni passaggio visibile invece che presunta dal solo fatto che e' avvenuto dentro una sessione approvata.
Costruire quel record non e' un problema specifico di Claude Code, e' la stessa responsabilita' che un team si assume nel momento in cui inizia a comporre agenti da solo, che si tratti di subagent dentro una sessione o di una pipeline costruita da zero. Una software house che consegna lavoro fatto cosi' deve avere pronta una risposta alla domanda che arriva sempre dopo: quando tre agenti hanno toccato il codebase di un cliente in una sessione, chi puo' mostrare, a cose fatte, chi ha fatto cosa, e chi ha firmato il risultato. La delega tra agenti non elimina quella domanda. Aggiunge solo uno strato tra il lavoro e chi deve rispondere.