L’harness a dieta

Intelligenza Artificiale agentica: gran fermento, poche certezze e molta confusione all’orizzonte. Almeno per me. Ciononostante prospettiva divertente, in un certo senso, per chi ci lavora, perché ‘apre’ a fantasia e creatività. E ad imparare come perdere qualche chilo di troppo, in un certo altro senso.

Scrivo qui, di getto, niente revisioni, quel che ho capito da questo interessante video (https://youtu.be/pEHfZUrahGc).

Le basi, innanzitutto. Qualche definizione.

• LLM: il modello, il motore, la rete neurale che “ragiona”, legge, decide
• Agente: il sistema, quello che usa il modello per raggiungere un obiettivo in più passaggi, interagendo con il mondo attraverso degli strumenti
• Harness: i finimenti, l’imbracatura (Furia ringrazia). Tutto il software che sta attorno al modello: il ciclo di esecuzione, l’accesso ai tool, la gestione del contesto. Un loop di qualche riga o un’infrastruttura enterprise da comitato di approvazione
• Agent framework: le librerie (LangGraph, etc.) con cui si costruisce il tutto, per non partire ogni volta dal ‘foglio bianco’

Quando il gioco si fa duro.

Un prototipo che funziona in demo è una cosa. Debuggare un’infrastruttura IT, o gestire un workflow finanziario complesso, è un’altra. Lì l’harness fa due mestieri:

1. Orchestrare il contesto. La finestra di contesto è finita, cioé non-infinita, e ogni token costa. L’harness decide cosa far vedere al modello a ogni giro: quali log, quale storico, cosa compattare. Dare tutto a tutti non è generosità, è rumore, e il rumore rende l’agente meno affidabile (come in certe mail con trenta persone in copia)
2. Fare da runtime.
   – Stato persistente. Molti processi aspettano ore o giorni un’approvazione o un evento esterno. Lo stato del task vive fuori dal modello, così l’agente riprende da dove aveva lasciato senza bruciare inferenza nei tempi morti. Se la sandbox salta, si riparte da una nuova
   – Sicurezza e permessi. Sapere cosa fare non vuol dire avere il permesso di farlo. L’harness tiene le credenziali al riparo (con un proxy, ad esempio) e impone regole deterministiche che il modello non può aggirare con la sua proverbiale fantasia. Una per tutte: prima di toccare la produzione, chiede a un umano
   – Tool al volo. Nei casi più avanzati l’agente si costruisce da solo un’utility temporanea, la usa, e la butta a fine lavoro. Meglio del sottoscritto che conserva, geloso, le due righe di C scritte da piccolo, anno domini 1989.

Il modello mangia l’harness?

Più i modelli migliorano col post-training, più assimilano quello che prima dovevamo imporgli da fuori con istruzioni rigide (lo scaffolding). Il giro è virtuoso: le tracce di quello che l’harness fa fare ai modelli diventano dati per addestrare i modelli successivi, che a quel punto sanno già farlo. Un volano dei dati, insomma.

Il risultato è un harness che si fa più magro. Nel caso di Cursor i system prompt si sono ridotti di circa il 66%: via le istruzioni su quando delegare ai sotto-agenti, perché il nuovo modello l’ha imparato da sé.

E chi non pota? (No, non è bergamasco). Paga la harness tax: token, latenza e costi in più per tenere istruzioni che il modello non ha più bisogno di sentirsi ripetere. Come mamma e il ‘metti la canottiera‘ al figlio ventenne. Nessun beneficio nei benchmark, solo fattura ‘più in carne’.

Non sparisce, cambia mestiere.

L’harness non va in pensione. Smette di insegnare come pensare e si specializza in quello che al modello non si può delegare: sicurezza, isolamento, persistenza, esecuzione affidabile. Meno pedagogo, più ingegnere di cantiere.

Che fare, allora?

Partire semplice: un modello, gli strumenti che servono, un ciclo minimo. Poi aggiungere un layer (contesto, stato, sicurezza) solo quando gli eval dicono che serve davvero, non perché ci sembra elegante.

E, già che ci siamo, coltivare una virtù rara: il coraggio di cancellare. Il codice più sano, a volte, è quello che si elimina.