Harness Engineering

La disciplina di curare contesto e ambiente attorno a un modello perché l'agente capisca, a ogni esecuzione, cosa il suo supervisore intende per "bene". Termine e pratica portati da Ryan Lopopolo (oggi in Google, che ha coniato "agent harness") con l'essay "leveraging Codex in an agent-first world" (febbraio 2026) — la cura dell'Agentic Harness.¹

Insight centrale

I modelli migliorano e seguono istruzioni sempre meglio, ma non imparano per default cosa vuoi tu. L'harness engineering riempie quel gap con curazione di tools e contesto — non front-loadando il prompt. Lopopolo: "aspiro a essere un prompter incredibilmente pigro"¹.

Lo spettro "shift left" degli interventi

Interventi sempre più a sinistra nel processo, sempre più economici e automatizzati¹:

1. Riprovare lo stesso prompt — non scala
2. Docs + agent che le indicizza
3. Static verifier e test (che possono promptare l'agente a loro volta)
4. Evals upstream al vendor del modello

Per agenti che vivono di testo, shift left = dare più testo in modi sempre più sofisticati. Il prompt append è l'estremo "right"; tools + ragionamento sulla documentazione è più a sinistra; il modello che scopre da solo il contesto è ancora più a sinistra.¹ (Sul fronte security vedi Shift Left Security.)

Perché i tool best-practice funzionano

Sono ben rappresentati nei training data e compongono bene: collassare un problema di osservabilità in PromQL dà al modello qualcosa che già sa fare. Trick di Lopopolo: markdown con link come anchor a fine paragrafo (non inline) — efficiente per il contesto, leggibile per l'umano, mitigazione del "loss in the middle" (vedi Context Rot).¹

Coerenza sui tempi lunghi: la size del loop

Sfida centrale: "Do agents cohere over long time horizons?". Le organizzazioni umane funzionano per iterazione; harness engineering = "trucchi sempre più sofisticati per riportare l'agente al baseline" (golden thread). Piccole PR reviewabili → agenti che reviewano agenti → state space più stretto → orizzonti più lunghi con meno umano → migrazioni integrali di linguaggio trattabili. Configurare un agente è come costruire un personaggio RPG: ogni contributore umano alza una stat¹.

Se solo agenti fanno il lavoro, nessuno divide i task per competenza in sprint planning: l'agente deve classificare da sé il lavoro che sta per fare e usare quella classificazione per scoprire dinamicamente il contesto da caricare (architettura backend, performance frontend...). Lopopolo misura la size del loop con la stessa domanda che si fa a un ingegnere che cresce da junior a staff: quanto in avanti nel futuro riesci a sciogliere l'ambiguità perché i tuoi agenti abbiano autonomia sul task? ¹

Non costruire il proprio harness

• Lopopolo non ha mai costruito un harness: tiene fisso l'harness (l'"Antigravity-like thing") e adotta il modello migliore appena esce
• Il metodo: avere grande ambizione, scartare i propri preconcetti su cosa è possibile, osservare dove l'agente fallisce, interrogare l'agente e se stessi sul perché, e sfruttare il fatto che codice e prosa costano pochissimo per raffinare l'ambiente e impedire quelle divergenze¹
• Tutti gli harness espongono essenzialmente file read, grep, esecuzione comandi: investire in tools e contesto crea leva in una parte che non diventa mai obsoleta
• Warning: l'over-scaffolding vincola gli agenti che migliorano e crea sunk cost¹
• Nella seconda parte del video (che invece sostiene che costruirsi un harness aiuta a capire cosa succede sotto il cofano) si mostrano tre pattern: loop lineare (determinismo), closed loop (edit→test→errore→memory, standard per il codice), ADK (Agent Development Kit di Google) con guardrail e compaction, per esempio una funzione che blocca comandi distruttivi come cancellare file, fare drop del database o push su GitHub. Non esiste un harness migliore di tutti: per ogni harness si decide quante volte iterare, quali tool usare e quando, quanta memoria serve e quando recuperarla. Antigravity, Claude Code e Cursor funzionano bene non per il modello ma per l'harness engineering attorno al modello¹

Stack a 3 layer

"Il tuo coding agent non ha bisogno di un modello più smart. Ha bisogno di uno stack migliore."¹

1. Modello: veloce ed economico > pesante (es. Gemini 3.8 Flash) — un agente può ripetere la sequenza 20, 40 o 60 volte per un task, velocità e costo compongono
2. Harness: orchestrazione (es. boost di Antigravity: orchestrator + subagent paralleli + verification indipendente), da riservare ai problemi di ingegneria complessi: per feature standard o componenti UI l'agente di default è più rapido
3. Knowledge: skill di dominio caricabili on demand (es. Google Skills, 100+ skill su Google Cloud, Firebase, Flutter, Maps, oltre 19.000 stelle su GitHub, harness-agnostiche). Una skill non è un server MCP né un plugin pesante, ma contesto curato e preciso che evita all'agente di tirare a indovinare — il pattern delle skills, vedi Hermes Agent¹

Motivazione di fondo di Lopopolo: il "capability overhang" — i modelli sono capaci ben oltre quanto riusciamo a estrarne oggi in lavoro utile; il suo obiettivo da applied engineer è assorbirne il più possibile. In Google Cloud lavora ad agenti che operano il cloud: dare un computer a un agente è parte del suo successo, e Google Cloud vuole essere "il miglior computer per agenti".¹

Il modello è solo il motore: Agent = Model + Harness (2026)

Nel whitepaper Google The New SDLC With Vibe Coding (maggio 2026), Addy Osmani, Shubham Saboo e Sokratis Kartakis inquadrano l'harness all'interno del modello fabbrica: se lo sviluppatore è il manager di stabilimento, il modello AI è solo il motore grezzo sul pavimento della fabbrica, incapace da solo di produrre alcunché senza la macchina circostante dell'harness, secondo l'equazione fondamentale Agent = Model + Harness. Il comportamento che gli sviluppatori sperimentano con Claude Code, Cursor, Codex, Antigravity, Aider o Cline è dominato da ciò che fa l'harness e da quanto deliberatamente viene configurato, vero spartiacque tra vibe coding e agentic engineering (vedi Spettro Vibe Coding e Agentic Engineering). ²

Concretamente, la superficie dell'harness — che è responsabilità del team ingegneristico e non del provider del modello — comprende sei componenti: ²

1. Instructions and Rule Files: il testo che definisce chi è l'agente, cosa conta e cosa gli è vietato (AGENTS.md, CLAUDE.md, GEMINI.md, skill file e prompt dei sub-agenti; vedi Context Engineering); ²
2. Tools: le funzioni, i server MCP e le API invocabili dall'agente, insieme alla prosa che spiega al modello quando e come chiamarli; ²
3. Sandboxes and execution environments: dove gira concretamente il codice dell'agente, a cosa ha accesso e cosa non può raggiungere; ²
4. Orchestration logic: creazione di sub-agenti, routing dei modelli, hand-off tra specialisti e regole che governano quando ciascuno si attiva; ²
5. Guardrails or Hooks: codice deterministico che gira in punti specifici del ciclo di vita (prima di una tool call, dopo la modifica di un file, prima di un commit) per presidiare ciò che l'agente non deve mai dimenticare ma spesso dimentica; ²
6. Observability: log, tracce (traces), valutazioni (evaluations) e misurazione di costi e latenza per sapere se l'agente sta lavorando bene o sta andando silenziosamente alla deriva (drifting). ²

L'harness opera attivamente lungo quattro fasi del nuovo SDLC: ²

• 1. Requisiti, pianificazione e architettura (Configuring the Harness): prima di scrivere codice di produzione, lo sviluppatore configura i file di istruzioni e regole (AGENTS.md, vincoli architetturali) e definisce i tool accessibili (API, schemi di database) e le regole invalicabili. ²
• 2. Implementazione (Running the Harness): durante la codifica, l'agente esegue il codice generato dentro la sandbox isolata dell'harness e usa i tool forniti per leggere file o cercare sul web. ²
• 3. Testing e QA (The Feedback Loop): tramite logica di orchestrazione e guardrail, l'harness esegue i test automatizzati in un terminale sandboxed; se un test fallisce, cattura l'output di errore e lo rimanda al modello chiedendogli di riprovare, realizzando il ciclo automatizzato think -> act -> observe. ²
• 4. Code review, deployment e manutenzione (Observing the Harness): gli hook deterministici bloccano azioni pericolose (ad esempio impedendo un commit se l'agente tenta di fare push di una password in chiaro hard-coded), mentre il layer di osservabilità traccia costi in token, latenza e agent drift per consentire l'audit umano sulle decisioni di deploy. ²

L'impatto di questa configurazione è misurabile sui benchmark pubblici: su Terminal Bench 2.0, un team ha portato un coding agent da fuori della Top 30 fino alla Top 5 cambiando esclusivamente l'harness, senza alcuna modifica al modello; uno studio separato di LangChain ha innalzato il punteggio di un coding agent sullo stesso benchmark di 13,7 punti ritoccando solo system prompt, tool e middleware attorno a un modello fisso. Nella pratica quotidiana, quando un agente sbaglia l'istinto è dare la colpa al modello, ma "la maggior parte dei fallimenti degli agenti, esaminati onestamente, sono fallimenti di configurazione" (most agent failures, examined honestly, are configuration failures): un tool mancante, una regola vaga, un guardrail assente o una context window piena di rumore. ²

Vedi anche: Shift Left Security, Pensare in Grande con l'AI, LLM come strumento, Spettro Vibe Coding e Agentic Engineering, Context Engineering, Modello Fabbrica, Conduttori e Orchestratori, Agentic Harness, Coding Agent, Context Rot, Hermes Agent

Fonti e Riferimenti