I LLM (Large Language Model), per quanto potenti, presentano vincoli intrinseci che ne impediscono l’uso diretto in compiti complessi e prolungati:
Finestra di contesto limitata e assenza di memoria persistente. Ogni sessione riparte da zero: un LLM non ricorda ciò che è accaduto nella sessione precedente. Per compiti di automazione di processo che richiedono ore o giorni di lavoro questa sorta di amnesia è fatale.
Incapacità di effettuare interazioni con l’ambiente virtuale o fisico circostante. Gli LLM producono esclusivamente testo. Non possono eseguire codice, interrogare database, navigare il web o interagire con API esterne senza un layer intermedio che traduca le loro “intenzioni testuali” in azioni reali.
Mancanza di pianificazione e auto-verifica. Senza struttura esterna, i LLM tendono a tentare di risolvere il compito assegnato in un colpo solo (“one-shotting”), perdendo il filo a metà di compiti complessi. Inoltre, tendono a dichiarare completato il compito senza alcuna reale verifica.
Lentezza e variabilità. A differenza del software tradizionale che opera in millisecondi, gli LLM impiegano diversi secondi per generare le singole risposte, producendo output di qualità variabile.
Gli enormi investimenti effettuati per scalare le dimensioni dei modelli e dei dataset di addestramento non hanno risolto questi problemi e la maggior parte dei ricercatori è oramai concorde nel fatto che la tecnologia alla base dei LLM abbia dei limiti strutturali e intrinseci.
La possibilità di produrre strumenti e soluzioni in grado di essere efficaci nei contesti di produzione reali in cui operano le aziende richiede un approccio architetturalmente diverso.
Su questo nuovo approccio sono basati i prodotti come Claude Cowork o OpenClaw, la cui efficacia è risultata talmente evidente da movimentare i mercati azionari allarmati dalla possibile obsolescenza dei prodotti basati sul tradizionale paradigma PaaS.
Per descrivere questo nuovo modello architetturale viene utilizzato il termine harness.
Cos’è un agent harness
Un agent harness è l’infrastruttura software che avvolge un LLM e gestisce tutto ciò che non è il modello stesso.
Philipp Schmid (Google Deep Mind) ha proposto un’analogia efficace: immaginando il modello LLM come la CPU del nostro sistema, la finestra di contesto sarebbe la RAM disponibile, l’agente sarebbe l’applicazione e l’harness sarebbe il sistema operativo, cioè il software che gestisce le risorse, fornisce interfacce standard verso driver e periferiche e controlla il ciclo di vita dell’elaborazione.
Così come la reale potenza e capacità di un PC o di un server non dipende solo dalla potenza della CPU ma è il risultato dell’architettura complessiva, inclusa la qualità del sistema operativo, analogamente la capacità e l’efficacia di uno strumento agentico dipende, oltre che dal modello LLM, anche e soprattutto dalla qualità dell’harness.
Ethan Mollick, autore del libro “Co-Intelligence: Living and Working with AI”, pubblicato in italiano come “L’intelligenza condivisa”, nella sua guida aggiornata a febbraio 2026, ha introdotto la distinzione tra modello, app e harness come le tre dimensioni fondamentali per valutare un sistema IA: “lo stesso modello può comportarsi in modo molto diverso a seconda dell’harness in cui opera”.
La nostra personale convinzione, derivata dall’esperienza sul campo nell’automazione attraverso l’IA dei processi aziendali dei nostri clienti, è che delle tre dimensioni citate da Mollick la più importante e decisiva sia proprio l’harness.
Evidenze a favore: l’harness conta più del modello
Diverse evidenze empiriche e osservazioni di settore convergono su questa nostra conclusione.
Anthropic, ad esempio, ha documentato come il modello Claude Opus 4.5, pur essendo un modello frontier, fallisse sistematicamente nella costruzione di applicazioni web complesse senza un harness adeguato.
Con un harness strutturato — agente inizializzatore, file di progresso, vincolo di lavoro incrementale, verifica end-to-end via browser automation — lo stesso modello è diventato capace di mantenere il focus e la coerenza del software in processi di sviluppo composti da decine di sessioni, spesso condotte in parallelo, ciascuna nell’ambito della propria finestra di contesto.
Come ulteriore esempio, il paper “General Modular Harness for LLM Agents in Multi-Turn Gaming Environments” (ICML 2025) ha dimostrato che un singolo LLM (classe GPT-4), equipaggiato con un harness modulare composto da moduli di percezione, memoria e ragionamento, ha migliorato il tasso di vittoria in tutti i giochi testati rispetto allo stesso modello senza harness.
Il fatto che nei due test il modello sia stato mantenuto esattamente lo stesso rende evidente che la differenza tra una soluzione IA con prestazioni production ready e un prototipo che sia poco più di una semplice proof of concept è fortemente incentrata sulla capacità di progettare e implementare buoni harness.
L’harness engineering ha sostituito il prompt engineering nelle best practices di implementazione di soluzioni IA a livello enterprise.
La scelta del modello resta rilevante per compiti avanzati
Ma attenzione, come lo stesso Ethan Mollick ha sottolineato, per lavori complessi è ancora fondamentale selezionare il modello appropriato: molti LLM open source sono spesso ottimizzati per velocità di chat, per performance nel campo della visione o nella traduzione automatica, ma non per compiti agentici, che richiedono capacità di ragionamento avanzato e di pianificazione dell’uso dei tools.
La co-ottimizzazione è la strategia vincente
Alcune case histories, come ad esempio l’esperienza di Cognition con il suo LLM SWE-1.5, mostrano che il massimo rendimento si ottiene dalla co-ottimizzazione simultanea di modello e harness: il modello viene addestrato specificamente per l’harness, e l’harness viene affinato in base ai punti deboli del modello. Non si tratta di scegliere l’uno o l’altro, ma di progettarli come un sistema integrato.
Se si guardano i recenti rilasci sul mercato, questo è il trend decisamente emergente.
L’harness engineering come disciplina emergente
L’harness engineering si sta affermando come disciplina autonoma, distinta sia dal prompt engineering sia dal più ampio context engineering.
Bassel Haidar, Vice President per le iniziative IA delle Agenzie Federali presso Booz Allen Hamilton, ha previsto che “entro la fine del 2026, l’agent reliability engineering diventerà una disciplina standard, come è successo con DevOps dopo il cloud”.
L’harness è il piano di controllo della cognizione artificiale: non si limita ad “eseguire l’agente”, ma governa le condizioni in cui avviene la cognizione e i criteri con cui viene validata.