HarnessX è un framework per agenti AI progettato per intervenire non soltanto sul modello linguistico utilizzato, ma sull’intera infrastruttura che ne guida il comportamento durante un compito. Il sistema considera infatti il cosiddetto harness, cioè l’insieme di prompt, strumenti esterni, memoria, politiche di controllo, ambiente di esecuzione e regole di valutazione, come un oggetto software modificabile, componibile e sottoponibile a evoluzione continua.
Nelle architetture agentiche tradizionali, il modello riceve una richiesta, utilizza gli strumenti previsti dal workflow e procede secondo una sequenza di istruzioni definita in anticipo. Se emergono errori, utilizzi inefficienti dei tool, difficoltà nel recupero della memoria o passaggi di ragionamento poco affidabili, la correzione richiede normalmente un intervento manuale sul codice, sui prompt o sulla configurazione dell’agente. HarnessX introduce invece un meccanismo che raccoglie le tracce prodotte durante l’esecuzione, analizza i punti nei quali il comportamento del sistema risulta insufficiente e propone modifiche mirate alla struttura operativa dell’agente.
Il framework separa la configurazione del modello dalla configurazione del harness. Il modello definisce quali LLM utilizzare per i diversi ruoli, ad esempio agente principale, valutatore o giudice, mentre il harness determina come il sistema costruisce il contesto, quali strumenti può chiamare, quali informazioni conserva in memoria, quali controlli applica prima e dopo una chiamata al modello e in che modo gestisce gli errori. Questa distinzione consente di usare lo stesso modello con configurazioni operative differenti oppure di applicare lo stesso harness a modelli diversi, isolando l’effetto delle modifiche introdotte.
La struttura di HarnessX è basata su processor tipizzati, componenti software che vengono inseriti in specifici punti del ciclo di vita dell’agente. Il sistema prevede hook all’avvio del compito, all’inizio di ogni passaggio, prima e dopo la chiamata al modello, prima e dopo l’uso di uno strumento, alla chiusura di ogni step e al termine dell’esecuzione. In ciascuno di questi punti un processor può lasciare invariato l’evento, trasformarlo, dividerlo in più eventi, bloccarne la propagazione oppure interrompere l’esecuzione. Il controllo dei tipi impedisce che una modifica inserita in un punto della pipeline alteri in modo silenzioso componenti incompatibili o campi che devono rimanere in sola lettura.
La superficie di modifica non riguarda quindi soltanto le istruzioni testuali rivolte al modello. HarnessX organizza il comportamento dell’agente in nove aree: selezione del modello, assemblaggio del contesto, gestione della memoria, ecosistema di strumenti, ambiente di esecuzione, valutazione e ricompensa, controllo e sicurezza, osservabilità e conversione delle tracce in dati per l’addestramento. Durante l’evoluzione, le modifiche più frequenti riguardano il contesto fornito al modello e l’uso dei tool, due elementi che incidono direttamente sulla capacità dell’agente di interpretare una richiesta, recuperare informazioni, verificare risultati e completare procedure composte da più passaggi.
L’adattamento è gestito da AEGIS, un motore multi-agente orientato alle tracce di esecuzione. Il processo è articolato in quattro ruoli: Digester, Planner, Evolver e Critic. Il Digester comprime le tracce raccolte e individua i segnali utili, il Planner definisce un piano di modifica, l’Evolver genera una nuova variante del harness e il Critic verifica se il cambiamento ha prodotto un miglioramento reale. Le modifiche non vengono quindi adottate in modo automatico soltanto perché una variante sembra promettente: il framework applica un gate deterministico basato sui risultati osservabili, con l’obiettivo di limitare regressioni, ottimizzazioni apparenti e comportamenti che migliorano una metrica senza aumentare l’affidabilità complessiva dell’agente.
Il meccanismo viene descritto come una forma di apprendimento per rinforzo applicata a uno spazio simbolico. In questo caso, lo stato non è costituito dai pesi della rete neurale ma dalla configurazione corrente del harness e dall’archivio delle tracce; l’azione è una modifica tipizzata ai componenti dell’agente; il feedback deriva dai risultati ottenuti e dalle verifiche esterne. In questo modo prompt, memoria, strumenti e politiche di controllo diventano parametri evolvibili anche senza intervenire immediatamente sull’addestramento del modello di base.
HarnessX include inoltre un ciclo di co-evoluzione tra harness e modello. Le traiettorie prodotte dalle diverse configurazioni vengono trasformate in segnali utili per un successivo addestramento tramite reinforcement learning. Il modello può quindi assimilare strategie emerse durante l’evoluzione del contesto operativo, mentre le versioni aggiornate del modello possono essere nuovamente sottoposte a evoluzione del harness. Il paper indica l’uso di un replay buffer condiviso e di un approccio denominato cross-harness GRPO, pensato per trasferire al modello le strategie efficaci emerse nelle successive varianti del sistema operativo dell’agente.
La valutazione è stata condotta su ALFWorld, GAIA, WebShop, tau³-Bench e SWE-bench Verified, utilizzando agenti basati su Claude Sonnet 4.6, GPT-5.4 e Qwen3.5-9B. Gli autori riportano un miglioramento medio assoluto del 14,5% su quindici combinazioni modello-benchmark, con incrementi fino al 44%. Il risultato più rilevante riguarda la distribuzione dei guadagni: i miglioramenti maggiori sono stati osservati nei casi in cui l’agente di partenza aveva prestazioni più basse. Su ALFWorld, ad esempio, Qwen3.5-9B ha ottenuto un incremento del 44%, mentre Claude Sonnet 4.6 ha registrato un aumento dell’11,2%, segnalando che una configurazione evoluta di strumenti, contesto e controllo può compensare in parte limiti comportamentali che un modello meno capace non riesce a correggere autonomamente.
Nei benchmark composti da compiti molto eterogenei, il sistema può creare varianti separate del harness invece di applicare la stessa modifica indistintamente a tutte le richieste. Questa modalità di variant isolation evita che un adattamento utile per una categoria di compiti peggiori il comportamento su un’altra. Nel test su GAIA, gli autori indicano che l’isolamento delle varianti ha riportato una crescita stabile delle prestazioni, con un miglioramento del 13,6% senza degradazioni nelle quindici iterazioni considerate.
HarnessX sposta quindi una parte rilevante dell’ottimizzazione dagli LLM al software che ne determina l’uso concreto. Il modello resta il componente che genera ragionamenti, azioni e chiamate agli strumenti, ma il sistema che organizza contesto, memoria, verifiche, retry e routing diventa un elemento adattivo, capace di essere osservato, modificato e confrontato attraverso risultati misurabili. Il codice completo non è ancora stato pubblicato, ma gli autori hanno indicato che sarà reso disponibile in una futura release.