Se avete usato un assistente AI — ChatGPT, Claude, Gemini — avete sperimentato la stessa cosa: funziona benissimo su un singolo compito, ma appena gli chiedete di fare qualcosa, tipo cercare un dato in un database, aggiornare un foglio di calcolo e mandarvi una email con il riassunto, la qualità crolla. Dimentica metà strada, si inventa strumenti inesistenti, si blocca su un passaggio semplice.

Il problema non è il modello. Il problema è quello che gli sta intorno.

Negli ultimi mesi del 2026 si è consolidata una nuova disciplina chiamata harness engineering — letteralmente “ingegneria del cablaggio” — che studia esattamente questo: come costruire il runtime che trasforma un modello linguistico in un agente funzionante. Non è teoria: un paper del luglio 2026 (arXiv 2609.00006) ha analizzato undici sistemi di produzione — Claude Code, Codex CLI, Gemini CLI, Aider, OpenHands e altri — e ha definito per la prima volta l’anatomia di un harness.

Questo articolo spiega cos’è, perché è nata, e cosa cambia per chi deve far funzionare l’AI in un contesto aziendale reale.

Cos’è un harness (e perché non è il modello)#

Partiamo da una distinzione semplice. Tutti i tool AI che usate hanno due parti:

  1. Il modello: il cervello, addestrato su enormi quantità di testo, che sa leggere, scrivere e ragionare. Può essere GPT, Claude, Gemini, Llama, DeepSeek — è il componente che “pensa”.

  2. L’harness: tutto il resto. Il codice che decide quali informazioni dare al modello, quali strumenti puó usare, in che ordine eseguire i passaggi, come verificare che il risultato sia corretto, e come riprovare se qualcosa va storto.

Senza harness, un modello è come un laureato in lettere chiuso in una stanza senza finestre, senza telefono, senza libri e senza carta: intelligentissimo, ma completamente inutile per qualsiasi compito pratico.

L’harness è ciò che apre quella stanza: gli dà accesso ai file, al browser, al database, alla posta, e gli dice “primo fai questo, poi controlla che sia giusto, e se sbagli riprova in un altro modo”.

La scoperta che ha fondato una disciplina#

Nel luglio 2026, un gruppo di ricercatori ha pubblicato un paper che ha fatto il giro del settore: “Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents” (arXiv 2609.00006). Hanno analizzato undici sistemi di produzione reali, per un totale di circa 4 milioni di righe di codice tra Python, TypeScript e Rust.

La scoperta principale? Nessuno di questi sistemi usa framework generalisti come LangChain, CrewAI o AutoGen. I sistemi che funzionano in produzione usano tutti loop custom scritti a mano, senza retrieval vettoriale, senza orchestrazione multi-agente. Il campo, insomma, è molto meno complesso di quanto si creda — e molto più artigianale.

Il paper ha definito sette sottosistemi canonici che ogni harness di produzione implementa, in varia misura:

1. Agent Loop#

Il ciclo principale: “prendi il prossimo step, eseguilo, controlla il risultato, ripeti”. Può essere sequenziale (un passo alla volta) o parallelo (più operazioni contemporanee). La scelta più comune nei sistemi analizzati? Un loop asincrono artigianale, non un framework.

2. Tool System#

L’insieme degli strumenti che l’agente può usare: filesystem, terminale, browser, repository Git, API esterne. La sfida è dare al modello abbastanza strumenti per essere utile, ma non troppi da confonderlo.

3. Context Management#

Cosa finisce nella “vista” del modello. La gestione del contesto è il problema più difficile: un agente che lavora su un progetto complesso accumula decine di migliaia di token di contesto. Decidere cosa tenere, cosa tagliare e cosa recuperare al volo è ciò che separa un harness funzionante da uno che annega nei dettagli.

4. Safety Controls#

Limiti espliciti su cosa l’agente può e non può fare. Non si tratta solo di “non cancellare file importanti”, ma di cose più sottili: non modificare file che non sono stati esplicitamente autorizzati, non eseguire comandi in produzione senza approvazione, non inviare dati sensibili a server esterni.

5. Orchestration#

Coordinamento tra più agenti o tra passaggi complessi. Chi fa cosa, in che ordine, cosa succede se uno fallisce. Nella pratica, la maggior parte dei sistemi usa orchestrazione piatta (un agente singolo con molti strumenti) piuttosto che multi-agente.

6. Verification#

Codice che controlla il lavoro dell’agente prima che arrivi a voi. Due tipi di controllo: regole fisse (es. “ogni numero citato deve esistere in un file letto”) e revisione AI (un secondo modello che giudica il risultato). La combinazione dei due è ciò che rende gli agenti affidabili.

7. Extension Surfaces#

I punti di connessione con l’esterno: server MCP (Model Context Protocol), skills, API. È la parte che evolve più velocemente.

Lo stesso modello, due risultati completamente diversi#

Per capire quanto conta l’harness, basta un dato concreto: lo stesso modello, con un harness diverso, può avere una differenza di prestazioni fino a 6 volte sullo stesso benchmark. Non è un errore di misura: è la differenza tra un agente che funziona e uno che sembra rotto.

Il paper di Meta-Harness (arXiv 2603.28052) ha dimostrato che un sistema automatico che cerca e ottimizza harness può superare quelli progettati a mano, migliorando punteggi del 7-8% su compiti complessi. E la ricerca procede: altri lavori recenti hanno introdotto la co-evoluzione di rubriche e harness (RuHarness) e la selezione adattiva dei task di evoluzione (SSR), tutti con miglioramenti misurabili.

Tradotto: non stiamo solo scoprendo come sono fatti gli harness. Stiamo imparando a farli evolvere da soli.

Cosa cambia per una PMI italiana#

Tutto questo discorso sembra roba da ingegneri che lavorano a OpenAI o Anthropic. In parte lo è. Ma ha conseguenze molto pratiche per chiunque voglia usare agenti AI in azienda oggi.

Non comprate framework, comprate soluzioni#

Se state valutando un tool AI per la vostra azienda — sia un agente come Hermes Agent, sia un servizio cloud — fate una domanda semplice: qual è l’harness? Non “che modello usa?”, ma “come è cablato?”.

Un tool con un modello mediocre ma un harness solido è quasi sempre più utile di uno con il modello migliore in assoluto ma un harness approssimativo. Perché l’harness determina cose concrete: se l’agente ricorda le conversazioni precedenti, se riesce a usare i vostri strumenti aziendali, se si blocca o riprova quando qualcosa va storto.

Il fattore MCP#

Il Model Context Protocol (MCP) è diventato lo standard di fatto per collegare agenti a strumenti esterni, al punto che il paper di Barbaste lo cita come adottato in 8 degli 11 sistemi analizzati (contro 9 per le skills). Se un agente supporta MCP — e la maggior parte ormai lo fa — può connettersi a database, CRM, sistemi di fatturazione, Google Calendar, Slack, GitHub, senza integrazioni custom.

Per una PMI, questo significa: non dovete aspettare che il vostro fornitore di software rilasci un’integrazione. Se esiste un server MCP per quello strumento, funziona. Bloomberg, Red Hat, Cloudflare, AWS — tutti stanno investendo su MCP come infrastruttura standard.

Skills e standard aperti#

L’altro standard che conta è quello delle skills: istruzioni strutturate che insegnano all’agente come eseguire un compito specifico. Skills over MCP (SEP-2640) è l’ultima evoluzione: le skills diventano distribuibili attraverso server MCP, in modo che un agente possa scoprire e imparare procedure nuove al volo.

Per una PMI, la conseguenza è che le competenze degli agenti diventano componibili e condivisibili — non dovrete addestrare l’agente da zero per ogni procedura aziendale.

I limiti da conoscere#

Harness engineering non è una bacchetta magica. Ci sono questioni aperte:

  • La sicurezza è ancora un problema aperto. Un harness mal configurato può dare a un agente accesso a strumenti che non dovrebbe usare. Il paper dell’ACM su MCP elenca 16 scenari di minaccia distinti.
  • Non tutti gli strumenti hanno un server MCP. Se usate un gestionale di nicchia, l’integrazione va costruita.
  • L’evoluzione automatica degli harness è ancora sperimentale. Funziona in laboratorio, ma in produzione la maggior parte delle aziende li progetta ancora a mano.
  • Più harness non significa sempre meglio. Aggiungere complessità a un sistema che già funziona rischia di peggiorarlo.

In pratica: come valutare un agente AI#

Riassumiamo in una checklist pratica. Quando valutate un agente AI per la vostra azienda:

  1. Che loop usa? È sequenziale o parallelo? Gestisce il fallimento? Riprova in automatico?
  2. Quali strumenti sa usare? Filesystem? Database? Browser? Email? I vostri strumenti specifici?
  3. Come gestisce il contesto? Quanto ricorda? Dove finiscono le informazioni che raccoglie?
  4. Che controlli di sicurezza ha? Può fare cose senza approvazione? Dove sono i limiti?
  5. Supporta MCP? Quanti server ci sono per i vostri strumenti?
  6. Impara procedure? Potete insegnargli un flusso di lavoro una volta e poi richiamarlo?
  7. Lo potete ispezionare? Se fa qualcosa di sbagliato, riuscite a capire perché?

L’ultimo punto è forse il più importante. Un harness ben progettato produce tracce verificabili di ogni decisione, in modo da poter capire cosa è successo quando — non se — l’agente sbaglia.

La lezione principale#

Il modello non è il prodotto. L’harness è il prodotto.

Per anni il settore AI ha parlato quasi solo di modelli: parametri, benchmark, nuovi record. Ma la differenza tra una demo impressionante e un sistema che funziona in produzione non sta nel modello. Sta in quel sottile strato di codice che decide cosa vedere, cosa fare e come verificare.

Per una PMI italiana che vuole usare agenti AI oggi, la domanda giusta non è “qual è il modello migliore?”. È: “questo sistema è cablato per funzionare nel mio contesto?”.

Se la risposta è sì, avete trovato qualcosa che può davvero cambiare il vostro modo di lavorare. Se è no, aspettate — perché la disciplina dell’harness engineering sta rendendo ogni agente migliore, un cablaggio alla volta.

Fonti: arXiv 2609.00006 (Barbaste et al., “Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents”), arXiv 2603.28052 (“Meta-Harness”), arXiv 2610.36826 (“RuHarness: Rubric–Harness Co-Evolution”), arXiv 2604.25850 (“Agentic Harness Engineering”), arXiv 2607.08028 (“From Prompts to Contracts”), ACM (“Model Context Protocol: Landscape, Security Threats, and Future Research Directions”), ignorance.ai (“The Emerging Harness Engineering Playbook”).