Un paper su arXiv presenta HANDBOOK.md, un benchmark che misura se i modelli seguono davvero le istruzioni di policy su orizzonti lunghi. Sessantacinque task agentici in ambienti aziendali simulati (email, chat, calendario, issue tracking via Model Context Protocol), ciascuno governato da un manuale operativo di 20-124 pagine scritto da esperti. Sotto valutazione rigorosa, il modello migliore passa il 36,2% dei trial. La maggior parte delle configurazioni frontier resta sotto il 25%.

Se hai dato per scontato che un system prompt lungo o un policy document basti a tenere un agente in riga, questi numeri dicono il contrario. Il paper identifica quattro pattern di fallimento ricorrenti. L’agente lascia che una richiesta plausibile nell’ambiente sovrascriva la policy stabile. Esegue un controllo obbligatorio e poi agisce contro il suo risultato. Perde i dettagli delle regole man mano che il contesto si allunga. Dichiara conformità che non ha raggiunto.

È la versione misurata e ripetibile di quello che abbiamo visto quando GPT-5.6 Sol ha gestito un’azienda vera per 24 ore: l’agente riceve istruzioni chiare e poi le viola, perché la pressione dell’ambiente pesa più del documento di partenza. La differenza è che qui il fallimento è strutturato anziché aneddotico, con 824 criteri di valutazione deterministici.

La conseguenza pratica è che la governance degli agenti non può stare solo nel contesto. Serve uno strato software esterno che verifichi le azioni dopo che l’agente le ha compiute. Il corso su come valutare se il tuo agente funziona parte dallo stesso principio: i benchmark generici non ti dicono se l’agente rispetta le tue regole.

Nel dettaglio

I benchmark tradizionali per agenti misurano se il modello completa un task. HANDBOOK.md misura qualcosa di diverso: se un documento di policy lungo e vincolante riesce a vincolare il comportamento dell’agente su un orizzonte esteso di uso di strumenti. È la differenza fra chiedere «l’agente ha finito il lavoro?» e «l’agente ha rispettato le regole mentre lo faceva?».

I 65 task sono modellati su come i dipendenti aziendali seguono i manuali operativi. Ogni task mette l’agente in un ambiente autosufficiente: un workspace con file, email, chat, calendario, issue tracking e servizi di commercio, tutti esposti via Model Context Protocol. La policy è un manuale scritto da esperti, lungo fra 20 e 124 pagine, che copre cinque domini (finanza, fatturazione medica, assicurazioni, logistica, risorse umane) in dieci aziende fittizie.

Per resistere alla memorizzazione, ogni task modifica uno dei dieci manuali di base, alterando le regole specifiche e le soglie su cui si basa la valutazione. Nessun task condivide la stessa policy. La valutazione è completamente deterministica: 824 criteri programmatici che verificano sia che le azioni richieste siano state compiute, sia che le azioni proibite non lo siano state.

I numeri. Trenta configurazioni di modello valutate. Sotto valutazione rigorosa (un trial passa solo se soddisfa ogni criterio), la migliore passa il 36,2% dei trial. La maggior parte delle configurazioni frontier resta sotto il 25%.

I quattro pattern di fallimento:

1. Sovrascrittura da ambiente. L’agente riceve una richiesta plausibile nell’ambiente (un’email, un messaggio in chat) che contrasta con la policy, e la segue invece della policy. È il pattern più preoccupante perché si sovrappone al vettore classico della prompt injection indiretta.
2. Controllo eseguito e ignorato. L’agente esegue il controllo richiesto dalla policy, ottiene il risultato, e poi agisce in modo opposto. Fa la verifica ma non la usa.
3. Degrado su orizzonte lungo. I dettagli delle regole si perdono man mano che la conversazione e l’uso di strumenti si allungano. Le regole all’inizio del manuale pesano di più di quelle verso la fine.
4. Conformità dichiarata. L’agente riferisce di aver rispettato la policy quando non l’ha fatto. Se ti fidi del self-report dell’agente per il monitoraggio, questo fallimento non lo intercetti.

Cosa significa per chi costruisce. La tesi implicita del paper è che il context engineering, da solo, non basta a governare gli agenti in produzione. Puoi scrivere il manuale più accurato del mondo, metterlo nel system prompt, e l’agente lo seguirà meno di quattro volte su dieci. La governance deve stare in uno strato software esterno: controlli post-azione, validazione dei risultati, e dove possibile restrizioni sui tool stessi (non dare all’agente uno strumento che non dovrebbe usare, invece di dirgli di non usarlo).

I limiti. Il benchmark usa ambienti simulati, non sistemi di produzione veri. I manuali sono scritti da esperti ma le aziende fittizie potrebbero non catturare tutta la complessità delle policy reali. Il campione di 65 task è relativamente piccolo, anche se i 824 criteri di valutazione lo compensano in parte. Non è chiaro come i risultati cambino con tecniche di context engineering più sofisticate (RAG selettivo sulla policy, retrieval delle regole rilevanti al momento dell’azione) rispetto al semplice inserimento del manuale nel contesto. Il paper non testa queste alternative.