Nov 5, 2026 · @Nunzio Fiore
Il salto non è venuto solo dai modelli
Negli ultimi due anni gli agenti sono migliorati più di quanto siano migliorati i modelli che li fanno funzionare. La differenza l'ha fatta quello che sta intorno al modello, e che oggi ha un nome: harness.
Un harness è il sistema che permette a un modello linguistico di agire come agente. Nella definizione che Google Research dà nel repository di Harness², è «il sistema intorno a un modello che gli permette di agire come agente»: il prompt che gli dice chi è e cosa deve fare, gli strumenti che può chiamare, la memoria che conserva fra una sessione e l'altra, le skill che descrivono come si fa un lavoro, i subagenti a cui può delegare. Il modello è il motore. L'harness è l'automobile.
La prova più semplice è questa: lo stesso modello, dentro due harness diversi, dà risultati diversi. È il motivo per cui si parla di harness engineering, ed è il motivo per cui a questa parola vale la pena dedicare un articolo intero: perché l'harness fa due lavori, e quasi tutti ne raccontano uno solo.
I due lavori dell'harness
Il primo lavoro è rendere capace il modello. Il secondo è tenerlo nei limiti. Quasi tutta la ricerca parla del primo; un'azienda ha bisogno di tutti e due.
i due lavori dell’harness
La cerchia interna è quella di cui si parla quando si dice harness engineering: il prompt che dà all'agente ruolo e istruzioni, gli strumenti che può chiamare, la memoria fra una sessione e l'altra, le skill che descrivono come si fa un lavoro, i subagenti a cui delegare. Più è fatta bene, più lo stesso modello rende.
La cerchia esterna è quella che decide cosa l'agente può raggiungere e per conto di chi: i permessi strumento per strumento, l'identità della persona che chiede, le credenziali che il modello non vede, le regole dell'azienda, la verifica degli esiti, il registro. Non rende l'agente più bravo. Rende possibile lasciarlo lavorare.
Le due cerchie hanno proprietari diversi. La prima la migliora chi costruisce l'agente, e può migliorarla anche l'agente stesso, sotto approvazione. La seconda la cambia solo l'amministratore, e nessun ciclo automatico la tocca. Tenere separate le due cerchie è la decisione di architettura da cui discende tutto il resto.
Da dove viene la parola
Harness ha due significati in inglese, e tutti e due servono. Nel software è l'impalcatura di prova: il test harness, il codice che circonda un programma per farlo girare in condizioni controllate e osservarne il comportamento. Fuori dal software sono i finimenti: le cinghie che tengono il cavallo, lo guidano e, insieme, gli lasciano la forza di tirare.
Quando la parola è passata agli agenti ha portato con sé soprattutto il primo significato, quello dell'impalcatura che rende possibile il lavoro. Il secondo è rimasto sullo sfondo, ed è un peccato, perché dice la parte che in azienda conta di più.
In italiano esiste una parola che tiene insieme entrambi i sensi: imbracatura. Tiene, guida, e lascia muovere. Nelle prossime pagine useremo harness, perché è la parola con cui il mercato parla, ma il senso che le diamo è quello.
La strada degli harness
In due anni l'harness è passato da segreto industriale a oggetto che un agente può riscrivere da solo. Le tappe sono quattro.
- Harness privati. I primi agenti di programmazione di largo uso, come Claude Code e Codex, hanno dimostrato quanto conti l'impalcatura: la gestione del contesto, il ciclo di prova e correzione, gli strumenti. Quell'impalcatura era, ed è, chiusa dentro il prodotto.
- Harness modulari. Sono arrivati progetti in cui ogni pezzo dell'harness si smonta e si rimonta: prompt, strumenti, memoria e orchestrazione come componenti separati, da combinare.
- Harness aperti. Gli stessi componenti sono diventati open source, e con loro la possibilità di studiare come un harness è fatto e di adattarlo ai propri compiti.
- Harness che si migliorano da soli. È il passo di Harness², un framework di ricerca di Google Cloud AI Research e Northwestern University, con codice Apache 2.0.
Harness² merita qualche riga in più, perché cambia la domanda. L'idea è tenere fermi i pesi del modello e far evolvere solo l'impalcatura. Sul compito di oggi l'agente esegue una prima volta e lascia una traccia; poi propone varianti del proprio harness, le prova una contro l'altra e tiene la combinazione che si comporta meglio. Lo fa senza un verificatore esterno e senza conoscere la risposta giusta: confronta i comportamenti, non i risultati con una soluzione nota. Il secondo livello riguarda i compiti di domani: le lezioni imparate finiscono in un harness di secondo grado, che l'agente si porta dietro e usa per migliorare la volta dopo. Da qui l'esponente nel nome.
Nei benchmark riportati dagli autori, su compiti di lavoro professionale, i miglioramenti arrivano fino a 11,8 punti, con GLM-5 e Gemini 3.5 Flash come modelli di base. Il framework si appoggia a un harness esistente invece di sostituirlo, e ogni ciclo di miglioramento consuma chiamate ai modelli: è un costo da mettere a bilancio quando lo si valuta.
La domanda del verificatore
Un harness che si migliora da solo pone una domanda che prima non c'era: chi decide se la modifica è buona?
In Harness² la risposta è l'agente stesso, che confronta le varianti fra loro e sceglie. È la parte più interessante del lavoro, perché nel mondo aperto, dove i compiti arrivano senza una risposta già nota, un verificatore esterno spesso non esiste. Togliere il verificatore è ciò che rende il metodo generale.
In un'azienda la stessa scelta ha un costo diverso. Un agente che lavora sul gestionale, sulla posta o sui documenti produce effetti su persone e sistemi veri, e il suo racconto di come è andata è convincente anche quando è sbagliato. Qui il verificatore non si può togliere: deve essere una persona che ne risponde, con il tempo e le prove per decidere.
Le due posizioni non si contraddicono. Descrivono due lavori diversi dell'harness. Il primo lavoro è rendere capace il modello, e lì il miglioramento automatico è una leva potente. Il secondo lavoro è tenere il modello nei limiti, e lì l'ultima parola resta a chi risponde del risultato. Un harness aziendale deve fare tutti e due.
L'harness di un agente AIsuru
Un agente AIsuru è un harness completo, con la cerchia interna costruita dalle persone dell'azienda e la cerchia esterna applicata dalla piattaforma.
Pezzo per pezzo, con il nome che ha nel catalogo:
Sopra questo harness gira il ciclo di evoluzione del Vibe Coder, lo stesso schema di Harness² con una differenza al centro.
il ciclo di evoluzione di un agente AIsuru
L'agente lavora, si misura sulle domande a cui non ha saputo rispondere e sulle statistiche, propone modifiche al proprio prompt, ai contenuti e alle skill. Al passo quattro non c'è un confronto automatico fra varianti ma il proprietario, che approva o scarta; al passo cinque ogni modifica applicata resta registrata e si può riportare indietro. La cerchia esterna non entra nel ciclo: permessi, credenziali, regole e identità stanno nel gateway, dove nessuna proposta dell'agente arriva.
Provare più varianti prima di proporle, e il confine
C'è un'idea precisa su cui le due strade convergono: provare più varianti sui casi reali prima di proporle. Oggi il ciclo di evoluzione di un agente AIsuru presenta al proprietario una proposta e il suo perché. Il passo successivo, su cui stiamo lavorando, è presentargli due o tre varianti del prompt già messe alla prova sulle ultime domande rimaste senza risposta, con l'esito di ciascuna accanto. Il proprietario continua a decidere, ma decide con le prove e non con un'opinione.
Il confine resta dov'è, e va detto con chiarezza. Dentro l'harness che si evolve stanno il prompt, i contenuti, le skill e le viste delle applicazioni: ciò che riguarda come l'agente lavora. Fuori, nel gateway, stanno i permessi per strumento, le credenziali, le regole aziendali e l'identità di chi chiede: ciò che riguarda cosa l'agente può raggiungere. La prima metà può migliorare da sola, sotto approvazione. La seconda la cambia solo l'amministratore, e nessun ciclo automatico la tocca.
È la stessa separazione che Harness² applica ai pesi del modello: tenerli fermi mentre l'impalcatura cambia. Noi la applichiamo anche al perimetro: tenerlo fermo mentre l'agente migliora.
Tre harness a confronto
Le differenze non sono di qualità ma di destinazione: ogni harness nasce per qualcuno, e quel qualcuno decide tutto il resto.
Sotto «harness per sviluppatori» stanno gli agenti di programmazione e gli harness modulari e aperti della strada descritta sopra: strumenti eccellenti per chi programma, nessuno dei quali nasce per cento persone con permessi diversi sugli stessi sistemi.
L'harness ha due lavori
Il modo più onesto di chiudere è dire da dove partiamo. L'harness rende capace il modello e lo tiene nei limiti; la ricerca sta facendo passi grandi sul primo lavoro, e li seguiamo con interesse. Noi siamo costruiti attorno al secondo, con il primo dentro, perché è quello che un'azienda chiede quando lascia un agente lavorare sui propri sistemi: sapere chi ha deciso, con quali permessi, e poterlo rileggere.
Per vedere come è fatto l'harness di un agente AIsuru sui vostri processi: demo@memori.ai, oggetto DEMO SUITE.
Fonti
- Harness²: Recursive Agent Harnessing for an Open World, arXiv, 9 ottobre 2026
- Repository google-research/harness2, codice Apache 2.0
- Scheda di AIsuru Vibe Coder, dove è descritto il ciclo di evoluzione
- Scheda di AIsuru Skills, con la skill squadra-di-agenti
- Catalogo dei connettori AIsuru