Cos’è l’harness di un modello linguistico

“Ho passato il CSV a GPT e mi ha fatto il grafico.” “Opus mi ha sistemato il bug e ha lanciato i test.” Lo diciamo tutti, io per prima, ed è un modo comodo per raccontare ciò che abbiamo fatto. Però non è proprio il modo esatto. GPT e Opus sono nomi di modelli, e un modello linguistico, preso da solo, fa una cosa soltanto: riceve del testo e produce del testo.

Quando GPT “fa il grafico”, il modello in realtà scrive del codice (solitamente Python), e lì si ferma. Eseguirlo in un ambiente isolato, recuperare l’immagine che quel codice produce e mostrarcela è compito del software che gli sta intorno, e quel software si chiama harness. Ce n’è uno in ogni prodotto costruito su un modello linguistico, dalla chat più semplice all’agente che lavora per ore su un repository, e buona parte delle differenze tra un prodotto e l’altro, nella pratica, sta lì.

Per spiegare meglio cos’è l’harness, cosa fa e soprattutto perché è importante tenerlo ben distinto dal modello che esso chiama, vorrei procedere per gradi. Prima guardiamo cosa sa fare il modello da solo; poi due casi che molti conoscono, una chat e un agente di coding, in cui intorno al modello c’è via via più software. Da lì si arriva a una definizione, e a una conseguenza che si tende a trascurare: se ciò che un sistema sa fare dipende dall’harness, ne dipendono anche i suoi rischi.

Che cosa fa il modello

Testo in ingresso, testo in uscita. Tutto il lavoro di un modello linguistico, per quanto grande sia, sta in questo passaggio, e qualunque altra cosa gli attribuiamo avviene da un’altra parte.

Al modello arriva una sequenza di token (frammenti di parole; nei modelli multimodali anche le immagini vengono convertite in token) e ne genera un’altra, un token alla volta. Non ha altri canali verso l’esterno: qualunque cosa il modello “faccia” deve passare da quel testo in uscita.

Per fargli fare qualcosa di più che rispondere con del testo, gli si mette a disposizione un elenco di strumenti, i tool: cercare sul web, eseguire del codice, leggere un file e così via. Di ogni tool il modello conosce soltanto il nome e una breve descrizione (a cosa serve, quali parametri accetta).

Quando, per rispondere ad una domanda, stabilisce che gli occorre usare un determinato tool, il modello non lo usa direttamente, bensì comunica al software esterno di usarlo.

Da sinistra a destra: l’input, la richiesta di fare il grafico delle vendite dal CSV; il modello, token dentro e token fuori; l’output, che non è un grafico ma una richiesta di tool, esegui_codice, con le prime righe di codice Python. Sotto: nessun disco, nessun terminale, non vede i nostri file.

Scrive una richiesta in un formato concordato, che in sostanza dice “vorrei eseguire questo codice” oppure “vorrei cercare questa frase”, e si ferma lì. Quella richiesta è testo come tutto il resto, e per diventare un’azione ha bisogno di un programma che la legga, decida se eseguirla, la esegua e restituisca il risultato al modello, che a quel punto può andare avanti.

È la divisione dei compiti descritta anche nella documentazione di Anthropic: il modello produce la richiesta, l’esecuzione spetta all’applicazione o, per alcuni tool, ai server del fornitore. Quel programma è l’harness.

Anche una chat ha un harness

Molti, quando pensano a un modello linguistico, pensano a una chat, come se le due cose coincidessero. Ma non è proprio così.

La chat non è un modello; è un modello con intorno un po’ di harness. La gestione della storia della conversazione, la rigenerazione di un messaggio, il retry se qualcosa va storto, la gestione della finestra di contesto (la quantità di testo che il modello può leggere in una volta) quando si satura: tutto questo è harness. Il modello, di per sé, non ricorda nulla da un messaggio all’altro ed entra in scena solo quando l’utente preme invio. A quel punto l’harness ricompone la storia dei messaggi, la fa precedere da un prompt di sistema con le istruzioni del prodotto, aggiunge la nuova richiesta e manda il tutto al modello.

Per non parlare poi delle funzionalità ormai quasi date per scontate: la ricerca sul web, il caricamento e la gestione dei file dell’utente, una memoria che passa da una conversazione all’altra, l’esecuzione di codice in una sandbox. Il grafico dal CSV nasce così. Ognuna di queste funzionalità è un tool che il modello chiede e che l’harness esegue, per cui in un solo turno il modello può essere chiamato più volte: chiede il tool, l’harness lo esegue e lo richiama con il risultato, finché il modello non risponde senza chiedere altro.

Questo harness, però, lavora nel suo ambiente e non nel nostro. La sandbox non è il nostro computer, e il nostro progetto il modello non lo vede. Così, quando usiamo una chat per programmare, la parte di lavoro che tocca il nostro ambiente resta a noi: leggiamo il codice, decidiamo se fidarci, lo lanciamo, copiamo l’errore e lo incolliamo di nuovo nella chat. In quel tratto, diciamocelo, l’harness siamo noi.

Due schemi. Chat: dentro la cornice dell’harness ci sono il modello e una sandbox; fuori, a destra, il nostro progetto con codice, test ed errori; in mezzo una persona, noi, con frecce in entrambe le direzioni verso l’harness e verso il progetto: ogni giro passa da noi. Agente di coding: la cornice dell’harness contiene sia il modello sia il nostro progetto, con file, terminale e test; il modello chiede di lanciare i test e l’output torna nel contesto; la persona sta fuori, all’inizio e alla fine: nessuna persona in mezzo.

Dalla chat all’agente di coding

Un agente di coding come Claude Code o Codex usa gli stessi ingredienti della chat (conversazione, prompt di sistema, tool). Quello che cambia è dove agisce. L’agente lavora direttamente nel nostro ambiente: gira nel terminale, legge e modifica i file del progetto, esegue comandi. E dal momento che agisce lì, l’harness deve farsi carico delle decisioni che in chat restavano a noi, cioè cosa leggere, cosa eseguire e quando fermarsi. Per vedere come, basta seguire un compito dall’inizio alla fine, per esempio la richiesta di sistemare un test che fallisce.

1. L’harness prepara il contesto: la richiesta dell’utente, le istruzioni del progetto, l’elenco dei tool disponibili.
2. Il modello risponde chiedendo di lanciare i test.
3. L’harness controlla che il comando sia consentito, lo esegue nel terminale e raccoglie l’output. Un test fallisce con un errore sul formato di una data.
4. L’output torna al modello, che chiede di leggere il file in cui la data viene formattata, poi di modificarne due righe, poi di rilanciare i test.
5. I test passano. Il modello non chiede altro e scrive un breve riepilogo; l’harness restituisce il controllo all’utente.

Un ciclo in quattro nodi, contesto, modello, esecuzione, risultato, con i cinque passi dell’esempio annotati intorno: l’harness prepara il contesto con la richiesta, le istruzioni del progetto e i tool; il modello chiede di lanciare i test, non li lancia; l’harness controlla ed esegue, e un test fallisce sul formato di una data; il risultato torna nel contesto e il modello chiede di leggere un file, cambiarne due righe e rilanciare; i test passano, il modello non chiede altro e l’harness restituisce il controllo.

Questo giro si chiama ciclo agentico (agent loop) ed è lo schema di base di ogni agente: contesto, richiesta del modello, esecuzione, risultato, e di nuovo contesto (Bolin, 2026). Scritto così sembra semplice, e il ciclo in sé lo è. La complessità sta altrove, cioè nelle decisioni che in una chat prendevamo noi senza pensarci. L’harness deve sapere quali comandi l’agente può lanciare da solo, per quali serve una conferma dell’utente e quali sono vietati; deve fargli conoscere il progetto, di solito con un file di istruzioni nella radice del repository (AGENTS.md o CLAUDE.md); deve tenere sotto controllo una conversazione che, tra comandi e output, riempie presto la finestra di contesto. E deve decidere quando fermarsi.

Il modello sotto può essere lo stesso che usiamo in chat. Credo sia questo che strumenti come Claude Code, arrivato nel febbraio 2025, hanno reso evidente a molti sviluppatori: a parità di modello, ciò che il sistema poteva fare dipendeva da cosa l’harness gli permetteva di leggere, eseguire e modificare.

Che cos’è, allora, un harness

Con i due esempi davanti, la definizione viene quasi da sé: l’harness è tutto ciò che, in un sistema costruito su un modello linguistico, non è il modello. Per gli agenti circola la formula “agente = modello + harness” (Böckeler, 2026), a cui va aggiunto un terzo elemento, l’ambiente, cioè il posto in cui le azioni hanno effetto: la sandbox di una chat, il nostro repository, un browser. Vista così, la chat è solo il caso più semplice, quello in cui il ciclo si chiude quasi subito e il resto lo facciamo noi.

Il nome, per inciso, viene dai finimenti, le cinghie che collegano il cavallo al carro, e il parallelo regge abbastanza bene. Il modello è il cavallo, e ci mette la forza; l’harness sono i finimenti, che quella forza la trasformano in trazione e le danno una direzione; il carro, con quello che trasporta, è l’ambiente in cui il lavoro arriva.

Il modello, un blocco nero, sta dentro la cornice dell’harness; a destra, fuori dalla cornice, l’ambiente, dove le azioni hanno effetto: la sandbox di una chat, il nostro repository, un browser. Dentro la cornice: il contesto che entra nel modello, i tool, la freccia dell’esecuzione che va dal modello all’ambiente passando per un cancello, i limiti; il risultato che torna indietro; e in basso l’arresto.

Per quanto complesso sia, un harness si occupa, tendenzialmente, sempre delle stesse cinque cose:

• Contesto: che cosa il modello legge a ogni passo.
• Tool: quali strumenti può chiedere e come sono descritti.
• Esecuzione: come le sue richieste diventano azioni nell’ambiente, e come il risultato torna indietro.
• Limiti: che cosa si può fare senza chiedere, che cosa richiede una conferma, che cosa è vietato.
• Arresto: quando il lavoro è finito, o quando va interrotto.

Tra una chat e un agente di coding l’elenco resta lo stesso; a cambiare è quanto è sviluppata ciascuna voce.

Lo stesso schema, altri contesti

Gli agenti di coding sono l’esempio più citato perché lì il meccanismo si vede bene: i file cambiano, i test passano o falliscono. Lo stesso schema, però, si ritrova ovunque un modello debba fare qualcosa oltre a rispondere, e da un contesto all’altro a cambiare sono soprattutto i tool e i limiti.

Le funzioni di ricerca approfondita delle app di chat, per esempio, sono un harness costruito intorno alla ricerca web. Nel sistema descritto da Anthropic un agente principale pianifica la ricerca e la divide tra più sub-agenti che cercano in parallelo, ciascuno con la propria finestra di contesto; alla fine un altro agente collega ogni affermazione del rapporto alla fonte da cui viene (Hadfield et al., 2025). Gran parte del lavoro sull’harness, raccontano gli autori, è stata trovare la misura, visto che le prime versioni avviavano decine di sub-agenti anche per domande semplici. Qui il prodotto finale è un testo, e il controllo che conta è che ogni affermazione abbia una fonte.

Gli agenti che usano il computer o il browser hanno invece i tool di una persona seduta davanti a uno schermo: fare uno screenshot, cliccare, scrivere, scorrere la pagina. L’harness cattura lo schermo, lo passa al modello come immagine ed esegue il clic richiesto. Il contesto si riempie di immagini al posto delle righe di codice, e i limiti diventano concreti: su quali siti l’agente può muoversi, e quali azioni (un pagamento, l’invio di un modulo) devono passare dalla conferma di una persona.

Ci sono poi gli assistenti personali, come OpenClaw, che collegano un modello alle app di messaggistica (WhatsApp, Slack, Discord, Signal e altre) e restano attivi nel tempo. Qui l’harness si occupa soprattutto di cose che a un agente di coding servono poco: una memoria a lungo termine, le preferenze dell’utente e addirittura messaggi programmati che attivano il modello a una certa ora, senza che nessuno glielo chieda (Huang e Sun, 2026).

Infine un caso inventato, ma tipico: un assistente per il servizio clienti di un negozio online, con tool come “cerca l’ordine”, “verifica la spedizione”, “emetti un rimborso”. Il modello potrebbe essere lo stesso di una chat qualunque; a renderlo utilizzabile in un’azienda è l’harness, che stabilisce quali dati del cliente il modello può vedere, fino a che cifra può rimborsare da solo prima di passare la richiesta a un operatore e che traccia resta di ogni azione.

In tutti questi casi il ciclo è lo stesso del test che fallisce. A distinguere un prodotto dall’altro sono le informazioni a cui il modello accede, gli strumenti che può chiedere e le azioni che gli sono permesse.

Harness engineering

Progettare queste scelte è diventato un lavoro con un nome, harness engineering, in circolazione dal febbraio 2026 (Lopopolo, 2026). In pratica significa decidere quali tool offrire e come descriverli, cosa mettere nel contesto e cosa lasciare fuori, quali azioni consentire senza conferma e che controlli far girare dopo ciascuna.

E non riguarda solo chi costruisce i prodotti. Anche chi lavora con un agente di coding fa harness engineering, ogni volta che scrive il file di istruzioni del progetto o aggiunge un test che l’agente può lanciare per verificare il proprio lavoro. Böckeler distingue tra ciò che orienta l’agente prima che agisca, come le istruzioni, e ciò che lo corregge dopo, come test e linter, e osserva che servono entrambi: con le sole istruzioni l’agente non sa se le ha seguite, con i soli controlli ripete gli stessi errori.

Guide prima di agire

prompt di sistema, convenzioni nel repository, definizioni degli strumenti

Agente

Sensori dopo, per correggersi

computazionali: linter, test, CI
inferenziali: un secondo modello che rilegge

il risultato torna all’agente

Senza sensori

ripete gli stessi errori

Senza guide

codifica regole senza sapere se funzionano

Un flusso da sinistra a destra: le guide (prompt di sistema, convenzioni nel repository, definizioni degli strumenti) orientano l’agente prima che agisca; i sensori osservano il risultato, computazionali come linter, test e CI, o inferenziali come un secondo modello che rilegge, e lo rimandano all’agente. Sotto: senza sensori l’agente ripete gli stessi errori; senza guide codifica regole senza sapere se funzionano.

Lopopolo, raccontando un progetto di OpenAI in cui tutto il codice era scritto da Codex, nota che un unico file di istruzioni lungo funzionava peggio di un indice di un centinaio di righe che rimandava alla documentazione nel repository. Il motivo vale anche fuori dal coding: per un agente, quello che non può leggere non esiste.

Prima un file solo

AGENTS.md

• occupa contesto
• tutto sullo stesso piano
• invecchia subito

Dopo un indice e una directory

AGENTS.md circa cento righe che puntano altrove

• docs/
• architettura/
• decisioni/
• piani/
• specifiche/
• riferimenti/

decisione presa su Slack per l’agente non esiste

Prima: un unico file AGENTS.md lungo, che occupa contesto, mette tutto sullo stesso piano e invecchia subito. Dopo: un AGENTS.md di circa cento righe che fa da indice e punta a una directory docs con sottocartelle come architettura, decisioni, piani, specifiche, riferimenti. Una decisione presa su Slack, barrata, per l’agente non esiste.

Si valuta il sistema, non solo il modello

Come abbiamo visto, l’harness incide molto sulle capacità di un sistema di AI generativa (si noti bene, un sistema di AI, non un modello).

Questo però non vuol dire che il modello non conti. I modelli più recenti sono addestrati a lavorare dentro questo ciclo, e nello stesso harness un modello più debole ottiene risultati peggiori. Su Agents’ Last Exam, un benchmark di compiti professionali lunghi, cambiare modello a parità di harness sposta la percentuale di compiti risolti di 18 punti; cambiare harness a parità di modello, di 5 o 6 (Huang e Sun, 2026). Il confronto però, va detto, riguarda solo modelli “forti”.

Cambiare modello a parità di harness

18 punti

Cambiare harness a parità di modello

5 o 6 punti

Compiti professionali lunghi; il confronto riguarda solo modelli forti.

Due barre in punti percentuali. Cambiare modello a parità di harness: 18 punti. Cambiare harness a parità di modello: 5 o 6 punti. Compiti professionali lunghi; il confronto riguarda solo modelli forti.

I componenti dell’harness, poi, invecchiano. Anthropic aveva aggiunto a un proprio harness un meccanismo per azzerare periodicamente il contesto, perché Claude Sonnet 4.5 tendeva a chiudere il lavoro in anticipo quando la finestra si riempiva; lo ha tolto quando, con Opus 4.5, quel comportamento è quasi sparito (Rajasekaran, 2026).

Contano quindi entrambi, e quello che osserviamo appartiene sempre all’insieme. Quando leggiamo che un modello “è migliore” su un benchmark di agenti, stiamo leggendo il risultato di quel modello dentro un certo harness, su un certo tipo di compito.

Per la sicurezza vale lo stesso, ed è lì che la distinzione pesa di più. Un modello può essere valutato con cura, ma sapere che in una chat si comporta bene dice poco su cosa succede quando lo si mette in un harness che gli dà accesso a un terminale, a una casella di posta o a un sistema di rimborsi. In una chat, nel caso peggiore, il modello scrive un testo sbagliato; dentro un agente può cancellare un file, mandare una mail, spendere soldi. E quanto può fare non lo decide il modello, bensì i permessi, la sandbox e le conferme richieste: l’harness, appunto.

A sinistra il testo che il modello legge, con dentro una riga evidenziata: un’istruzione per lui. Il testo entra nel modello, che sta nella cornice dell’harness. Dal modello partono tre frecce, ciascuna con un cancello: i permessi davanti a cancellare un file, la sandbox davanti a inviare una mail, le conferme davanti a spendere denaro; quanto passa lo decide l’harness. In una chat non c’è niente oltre il testo di risposta: al peggio, sbagliato.

Il caso tipico è la prompt injection: istruzioni rivolte al modello e nascoste in un testo che il modello leggerà. Un agente legge di continuo testo che non abbiamo scritto noi (pagine web, email, documenti, output di altri programmi), e se il modello segue quelle istruzioni il danno dipende da ciò che l’harness gli permette di fare. Anthropic racconta che nella prima versione della sua infrastruttura per agenti il codice scritto dal modello girava nello stesso ambiente delle credenziali: a un’istruzione malevola sarebbe bastato convincere il modello a leggerle. Invece di affidarsi al buon comportamento del modello, le credenziali sono state spostate dove il codice dell’agente non può arrivare (Martin et al., 2026). Anche aggiungere un tool cambia il quadro: in Codex, per esempio, la sandbox protegge il terminale, mentre i tool aggiunti tramite MCP i propri limiti devono imporseli da soli (Bolin, 2026).

Chi deve decidere se usare un agente, in azienda o anche solo sul proprio computer, ha quindi una domanda in più da farsi, oltre a “quale modello usa?”: cosa può fare, con quali dati, e chi deve confermare cosa.

Che cosa resta

Ogni prodotto costruito su un modello linguistico ha tre parti. Il modello legge e scrive testo, comprese le richieste di usare un tool; l’harness decide cosa il modello vede, esegue le sue richieste, mette i limiti e stabilisce quando fermarsi; l’ambiente è dove le azioni hanno effetto. Una chat ha un harness semplice che agisce in una sandbox, un agente di coding ne ha uno più complesso che agisce nel nostro repository, e un agente di ricerca, un agente che usa il browser o un assistente aziendale ne hanno altri ancora, con tool e limiti diversi.

La prossima volta che sentiamo dire “GPT ha fatto”, la traduzione più fedele è questa: un modello ha proposto, un harness ha eseguito, in un ambiente che qualcuno ha preparato. Ne vengono tre abitudini pratiche: quando qualcosa va storto, guardare all’harness oltre che al prompt; quando si confrontano due modelli, chiedersi se si stanno confrontando anche due sistemi; quando si valuta se un agente è sicuro, chiedersi a cosa ha accesso, prima ancora di quale modello usa.

Chi vuole vedere un harness dall’interno può partire dal post di OpenAI sul ciclo di Codex; chi vuole migliorare quello intorno all’agente che usa già trova nell’articolo di Böckeler un buon punto di partenza.

Fonti

• Anthropic, Tool use with Claude, documentazione (pagina senza data).
• Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com, 2 aprile 2026.
• Michael Bolin, Unrolling the Codex agent loop, OpenAI, 23 gennaio 2026.
• Jeremy Hadfield et al., How we built our multi-agent research system, Anthropic, giugno 2025.
• Yixiao Huang, Yiyou Sun, Does the Harness Matter? Lessons from ALE-Claw on Agents’ Last Exam, 11 giugno 2026.
• Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world, OpenAI, 11 febbraio 2026.
• Lance Martin, Gabe Cemaj, Michael Cohen, Scaling Managed Agents: Decoupling the brain from the hands, Anthropic, 8 aprile 2026.
• Prithvi Rajasekaran, Harness design for long-running application development, Anthropic, 24 marzo 2026.