Negli ultimi mesi il termine harness è uscito dalla nicchia degli AI Engineer ed è entrato nel vocabolario di chi parla di startup e strategia.
Tecnicamente, un harness è tutto ciò che circonda un modello: system prompt, i tool, il file system, sandbox per eseguire codice in sicurezza, memoria persistente, meccanismi per non far degradare il contesto man mano che l'agente lavora su un task lungo e vari altri moduli.

In generale, oggi diciamo che un agente è un modello più un harness.
Un modello da solo non ricorda nulla da una sessione all'altra, non sa verificare se il proprio output è corretto, e più il lavoro si allunga più la qualità tende a scivolare senza che nessuno se ne accorga.
Per questo, attorno a un singolo agente, si costruisce uno stato che persista, un passaggio di controllo prima che il lavoro venga consegnato, un meccanismo che impedisca il degrado silenzioso su task lunghi.

Ora prova a fare la stessa domanda non su un agente, ma su un'azienda che vende SaaS e inizia a spostare la produzione stessa del prodotto dagli ingegneri agli agenti.
Chi si assicura che quello che un agente ha imparato lavorando su una feature resti visibile e riusabile quando un altro agente tocca lo stesso codice mesi dopo?
Chi verifica il codice prima che arrivi in produzione, quando nessun umano lo ha scritto riga per riga?
Chi si accorge che la qualità del prodotto sta scendendo, prima che sia il cliente a scoprirlo?
Sono esattamente gli stessi tre problemi - memoria che persiste, controllo prima della consegna, degrado che va intercettato - spostati dalla scala di un singolo task alla scala di un intero prodotto software: cambia cosa viene costruito, non la natura del problema.
Ed è questo a giustificare l'idea che un'azienda intera possa iniziare a somigliare a un harness: non più solo l'infrastruttura agentica attorno a un modello, ma tutto ciò che una SaaS mette in piedi - org chart, loop di revisione umana, integrazioni, contesto di dominio - per far girare il business tramite l’AI.
Ma come ci si arriva?
La traiettoria è quasi sempre la stessa:
Il punto di non ritorno è quando il sistema stesso inizia a orchestrare le persone.

Ok, ma questo non è solo hype da "AI slop factory"?
È l'obiezione più ovvia, assolutamente!
Un'azienda governata così non produce automaticamente output mediocri, a patto che sappia dove inserire il giudizio umano - non ovunque, solo dove conta davvero.
Un esempio tipico: un feedback raccolto in una call con un cliente arriva a un ingegnere solo se si trasforma in una vera decisione architetturale, non per ogni dettaglio.
In pratica: attenzione umana come risorsa scarsa da allocare chirurgicamente, non da spalmare uniformemente.
Perché dovrebbe interessarci?
Perché se il sistema produce e vende il prodotto, costruirlo bene diventa la competenza core dell'azienda - qualcosa che non esternalizzi più di quanto esternalizzeresti il tuo team prodotto.
Ramp, Stripe, DoorDash coi loro tool interni per sviluppatori AI sono, in quest'ottica, solo l'inizio.
Ma c'è un punto debole meno ovvio.
Se una terza parte diventasse abbastanza brava a gestire l'intero ciclo "as a service", il business sottostante si commoditizzerebbe - il che indebolisce da solo l'idea di moat.

Detto questo, se l'organigramma smette di rispondere a "chi fa cosa" e inizia a rispondere a "dove metto le persone perché il sistema estragga il massimo di giudizio da loro", la vera competizione tra aziende AI-native non sarà su chi ha il modello migliore, ma su chi ha capito prima dove va messo l'umano.
Giacomo Ciarlini - CIO - Datapizza
Simone Conversano - AI Transformation & Marketing Specialist - Datapizza