Il 29 settembre Anthropic ha rilasciato tre cose nello stesso giorno: Claude Sonnet 4.5, Claude Code 2.0 e quello che fino a pochi giorni prima si chiamava Claude Code SDK e ora si chiama Claude Agent SDK. Sembra un dettaglio da changelog, quel rename. Secondo me è il segnale più importante dei tre, e provo a spiegare perché dal punto di vista di chi, come me, ha smesso di guardare gli agenti come una curiosità e ha cominciato a costruirseli per lavorare.
Lo dico subito, senza giri: un SDK che perde la parola “Code” dal nome sta dicendo che il tool non serve più solo a scrivere codice. È un riposizionamento, non un ritocco di marketing. E dietro c’è una cosa più grossa: si sta abbassando il costo di trasformare un’idea in qualcosa che gira. Non il costo di scrivere codice. Il costo di provare.
Perché il rename da “Claude Code SDK” ad “Agent SDK” conta
Nella pratica quotidiana Claude Code lo usavo già come un agente, non come un autocompletamento intelligente. Gli davo un obiettivo, gli lasciavo leggere una cartella, gli facevo eseguire comandi, gli facevo verificare il risultato. La parte “coding” era solo il dominio in cui giravano quei loop: leggi, ragiona, agisci, controlla, correggi. Ma quel loop è agnostico rispetto al dominio.
Il rename ufficializza questo. Il valore dell’Agent SDK non è che scrive Python meglio di ieri. È l’infrastruttura del loop agentico, cioè gestione del contesto, uso dei tool, permessi e verifica, resa riutilizzabile fuori dal codice. Anthropic stessa, nel comunicato, descrive lo stesso motore che alimenta Claude Code come la base per costruire agenti generici. Tradotto per chi lavora come me nell’ecosistema Adobe: posso pensare a un agente che non tocca un repository ma interroga un catalogo, prepara una configurazione, redige una nota tecnica.
Qui mi tocca dire una cosa impopolare tra i colleghi sviluppatori. Lo sviluppatore che continua a liquidare questi strumenti come giocattoli inaffidabili, secondo me, sta guardando dal lato sbagliato. Non perché l’AI sia magica: perché uno sviluppatore che ha chiare l’idea, i processi e i metodi, con un agente fa in una frazione del tempo quello che faceva prima. Il se non è una clausola di salvaguardia, è tutta la tesi. Senza idee chiare e senza metodo, lo stesso strumento produce un disastro veloce e ben formattato.
Sonnet 4.5: il modello che regge il compito lungo
Un agente vale quanto il modello che lo guida sui compiti lunghi. È lì che gli assistenti crollavano: dopo qualche passaggio perdevano il filo, dimenticavano il vincolo iniziale, ripetevano un errore già corretto.
Sonnet 4.5 è presentato da Anthropic come il loro modello migliore proprio su coding e task agentici, con particolare attenzione ai lavori a orizzonte lungo, quelli che richiedono di tenere insieme molti passaggi senza deragliare. Per costruirsi agenti la variabile critica non è quanto un modello è brillante su una singola risposta, ma quanto rimane coerente su una catena di venti azioni. Un agente che a metà strada dimentica il vincolo di partenza è peggio di nessun agente, perché ti fa perdere tempo a fidarti e poi a verificare.
Non ho numeri miei da mostrare, sono all’inizio con questa versione, e non ho intenzione di riportare percentuali che non ho misurato io. La direzione mi convince. La provo su cose vere, e poi ne riparliamo.
Claude Code 2.0: checkpoint ed estensione VS Code
Due novità di Claude Code 2.0 mi interessano più delle altre perché toccano il punto dolente di chi costruisce agenti: la fiducia.
La prima sono i checkpoint. L’agente salva lo stato prima di agire e posso tornare indietro se una direzione non mi piace. Sembra banale, non lo è. Il motivo per cui molti non lasciano lavorare un agente in autonomia è la paura del danno irreversibile: tocca il file sbagliato, esegue il comando sbagliato, e non torni indietro. Il checkpoint trasforma l’autonomia da scommessa a esperimento reversibile, ed è esattamente la condizione che serve per lasciare più corda a un agente senza stare col fiato sospeso.
La seconda è l’estensione per VS Code. Portare l’agente dentro l’editor, con una vista integrata invece del solo terminale, non è una comodità estetica: abbassa la barriera d’ingresso. Chi lavora tutto il giorno in un IDE non deve cambiare contesto per delegare un pezzo di lavoro. E abbassare la barriera è ciò che fa passare uno strumento dal “lo provo il weekend” al “ci lavoro il lunedì”.
Un esempio dal campo, anonimizzato. Su un progetto Adobe Commerce per un merchant fashion mid-market mi capita spesso una classe di attività ripetitive e a basso rischio: rileggere una configurazione, incrociarla con una checklist, produrre una bozza di nota per il cliente. È il tipo di lavoro perfetto per un agente su misura, cioè noioso, procedurale, verificabile. Con i checkpoint mi sento di lasciarglielo fare davvero, perché so che ogni passo è reversibile.
Il tentativo che non ha funzionato
Visto che ho appena scritto due paragrafi entusiasti, tocca mettere sul tavolo anche l’altra metà. Qualche settimana fa ho provato a costruire un agente che, partendo dall’export di un catalogo, proponesse una normalizzazione degli attributi. Sulla carta il caso d’uso ideale: procedurale, ripetitivo, misurabile.
Non ha funzionato. Non perché il modello fosse scarso, ma perché il catalogo di partenza era un pantano: attributi che significavano cose diverse a seconda della categoria, valori duplicati con grafie diverse, regole di prezzo che si contraddicevano. L’agente ha prodotto proposte perfettamente coerenti con la sua lettura dei dati, e sbagliate rispetto alla realtà del business. La parte peggiore è che erano proposte convincenti: per accorgersi che erano sbagliate bisognava già conoscere la risposta giusta.
La lezione me la porto dietro, ed è la ragione per cui diffido di chi promette agenti che “sistemano i dati”. Sui dati sporchi l’agente non fa ordine, fa disordine più in fretta. Il lavoro noioso a monte, catalogo, attributi, prezzi, integrazioni, resta la precondizione. Non c’è modello che te lo tolga.
MCP Registry: il pezzo che mancava per i connettori
Un agente isolato dai sistemi reali è un giocattolo. Il ponte verso i sistemi è il Model Context Protocol (MCP), lo standard con cui un agente parla con tool e sorgenti dati. Il problema, fino a poco fa, era trovare i connettori: server MCP sparsi, senza un posto ufficiale dove cercarli.
L’8 settembre è arrivato l’MCP Registry, per ora in preview: un catalogo aperto dei server MCP disponibili. Il Registry è al MCP ciò che un package manager è alle librerie, cioè rende scopribile quello che prima si trovava solo a passaparola. Non è ancora maturo, è una preview e va trattata come tale, ma la logica è quella giusta.
Per il mio contesto significa una cosa concreta: quando provo a costruire un agente per il lavoro Adobe, la domanda non è più solo “so scrivere il connettore?” ma “esiste già un connettore per il sistema che devo toccare?”. Sto scrivendo qualche server MCP mio, ma sono prototipi da banco di prova, non strumenti che metterei in mano a un cliente. È esattamente questo il tipo di cosa che prima non facevo affatto: non è che vada più veloce, è che è un perimetro nuovo.
La mia lettura, da chi inizia a costruirsi agenti
Metto insieme i pezzi. Sonnet 4.5 tiene il compito lungo. L’Agent SDK porta il loop agentico fuori dal codice. Claude Code 2.0 rende l’autonomia reversibile e la mette a portata di IDE, mentre il MCP Registry serve a trovare i connettori senza dover chiedere in giro. Sono quattro tessere che, guardate insieme, dicono una cosa sola: costruirsi un agente su misura sta diventando un lavoro da practitioner, non da laboratorio di ricerca.
Resto cauto su una cosa, e la dico perché sarebbe disonesto tacerla. La preview del Registry, il modello nuovo da mettere alla prova, l’autonomia che ancora richiede supervisione: niente di tutto questo è “pronto e via”. La differenza tra una demo che gira e un agente che uso su un cliente vero è tutta nella verifica, nei permessi, nei limiti che gli metto io. Gli strumenti abbassano la barriera; non sostituiscono il giudizio di chi li usa. Anzi, lo rendono più prezioso: il collo di bottiglia si sposta sul sapere cosa vale la pena costruire.
Il mio piano è semplice: partire dai compiti ripetitivi e a basso rischio, quelli dove l’errore costa poco e il tempo risparmiato è tangibile. Costruire lì i primi agenti, misurare, e solo dopo alzare l’asticella. È il modo in cui ho sempre adottato tecnologia Adobe, e non vedo perché con gli agenti dovrei cambiare metodo.
Mini-FAQ
Cos’è il Claude Agent SDK?
È l’SDK, prima chiamato Claude Code SDK e rinominato il 29 settembre 2025, che espone lo stesso motore agentico di Claude Code per costruire agenti su misura anche fuori dal dominio del codice: gestione del contesto, uso dei tool, permessi e verifica.
Perché il rename da Claude Code SDK ad Agent SDK è importante?
Perché segnala che lo strumento non serve più solo a scrivere codice: il loop agentico diventa riutilizzabile in domini diversi, dal supporto tecnico alla preparazione di configurazioni e documenti.
Cosa sono i checkpoint di Claude Code 2.0?
Sono salvataggi di stato che permettono di tornare indietro se una direzione dell’agente non convince. Rendono l’autonomia reversibile e quindi più facile da concedere.
A cosa serve il MCP Registry?
È un catalogo aperto, in preview dall’8 settembre 2025, dei server MCP disponibili. Serve a trovare i connettori con cui un agente si collega a tool e sorgenti dati, senza cercarli a passaparola.
Chi scrive. Sono Fabio Canovi, consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Da un po’ approfondisco l’AI agentica e l’ecosistema Claude, e sto cominciando a costruirmi agenti su misura per il lavoro quotidiano nell’ecosistema Adobe.