Il termine agent harness descrive l’infrastruttura runtime che avvolge il modello: retrieval, memoria, tool dispatch, orchestrazione, safety, observability. Anthropic, Salesforce, Devin e Veso AI stanno arrivando agli stessi pattern architetturali
Consulente in trasformazione digitale – AI & product strategy
Come gli LLM stanno diventando parte integrante dell’ecosistema aziendale
C’è un’osservazione che gira con insistenza nei thread tecnici degli ultimi mesi e che vale la pena prendere sul serio. I modelli di frontiera del 2026, Claude Opus 4.7, GPT, Gemini 3, hanno capacità di ragionamento sufficientemente simili da rendere la scelta del modello raramente il vincolo per chi sta costruendo agenti enterprise. La differenza la fa il layer che avvolge il modello, e quel layer ha trovato un nome che si sta affermando come categoria operativa: agent harness.
Un’analisi di Atlan parla di un mercato che è passato da “tooling opzionale” a “infrastruttura non negoziabile” nell’arco di dodici mesi, e di un dato secco, ovvero che il 40% delle applicazioni enterprise includerà agenti task-specific entro fine 2026, ma con una resa molto diseguale tra chi ha investito sull’harness e chi è rimasto a livello di chiamata API.
Che cos’è un agent harness
La definizione operativa è semplice e merita di essere fissata. L’harness è l’infrastruttura software non-modello che intercetta e governa il loop di ragionamento di un LLM: dispatch dei tool, gestione del contesto, persistenza dello stato, applicazione delle policy di sicurezza, intervento umano nei punti critici. Il modello fornisce capacità cognitiva grezza, l’harness fornisce le mani, gli occhi, la memoria e i limiti operativi che permettono a quella capacità di trasformarsi in lavoro fatto.
Salesforce ha articolato il rapporto come quello tra un avvocato e il sistema giudiziario che lo circonda, dove l’avvocato sa la legge ma per fare giustizia serve tutta un’infrastruttura attorno. È una metafora forse troppo legalistica, però rende l’idea: il modello da solo non è un prodotto, l’harness rende il modello un prodotto.
I sei layer principali di un agent harness
Il consenso tecnico emerso nei whitepaper e nei post ingegneristici del primo semestre 2026 identifica sei layer che ogni harness in produzione deve coprire, indipendentemente dalla complessità del caso d’uso. Vale la pena enumerarli con precisione, perché la diagnosi dei fallimenti agentici di solito ricade su uno o due di questi che sono stati saltati o sottostimati.
- Il primo layer è il retrieval, ovvero come l’harness porta nel contesto del modello le informazioni giuste al momento giusto.
- Il secondo è la memory, la persistenza selettiva.
- Il terzo è il tool dispatch, ovvero come l’harness decide quali strumenti rendere disponibili al modello in ogni fase del task.
- Il quarto è l’orchestrazione, la logica che decide quando fermarsi, quando re-iterare.
- Il quinto è la safety enforcement, l’insieme dei guardrail e dei punti di approval umana per le azioni ad alto rischio.
- Il sesto è l’observability, il livello di tracing, logging, costing e auditing che rende il sistema diagnosticabile in produzione.
Anthropic e la soluzione architetturale a due agenti
Anthropic ha rilasciato a fine 2025 una ricerca specifica su come costruire harness efficaci per agenti che lavorano su task che attraversano molte context window, e il pattern che ne emerge è istruttivo. Il problema di base è che ogni nuova sessione di un agente comincia senza memoria di quello che è stato fatto prima, come una catena di ingegneri che si alternano in turni di lavoro senza handover.
Come Anthropic ha risolto il problema
La compaction del contesto da sola non basta, perché anche un modello come Opus eseguito in loop tende a fallire in due modi: cercando di fare tutto in un colpo solo, oppure perdendo il filo della pianificazione a metà strada. La soluzione proposta da Anthropic poggia su un’architettura a due agenti.
Un initializer agent riceve il prompt iniziale e produce gli artifact di stato: una lista di feature, un progress log, una struttura git. Un coding agent, sui context window successivi, legge questi artifact, sceglie la prossima feature da implementare, la porta a casa, aggiorna il progress log e si chiude lasciando un handover pulito per la sessione successiva.
Conviene comprare o costruire?
Il trucco è che il prompt del primo context window è diverso dal prompt dei context window successivi, perché ha un compito esplicito di setup ambientale. C’è una domanda strategica che ogni CTO si trova davanti adesso, e che Adnan Masood ha formulato nel modo più chiaro: cosa conviene costruire e cosa conviene comprare nel harness. La risposta che sta emergendo è netta.
Raccomandazioni per i CTO
Conviene comprare il plumbing commodity, ovvero runtime gestiti, telemetria di base, control plane, framework open source come LangGraph, Mastra, Semantic Kernel, Claude Agent SDK, OpenHarness. Conviene costruire le integrazioni proprietarie, ovvero tool specifici del dominio, dataset di valutazione custom, environment map disegnati sul proprio business.
Environment Engineering vs. Harness Engineering
Sopra questo livello c’è un’idea ancora più radicale che vale la pena tenere a mente per i prossimi cicli di pianificazione. Si chiama “environment engineering” ed è l’inverso del harness engineering: invece di costruire agenti più intelligenti per navigare sistemi legacy disordinati, le aziende ri-architettano i propri sistemi interni (API, codebase, database) perché siano intrinsecamente leggibili da un agente.
Perché è più vantaggioso
È un cambio di paradigma che sposta il costo della complessità dal layer agentico al layer architetturale, e per molte aziende italiane con stack legacy storici è probabilmente il single biggest leverage nei prossimi diciotto mesi. Un’API ben documentata, uno schema database semanticamente coerente, una codebase con buona naming convention valgono più di sei mesi di prompt engineering.
Indicatore per misurare la maturità
Per un team che sta valutando dove si trova nella curva di maturità, ci sono tre indicatori operativi che funzionano meglio di qualunque assessment generico. Primo indicatore, la diagnosticabilità dei fallimenti: quando un task agentico fallisce, quanto tempo serve per capire se è stato il modello, il retrieval, il tool dispatch o l’orchestrazione? Se la risposta è “dipende, dobbiamo rileggere i log”, l’observability layer è sottosviluppato.
Se è “guardiamo il trace, vediamo subito”, l’harness è in salute. Secondo indicatore, la sostituibilità del modello: quanto è semplice cambiare il modello sottostante senza riscrivere la logica? Se cambiare da Claude a un modello di altro vendor