Come Funzionano gli Agenti AI? - Strumenti e Strategie

Quando un founder o un builder italiano si avvicina al mondo degli agent LLM, la prima difficoltà è semantica: la parola "agente" in italiano suona generica, ma deriva dall'inglese agency, ovvero libertà di azione e autonomia. Nel video di Datapizza, Luca e Raul partono proprio da qui per spiegare cos'è davvero un agent AI, come si progetta un sistema multi-agent e quando ha senso usarlo invece di un workflow tradizionale. Il taglio è pratico e operativo, con esempi presi da progetti reali e domande live dal pubblico che toccano i nodi concreti di chi sta sviluppando questi sistemi adesso.

1. Cos'è un agent LLM e perché un tool cambia tutto

Un agent LLM è un large language model a cui viene fornito un set di strumenti (tool) che può invocare per compiere azioni. L'esempio più semplice: ChatGPT puro non sa che tempo farà domani a Milano, perché la sua conoscenza interna è statica. Diventa un agent nel momento in cui gli si dà accesso a un tool che, dato un luogo e una data, restituisce le previsioni meteo. L'analogia con l'essere umano è precisa: una persona senza tool risponde solo con quello che ha studiato, una persona-agent può consultare una calcolatrice, cercare su internet o telefonare a qualcuno per arrivare alla risposta. La parte interessante è che un tool, dietro le quinte, è semplicemente una funzione Python con dei parametri. Quindi qualsiasi cosa scrivibile in codice diventa potenzialmente un tool: una chiamata API al meteo, un generatore di immagini come DALL-E, una query a un database, l'accesso al codice di un software aziendale interno. È proprio questa apertura che rende il paradigma agentico interessante per chi costruisce prodotti: se hai accesso al codice del software che la tua azienda usa per processi macchinosi, puoi avvolgerlo in una funzione Python e dare a un agent la capacità di automatizzare o semi-automatizzare quel processo.

2. Multi-agent: il vero lavoro è l'architettura, non il codice

Il salto concettuale arriva quando si capisce che un tool può essere un altro agent. A quel punto si possono costruire reti di agent che si chiamano a vicenda, ognuno specializzato in un sotto-task. Luca racconta l'emozione del momento in cui Raul gli ha mostrato per la prima volta agent che collaboravano da soli per risolvere un caso d'uso. Il punto operativo è chiaro: il singolo agent non è complicato da implementare, la difficoltà sta nell'architettura. Bisogna prendere il task principale, scomporlo nelle sue parti più elementari e assegnare ognuna a un agent specializzato. Raul porta un esempio concreto preso da un progetto in corso: un sistema che riceve via mail dei form da compilare (nello specifico, moduli di iscrizione a un workshop di cucina con regole non banali — sezioni obbligatorie, sezioni alternative, dati personali da incrociare). La rete è composta da tre agent in sequenza: un classificatore che capisce se il PDF allegato è davvero il modulo atteso, un ispettore che applica le regole di compilazione e identifica errori, e uno scrittore che genera la mail di risposta al cliente con i problemi rilevati. Una domanda dal pubblico chiede perché non risolvere tutto con una catena di chiamate API. La risposta è che a priori non sai cosa ti arriva nella mail: serve un livello che ragioni sulla richiesta e decida quale percorso attivare, cosa che un singolo prompt monolitico fa fatica a gestire bene per limiti di context window e di affidabilità.

3. Strutturato vs non strutturato: dove gli agent fanno la differenza

I tool richiedono parametri strutturati per definizione: una funzione Python ha bisogno di sapere che il primo argomento è una data e il secondo una città. Quando dichiari un tool all'agent, gli passi anche le descrizioni dei parametri. Dietro le quinte, framework come quelli di OpenAI inseriscono queste descrizioni nel system message, e il modello è addestrato a capire quale tool usare e con quali parametri. La forza dell'agent emerge proprio nella conversione dell'input non strutturato in chiamata strutturata: se l'utente chiede "che tempo farà domani nel capoluogo lombardo", l'agent capisce che deve chiamare il tool meteo con città uguale a Milano. Se manca un parametro, lo chiede. Questa capacità di tradurre linguaggio naturale ambiguo in azioni precise è esattamente ciò che la programmazione deterministica con if/else o regex fatica a fare. Un esempio operativo: capire se in un form PDF una checkbox è stata spuntata. A livello programmatico è un incubo, perché le checkbox non fanno parte del testo estraibile e i PDF hanno formati eterogenei. Se poi il modulo è scannerizzato o fotografato male, non c'è proprio modo di leggerlo senza un sistema che ragioni come farebbe un occhio umano. Lì l'agent diventa la scelta naturale.

4. RAG agentico ed embedding: quando l'approccio classico non basta

Una domanda dal pubblico tocca il tema RAG. Il limite del RAG tradizionale è che la ricerca per similarità tra query e chunk si basa su distanze tra vettori numerici, senza un livello di intelligenza che valuti davvero la rilevanza. Quando il caso d'uso è complesso, succede di non beccare mai il chunk giusto. La soluzione che sta emergendo nei progetti più articolati è il RAG agentico: agent che hanno in pancia pezzi di documenti critici e decidono attivamente cosa portare nel contesto del modello. Su un altro fronte, sul fine-tuning dei modelli di embedding, il messaggio è prudente. Sui modelli piccoli può aiutare, sui modelli grandi e generalisti ha senso solo se lavori in un dominio molto specifico e nessun modello pre-trained disponibile ti soddisfa. La parte difficile è costruire il dataset: servono migliaia, idealmente decine di migliaia di esempi, e anche se gli LLM moderni aiutano a generare dati sintetici, bisogna fare attenzione alla qualità.

5. Pain point reali: framework, parallelismo e quando NON usare un agent

Il pain point principale, secondo Raul, non è scrivere codice ma decidere dove serve davvero un agent. Le casistiche estreme sono semplici: workflow completamente deterministico (niente agent) o workflow completamente agentico con molto ragionamento freestyle. Le situazioni difficili stanno nel mezzo, dove parte del flusso è deterministica e parte richiede ragionamento. La regola pratica è chiara: se un problema si risolve con un if/else, usare un agent equivale a uccidere una formica con un bazooka. Un agent al 99% di accuracy va peggio di una regex al 100%. Ma quando devi capire se un testo parla di un certo argomento, o gestire input non strutturati, allora la programmazione deterministica non scala. Sul fronte tooling, il giudizio sui framework esistenti è duro ma onesto: librerie come CrewAI sono molto specializzate in una direzione, LangChain ha un livello di complessità non trascurabile, e nessuna delle opzioni è ancora completamente matura per ogni caso d'uso. Per questo Datapizza sta sviluppando un proprio framework interno. Un altro problema operativo è il parallelismo: quando alcuni agent vanno richiamati in sequenza e altri in parallelo per ridurre la latenza, bisogna scegliere tra threading, async e multiprocessing. La direzione che stanno prendendo è async, per i limiti noti del multithreading in Python. Sulla comunicazione tra agent ci sono diverse opzioni valide: function calling con parametri strutturati, scambio di messaggi, oppure una memoria condivisa implementata tramite un database esterno trasformato in tool accessibile a più agent.

Il messaggio finale per chi costruisce con gli agent oggi è coerente con l'esperienza di chi ci lavora ogni giorno: la documentazione strutturata su questi temi è scarsa, le tecnologie sono troppo nuove perché esistano percorsi formativi consolidati, e l'unica strada è l'autodidatta — leggere documentazione, seguire chi sperimenta su Twitter e LinkedIn, e soprattutto provare. La fase di brainstorming architetturale, fatta anche solo con un foglio e una penna per disegnare il flusso, sta diventando più importante della fase di scrittura del codice vero e proprio. Per un founder italiano che sta valutando se costruire il proprio prodotto attorno a un sistema multi-agent, questo è il segnale operativo principale: il vantaggio competitivo si gioca sulla capacità di scomporre bene il problema, non sulla padronanza del singolo framework.