Attenzione all'entusiasmo con gli Agenti AI. Costruirli bene è complesso, parola di chi ne ha già scritti.

Soundtrack: I still Haven’t Found What I’m Looking For — U2

Sono diversi mesi che ho la fortuna (e la croce, sic!) di lavorare su diversi progetti di AI Agentica e l’entusiasmo che vedo online per questo strumento mi sembra ben esagerato.

Son sicuro, vista l’importanza della buzzword, che chiunque può stia cercando di mettersi un progetto AI sotto la cintola: d’altronde fa curriculum! Sono però molto meno convinto che gran parte degli agenti AI (o millantati tali) che vengono prodotti in queste settimane, siano davvero in grado di far quel che gli autori promettono, e men che meno di essere realmente autonomi.

Quindi, visto che qualche agentino funzionante l’ho costruito e non ho di che millantare, in questo #postNerd vi condividerò cosa ho scoperto durante la creazione dei miei agenti AI e le ragioni del mio scarso entusiasmo nei confronti di quel che sento raccontare in giro.

Badate bene, credo in questa tecnologia e nel suo potenziale in modo feroce. Ciò in cui non credo è che sia semplice, sempre affidabile ed economica come ve la vuol far passare il fuffaguru di turno.

Quel che invece è vero, a mio avviso, è che per far funzionare molto bene un agente AI sia necessaria una quantità più che proporzionale di lavoro da parte di più esseri umani per comprendere cosa l’agente farà, come lo farà, con quali limiti, agganciato a cosa e con quali azioni a disposizione. Rispondere alle condizioni di cui sopra, richiede a sua volta che l’azienda abbia ben chiari i processi che andranno automatizzati, e che ne abbia anche creato quantomeno delle funzioni primitive a cui l’automazione si aggancia: così non fosse, cosa mai potrebbe automatizzare l’agente?

Ma bado alle ciance, se dopo questo TLDR siete ancora avidi di scoprire quanto è profonda la tana del bianconiglio, continuate a leggere. Altrimenti smettete qui e domani sarete liberi di credere quel che vi va, oltre che alle cazzabbubbole che vi propinerà l’“esperto” di turno.

Why oh why, didn’t you choose the blue pill?

Un caso concreto: il customer journey di Peppino ‘u Suricillo

Iniziamo con il definire un customer journey.

Il cliente “Peppino ‘u Suricillo” chiama il customer care e dice che vuole sostituire un prodotto difettoso acquistato online 25 giorni fa e consegnato tre giorni dopo. L’ordine contiene più righe con degli SKU che sono arrivati perfetti e dell’unico prodotto incriminato il cliente ne ha ordinato tre unità, ma solo una è arrivata danneggiata. Il danno consiste nella presenza di muffa all’interno del packaging primario. Il cliente ha usato gli altri due prodotti simili nei giorni successivi all’acquisto, oggi ha aperto il terzo e ha trovato la “sorpresa”.

Questo è un journey che a prima vista potrebbe sembrare banale, ma che anche per un essere umano esperto di servizio clienti può presentare diverse insidie. E per un bot LLM? Scomponiamolo in passaggi, come farebbe un essere umano, e riflettiamo su cosa debba fare l’agente AI e come.

Riconoscere il cliente

Questa è la prima cosa da fare, e subito ci si pone il primo problema: “Peppino ‘u Suricillo” non è un utente noto al sistema. Forse si è presentato con un soprannome, o forse ci sono altri errori. Fatto sta che in mancanza di riconoscimento, il sistema dovrà chiedere perlomeno una mail di riferimento, oppure un numero d’ordine, oppure chiedere aiuto a un essere umano.

Fare questo, per un bot, significa avere l’anagrafica cliente, l’anagrafica ordini (divisa in testate e righe opportunamente) e l’anagrafica agenti collegata al motore di LLM; ovviamente le anagrafiche devono essere aggiornate, e per funzionare il sistema deve avere almeno 4 primitive funzionanti:

• trova il cliente per nome e cognome
• trova il cliente per email
• trova il cliente per numero d'ordine
• passa a un agente umano in caso di emergenza

Ovviamente serve anche una logica che dica al sistema che se non trova il cliente con un metodo deve utilizzarne uno degli altri tre, e se in nessun caso lo trova deve passare a un agente umano per il riconoscimento.

Questa logica può anche essere un prompt, ma di fatto è una logica di programmazione e va “blindata” contro tutti gli input erronei che il cliente potrebbe immettere. Non mi va di portarvi giù negli inferi della validazione dei campi di input, che in caso di LLM configura una possibile prompt injection così come nei sistemi tradizionali esistono le SQL injection, ma la logica (e il pericolo per il vostro bot) sono gli stessi e quindi ne dovete essere consapevoli.

In questa ipotesi, avete eseguito se va bene 1 prompt e se va male 4. Ogni prompt ha un costo in token, poco o tanto che sia.

Il flusso completo: quante API servono davvero?

Una volta riconosciuto il cliente, l’agente deve:

1. Riconoscere il cliente, identificare la sua anagrafica e recuperare l’ordine (getCustomerByPhoneNumber e getOrderDetails)
2. Capire se la sostituzione è possibile, con regole aziendali che cambiano a seconda del prodotto e del tempo trascorso (checkReturnEligibility)
3. Se tutto è ok: creare la pratica di reso (createReturnRequest), generare l’etichetta (generateReturnLabel) e prenotare un ritiro con il corriere (schedulePickup)
4. Attivare la spedizione del prodotto sostitutivo (createReplacementOrder + generateShippingLabel)
5. Aggiornare lo stato dell’ordine nei sistemi (updateOrderStatus) e informare il cliente con una notifica chiara (sendCustomerNotification)

In totale parliamo di 8–10 chiamate API distinte, ciascuna con potenziali errori e casi limite. Se anche solo una di queste fallisce (un corriere non conferma il ritiro, un’etichetta non viene generata), tutto il flusso si blocca.

Con una probabilità di successo del 95% per ogni step, la riuscita complessiva di un processo a 10 step scende al 60%. E per un cliente che aspetta la sostituzione di un prodotto, questo non è accettabile.

La lezione che sto imparando

Negli ultimi mesi ho avuto la fortuna (e la fatica) di lavorare su diversi progetti che avevano al centro agenti AI complessi. Penso al Virtual CS Beauty, l’agente per il customer care che stiamo sviluppando per il mondo beauty, oppure a VirtualCami, il nostro esperimento di assistente intelligente capace di integrare dati, protocolli e logiche di business.

Ecco perché, più passa il tempo, più mi rendo conto che gli agenti AI non sono magia. Funzionano solo quando hanno attorno una base solida di funzioni primitive — quelle API granulari e affidabili che permettono di orchestrare flussi complessi senza andare in crash a ogni deviazione.

È un po’ la stessa lezione che sto imparando giorno dopo giorno: non basta “collegare GPT a un CRM” per avere un customer care intelligente o un assistente di business. Serve ingegneria seria, strumenti robusti e un ecosistema che tolleri errori, rollback, fallimenti parziali.

Non basta l’entusiasmo. Serve il lavoro.