Architettura di un agente AI: di cosa è fatto, e quando non serve

La confusione più diffusa sugli agenti AI è che siano modelli di linguaggio con un nome più ambizioso. Non lo sono, e la differenza non è accademica: quasi tutte le capacità che si attribuiscono all’agente stanno nei pezzi che gli girano intorno, non nel modello. Chi lo dimentica compra il modello sbagliato per risolvere un problema che il modello non ha.

Un agente è un sistema che percepisce, decide e agisce per raggiungere un obiettivo, usando un modello di linguaggio come organo semantico - cioè come la parte che capisce il testo. Il salto rispetto a un programma tradizionale non è che «capisce l’italiano»: è che non serve prevedere in anticipo tutti i casi. Un sistema classico interroga i dati con domande scritte prima; un agente riceve un’istruzione in linguaggio naturale, decide quali passi compiere e li compie.

L’idea non è nuova, come realizzarla sì

Gli agenti esistono dagli anni Novanta. A cambiare non è l’idea: è che le regole non si scrivono più.

Il termine «agente» circola dagli anni Novanta, con i sistemi multi-agente e il modello BDI - dall’inglese beliefs, desires, intentions, cioè credenze, desideri e intenzioni. Quegli agenti avevano stati interni e regole di ragionamento, ed erano sistemi basati su regole: innovativi per il periodo e incapaci di apprendere.

La differenza con oggi non è la quantità di regole. È che le regole non si scrivono più: il comportamento emerge dal modello e dalle istruzioni che gli si danno. È un guadagno enorme in flessibilità e una perdita altrettanto grande in prevedibilità, ed è la ragione per cui gran parte del lavoro di costruire un agente consiste nel rimettere dei vincoli intorno a qualcosa che non ne ha.

I cinque pezzi

Modello, orchestrazione, ragionamento, collegamento al mondo, monitoraggio. Quattro su cinque non sono il modello, e insieme hanno un nome: harness.

Un agente si articola in moduli che cooperano. Sono cinque, e conviene guardarli per quello che fanno invece che per come si chiamano.

Pezzo	Che cosa fa	Cosa succede se manca o è debole
Modello di linguaggio	Interpreta il testo e produce risposte	Senza, non c’è agente: è l’organo semantico
Motore di orchestrazione	Decide quali passi compiere, in che ordine, con quali strumenti	L’agente risponde ma non conclude niente: sa dire, non sa fare
Modulo di ragionamento	Affronta compiti che richiedono pianificazione o più passaggi	L’agente gestisce richieste semplici e si perde su quelle composte
Interfacciamento esterno	Collega servizi, interfacce di programmazione, banche dati, sensori	L’agente resta un conversatore: nessuna azione tocca il mondo
Monitoraggio e riscontro	Registra cosa è successo, verifica gli esiti, corregge gli errori sistematici	Nessuno sa se funziona, e gli errori si ripetono uguali

Tutto il resto ha un nome: harness

Nell’uso corrente questo insieme - tutto ciò che sta intorno al modello e ne rende affidabile l’impiego - si chiama harness, termine inglese che si è diffuso negli ultimi due anni e per cui non esiste ancora una traduzione italiana consolidata. Alla lettera è la bardatura: l’attrezzatura che si mette a un animale da tiro perché la sua forza vada dove serve.

L’immagine è azzeccata e conviene tenerla, perché dice due cose insieme. La forza è del modello e non della bardatura. E un modello senza bardatura non è più libero: è solo inutilizzabile per un lavoro.

Concretamente l’harness si occupa di sei cose:

• governare il ciclo, cioè decidere quando richiamare il modello, quando ritentare e quando fermarsi;
• mettere gli strumenti a disposizione del modello, dichiarandoli in una forma che possa usare e verificando gli argomenti che produce;
• costruire il contesto da passare al modello a ogni iterazione, che è finito e va speso bene: cosa tenere, cosa riassumere, cosa buttare;
• gestire la memoria, perché un compito lungo non entra in un solo scambio e ciò che vale oltre il compito va conservato senza invecchiare male;
• presidiare la sicurezza: cosa l’agente può toccare, quali dati non devono finire nel contesto, cosa richiede una conferma prima di essere eseguito;
• registrare e misurare quello che è successo, perché sia ricostruibile e perché si possa sapere se una modifica ha migliorato l’agente o l’ha peggiorato.

Sono i moduli della tabella, tranne il modello, guardati come una cosa sola invece che come pezzi separati. Ognuno di questi compiti merita più spazio di una riga, e lo ha: I sei mestieri dell’harness li prende uno per uno. Qui basta sapere che esistono e che nessuno di essi sta nel modello.

E non è un accessorio: l’harness è un componente fondamentale dell’agente, al pari del modello. Lo si vede bene negli strumenti di programmazione assistita più diffusi - Claude Code di Anthropic, e i suoi omologhi. Quando uno di questi lavora a un compito lungo, il modello interviene per il passo semantico: che cosa significa questo codice, che cosa conviene scrivere adesso. Tutto il resto lo fa l’harness - decidere quali file leggere e quali no, tenere il contesto dentro i limiti, eseguire i comandi, leggere gli errori, ritentare con una strategia diversa, ricordare a che punto è il lavoro dopo cento passaggi, fermarsi quando ha finito.

Non è un’impressione: è misurato. Lo stesso modello, sugli stessi compiti, passa dal 46% all’80% di riuscita a seconda di come è costruito l’harness che lo avvolge. Uno studio di Stanford e Tsinghua riporta divari fino a sei volte a parità di modello, cambiando solo il modo in cui l’agente recupera i file, usa gli strumenti e gestisce il ciclo. Un articolo di posizione del maggio 2026, Stop Comparing LLM Agents Without Disclosing the Harness, ne trae la conseguenza e la formalizza. La chiama tesi del vincolo stringente: sui compiti lunghi, e fra modelli di capacità comparabile, la variabilità dei risultati dipende più da come è configurato l’harness che da quale modello si è scelto. Con un corollario scomodo per chi legge le classifiche: i protocolli di valutazione attuali attribuiscono al modello miglioramenti che appartengono all’harness, e ci sono casi documentati in cui la graduatoria fra due modelli si inverte cambiando solo l’infrastruttura intorno.

L’ambito della tesi va tenuto stretto: riguarda i compiti a orizzonte lungo fra modelli di livello simile. Su una singola domanda breve, o fra modelli di generazioni diverse, il modello torna a pesare di più.

Il che ribalta l’intuizione comune. Cambiando modello dentro un buon harness il salto è quasi sempre minore di quanto ci si aspetti; cambiando harness a parità di modello, il salto è quasi sempre maggiore.

È la ragione per cui la domanda «quale modello usate?» è quasi sempre la domanda sbagliata da fare a chi ha costruito un agente che funziona.

Il termine ha confini ancora mobili - c’è chi vi include la scelta del modello e chi no - e va saputo prima di usarlo in una discussione tecnica. Ma il concetto è utile proprio perché sposta la domanda: non quale modello scegliere, ma che bardatura serve a questo lavoro. È la stessa differenza fra comprare un cavallo e attrezzare un carro.

Modello, harness e protocolli: tre strati da non confondere

Modello, harness e protocolli vengono nominati spesso come se fossero la stessa cosa. Non lo sono, e il modo più rapido per tenerli distinti non è la definizione: è chiedersi che cosa puoi sostituire senza toccare il resto.

Strato	Che cos’è	Se lo sostituisci
Modello di linguaggio	La capacità semantica: capisce il testo e ne produce	Cambi fornitore o versione. Se l’harness è fatto bene, non tocchi nient’altro
Harness	Contesto, ciclo, definizione degli strumenti, verifica, registrazione	Cambi il comportamento dell’agente a parità di modello. È qui che si lavora davvero
Protocolli	Il modo in cui l’agente parla con gli strumenti, e in cui qualcuno parla con l’agente	Cambi con chi puoi collegarti, non cosa sai fare

Se sostituendo il modello devi riscrivere metà del sistema, l’harness non è un harness: è codice che ha il modello incorporato dentro.

Di com’è fatto dentro il primo strato - i token, i vettori, l’attenzione che li mette in relazione - si occupa la serie sul machine learning: là la scatola si apre, qui la si usa.

I protocolli si dividono a loro volta in due direzioni che è bene non mescolare. Verso gli strumenti: come l’agente chiede a una banca dati, a un servizio o a un’applicazione di fare qualcosa. Qui la frammentazione degli inizi si è risolta - il Model Context Protocol si è affermato come standard aperto ed è oggi adottato in modo trasversale dai principali fornitori, il che significa che uno strumento scritto una volta funziona con agenti diversi. Come sia fatto quel dialogo, e come si parlano fra loro due agenti di produttori diversi, lo racconta il pezzo sui protocolli della serie.

Verso l’agente: come una persona o un altro sistema interpella l’agente e ne riceve gli esiti. Questa direzione è ancora meno assestata, e chi costruisce oggi farebbe bene a trattarla come una scelta reversibile invece che come una fondazione.

La distinzione conta in pratica per una ragione sola: sono tre decisioni con tempi di vita diversi. Il modello cambia ogni pochi mesi, i protocolli ogni pochi anni, l’harness è il pezzo che resta ed è quello in cui vale la pena investire.

Due dei cinque pezzi vengono regolarmente sottovalutati.

L’orchestrazione è dove sta l’intelligenza pratica. Se l’utente chiede di estrarre dati da una banca dati e poi sintetizzarli in un rapporto, è l’orchestratore a stabilire che i passi sono due, in quell’ordine, e quali strumenti attivare. Quando si dice «l’agente ha deciso», nella grande maggioranza dei casi ha deciso l’orchestrazione - o, più spesso, l’ha deciso chi ha scritto le istruzioni.

Il monitoraggio non è un accessorio da aggiungere dopo. In sanità, finanza o pubblica amministrazione la tracciabilità delle decisioni è un requisito, non una buona pratica: bisogna poter dire cosa ha fatto l’agente, con quali dati e su quale base. Costruirlo alla fine significa quasi sempre non costruirlo.

Il modulo di ragionamento merita una precisazione. Può basarsi su intelligenza simbolica, su logiche formali, o su un misto di regole e reti neurali. In molti casi è lo stesso modello di linguaggio a fare da motore di ragionamento - ed è la soluzione più rapida. In contesti critici si preferisce affiancargli logiche più trasparenti, per una ragione semplice: di un ragionamento fatto dal modello si può leggere l’esito, non il percorso.

Come si guida un modello

Si guida con le istruzioni, non con il codice. Mostrargli tre esempi fatti bene risolve più problemi di quanto sembri.

Il modello si indirizza con il prompt, cioè l’insieme di istruzioni, esempi e contesto che gli si fornisce in linguaggio naturale - «comportati come un assistente del servizio clienti e rispondi con tono cortese». Queste istruzioni si fissano al momento della configurazione e orientano il comportamento dell’agente per tutte le richieste successive.

Una tecnica che conviene conoscere perché costa poco e rende molto è il few-shot prompting, cioè includere nel prompt qualche esempio di quello che si vuole ottenere: due o tre coppie di richiesta e risposta desiderata. Il modello generalizza dagli esempi senza bisogno di alcun addestramento. Quando una risposta esce nel formato sbagliato, prima di pensare a soluzioni complicate vale la pena provare a mostrargliene tre fatte bene.

In assenza di contesto chiaro il modello tende a produrre risposte generiche o a fraintendere la richiesta. Non è un difetto da correggere: è il modo in cui funziona.

Cosa sa fare davvero

Il vantaggio vero è lavorare su dati disordinati senza definire prima gli schemi.

Il vantaggio più concreto, e quello meno raccontato, riguarda i dati non strutturati. Un sistema di business intelligence tradizionale lavora su banche dati relazionali e interrogazioni rigide: perché funzioni, i campi vanno definiti prima. Un agente estrae concetti da documenti eterogenei - messaggi di posta, PDF, pagine web - senza schemi fissi decisi in anticipo.

L’esempio che rende l’idea: filtrare e comprendere migliaia di reclami arrivati via posta elettronica in un negozio in linea, classificandoli per problema e proponendo risposte. Con gli strumenti classici servirebbero campi predefiniti e procedure di estrazione e trasformazione da costruire prima di vedere il primo risultato.

Il secondo vantaggio è la riconfigurazione senza riscrittura. Un agente costruito per assistere i clienti si sposta su analisi di mercato o segnalazioni tecniche cambiando le istruzioni e gli strumenti collegati, non il codice. Il che sposta il costo dallo sviluppo alla progettazione delle istruzioni: meno lavoro tecnico, più lavoro di definizione.

Il terzo è l’adattabilità a domini specialistici. I modelli generalisti coprono un ampio spettro; su materie molto tecniche - medicina, finanza, manifattura - si possono raffinare modelli su dati verticali e ottenere accuratezza superiore senza costruire sistemi di regole.

Quanto costa: saperlo prima di decidere

Calcolo ricorrente, formazione delle persone, allucinazioni, responsabilità. Nessuno dei quattro è marginale.

Il costo di calcolo ed energetico. Far girare modelli grandi consuma risorse di calcolo specializzate, e il costo arriva sia in fattura sia sul piano ambientale. L’addestramento è enormemente più costoso, ma nella maggior parte dei casi si usano modelli già addestrati da terzi: il costo che riguarda quasi tutti è quello dell’uso quotidiano, ed è ricorrente.

La difficoltà di integrazione, che è un cambio di mentalità. Per adottare davvero un agente il personale deve capire come si scrivono le istruzioni e quali sono i limiti del modello. Si passa da processi rigidamente strutturati a un approccio più flessibile e più incerto: senza formazione, gli operatori scrivono istruzioni ambigue oppure si fidano di sistemi che nessuno sta controllando. Entrambi gli errori sono silenziosi.

Gli altri due si tengono insieme, perché il secondo è la conseguenza legale del primo. L’allucinazione - il contenuto inesatto prodotto con la stessa sicurezza di quello giusto - non è un difetto che una versione futura eliminerà: accompagna questi modelli per costruzione. E allora la responsabilità va chiarita prima, non dopo: chi risponde degli errori dell’agente, quali dati tratta, come si garantisce la conformità alle norme sulla riservatezza. Nelle fasi sensibili questo significa tenere l’essere umano nel ciclo - negli articoli in inglese lo si trova come human in the loop, sigla HITL.

E qui la distinzione è netta, perché le due formule che si somigliano non sono la stessa cosa. Human in the loop vuol dire che il sistema si ferma e aspetta l’approvazione di una persona prima di agire: quella persona ha l’autorità di bloccare. Human on the loop vuol dire che qualcuno guarda, e può intervenire dopo. La seconda è sorveglianza, la prima è un vincolo. Confonderle è comodo per chi vende e costoso per chi risponde.

Non è più solo buona pratica: sia l’articolo 14 del regolamento europeo sull’intelligenza artificiale sia il quadro di gestione del rischio del NIST richiedono una sorveglianza umana dimostrabile, cioè documentata e verificabile.

Ricapitolando, le quattro voci da mettere a preventivo:

• il calcolo, che è ricorrente: arriva a ogni uso, non una volta sola;
• la formazione delle persone, perché adottare un agente è un cambio di mentalità, e senza formazione gli errori sono silenziosi;
• le allucinazioni, che non si eliminano: si gestiscono;
• la responsabilità, da chiarire prima: chi risponde degli errori, con l’essere umano nel ciclo dove la fase è sensibile.

Quando non serve un agente

Se il processo è stabile, se serve una risposta esatta, o se non sai come misurare l’esito.

Senza questa domanda la descrizione resterebbe a metà: sapere di cosa è fatto uno strumento serve anche a riconoscere quando è quello sbagliato.

Un agente conviene quando il compito non è prevedibile in anticipo e i dati sono disordinati. Non conviene, e spesso è una complicazione costosa, in tre casi ricorrenti.

Quando il processo è stabile e ben definito: se i passi sono sempre gli stessi e gli scarti sono rari, un programma tradizionale costa meno, è più rapido, e soprattutto fa la stessa cosa tutte le volte.

Quando serve una risposta esatta e verificabile: un totale contabile, il calcolo di uno sconto, una regola normativa. Chiedere a un modello di calcolare ciò che una formula calcola con certezza aggiunge un rischio e non toglie lavoro.

Quando non esiste un modo di misurare se ha funzionato. È il caso più frequente e il più insidioso, perché non si vede all’inizio: senza un criterio per dire se l’esito è giusto, non si può migliorare l’agente né accorgersi che ha smesso di funzionare. Prima di costruirlo conviene rispondere a una domanda - come faccio a sapere che sta lavorando bene? Se la risposta non c’è, il problema da risolvere è quello, non l’agente.

---

I concetti che questo articolo introduce

Sedici voci con ambito e legami. Ogni articolo della serie aggiunge i propri, e insieme formano la mappa dei concetti del sito.

Fonti

• Yunbei Zhang et al., Stop Comparing LLM Agents Without Disclosing the Harness, arXiv:2605.23950, maggio 2026 - la tesi del vincolo stringente, la formalizzazione dell’harness come controllore di un sistema a ciclo chiuso, e i casi di inversione della graduatoria fra modelli. È da qui che viene la definizione di harness usata in questo articolo.
• From Question Answering to Task Completion: A Survey on Agent System and Harness Design, arXiv:2606.20683 - l’inquadramento generale e la tassonomia.
• Anand S. Rao e Michael P. Georgeff, BDI Agents: From Theory to Practice, ICMAS-95, AAAI, 1995 - la formalizzazione classica del modello BDI nominato nella sezione sulla storia: agenti con stati mentali (credenze, desideri, intenzioni) e regole di ragionamento simboliche, radicati nella filosofia dell’intenzione di Bratman. È il riscontro di prima mano su cosa erano gli agenti degli anni Novanta.
• Coding Agent Harness Benchmarks per il divario 46%–80% a parità di modello, e Harness Engineering per lo studio di Stanford e Tsinghua. Sono fonti di seconda mano: i numeri vanno presi come ordini di grandezza documentati, non come misure verificate qui.