La maggior parte dei progetti di agenti AI non fallisce perché il prototipo era scadente. Fallisce perché il team ha scelto un framework che funzionava bene in un Jupyter notebook e ha scoperto i suoi limiti tre mesi dopo, nel bel mezzo di una build in produzione — quando il costo di cambiare è alto e la pressione di rilasciare è ancora più alta.
LangGraph, CrewAI, AutoGen (ora in modalità manutenzione — Microsoft reindirizza i nuovi progetti al Microsoft Agent Framework), Mastra, VoltAgent, Smolagents — ciascuno ha una storia legittima, una community in crescita e demo che sembrano convincenti. Il problema è che le demo non sono la giusta unità di valutazione. La giusta unità è: reggerà sotto un carico reale, con veri modi di fallire, all’interno di un’organizzazione che deve verificare, governare e mantenere il sistema?
Di seguito trovi gli otto criteri che applichiamo in ogni ingaggio con i clienti prima di impegnarci su un framework. Lavoraci e potrai eliminare la maggior parte dei candidati deboli in un pomeriggio.
Perché la production readiness dei framework è una disciplina a sé
Un modello linguistico che chiama una funzione non è un agente. Un agente è un sistema automatizzato che percepisce lo stato, sceglie le azioni, chiama strumenti e itera — a volte per minuti, a volte su più passaggi, a volte con denaro o dati in gioco. Il divario tra “funziona in demo” e “sicuro da eseguire in autonomia su larga scala” è più ampio di quanto la maggior parte dei team si aspetti.
La production readiness copre aspetti che i tutorial saltano: cosa succede quando una chiamata LLM va in timeout a metà ciclo? Chi verifica le decisioni dell’agente? Dove vive lo stato della conversazione se il container crasha? Non sono casi limite — sono le normali condizioni operative di qualsiasi sistema che gira a volume.
La checklist degli otto criteri
1. Osservabilità: riesci a vedere cosa ha fatto davvero l’agente?
È la prima cosa da sondare ed è quella più spesso poco sviluppata.
Un agente in produzione ha bisogno di trace strutturate ed esportabili: record a livello di step che mostrano quale strumento è stato chiamato con quali argomenti, cosa ha restituito l’LLM, quanto ha impiegato ogni step e dove il ciclo ha biforcato. Senza questo, il debug di un errore diventa archeologia.
Domande da fare:
- Il framework emette trace compatibili con OpenTelemetry in modo nativo, o le aggiungi a mano?
- Puoi riprodurre una run specifica per l’analisi post-mortem?
- I conteggi di token e la latenza vengono tracciati a livello di step?
I framework che trattano il logging come un’aggiunta secondaria ti obbligano a strumentare tutto da solo — questo costa tipicamente uno sprint su qualsiasi deployment serio.
2. Gestione degli errori: cosa si rompe con grazia e cosa esplode
Le chiamate LLM falliscono. Le API restituiscono errori di rate limit. Gli strumenti lanciano eccezioni. La domanda non è se i fallimenti accadono, ma se il framework ha una risposta ragionata a essi.
Cerca:
- Policy di retry con backoff configurabile, che distingua i fallimenti recuperabili da quelli terminali
- Ripresa da run parziale — un workflow interrotto può riprendere dall’ultimo stato valido, o riparte da zero?
- Propagazione degli errori degli strumenti — l’agente riceve un segnale utile, o entra silenziosamente in uno stato errato?
Un framework senza logica di retry e senza checkpoint di stato causerà incidenti in produzione alle 2 di notte.
3. Persistenza di stato e memoria: chi possiede il contesto?
Gli agenti da demo sono stateless. Gli agenti reali non lo sono.
Per qualsiasi cosa che si estenda su più turni, sessioni utente o task a lunga durata, devi capire esattamente dove vive lo stato dell’agente:
- È in memoria nel processo (sparisce al riavvio), in un database o in uno store esterno?
- Chi gestisce le migrazioni di schema quando la forma dello stato dell’agente cambia?
- Lo stato può essere ispezionato e corretto manualmente se un agente si blocca?
Alcuni framework usano per default lo stato in memoria senza persistence layer. Va bene per il prototipaggio. Per un agente rivolto ai clienti che gestisce ticket di supporto o trattative commerciali, significa perdere il contesto a ogni deploy — o costruire un persistence layer da zero.
Correlato: nelle architetture multi-agente, il coordinamento dello stato condiviso diventa un problema a sé. Verifica se il framework ha un pattern documentato per questo, o se lo lascia interamente a te. Vedi AI Agent Orchestration: far lavorare gli agenti come un sistema per un approfondimento.
4. Strumenti di valutazione: come sai se sta migliorando?
Questo è il criterio che separa i team che rilasciano agenti affidabili da quelli che “lo monitorano manualmente.”
Gli agenti in produzione hanno bisogno di regression testing — la capacità di eseguire una suite definita di input e verificare che gli output soddisfino un livello di qualità. Questo si chiama evals, ed è tutt’altro che banale da costruire da zero.
Chiedi:
- Il framework include strumenti di eval, o assume che integrerai uno strumento esterno?
- Puoi eseguire gli eval in locale prima di un deploy?
- Esiste un formato di dataset per catturare esempi buoni/cattivi dalla produzione da reintrodurre nei test?
Senza infrastruttura di eval, ogni aggiornamento del framework o modifica al prompt diventa un lancio di dadi. Vedi Testing degli agenti AI: come gli evals mantengono l’automazione affidabile per un approfondimento.
5. Postura di sicurezza: esecuzione degli strumenti e prompt injection
Gli agenti eseguono codice, chiamano API e scrivono su database. La superficie di attacco è materialmente diversa da quella di un chatbot.
Cose critiche da verificare:
- Permissioning degli strumenti — puoi limitare quali strumenti un agente può chiamare in base al contesto o al ruolo? O ogni strumento ha lo stesso livello di accesso?
- Sanitizzazione dell’input — c’è qualche protezione contro gli attacchi di prompt injection, dove contenuti ostili in un documento recuperato dirottano il comportamento dell’agente?
- Gestione dei segreti — le chiavi API e le credenziali sono gestite a livello di framework, o ogni sviluppatore le gestisce in modo ad hoc?
Un framework senza il concetto di permessi a livello di strumento non è adatto per nessun workflow in cui un agente tocca dati dei clienti o sistemi esterni con accesso in scrittura.
6. Hook di governance: umano nel ciclo quando conta
Non ogni decisione dovrebbe essere autonoma. Il tuo team di governance — e alla fine i regolatori — vorrà punti documentati in cui un umano potrebbe intervenire o revisionare.
Cerca:
- Meccanismi di interruzione/pausa — l’agente può portare una decisione a un operatore umano prima di intraprendere un’azione sopra una soglia di rischio definita?
- Workflow di approvazione — esiste un pattern integrato per il sign-off umano su chiamate di strumenti specifiche (es. inviare un’email, emettere un rimborso)?
- Audit log — c’è una registrazione immutabile di ciò che l’agente ha deciso e perché, con una granularità sufficiente per la revisione di conformità?
La governance è sempre più un requisito contrattuale per i clienti enterprise e un obbligo regolatorio concreto sotto l’EU AI Act, in vigore dall’agosto 2024 con più tranche già vincolanti. Vedi Governance degli agenti AI: una guida pratica per le PMI per il quadro di governance più ampio.
7. Salute della community e traiettoria di manutenzione
I framework open source sono duraturi solo quanto le community che li supportano. Prima di impegnarti, verifica:
- Frequenza dei commit — il repo è mantenuto attivamente o sta perdendo slancio?
- Tempo di risposta alle issue — quanto ci vuole prima che un maintainer riconosca una segnalazione di bug?
- Policy sui breaking change — il progetto documenta la stabilità delle API e i percorsi di migrazione?
- Dipendenza dallo sponsor — è un progetto di una singola azienda in cui un cambiamento di strategia aziendale può terminare il supporto?
Un framework che era di tendenza su GitHub sei mesi fa con velocità di contribuzione in calo è un rischio da prezzare prima di spendere mesi di tempo di ingegneria su di esso.
8. Costo di uscita: come sarebbe una migrazione?
Questa è la domanda che quasi nessuno fa durante la selezione e che tutti fanno diciotto mesi dopo.
Se devi abbandonare questo framework — perché ha smesso di essere mantenuto, perché i tuoi requisiti lo hanno superato, o perché è emersa un’opzione migliore — qual è il costo?
Considera:
- Quanta parte della tua logica di business è in costrutti specifici del framework rispetto a Python/TypeScript portabile?
- Le tue definizioni di strumenti sono riutilizzabili fuori dal framework?
- Lo schema di stato del tuo agente è in un formato che controlli, o è opaco al framework?
I framework con alta astrazione e internals opachi tendono ad avere alti costi di uscita. Non è automaticamente penalizzante, ma dovrebbe essere prezzato. Vedi Platform lock-in degli agenti AI: i rischi che nessuno prezza per un trattamento dettagliato.
Come valutare rapidamente un framework
Applica ogni criterio su una scala a tre punti:
| Punteggio | Significato |
|---|---|
| 2 | Nativo, documentato, funziona subito |
| 1 | Possibile con integrazione o codice personalizzato |
| 0 | Assente — lo costruisci tu |
Un totale sotto 10 su 16 è un segnale d’allerta. Sotto 8 è un no secco per qualsiasi cosa rivolto ai clienti o sensibile alla conformità. Gli zeri specifici contano più del totale — uno zero sulla postura di sicurezza è un blocco indipendentemente dal punteggio complessivo.
Come si svolge concretamente una sessione di vetting di un framework
Applica gli otto criteri alla tua shortlist in una sessione strutturata. Due framework vengono eliminati rapidamente perché mancano di meccanismi di interruzione/approvazione. Uno ottiene un buon punteggio sulla governance ma ha una storia di manutenzione scarsa — viene segnalato come rischio di dipendenza. Il candidato rimanente arriva a 13/16 con un percorso di migrazione chiaro. Quello è il framework su cui costruire.
I criteri sono gli stessi indipendentemente da quali framework finiscono sulla tua shortlist. Per un contesto più ampio su cosa tipicamente supera la selezione, vedi Scegliere un framework open source per agenti AI: la shortlist per CTO e CrewAI vs LangGraph: scegliere il framework giusto.
Quando coinvolgere occhi esterni
Se il tuo team sta per impegnare budget su un framework di agenti senza una valutazione strutturata, quello è il momento di massima leva per coinvolgere qualcuno che lo ha già fatto. La selezione del framework influenza la tua postura di sicurezza, la documentazione di conformità, il carico operativo e il costo futuro di migrazione — non solo la velocità degli sprint.
In Orange ITS, questa valutazione fa parte di ogni ingaggio di sviluppo di agenti AI. Abbiamo visto framework che sembrano eccellenti in demo e crollano sotto carichi reali, e framework che partono in modo grezzo ma sono duraturi su larga scala. Quel riconoscimento di pattern è ciò che un buon partner di valutazione porta.
Pronto a testare sotto pressione la tua shortlist di framework prima che inizi la build? Prenota una chiamata di 30 minuti con Orange ITS — valuteremo i tuoi candidati rispetto a questi criteri e ti diremo onestamente su quali costruiremmo.