L'ingegneria degli agenti innanzitutto restringe il contesto e i sensori

Osservando un gruppo di discussioni su Harness Engineering in questi giorni, la sensazione più intuitiva non è che “l’agente abbia aggiunto un nuovo livello di funzionalità”, ma che il focus delle discussioni ingegneristiche sia cambiato. In passato ci chiedevamo spesso se il modello fosse abbastanza forte. Ora ci concentriamo innanzitutto su quanto contesto inserire, quanto tempo inserire nel file delle regole e quale segnale fornisce il sensore. Il modello è ancora a metà, ma ciò che realmente determina la stabilità è l’imbracatura esterna.

Più grande è la finestra di contesto, più stabile sarà l’attenzione.

Qualcuno nel ritiro ha detto che agents.md dovrebbe essere controllato a meno di 200 linee. Questo numero non è pretenzioso o adorazione del numero di riga, ma più di un promemoria del budget. Più grande è la finestra di contesto significa solo che è possibile stipare più contenuti al suo interno, ma non significa che il modello afferrerà in modo più stabile la parte che dovrebbe essere afferrata. I modelli spesso si concentrano solo su una piccola parte del contesto e, anche se il resto del contenuto è nella finestra, non tutto potrebbe essere a fuoco.

Questo è molto fastidioso in ingegneria. Più regole ci sono, più facile è scrivere “vincoli” come “rumore”; quanto più lunghe sono le istruzioni, tanto più facile sarà seppellire in un angolo ciò che realmente va osservato. Mantenere il file molto breve non significa dare al documento un aspetto ordinato, ma forzare i vincoli a diventare visibili. Ciò che il modello affronta non è un’enciclopedia, ma un contratto operativo limitato.

Il sensore non alimenta nuovamente il tronco

Un altro cambiamento evidente è che la discussione ha iniziato a spostarsi sui sensori computazionali. I sensori qui non sono semplicemente sepolti, né i log di sistema sono inseriti intatti nel modello, ma lo stato di runtime è compresso in un numero limitato di segnali utilizzabili. Ciò che fa è filtrare il rumore, non creare nuovi oneri contestuali.

Questo è il motivo per cui si dice “passa a Rust invece che a Python”. L’attenzione non è schierarsi con il linguaggio, ma sul controllo. Una volta che un sensore si basa su limiti di runtime, vincoli di risorse, percorsi di eccezione e output deterministico per garantire la qualità, il linguaggio e l’ambiente di esecuzione non sono più solo dettagli di implementazione, ma parte del sensore stesso. Se il segnale è instabile, non importa quanto sia forte il modello, farà solo ipotesi sull’input instabile.

L’invio di dati grezzi direttamente al modello può sembrare più informativo a breve termine, ma spesso rende la scena solo più rumorosa a lungo termine. Un sensore veramente utile dovrebbe prima comprimere “ciò che è accaduto” in pochi stati chiari, e poi decidere quali dettagli sono lasciati agli esseri umani e quali agli strumenti.

La responsabilità dell’imbracatura è quella di tagliare il mondo in pezzi che possano essere dati in pasto al modello

Una volta che questo tipo di discussione matura, inizia ad assomigliare più alla progettazione di un sistema che a tecniche tempestive. L’imbracatura è responsabile dei confini: cosa entra nel contesto, cosa rimane fuori dal contesto, su quale stato può fare affidamento il modello e quale stato deve essere riconfermato dagli strumenti. Non è un guscio, ma uno strato di filtro e più vicino.

Questo è anche il costo più sottovalutato nel sistema Agent. La sostituzione del modello è veloce, ma il cablaggio è molto più lento perché collega direttamente la catena di azione, la catena del segnale e la catena del guasto. Il budget del contesto, la progettazione del sensore, i limiti delle autorizzazioni, i percorsi di fallback, alla fine ricadono tutti su questo livello. Finché questo strato non è stretto, più forte è il modello, più facile sarà per il sistema diffondere ulteriormente l’instabilità.

Osservando ora questo tipo di frammenti, la parte più preziosa non è un’unica conclusione, ma il fatto che indichi chiaramente il focus del progetto: l’agente non è più solo “se può fare qualcosa”, ma “se il sistema esterno ha raccolto attenzione e segnali”. Questo passaggio non è stabile e un ulteriore miglioramento delle capacità del modello non farà altro che amplificare il caos più velocemente.