Il piano di sotto: come sono fatti i sistemi che fanno lavorare le AI

C’è un piano dove si usano gli agenti e un piano dove si costruiscono. Il primo è popolato di strumenti già pronti, interfacce accessibili, automazioni che non richiedono competenze tecniche. Il secondo è fatto di architetture, protocolli, decisioni progettuali che determinano cosa quei strumenti possono fare e cosa no. Sono due mondi che si parlano poco, ma il secondo governa il primo: le scelte fatte a livello di sistema, di orchestrazione e di affidabilità stabiliscono i confini reali di tutto ciò che poi appare in superficie come semplice e immediato. Capire come funziona quel piano profondo non è una questione per soli sviluppatori: è la precondizione per non scambiare i limiti attuali con le possibilità future.

Il rumore e il segnale

Il problema con il dibattito attuale sull’intelligenza artificiale (AI) non è la mancanza di parole: è l’eccesso. Agenti, sistemi agentic, architetture multi-agente, comunicazione AI-to-AI, protocolli di interoperabilità: il vocabolario si è gonfiato a dismisura, e con esso la difficoltà di separare l’innovazione reale dalla narrazione. Eppure, sotto il rumore, c’è un cambiamento strutturale che vale la pena capire con precisione. Dopo che abbiamo già spiegato la differenza tra sistemi fatti da agenti e agentici, adesso scendiamo più in profondità.

Il mutamento non è nei modelli. I grandi modelli di linguaggio (Large Language Model, LLM) non sono diventati improvvisamente più intelligenti. Quello che è cambiato è il modo in cui vengono impiegati: non più come terminali conversazionali isolati, capaci di rispondere a una domanda e basta, ma come componenti attivi all’interno di sistemi più complessi, capaci di pianificare, agire, osservare i risultati e correggere il tiro.

Da rispondere a fare

Sino a poco tempo fa, il modello d’uso dominante era lineare: si forniva un input, si otteneva un output. Era una conversazione, nel senso più semplice del termine. Quello che emerge adesso è qualcosa di strutturalmente diverso: un ciclo continuo di pianificazione, esecuzione, osservazione e iterazione, in cui il modello non risponde soltanto, ma partecipa a un processo.

Lo spostamento di valore è radicale. La qualità della singola risposta diventa meno rilevante rispetto alla qualità del processo complessivo: come vengono organizzate le azioni, in che ordine, con quali strumenti, con quanta capacità di correggere gli errori intermedi. Non si tratta più di una conversazione. Si tratta di un processo produttivo, con tutto ciò che questo comporta in termini di architettura, affidabilità e controllo.

Questo è il punto di partenza per capire cosa sia davvero un agente. Non un chatbot con qualche funzione aggiuntiva, non un prompt elaborato con l’illusione dell’autonomia. Un agente, nella sua definizione operativa, è un sistema che percepisce input di vario tipo (testo, dati strutturati, risposte di applicazioni esterne), prende decisioni sulle azioni da compiere, utilizza strumenti per eseguirle e itera fino a raggiungere un obiettivo o riconoscere un fallimento.

Che cosa fa davvero un agente

Lo stato dell’arte, però, invita alla sobrietà. Gli agenti funzionano bene su compiti ben delimitati: automazioni di supporto, estrazione di dati da fonti strutturate, piccole sequenze decisionali in contesti prevedibili. Framework come LangGraph, CrewAI e Semantic Kernel mostrano che gli agenti funzionano in modo affidabile su flussi brevi e ben testati, ma richiedono ancora molta ingegneria manuale per essere portati davvero in produzione.

Gli agenti diventano fragili, invece, quando si chiede loro di gestire processi lunghi, critici, con molte variabili imprevedibili. Gli esperimenti in stile AutoGPT e AutoGen hanno avuto tassi di fallimento elevati sui task aperti e poco specificati, e questo ha spinto i framework moderni verso agenti più “stretti”, osservabili e controllati. L’autonomia reale è ancora limitata, e riconoscerlo non è un limite intellettuale: è una precondizione per usare questi strumenti in modo sensato.

Il ruolo dei componenti nel sistema

Il salto vero avviene quando un agente non opera da solo, ma diventa parte di un sistema. I sistemi agentic non sono agenti più potenti: sono architetture in cui il comportamento emerge dall’interazione tra componenti diverse. Al centro c’è il modello di linguaggio, che ragiona. Attorno a lui ci sono l’orchestrazione, che decide cosa fare e in che ordine; gli strumenti (tool), che permettono di agire sul mondo esterno; la memoria, che garantisce continuità tra un’azione e l’altra; lo stato, che tiene traccia di dove si è arrivati, cosa ha funzionato e cosa no.

Nel mondo reale questo si traduce in grafi di esecuzione e macchine a stati esplicite: piattaforme come LangChain/LangGraph o IBM watsonx Orchestrate modellano l’agente come un nodo dentro un workflow più ampio, non come il sistema intero.

Il modello pensa. Il sistema agisce. È una distinzione semplice, ma cambia tutto. Il progettista di questi sistemi non deve chiedersi soltanto quanto è capace il modello, ma come funziona l’orchestrazione, quanto è affidabile la memoria, se gli strumenti sono ben integrati e se c’è un modo per capire cosa sta succedendo quando qualcosa va storto. È il motivo per cui l’“AI engineering” oggi riguarda più il disegno di planner, controller, sistemi di logging e fallback che la scelta del singolo modello, come si vede nelle architetture di Azure AI Agents, Google Agent Builder e dei principali framework enterprise.

Quando gli agenti lavorano in gruppo

L’architettura multi-agente introduce una complessità ulteriore. In certi scenari, un singolo agente non basta: i problemi sono troppo articolati, richiedono competenze specializzate o possono essere scomposti in sotto-task da eseguire in parallelo. In questi casi si usano sistemi in cui più agenti collaborano, ciascuno con un ruolo definito. Uno pianifica, uno esegue, uno verifica. Oppure si creano squadre specializzate: un agente che fa ricerca, uno che produce testo, uno che valida i risultati.

Pattern come planner‑executor‑critic e le “squadre” di agenti specializzati sono alla base di molti framework multi‑agente di nuova generazione, da CrewAI alle soluzioni ispirate a AutoGen e Swarm per la ricerca automatica e le pipeline di data analysis.

I vantaggi sono reali: modularità, scalabilità, separazione delle responsabilità. I limiti, però, crescono di pari passo. La coordinazione tra agenti è difficile, genera un overhead comunicativo non trascurabile e può produrre conflitti, loop o comportamenti imprevedibili. Il numero di agenti non è un indicatore di intelligenza: spesso è soltanto un indicatore di complessità. E la complessità senza controllo non è progresso.

Infatti, le implementazioni industriali più solide usano pochi agenti ben definiti, spesso coordinati da un orchestratore centrale, come nei casi pilota di virtual sales team e assistenti interni sviluppati su LangGraph o su stack cloud proprietari.

La comunicazione tra agenti, di conseguenza, non ha niente di romantico. Non si tratta di macchine che socializzano o sviluppano forme di linguaggio autonomo. Si tratta di scambio strutturato di dati: task, stati, risultati intermedi. I messaggi non sono testo libero, ma formati tipizzati con contratti semantici precisi. Qui sta la differenza tra passarsi stringhe di testo “alla buona” e usare veri protocolli di comunicazione tra agenti, con schemi versionati, campi obbligatori e contratti di risposta verificabili, come nei primi esperimenti enterprise su A2A.

I protocolli emergenti, come MCP (Model Context Protocol, per la comunicazione tra modello e strumenti) e A2A (Agent-to-Agent, per la comunicazione tra agenti), sono ancora in fase di consolidamento. Per ora la maggior parte dei sistemi in produzione usa ancora formati ad hoc, con qualche adozione selettiva di MCP per l’integrazione dei tool e di A2A per coordinare micro‑servizi intelligenti in contesti controllati. Gli standard infatti non sono ancora stabilizzati, le implementazioni sono spesso proprietarie o costruite caso per caso.

I limiti che contano

C’è poi la frattura strutturale tra ecosistemi aperti e chiusi che attraversa tutto questo mondo. Da un lato ci sono i modelli open source, i framework liberamente componibili, la flessibilità e la possibilità di personalizzare ogni strato dell’architettura. Dall’altro ci sono le piattaforme proprietarie, con integrazione verticale, garanzie di servizio e lock-in. Sul lato chiuso, invece, l’approccio dominante è “API + servizi gestiti”: agenti costruiti sopra GPT, Claude o Gemini, con strumenti di orchestrazione integrata forniti direttamente dal cloud provider, come Azure AI Studio, Vertex AI Agent Builder o le suite di automazione di Salesforce e ServiceNow.

Gli agenti amplificano questa tensione perché vivono di integrazione: ogni agente dipende da altri sistemi, e la scelta dell’ecosistema determina cosa è possibile costruire e a quale costo.

Il problema più urgente, però, non è architetturale. È quello dell’affidabilità. Gli errori tipici dei sistemi agentic attuali sono ben noti a chi li usa in produzione: allucinazioni operative (azioni non valide, uso scorretto degli strumenti), loop senza progresso, interpretazioni errate dei risultati intermedi. Più un sistema è autonomo, meno è facile controllarlo direttamente. Non a caso stanno nascendo benchmark e suite di test pensate specificamente per agenti, che misurano non solo l’accuratezza linguistica ma il tasso di completamento dei task, il numero di errori operativi e la necessità di intervento umano lungo un intero workflow.

Le soluzioni adottate, come la self-verification, i sistemi di valutazione esterni, il human-in-the-loop e le infrastrutture di osservabilità (log, tracciamento, monitoraggio), sono utili ma non risolutive. Il problema non è cosa sanno fare questi sistemi. Invece, ci dobbiamo preoccupare soprattutto di quanto ci si può fidare di loro.

Infine, c’è anche un costo computazionale non banale: un flusso agentico composto da molte chiamate al modello, più uso di tool e accessi a memoria esterna, è sensibilmente più caro e più lento di una singola risposta LLM, e questo obbliga a scelte di design molto pragmatiche.

Cosa fa realisticamente un agente oggi

Realtà e narrazione

Distinguere la realtà dall’hype è, in questo momento, il lavoro più importante. Tra i trend reali ci sono: la centralità dell’orchestrazione come strato critico dell’architettura, l’uso crescente degli agenti in produzione su compiti limitati e ben definiti, lo sviluppo di protocolli e standard e la crescita dei framework agentic come strumenti maturi.

In pratica si vedono soprattutto agenti verticali in produzione: assistenti per il supporto clienti, estrazione dati da documenti, automazione di workflow interni in ambito finance, legale e customer operations, spesso integrati nei CRM o nelle piattaforme di ticketing esistenti.

Tra l’hype, invece, ci sono l’autonomia completa, i sistemi auto-organizzati senza supervisione umana e la sostituzione generalizzata del lavoro cognitivo nel breve periodo. Anche i sistemi multi‑agente realmente usati oggi sono quasi sempre sotto una supervisione forte, con ruoli e permessi espliciti, limiti chiari alle azioni automatizzabili e percorsi obbligati di escalation verso un umano quando qualcosa esce dal tracciato previsto.

Ecco perché possiamo dire che la GenAI non sta diventando più intelligente. Sta diventando più organizzata. Il salto che stiamo vivendo non è cognitivo: è architetturale. E come ogni salto architetturale nella storia della tecnologia, richiede meno entusiasmo e più ingegneria.