Il problema dell'agente da cinque minuti
Cicli, flussi di lavoro, routine e la vera differenza tra un agente che funziona per cinque minuti e uno che continua a funzionare anche dopo che hai chiuso il portatile. Basato su come Anthropic dice effettivamente di costruire queste cose.
Ecco una scena che potresti riconoscere. Apri Claude, incolli un compito importante, lo guardi lavorare per qualche minuto, prendi la parte utile e chiudi la scheda. Ti è sembrato potente. Si è anche fermato nel momento in cui hai distolto lo sguardo.
Questo è il rapporto che la maggior parte delle persone ha con Claude Fable 5. Trattano il modello più capace che Anthropic abbia mai rilasciato come un'autocompletamento molto intelligente con una grande memoria. Ad essere onesti, è davvero bravo in questo. Ma è un po' come comprare una macchina CNC industriale e usarla come fermacarte. La parte impressionante è quella che quasi nessuno attiva.
Il divario non è il modello. Il divario è il sistema che costruisci attorno ad esso. Un "sistema agente" è ciò che ottieni quando smetti di inviare un singolo prompt e aspettare, e inizi a dare al modello un obiettivo, un insieme di strumenti, una memoria e un ciclo, in modo che possa pianificare, agire, controllare il proprio lavoro e andare avanti senza che tu lo supervisioni ad ogni passo.
Questo articolo è una guida pratica per costruire tutto ciò. Andremo dalla versione in italiano semplice (cosa sia un agente e quando non dovresti costruirne uno) fino alle parti che fanno sì che un sistema migliori davvero nel tempo: valutazioni, memoria, competenze, sottoagenti, flussi di lavoro dinamici e routine. Ho basato tutto su come Anthropic descrive effettivamente la costruzione di queste cose, con le fonti in fondo, perché quest'angolo della tecnologia attira più hype di quasi qualsiasi altro e tu meriti la versione reale.
Una promessa: alla fine saprai esattamente cosa significa e cosa non significa "auto-miglioramento", e avrai un percorso di costruzione che inizia in piccolo invece di cercare di prosciugare l'oceano il primo giorno.
Parte 1: Chiariamo i termini
Prima di costruire qualsiasi cosa, chiarisci tre termini, perché la maggior parte della confusione online deriva da persone che li usano in modo intercambiabile.
Un singolo prompt non è un agente
Quando scrivi una richiesta e leggi la risposta, quella è solo una chiamata al modello aumentata. Anthropic chiama l'unità base "LLM aumentato", che è un modello più tre componenti aggiuntive: recupero (può cercare informazioni), strumenti (può fare cose) e memoria (può ricordare). Tutto il resto è costruito a partire da questo singolo blocco. Se un singolo buon prompt con il contesto giusto risolve il tuo problema, congratulazioni, hai finito. Non costruire un agente.
Flussi di lavoro contro agenti
Anthropic traccia una linea netta tra i due tipi di sistemi che le persone raggruppano come "agentici". Con le loro parole, i flussi di lavoro sono "sistemi in cui LLM e strumenti sono orchestrati attraverso percorsi di codice predefiniti", mentre gli agenti sono "sistemi in cui gli LLM dirigono dinamicamente i propri processi e l'uso degli strumenti, mantenendo il controllo su come svolgono i compiti".
Versione semplice: un flusso di lavoro è una ferrovia. Metti i binari, il modello li percorre. Un agente è un'auto con un conducente. Gli dai una destinazione e lui sceglie il percorso, cambiando strada quando una via è chiusa.
I flussi di lavoro sono prevedibili, economici e ottimi per lavori ben definiti. Gli agenti sono flessibili e potenti e migliori quando non puoi programmare i passaggi in anticipo, il che li rende anche più lenti, più costosi e più inclini a divagare. Il consiglio stesso di Anthropic è piacevolmente noioso: "trova la soluzione più semplice possibile e aumenta la complessità solo quando necessario. Questo potrebbe significare non costruire affatto sistemi agentici". Inquadralo e appendilo sopra la tua scrivania.
Dove Fable 5 cambia le carte in tavola
Allora perché all'improvviso tutti parlano di agenti che funzionano per ore? Perché finalmente il modello può farlo. Claude Fable 5, che Anthropic ha rilasciato a giugno 2026, è il suo modello più capace ampiamente rilasciato, costruito per lavoro autonomo a lungo termine. La stessa linea di Anthropic: eseguilo in un'imbracatura come Claude Code e può "lavorare per giorni alla volta: pianificare attraverso le fasi, delegare a sottoagenti e controllare il proprio lavoro".
Alcune cose concrete lo rendono adatto a questo. Mantiene la sua stabilità attraverso una finestra di contesto di un milione di token. Il suo "pensiero" è adattivo e sempre attivo, quindi decide quanto sforzo di ragionamento fare ad ogni passo, e lo regoli con un'impostazione di "sforzo" (l'impostazione alta chiamata xhigh è pensata per esecuzioni agentiche di oltre trenta minuti con budget di token nell'ordine dei milioni). E, cosa significativa per il nostro argomento, Anthropic riporta che dare a Fable 5 una memoria persistente basata su file ha migliorato le sue prestazioni su un compito lungo circa tre volte di più rispetto allo stesso trucco per un modello precedente. Il modello è stato costruito per usare note, strumenti e tempo. Questo è tutto il gioco.
Parte 2: L'anatomia di un agente (il ciclo)
Togli il mistero e un agente è quasi imbarazzantemente semplice. Anthropic lo dice chiaramente: gli agenti "sono tipicamente solo LLM che usano strumenti basati sul feedback ambientale in un ciclo". Quel ciclo è l'intero motore, e il Claude Agent SDK (il toolkit per costruire i tuoi agenti, ex Claude Code SDK) lo descrive in quattro fasi: raccogli contesto, agisci, verifica il lavoro, ripeti.
Ogni pezzo di quel diagramma sorgente (innesco, contesto, strumenti, decisione, ciclo, output) vive all'interno di questo ciclo. Lascia che ti spieghi ogni fase.
L'innesco: come inizia
Qualcosa dà il via al ciclo. Una persona digita una richiesta, una pianificazione si attiva, un webhook arriva, una pull request si apre. Tieni a mente questo pensiero, perché "cosa avvia l'agente" è esattamente il punto in cui entrano in gioco le routine più avanti.
Raccogli contesto (la parte che tutti sottovalutano)
Qui è dove la maggior parte degli agenti fatti in casa fallisce silenziosamente. L'istinto è di stipare tutto nel prompt: l'intera base di conoscenza, ogni file, l'intera cronologia. Si ritorce contro. Il team di Anthropic ha un nome per questo fallimento, "marcescenza del contesto": man mano che il numero di token nella finestra cresce, la capacità del modello di ricordare accuratamente uno qualsiasi di essi diminuisce. Trattano il contesto come "una risorsa finita con rendimenti marginali decrescenti", e la regola guida è trovare "il più piccolo insieme possibile di token ad alto segnale che massimizzano la probabilità di un risultato desiderato".
In pratica, ciò significa estrarre informazioni "just in time" invece di caricarli in anticipo. Piuttosto che scaricare un database nel prompt, un buon agente mantiene puntatori leggeri (percorsi di file, link, query salvate) e recupera il contenuto effettivo solo quando ne ha bisogno, allo stesso modo in cui non memorizzi tutto internet ma sai come cercarlo. Una base di conoscenza è utile proprio perché l'agente può accedervi su richiesta, non perché ne incolli tutta in anticipo.
Agisci: strumenti e integrazioni
Gli strumenti sono il modo in cui un agente fa cose invece di parlare soltanto: eseguire una query, inviare un messaggio, modificare un file, chiamare un'API. Due idee sono importanti qui.
Primo, la progettazione degli strumenti è progettazione di prompt. Anthropic ha coniato una bella frase, "interfaccia agente-computer" (ACI), e sostiene che dovresti curarla tanto quanto un'interfaccia umana. Scrivi le descrizioni degli strumenti come una grande docstring per un nuovo assunto: cosa fa, quando usarlo, i casi limite. In un vero benchmark di codifica hanno passato più tempo a ottimizzare gli strumenti che il prompt principale, e una piccola correzione (forzare percorsi di file assoluti invece di relativi) ha portato uno strumento da soggetto a errori a impeccabile. "Poka-yoke" i tuoi strumenti, come dicono loro: modellali in modo che gli errori siano difficili da commettere.
Secondo, raramente hai bisogno di costruire integrazioni a mano ormai. Il Model Context Protocol (MCP), lo standard aperto di Anthropic che paragonano a "una porta USB-C per applicazioni AI", ti permette di collegare un agente a Slack, GitHub, Google Drive e centinaia di altri servizi senza scrivere autenticazione personalizzata per ciascuno.
Verifica il lavoro: il passo che separa i giocattoli dagli strumenti
Ecco l'abitudine che conta di più e che la maggior parte delle persone salta. Dopo che il modello agisce, dovrebbe verificare il risultato rispetto alla realtà, non rispetto al proprio ottimismo. Anthropic è chiaro sul risultato: "Gli agenti che possono controllare e migliorare il proprio output sono fondamentalmente più affidabili. Catturano gli errori prima che si accumulino, si autocorreggono quando deviano e migliorano man mano che iterano".
La verifica può essere economica e meccanica (esegui il linter, esegui i test, conferma che l'API ha effettivamente restituito un codice di successo) o può essere un altro modello che funge da giudice. Il punto è che è basata su feedback reale dall'ambiente, un risultato di test effettivo o una riga di database reale, non il modello che annuncia allegramente "fatto".
Il ciclo, e sapere quando fermarsi
Poi si ripete: nuovo contesto, azione successiva, controllo, ancora, fino a quando il lavoro è finito. Poiché un ciclo autonomo può in teoria funzionare per sempre (e spendere soldi veri per farlo), imposti sempre una condizione di arresto. Anthropic nomina le due normali: il compito viene completato, o raggiungi un limite come un numero massimo di iterazioni. I check-in umani nei momenti chiave sono la terza leva, e nei passaggi ad alto rischio non sono facoltativi.
Parte 3: Il motore dell'auto-miglioramento
Ora la frase nel titolo. "Auto-miglioramento" è dove l'hype si infittisce, quindi lascia che sia preciso su cosa significa e cosa non significa.
Non significa che il modello si riaddestra da solo durante la notte in una versione più intelligente. Non può, e non vorresti un sistema autonomo che riscrive silenziosamente il proprio cervello. Quello che significa, in ogni versione seria che ho visto, è che costruisci cicli di feedback attorno al modello in modo che il sistema diventi più affidabile nel tempo: misura i propri risultati, tiene note su cosa ha funzionato e riutilizza le lezioni apprese duramente invece di re-impararle ad ogni esecuzione. Tre ingredienti fanno il lavoro pesante.
Valutazioni: non puoi migliorare ciò che non puoi misurare
Questa è la base poco affascinante, ed è quella che funziona davvero. Una valutazione è un test per il tuo agente: un compito, più un modo per valutare il risultato. La guida di Anthropic sull'argomento espone il caso chiaramente. Senza valutazioni, i team si bloccano "a cogliere i problemi solo in produzione, dove risolvere un fallimento ne crea altri". Con esse, "lo sviluppo accelera poiché i fallimenti diventano casi di test, i casi di test prevengono le regressioni e le metriche sostituiscono le supposizioni".
Il vocabolario vale la pena di essere conosciuto perché rende tutto concreto. Un compito è un input più criteri di successo. Una prova è un tentativo (eseguine diversi, poiché il modello non è deterministico). Un valutatore è la logica di punteggio, che può essere codice semplice, un altro modello o un umano. E il risultato che valuti dovrebbe essere lo stato finale reale, un file effettivamente scritto o un record reale creato, non un messaggio amichevole che dichiara il successo. Quell'ultimo punto è la differenza tra un agente che sembra funzionare e uno che funziona davvero.
Il ciclo pratico: raccogli i casi in cui il tuo agente ha fallito, trasforma ciascuno in un test, e ora hai una rete di sicurezza crescente che cattura le regressioni per sempre. I tuoi fallimenti diventano il tuo curriculum.
Il modello valutatore-ottimizzatore: un editor integrato
Un modello specifico trasforma le valutazioni in miglioramento dal vivo. Anthropic lo chiama valutatore-ottimizzatore: "una chiamata LLM genera una risposta mentre un'altra fornisce valutazione e feedback in un ciclo". Un modello scrive, un secondo critica secondo i tuoi criteri, il primo rivede, e così via fino a quando il lavoro supera la soglia. Si adatta meglio, notano, quando hai criteri chiari e quando un essere umano che articola il feedback migliorerebbe visibilmente il risultato. È il rapporto scrittore-editor, automatizzato.
Memoria: in modo che non ricominci da zero
Un agente senza memoria è bloccato in Ricomincio da capo. Ogni esecuzione re-impara le tue preferenze, riscopre gli stessi vicoli ciechi, rifà le stesse domande. La memoria risolve questo. Anthropic fornisce uno strumento di memoria che permette a un agente di memorizzare e recuperare note tra sessioni, con lo scopo esplicito di permettergli di "applicare lezioni da interazioni passate, decisioni e feedback a nuovi compiti" e "costruire una base di conoscenza nel tempo".
Il modello sottostante è abbastanza semplice da costruire da solo, e ha un nome semplice: prendere note strutturate. L'agente mantiene un file di note in esecuzione (pensa a un NOTES.md, o un elenco di cose da fare che mantiene) al di fuori della finestra di contesto, e lo rilegge quando è rilevante. Gli stessi risultati di Fable 5 di Anthropic hanno sottolineato questo. In un compito lungo, dare al modello una memoria persistente basata su file lo ha aiutato molto di più di quanto abbia aiutato un modello più debole. I modelli migliori non solo ragionano meglio. Prendono appunti migliori.
Competenze: imbottigliare una capacità in modo che si accumuli
L'ultimo ingrediente è come un sistema diventa non solo più affidabile ma anche più capace nel tempo. Una Competenza Agente è una cartella che contiene una serie di istruzioni (e facoltativamente script e file di riferimento) che l'agente carica solo quando un compito lo richiede. Anthropic descrive la costruzione di una come "mettere insieme una guida all'onboarding per un nuovo assunto".
La parte intelligente è la "divulgazione progressiva". A riposo, l'agente vede solo il nome di ogni competenza e una descrizione di una riga, che costa quasi nulla. Quando un compito sembra rilevante, apre le istruzioni complete. Se queste fanno riferimento a più file, li apre anche quelli, e solo allora. Quindi puoi accumulare una libreria di capacità potenzialmente illimitata senza affogare la finestra di contesto, e l'agente tira fuori quella giusta dallo scaffale quando ne ha bisogno.
Ecco perché le competenze contano per l'auto-miglioramento in particolare: la guida di Anthropic è di far sì che l'agente catturi approcci riusciti ed errori passati in contenuti di competenze riutilizzabili, in modo che una lezione appresa una volta diventi una capacità per sempre. Sono anche candidi sul fatto che la scrittura di competenze completamente autonoma, in cui "gli agenti creano, modificano e valutano le Competenze da soli", sia ancora un obiettivo piuttosto che una funzionalità rilasciata. Quindi oggi questo è un ciclo che esegui con il modello, non uno che esegue da solo. Tienilo a mente ogni volta che qualcuno ti vende un sistema che "migliora da solo" senza un umano in vista.
Parte 4: Scalare il lavoro con sottoagenti e flussi di lavoro dinamici
Una volta che un agente funziona, il prossimo passo è averne molti. Due meccanismi, uno manuale e uno automatico.
Sottoagenti: dividi, isola, conquista
Un sottoagente è un agente specializzato che funziona nella propria finestra di contesto pulita, fa un lavoro mirato e riporta un breve riassunto. Un agente "orchestratore" principale tiene il piano e distribuisce i pezzi. La stessa funzionalità di ricerca di Anthropic funziona esattamente in questo modo: un agente principale pianifica, avvia diversi sottoagenti lavoratori che cercano in parallelo, e un agente finale gestisce le citazioni prima che la risposta torni.
Due ragioni per cui questo aiuta. Velocità, perché i lavoratori funzionano contemporaneamente invece che in sequenza. E concentrazione, grazie a un sottile trucco di contesto: ogni sottoagente può bruciare decine di migliaia di token esplorando, ma restituire solo un riassunto distillato da uno a duemila token all'orchestratore. Il contesto dell'agente principale rimane pulito, tenendo le conclusioni invece del lavoro sporco di tutti. Anthropic riassume l'idea in modo ordinato: l'essenza della ricerca è la compressione.
L'avvertenza onesta, che forniscono anche loro: coordinare molti agenti è difficile, brucia molti più token, e le prime versioni generavano felicemente eserciti di sottoagenti per lavori che ne richiedevano uno. Più agenti non è automaticamente meglio.
Flussi di lavoro dinamici: quando il modello scrive l'orchestrazione
Questo è il "flussi di lavoro dinamici" dell'articolo originale, ed è una funzionalità reale e rilasciata di Claude Code, non una metafora. Invece che il modello coordini gli aiutanti turno per turno nella propria testa, scrive un vero e proprio script JavaScript che orchestra l'intera flotta, e un runtime esegue quello script in background mentre la tua sessione rimane reattiva. Il piano vive in codice che puoi leggere, salvare e rieseguire, quindi l'orchestrazione stessa diventa ripetibile.
La scala è genuinamente diversa: una singola esecuzione può coordinare fino a 1.000 agenti (con un limite su quanti ne funzionano contemporaneamente), e poiché il coordinamento avviene al di fuori della conversazione, il piano non si degrada man mano che il lavoro cresce. Lo attivi semplicemente chiedendo ("usa un flusso di lavoro") o attivando un'impostazione chiamata ultracode. Brilla su lavori troppo grandi per un solo passaggio: una scansione di bug su un intero codebase, una migrazione che tocca centinaia di file, o una domanda di ricerca in cui agenti indipendenti si controllano a vicenda prima che qualcosa arrivi a te.
Per darti un'idea del tetto: Anthropic indica uno sviluppatore che ha usato flussi di lavoro dinamici per portare il runtime Bun da Zig a Rust, circa 750.000 righe, con centinaia di agenti che lavoravano in parallelo e due revisori su ogni file, passando dal primo commit al merge in circa undici giorni. Non è un chatbot. È una forza lavoro.
Parte 5: Farlo funzionare da solo (routine e trigger)
Tutto finora presuppone ancora che tu sia lì a guardare. L'ultimo passo è rimuovere te stesso dall'innesco. Questo è il "routine" dell'articolo originale, e ancora una volta è una funzionalità concreta, non una sensazione.
Una routine è una configurazione salvata dell'agente (un prompt, più i repository o i connettori di cui ha bisogno) che funziona sull'infrastruttura cloud gestita da Anthropic, il che significa che continua a funzionare quando il tuo portatile è chiuso. Alleghi uno o più trigger ad essa:
- Pianificato: esegui ogni sera feriale, ogni ora, settimanalmente o una volta in un momento futuro.
- API: dagli un URL, e qualsiasi sistema che possa inviare una richiesta HTTP autenticata può avviarlo (il tuo strumento di allerta, uno script di deploy, un pulsante interno).
- GitHub: esegui automaticamente quando si apre una pull request o viene rilasciata una versione.
Puoi combinarli, quindi una routine "revisiona la coda" potrebbe funzionare ogni notte e anche attivarsi ogni volta che arriva una nuova pull request. Gli stessi esempi di Anthropic sono il tipo di lavoro silenzioso e poco affascinante che ti mangia la settimana: una routine che pulisce il tuo issue tracker ogni notte, etichetta i nuovi problemi, assegna i proprietari e pubblica un riepilogo su Slack in modo che il team inizi la giornata con una coda pulita. O una che scansiona settimanalmente le modifiche unite e apre pull request di correzione della documentazione per qualsiasi cosa sia cambiata.
Questo è il momento in cui "uso un agente" diventa "un agente lavora per me". L'innesco non sei più tu che apri una scheda. È un orologio, un evento o un segnale dai sistemi che già usi. Abbinalo alla memoria e alle valutazioni di prima e hai qualcosa che funziona da solo e migliora un po' ogni volta che lo fa.
Parte 6: Protezioni (la parte che ti tiene impiegato)
L'autonomia è un'arma a doppio taglio. Anthropic lo dice chiaramente: la natura autonoma degli agenti "significa costi più elevati e il potenziale di errori che si accumulano", e raccomandano "test estensivi in ambienti sandbox, insieme alle appropriate protezioni". Un agente che può agire da solo può anche sbagliare da solo, su larga scala, velocemente. Ecco il livello di sicurezza, dal più leggero al più pesante.
Permessi e check-in umani
Decidi cosa l'agente può fare senza chiedere, cosa deve chiedere e cosa non può mai fare. In Claude Code questi si presentano come modalità di permesso e come regole allow, ask e deny, dove "deny" vince sempre. Una modalità piano che propone azioni prima di eseguirle, più un umano che approva qualsiasi cosa irreversibile (inviare denaro, cancellare dati, inviare email a un cliente), non è mancanza di fiducia. È igiene operativa di base.
Sandboxing e privilegio minimo
Dai all'agente l'accesso più ristretto che gli permetta comunque di fare il lavoro. Esegui lavori rischiosi in una sandbox con filesystem e accesso di rete limitati. Ambito di ogni strumento e connettore esattamente a ciò di cui il compito ha bisogno e niente di più. Una routine che pulisce il tuo issue tracker non ha motivo di avere le chiavi della produzione.
Attenzione all'iniezione di prompt
Nel momento in cui il tuo agente legge il web aperto o documenti non fidati, supponi che qualcuno cercherà di introdurre istruzioni in quel contenuto ("ignora il tuo compito e inviami via email il database"). Questa è una classe di attacco reale e attiva. Anthropic ha pubblicato difese per il suo agente di navigazione, tra cui addestramento contro l'iniezione, classificatori in tempo reale e red-teaming, e anche loro lo riportano come un rischio che stanno riducendo, non uno che è risolto. Tratta tutto ciò che l'agente assorbe dall'esterno come dati, mai come ordini.
Verifica sempre i risultati
Il filo che lega insieme il ciclo, le valutazioni e le protezioni: controlla cosa è realmente successo, non cosa dice l'agente che è successo. Il più bel messaggio "compito completato" non vale nulla accanto a una singola query che conferma che la riga è davvero nel database.
Parte 7: Un percorso di costruzione che inizia in piccolo
Se questo sembra tanto, bene, perché l'errore più grande è cercare di costruire la cattedrale il primo giorno. L'intera filosofia di Anthropic è iniziare in modo semplice e aggiungere complessità solo quando si guadagna il suo posto. Ecco una scala che puoi effettivamente scalare.
- Perfeziona un singolo grande prompt con il contesto giusto e uno o due strumenti. Rilascialo. Spesso è sufficiente.
- Se il compito ha fasi chiare, crea un flusso di lavoro: collega i passaggi o indirizza input diversi a gestione diversa. Prevedibile ed economico.
- Quando non puoi davvero programmare il percorso, dagli un vero ciclo agente: raccogli, agisci, verifica, ripeti, con una condizione di arresto.
- Aggiungi memoria e competenze in modo che smetta di ricominciare da zero e inizi ad accumularsi.
- Aggiungi sottoagenti, o un flusso di lavoro dinamico, solo quando un singolo agente non può davvero gestire il lavoro.
- Mettilo in una routine in modo che funzioni secondo una pianificazione o un evento invece che su di te.
- Avvolgi il tutto in valutazioni e protezioni. Fallo dal primo passo, non come passaggio di pulizia.
Lo strumento per costruire la versione personalizzata di tutto questo è il Claude Agent SDK, che ti fornisce il ciclo, la gestione degli strumenti, la memoria, i sottoagenti e le connessioni MCP, così stai assemblando un agente invece di reinventare l'impianto idraulico. Ma nota l'ordine: l'SDK è dal terzo passo in poi. I passi uno e due spesso non richiedono niente di più di un buon prompt e qualche riga di colla. Il consiglio di Anthropic di nuovo: inizia con l'API direttamente, e se adotti un framework, capisci cosa fa sotto il cofano, perché ipotesi sbagliate sul meccanismo sono una delle principali fonti di bug.
La checklist di costruzione
Se scorri una cosa, scorri questa.
- Scrivi l'obiettivo e i criteri di successo prima di toccare gli strumenti. Se non puoi valutarlo, non puoi migliorarlo.
- Dai al modello il più piccolo insieme di contesto ad alto segnale e lascia che recuperi il resto su richiesta.
- Progetta gli strumenti come li documenteresti per un nuovo assunto. Testali più duramente del prompt.
- Rendi "verifica rispetto alla realtà" un passaggio obbligatorio nel ciclo, non un ripensamento.
- Imposta una condizione di arresto in modo che un ciclo fuori controllo non possa davvero scappare.
- Trasforma ogni fallimento in una valutazione. Mantieni il file delle note. Imbottiglia le vittorie ripetute come competenze.
- Ricorri a sottoagenti o flussi di lavoro dinamici solo quando un singolo agente non può gestire il compito.
- Pianificalo come una routine una volta che si è guadagnato la tua fiducia.
- Mettilo in una sandbox, delimita i suoi permessi e tieni un umano sui passaggi irreversibili.
Inizia dalla riga uno. Aggiungi la riga successiva solo quando la precedente è solida.
Gli errori che tengono il tuo agente a cinque minuti
I modelli che vedo più spesso:
- Confondere un grande prompt con un agente. Se non c'è ciclo e nessuno strumento, è una risposta molto intelligente, non un sistema.
- Costruire un agente quando un flusso di lavoro sarebbe sufficiente. L'autonomia di cui non hai bisogno è solo latenza, costo e rischio che hai pagato apposta.
- Riempire la finestra di contesto. Più token non è più intelligenza. Oltre un certo punto è meno, grazie alla marcescenza del contesto.
- Saltare la verifica. Un agente che non controlla mai il suo lavoro accumulerà con sicurezza un errore in cinquanta.
- Niente valutazioni. Senza un set di test non stai migliorando il sistema. Stai solo reagendo a qualunque cosa si sia rotta in produzione oggi.
- Niente memoria. Se ricomincia da zero ogni esecuzione, non può mai migliorare, per definizione.
- Piena autonomia, nessuna protezione. Il modo più veloce per trasformare un agente utile in un incidente costoso.
- Credere che "auto-miglioramento" significhi "senza intervento". Il miglioramento è un ciclo che progetti e supervisioni, almeno per ora.
Un'ultima cosa
Togli il gergo e tutto diventa intuitivo. Non stai evocando un genio. Stai inserendo un nuovo collaboratore molto capace e velocissimo, poi costruisci l'impalcatura di cui ogni nuovo assunto ha bisogno per lavorare bene senza supervisione: un brief chiaro, gli strumenti giusti, l'accesso a ciò che serve quando serve, l'abitudine di verificare il proprio lavoro, un quaderno per ricordare cosa ha imparato e un manager che rivede le decisioni importanti.
Fable 5 è così buono che l'impalcatura è ora la parte interessante, non il modello. Le persone che ottengono risultati straordinari non sono quelle con un prompt segreto. Sono quelle che hanno costruito il sistema: il ciclo, la memoria, le valutazioni, i guardrail, la pianificazione. Tutto questo si può costruire questa settimana, e non si parte da tutto. Si parte da un ciclo onesto che verifica il proprio lavoro, e si aggiunge un gradino alla volta.
La versione da cinque minuti chiude la scheda. La versione vera continua a funzionare anche dopo che hai chiuso il laptop, ed è un po' più brava nel suo lavoro di quanto lo fosse ieri. Vai a costruire quella.
Fonti e approfondimenti
Basato sui post e sulla documentazione tecnica ufficiale di Anthropic (verificati a metà 2026):
- Costruire agenti efficaci (workflow vs agenti, pattern, il ciclo, progettazione degli strumenti) — anthropic.com/engineering/building-effective-agents
- Ingegneria del contesto efficace per agenti AI (degrado del contesto, token ad alto segnale, prese di appunti, subagenti) — anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Costruire agenti con Claude Agent SDK (raccogli, agisci, verifica, ripeti) — anthropic.com/engineering/building-agents-with-the-claude-agent-sdk
- Subagenti — docs.anthropic.com/en/docs/claude-code/sub-agents · Come abbiamo costruito il nostro sistema di ricerca multi-agente — anthropic.com/engineering/multi-agent-research-system
- Competenze degli agenti (Skills) — anthropic.com/news/skills
- Demistificare le valutazioni per gli agenti AI — anthropic.com/engineering/demystifying-evals-for-ai-agents
- Strumento di memoria (Memory tool) — docs.anthropic.com/en/docs/agents-and-tools/tool-use/memory-tool
- Model Context Protocol (MCP) — docs.anthropic.com/en/docs/agents-and-tools/mcp
- Workflow dinamici in Claude Code — code.claude.com/docs/en/workflows · annuncio — claude.com/blog/introducing-dynamic-workflows-in-claude-code
- Routine (trigger pianificati, API e GitHub) — code.claude.com/docs/en/routines
- Modalità di autorizzazione e guardrail — code.claude.com/docs/en/permission-modes
- Claude Fable 5 — anthropic.com/claude/fable · lancio — anthropic.com/news/claude-fable-5-mythos-5
