Sviluppo di agenti AI che reggono in produzione

Sviluppare un agente AI significa costruire software in cui un modello linguistico decide quale passo compiere, chiama strumenti reali per compierlo, legge il risultato e decide di nuovo — finché un obiettivo è raggiunto o un limite lo ferma. Il prodotto non è il modello: è il ciclo che gli sta attorno. È lì che vive l’ingegneria: cosa l’agente può invocare, come gli tornano gli errori, come lo stato viaggia tra i passi, cosa succede quando esce di rotta e come, alla fine, sapete se ha fatto il lavoro. Un chatbot risponde. Un agente agisce, e quell’azione è ciò che rende tutto questo un progetto software e non un prompt.

Un prototipo funzionante su un compito stretto richiede di solito da una a tre settimane. Portarlo a uno stato che mostrereste ai clienti richiede molto di più — tipicamente da due a quattro mesi — e quasi nulla di quel tempo va nel prompting. Va nelle integrazioni che falliscono in modi che il modello deve gestire, in un set di valutazione che intercetta le regressioni, nei permessi, in log da cui si possa fare debug e nel percorso di passaggio a una persona per i casi che l’agente non deve decidere da solo. I team che mettono a budget la demo e non la seconda fase sono quelli il cui agente non esce mai dal pilota.

Partite dalla cosa più leggera che risolve il compito. Per un singolo agente con pochi strumenti, l’SDK del fornitore del modello più un ciclo scritto da voi è spesso tutto il lavoro, e vi lascia in grado di fare debug di ogni passo. Passate a un framework di orchestrazione quando servono davvero stato durevole, controllo di flusso con rami, ritentativi su passi lunghi o più agenti coordinati. Il costo di un framework non è l’API: è che proprio le parti che dovete ispezionare in una giornata storta stanno dentro l’astrazione di qualcun altro. Qualunque cosa scegliate, tenete prompt, definizioni degli strumenti e set di valutazione fuori dal framework: cambiare costerà un giorno, non una riscrittura.

Ci sono due costi e i team pianificano regolarmente quello sbagliato. Costo di costruzione: un agente interno stretto sta tipicamente tra 8.000 e 30.000 $ di ingegneria; uno rivolto ai clienti, con integrazioni reali, valutazione e monitoraggio, sta più spesso tra 30.000 e 120.000 $. Costo di esercizio: la spesa in token è di solito la voce minore e la più facile da ridurre — instradare i passi semplici su un modello più economico, usare la cache e potare il contesto la dimezzano spesso. La voce che si dimentica è la manutenzione: i modelli vengono dismessi, le API cambiano, il set di valutazione va rieseguito. Mettete a bilancio circa il 15–25% del costo di costruzione all’anno.

Limitando ciò che può fare, invece di sperare che si comporti bene. In pratica: ancorate le risposte a documenti recuperati e fate citare la fonte usata; date agli strumenti argomenti tipizzati e rigidi, validati prima dell’esecuzione; lasciate che uno strumento restituisca un onesto «non trovato» e insegnate all’agente che non restituire nulla è un esito accettabile; mettete un tetto al numero di passi e alla spesa per esecuzione; e piazzate un’approvazione umana davanti a tutto ciò che è irreversibile — pagamenti, cancellazioni, messaggi in uscita verso i clienti. Poi misurate. Un set di valutazione con cinquanta casi reali, compresi quelli scomodi, dice sull’affidabilità più di qualsiasi ritocco ai prompt.

Usate una piattaforma no-code quando il compito è standard, il volume moderato e il costo di una risposta sbagliata è basso: instradare una FAQ interna, smistare richieste, redigere prime risposte. Portano davvero più in fretta a un risultato e vi insegnano che cosa serve davvero al compito. Costruite su misura quando l’agente deve toccare i vostri sistemi con permessi reali, quando latenza o costo unitario contano ai vostri volumi, quando vi serve una valutazione e una tracciabilità vostre, o quando l’agente fa parte del prodotto che vendete. Il percorso consueto ha senso: provate il flusso su una piattaforma, poi ricostruite le parti che se lo sono meritato.