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.
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.
Indice degli argomenti:
I layer dell’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. RAG resta il pattern dominante perché le aziende hanno più dati di quanti possano stare in un prompt, e l’harness deve fare il lavoro di indicizzazione, ricerca e ranking prima di consegnare al modello, formattando in modo che il contesto sia leggibile.
Il secondo è la memory, la persistenza selettiva: quale informazione conviene tenere tra sessioni e quale è solo rumore. Preferenze utente, convenzioni di repository, workflow ricorrenti, vanno preservate; il resto va scartato per non saturare il contesto.
Il terzo è il tool dispatch, ovvero come l’harness decide quali strumenti rendere disponibili al modello in ogni fase del task, e questo è il punto in cui MCP entra come standard di interfaccia. La tecnica dei logits masking, dove l’harness rende dinamicamente disponibili solo i tool pertinenti alla fase corrente del task, è documentata come pratica matura per evitare la frammentazione dell’attenzione causata dal caricamento di troppi tool nel prompt.
Il quarto è l’orchestrazione, la logica che decide quando fermarsi, quando re-iterare, quando spezzare un task in subtask paralleli o sequenziali.
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.
Cosa ha pubblicato Anthropic sui long-running harness
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.
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. Il trucco è che il prompt del primo context window è diverso dal prompt dei context window successivi, perché ha un compito esplicito di setup ambientale.
Devin, l’agente di coding di Cognition, ha portato la stessa logica all’estremo con sandbox isolati, fork-and-rollback, machine snapshot, async session handoff e un’unità di misura dedicata, l’ACU (Agentic Compute Unit), che riconosce il fatto economico fondamentale: il driver di costo principale è l’orchestrazione, non l’inferenza. Per chi sta progettando agenti che devono lavorare su task di giorni o settimane, il punto da assorbire è che l’environment isolation va trattata come scelta architetturale, non come dettaglio implementativo, perché definisce cosa il sistema può fare e cosa non può fare.
Build, buy, o environment engineering: la regola del 2026
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. 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.
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. È 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.
Gli indicatori per misurare la maturità del proprio harness
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 richiede settimane, l’astrazione è leaky e il harness è troppo accoppiato. Se richiede ore o giorni, l’harness sta facendo bene il proprio lavoro di disaccoppiamento.
Terzo indicatore, il costo per task completato: quanto si paga, in token e in compute, per un task riuscito? Se questo numero non è tracciato, manca il livello base di FinOps agentico, e qualsiasi conversazione di scaling è prematura.
L’analogia che gira nei thread tecnici è quella del motore e dell’auto. Il modello è il motore, il harness è il resto dell’auto, ovvero il telaio e tutto l’apparato di controllo necessario perché il motore produca movimento utile. Il motore migliore montato in un’auto senza freni va da nessuna parte di utile.
La maturità del 2026 non si misura sull’inferenza per secondo, si misura sulla quantità di lavoro che il sistema completa in produzione con affidabilità contrattualizzabile. Le aziende che hanno capito questo stanno investendo in harness adesso, sapendo che quando arriveranno i prossimi modelli di frontiera, troveranno un’infrastruttura pronta a sfruttarli.
Le altre staranno ancora cercando di farsi funzionare il primo prompt complesso, e troveranno la concorrenza un anno avanti senza margine di recupero.
Partecipa alla community