Il 29 settembre 2025 Anthropic ha fatto due cose contemporaneamente: ha presentato Claude Sonnet 4.5 e ha aperto in libreria l’infrastruttura che fa funzionare Claude Code. Da quel momento il Claude Agent SDK aziende è diventato un tema concreto anche fuori dalla Silicon Valley: non più “come uso un chatbot”, ma “come costruisco un software che agisce”. La distanza tra le due domande è enorme, e in Italia quella distanza ha un nome preciso: mancano le persone in casa per coprirla.
A un anno di distanza il quadro è cambiato meno di quanto ci si aspetterebbe sul lato libreria — l’SDK è ancora la stessa cosa, con le stesse quattro alternative — e molto di più sul lato prodotto: Anthropic ha iniziato a costruire verticali già pronti sopra la propria infrastruttura, e questo aggiunge una domanda da farsi prima di scrivere codice. Questo articolo spiega cos’è l’Agent SDK in termini utili a chi decide, cosa permette di costruire davvero, dove i progetti si rompono e come si struttura un percorso con un partner di sviluppo quando il team interno non c’è o è già saturo.
In questo articolo scoprirai:
- Cos’è il Claude Agent SDK e perché non è “un’altra API”
- Gestione del contesto e indipendenza dal modello
- Cosa si costruisce concretamente: il caso BGL
- Perché il Claude Agent SDK nelle aziende italiane resta sulla carta
- I quattro punti dove il progetto si rompe
- Quanto costa un agente Claude Agent SDK (e perché l’abbonamento non basta)
- Prima di costruire, controllate se il verticale esiste già
- Claude Agent SDK per le aziende: come lavoriamo in Mimir
- Quando serve un partner e quando basta il team interno
Cos’è il Claude Agent SDK e perché non è “un’altra API”
La documentazione ufficiale è netta: «L’Agent SDK mette a disposizione gli stessi tool, il ciclo agentico e la gestione del contesto che alimentano Claude Code, programmabili in Python e TypeScript» (Claude Docs). Tradotto: non è un modello linguistico esposto via HTTP, è il motore agentico completo, disponibile come libreria che gira nel vostro processo.
La differenza operativa è sostanziale. L’API classica di Claude è un’interfaccia richiesta-risposta: mandi un messaggio, ricevi un testo, e il ciclo di chiamata degli strumenti lo implementi tu. L’Agent SDK esegue quel ciclo al posto vostro: riceve un obiettivo, decide quali azioni compiere, le esegue con strumenti integrati e decide quando il compito è finito (MindStudio). Se conoscete già le basi del modello, la nostra guida completa a Claude AI copre il livello sottostante.
Le capacità che l’Agent SDK porta out of the box
Nel pacchetto ci sono strumenti nativi per leggere e scrivere file, eseguire comandi e cercare sul web; hooks per inserire codice custom nei punti chiave del ciclo di vita; subagent con contesto isolato; permessi granulari su quali tool girano in automatico e quali richiedono approvazione; sessioni che si possono riprendere o biforcare; e il supporto MCP per collegare dati e sistemi esterni, se il tema vi è nuovo, partite dalla nostra guida al Model Context Protocol. Nel frattempo la libreria ha assorbito altre due cose che prima stavano solo nel CLI: skill, comandi e memoria caricati automaticamente dalla cartella .claude/ del progetto, esattamente come fa Claude Code, e i plugin, che impacchettano skill, agenti, hook e server MCP in un’unica unità caricabile da percorso locale (Claude Docs). È un dettaglio che conta in azienda: la conoscenza di dominio diventa un artefatto versionabile e non una stringa dentro il codice.
Gestione del contesto e indipendenza dal modello
C’è poi la gestione del contesto, che è il vero lavoro sporco risparmiato: l’SDK compatta automaticamente la conversazione quando si avvicina ai limiti di token e rilegge i file di istruzioni dopo la compattazione. Chi ha provato a scriverselo da zero lo descrive senza giri di parole: «la differenza in quanto codice di collegamento devi scrivere è significativa» (ksred.com).
Sul fronte modello, il riferimento del lancio era Sonnet 4.5, con il 77,2% su SWE-bench Verified e il 61,4% su OSWorld (Anthropic); da allora la famiglia è ruotata più volte ed è arrivata alla generazione 5. La cosa importante, per chi deve decidere, è che l’SDK è indipendente dal modello: il codice dell’agente non si riscrive quando esce il modello nuovo, si cambia un identificativo — ed è per questo che i benchmark del mese non sono il criterio con cui si sceglie di partire.
Cosa si costruisce concretamente: il caso BGL
La domanda che conta non è tecnica ma economica: cosa produce valore misurabile. Il caso più documentato è quello di BGL, provider australiano di amministrazione fondi pensione che serve oltre 12.700 imprese in 15 Paesi (AWS Machine Learning Blog). Il problema era classico e italianissimo: gli utenti business non sapevano interrogare i dati e dipendevano dal team dati per ogni analisi, creando un collo di bottiglia permanente.
La soluzione costruita con l’Agent SDK non è un chatbot. È un agente che scrive ed esegue script Python per elaborare i risultati delle query e generare visualizzazioni, con la conoscenza di dominio organizzata in file CLAUDE.md e SKILL.md per linea di prodotto, appoggiato su 400+ tabelle analitiche già modellate e con un livello di sicurezza che valida solo query in sola lettura. Risultato: oltre 200 dipendenti accedono ad analisi istantanee da Slack, dai product manager che validano ipotesi ai customer success manager che tirano numeri di account durante una call col cliente (AWS Machine Learning Blog).
Tre lezioni trasferibili alla PMI italiana
Primo: il valore stava nella preparazione del dato, non nell’agente. La logica di business viveva nel layer di trasformazione, non nella finestra di contesto del modello, ed è questa la scelta che rende le risposte coerenti. Secondo: la sicurezza era architetturale (sessioni isolate, permessi in sola lettura), non una policy scritta in un documento. Terzo: l’interfaccia era uno strumento che le persone già usavano.
Sono le stesse tre lezioni che emergono quando si prova a mettere un agente sopra un gestionale esistente, tema che abbiamo trattato in integrare agenti AI con ERP e CRM legacy: la parte difficile non è mai il modello.
Perché il Claude Agent SDK nelle aziende italiane resta sulla carta
Qui arriva il dato che spiega tutto. Secondo il rapporto Istat Imprese e ICT, l’adozione di AI nelle imprese italiane con almeno 10 addetti è raddoppiata in un anno, dall’8,2% del 2024 al 16,4% del 2025 (era il 5% nel 2023). Ma la media nasconde una frattura netta: 53,1% nelle grandi imprese contro il 15,7% nelle PMI, con un divario passato da 25 a 37 punti percentuali in dodici mesi. E fra chi ha valutato l’AI senza poi adottarla, l’ostacolo più citato è la mancanza di competenze, indicata dal 58,6% delle imprese — davanti all’incertezza normativa (47,3%) e alla qualità dei dati (45,2%) (Istat, Imprese e ICT, anno 2025).
Il quadro strutturale conferma: se il 70,2% delle PMI italiane raggiunge almeno un livello base di digitalizzazione, il divario con le grandi imprese si concentra proprio nella carenza di specialisti ICT interni e nella formazione limitata sulla sicurezza informatica (dati Istat via Namirial). Non è un problema di volontà: un’azienda da 40 persone con un IT manager che tiene in piedi rete, gestionale e backup non ha, realisticamente, una persona da dedicare per tre mesi alla progettazione di un sistema agentico.
Quanti progetti Claude Agent SDK arrivano davvero in produzione
La conseguenza è prevedibile e Gartner l’ha quantificata: oltre il 40% dei progetti di AI agentica sarà cancellato entro fine 2027, per costi crescenti, valore di business non chiaro o controlli di rischio inadeguati. La causa individuata dall’analista Anushree Verma è che «la maggior parte dei progetti di AI agentici in questo momento sono esperimenti allo stadio iniziale o proof of concept guidati principalmente dall’hype», distribuiti senza strategia e senza governance per gestire gli errori (MarTech). Sul perché il problema quasi mai sia tecnologico, rimandiamo a se l’AI generativa non genera ROI.
I quattro punti dove il progetto si rompe
Skill gap. L’SDK è una libreria Python/TypeScript, non un prodotto no-code. Chi lo usa deve saper progettare i confini di un agente, scegliere quali tool esporre e quando isolare il contesto in un subagent. È lavoro di software engineering, con una sensibilità nuova sul non-determinismo.
Integrazione. Un agente utile deve leggere il vostro ERP, il CRM, il magazzino. MCP standardizza il collegamento, ma qualcuno deve scrivere e mantenere quei server e decidere quali dati escono dal perimetro aziendale. Le Skills di Anthropic aiutano a impacchettare la conoscenza di dominio, non a inventarla.
Sicurezza in produzione: sandbox, permessi ed errori silenziosi
Portare l’SDK in produzione richiede «sandboxing, restrizioni di rete e controlli sui permessi», oltre alla gestione di ciclo di vita dei processi e limiti di risorsa (MindStudio). C’è poi un dettaglio che genera bug silenziosi: se un tool custom non restituisce isError: true su un fallimento recuperabile, il ciclo si ferma e Claude non vede mai l’errore.
Manutenzione: un agente non è un progetto a scadenza
Il campo si muove ogni poche settimane: in poco più di un anno la libreria ha attraversato un’intera rotazione di modelli, da Opus 4.6 alla generazione successiva, e altrettanti cambi nella gestione dei permessi come la modalità Auto di Claude Code. Le sessioni create su versioni vecchie dell’SDK non sempre riprendono su versioni nuove: un agente è un sistema da presidiare, non un progetto che si chiude.
Quanto costa un agente Claude Agent SDK (e perché l’abbonamento non basta)
Sul fronte economico il rischio è banale ma costoso: max_turns è illimitato per default e max_budget_usd è opzionale, quindi «un agente in produzione senza limiti espliciti può girare per molti turni e accumulare costi senza un interruttore di sicurezza» (Augment Code). Sono i due parametri da fissare al primo giro, non al secondo.
Un vincolo che spiazza al primo preventivo non è tecnico ma contrattuale, e sta scritto nella documentazione: salvo approvazione preventiva, «Anthropic non consente agli sviluppatori terzi di offrire il login a claude.ai o i rate limit per i propri prodotti, inclusi gli agenti costruiti sul Claude Agent SDK» — l’autenticazione va fatta con chiavi API. Tradotto in budget: gli abbonamenti Claude che avete già in azienda non coprono il consumo dell’agente, che diventa una voce di costo a consumo separata e va stimata prima, non a valle del pilota; su come si confrontano le due formule abbiamo una guida sui costi delle API di Claude rispetto all’abbonamento. La stessa pagina fissa anche i limiti di marchio: potete chiamarlo «Claude Agent» o «{IlVostroNome} Powered by Claude», non «Claude Code», e il prodotto non deve sembrare un prodotto Anthropic (Claude Docs).
Prima di costruire, controllate se il verticale esiste già
Nel 2026 si è aggiunta una domanda che nel 2025 non aveva senso porsi: qualcuno ha già impacchettato il vostro dominio? Anthropic ha smesso di vendere solo l’infrastruttura e ha cominciato a costruirci sopra prodotti verticali. Claude Science, annunciato il 30 giugno 2026, è un banco di lavoro per ricercatori che arriva con oltre 60 fra skill e connettori già curati per genomica, analisi single-cell, proteomica, biologia strutturale e cheminformatica; permette di creare agenti specialisti accanto a un agente coordinatore generalista, include un agente revisore che controlla citazioni e calcoli segnalando gli errori, e soprattutto tiene una traccia verificabile: «ogni output porta con sé una cronologia verificabile», con il codice esatto, le specifiche d’ambiente e la cronologia completa dei messaggi (Anthropic). La stessa logica era già stata applicata a Claude for Life Sciences, che collegava Claude agli strumenti che i ricercatori usano davvero — Benchling, BioRender, PubMed — invece di addestrare un modello dedicato (Maginative).
Anthropic apre 10.000 postazioni per scienziati
Il 27 agosto 2026 la direzione si è fatta esplicita anche sul lato distribuzione: Anthropic ha aperto 10.000 postazioni per scienziati, gratuite nella versione standard e a 15 dollari al mese in quella premium con limiti d’uso quintuplicati, riservate a chi è «principal investigator o equivalente presso un istituto di ricerca accademico o non profit», e ha esteso il programma AI for Science oltre la biologia con crediti fino a 50.000 dollari per progetto (Anthropic). Dove un dominio è grande e standardizzato abbastanza, il verticale lo costruisce chi produce il modello e voi lo comprate: è la scelta fra prodotto pronto e sistema su misura che abbiamo sviscerato in agente AI custom contro soluzione SaaS, e riscriverlo con l’Agent SDK sarebbe un errore.
Cosa insegna Claude Science a chi un verticale non ce l’ha
La manifattura di provincia, la logistica di un distributore, un gestionale cucito addosso in quindici anni: questi domini un prodotto pronto non lo avranno mai, perché il mercato non è abbastanza grande per giustificarlo. È esattamente lì che l’Agent SDK smette di essere un’alternativa e diventa l’unica strada, il territorio degli agenti AI su misura — ma la struttura di Claude Science resta il modello da copiare, e dice con precisione quale sia il lavoro: skill e connettori curati sul dominio (non generici), agenti specializzati sotto un coordinatore, un controllo automatico degli output e una traccia ispezionabile di come ci si è arrivati. Sono le stesse quattro cose che nel caso BGL vivevano nei file CLAUDE.md e SKILL.md, ed è la parte che nessuna licenza vi regala.
Da qui esce anche la domanda giusta da fare a un fornitore, che non è «sapete usare l’Agent SDK» — la sanno usare in molti — ma chi scrive e mantiene le skill del nostro dominio, e come faccio a verificare cosa ha fatto l’agente.
Claude Agent SDK per le aziende: come lavoriamo in Mimir
Qui la posizione di Mimir è esplicita: vendiamo un servizio, non solo un prodotto. Un’azienda che vuole un agente costruito sull’Agent SDK non ha bisogno di una licenza in più, ha bisogno di qualcuno che copra i quattro punti sopra al posto suo e poi le lasci in mano qualcosa di governabile.
Le quattro fasi di un progetto Claude Agent SDK
Il percorso tipico che proponiamo ha quattro momenti. Il primo è la selezione del caso d’uso: si parte da un collo di bottiglia dove il costo del lavoro manuale è già visibile in ore-persona, non dal processo più affascinante. Il secondo è la preparazione del terreno: dati accessibili e coerenti, perimetro degli strumenti, definizione di cosa l’agente non deve poter fare, è la lezione del caso BGL applicata a scala PMI. Il terzo è la costruzione con permessi e budget stretti, misurando su un gruppo pilota. Il quarto, quello che di solito manca nei progetti che poi vengono cancellati, è l’onboarding delle persone e il presidio nel tempo: chi legge i log, chi decide di allentare un permesso, chi aggiorna l’SDK quando cambia.
Su cosa aspettarsi concretamente da questo tipo di rapporto abbiamo scritto una guida dedicata alla consulenza agenti AI per PMI, e una su come scegliere un partner AI in Italia, utile anche se poi sceglierete qualcun altro, perché contiene le domande da fare a chiunque si presenti. Vale la pena ricordare il dato Gartner sull’agent washing: su migliaia di fornitori che si dichiarano agentici, secondo l’analisi solo un centinaio circa offre capacità reali (Gartner).
Quando serve un partner e quando basta il team interno
Non tutte le aziende hanno bisogno di aiuto esterno. Il criterio è ragionevolmente semplice. Se in casa avete almeno uno sviluppatore Python o TypeScript senior con tempo dedicato reale, un’infrastruttura dove potete girare processi con sandbox e un caso d’uso a basso rischio, l’SDK è documentato e i demo ufficiali sono pubblici: fatelo internamente e imparate.
Serve un partner quando ricorre almeno uno di questi tre segnali. Primo: l’agente deve toccare dati regolamentati o sistemi di produzione, lì gli errori non sono didattici. Secondo: nessuno in azienda ha mai messo in produzione un sistema non-deterministico, quindi mancano le abitudini di osservabilità e rollback prima che manchino le competenze. Terzo: avete già fatto un proof of concept che funzionava in demo e non ha mai superato il muro dell’integrazione, è esattamente il pattern che Gartner descrive.
Agent SDK, CLI, API o Managed Agents: come scegliere
Anthropic stessa distingue quattro strade: l’Agent SDK se volete un agente senza implementare il tool loop; la CLI per lavoro interattivo e task one-off; il Client SDK se preferite chiamare l’API e gestire il loop da soli; i Managed Agents, prodotto separato con REST API ospitata, se non volete gestire sandbox e infrastruttura di sessione. Un dettaglio operativo spesso ignorato: la libreria esiste solo per Python e TypeScript, e per pilotare lo stesso ciclo da altri linguaggi si lancia la CLI come sottoprocesso con -p e --output-format json. Per il livello successivo, integrazione nei processi e guardrail, vedi integrare Claude in azienda.
Se state valutando un agente costruito sull’Agent SDK e vi riconoscete in almeno uno dei tre segnali qui sopra, vale la pena parlarne prima di scrivere codice: la fase in cui si decide cosa l’agente non deve poter fare è quella che determina se il progetto arriva in produzione. Su mimir.bot trovate come lavoriamo e come richiedere una consulenza sul vostro caso specifico.
Fonti:
- Claude Docs, Agent SDK overview
- Anthropic, Introducing Claude Sonnet 4.5
- Anthropic, Claude Science, an AI workbench for scientists
- Anthropic, Expanding our support for scientists
- Maginative, il lancio di Claude for Life Sciences e i connettori Benchling e PubMed
- AWS Machine Learning Blog, il caso BGL con Claude Agent SDK
- MindStudio, Claude Agent SDK vs Claude API
- Augment Code, agent loop, tool call e limiti di budget
- ksred.com, cosa fa davvero il Claude Agent SDK
- Namirial, lettura dei dati Istat sulla digitalizzazione delle imprese
- DeepLearning.AI The Batch, lancio di Sonnet 4.5 e dell’Agent SDK
- Gartner, oltre il 40% dei progetti di AI agentica cancellati entro il 2027
- MarTech, le cause di fallimento dei progetti agentici secondo Gartner
