Contesto, non controllo
Ogni regola nel prompt del tuo agente è nata come un bug.
Qualcuno ha visto un comportamento sbagliato, ha scritto una regola e ha tirato dritto. Qualcun altro ha fatto lo stesso. Una terza persona ha aggiunto un "non fare mai X" perché il modello una volta, di martedì, si è comportato in modo strano. Nessuno ha mai cancellato nulla.
Sei mesi dopo, l'agente passa più tempo a navigare nel proprio regolamento, all'interno della finestra di contesto, che a ragionare sul compito vero e proprio.
Questo è il modo di pensare orientato al controllo. E credo sia uno dei più grandi errori di progettazione che i team commettono quando costruiscono agenti AI.
Un piccolo esempio che rivela uno schema più ampio
Ci siamo imbattuti in un problema in cui un agente, attivato da un'attività pianificata, continuava a creare nuove attività pianificate dall'interno dell'esecuzione. Ricorsione infinita, ma con effetti collaterali nel mondo reale.
Due modi di rispondere.
Stile controllo: vietarlo. Scrivere codice che impedisce alle pianificazioni di creare altre pianificazioni. Aggiungere una regola al prompt: "non creare mai una pianificazione all'interno di una pianificazione." E spedirlo.
Stile contesto: dire all'agente cosa sta realmente accadendo.
Sei stato attivato da un'attività pianificata alle 3:00 del mattino, ora del Pacifico. ID pianificazione: sched_29x8f. Un'esecuzione pianificata è un'esecuzione isolata con un ambito definito che l'utente aveva originariamente autorizzato. Creare una nuova attività pianificata estenderebbe quell'ambito oltre l'autorizzazione originale.
Il primo approccio applica una toppa a un singolo comportamento. Il secondo fornisce all'agente un modello della situazione.
Ora può ragionare anche su questioni vicine: dovrei inviare una notifica alle 3 del mattino? Dovrei creare un processo di follow-up che l'utente non ha esplicitamente richiesto? Dovrei modificare qualcosa che si estende oltre l'ambito dell'esecuzione originale?
Nessuna regola necessaria. L'agente lo ha capito da solo.
Molti team ricorrono al controllo quando ciò di cui hanno davvero bisogno è il contesto.
La stessa distinzione emerge all'interno dei prompt
Non si tratta solo di applicazione a livello di sistema. La divisione tra contesto e controllo esiste anche all'interno dei prompt.
Prompting in stile contesto: principalmente fatti, opinioni al minimo:
Sei in esecuzione a causa di un'attività pianificata. Attivato alle 3:00 del mattino, ora di Pechino. ID attività: sched_29x8f. L'utente ha autorizzato questa esecuzione per un ambito specifico.
Prompting in stile controllo: opinabile, prescrittivo:
Evita di creare pianificazioni. Dovresti notificare l'utente con lo strumento X. Non fare mai Y a meno che Z.
A volte le istruzioni prescrittive sono utili. Ma molto spesso stanno compensando fatti mancanti. E una volta che inizi a compensare in questo modo, diventa una dipendenza.
Come i prompt diventano burocrazia
Questa è la modalità di fallimento più profonda.
Un team vede un problema e aggiunge una regola. Poi un'altra. Poi un'altra ancora. Ognuna applica una toppa a un problema locale, ma insieme creano un sistema pieno di proxy.
Bezos ha descritto questo schema nella sua lettera agli azionisti del 2016: un buon processo è al tuo servizio in modo che tu possa servire i clienti. Ma se non stai attento, il processo diventa la cosa in sé.
È esattamente ciò che accade nei sistemi di agenti.
La regola non è la cosa. La regola è un proxy per il risultato che desideri. E i proxy si accumulano. Uno crea casi limite che ne richiedono altri. Presto l'agente ragiona attraverso strati di istruzioni accumulate, ognuna aggiunta per qualche ragione storica che nessuno ricorda più del tutto.
Nelle organizzazioni umane, questo diventa burocrazia. Nei sistemi di agenti, diventa un prompt gigantesco pieno di tessuto cicatriziale.
I fatti invecchiano. Le opinioni marciscono.
Un fatto come "questa esecuzione è stata attivata da un'attività pianificata alle 3 del mattino" è stabile. Rimane vero indipendentemente da quale modello lo legga: Claude, GPT, Gemini, qualunque cosa esca il prossimo trimestre.
Un'affermazione come "dovresti evitare di creare sotto-pianificazioni" è fragile. Dipende dall'interpretazione. Può aiutare in una situazione e fallire silenziosamente in un'altra.
Quando cambi modello, ogni opinione nel tuo prompt è una potenziale mina vagante. Il nuovo modello ha tendenze di ragionamento diverse, e il tuo "evita" attentamente calibrato potrebbe significare qualcosa di completamente diverso per lui.
Ma i fatti concreti sull'ambiente, i permessi, l'ambito e i vincoli tendono a generalizzare bene tra modelli e casi limite. Ecco perché i fatti sono il materiale da costruzione migliore.
La trappola delle stranezze del modello
Questa potrebbe essere la versione più insidiosa del problema del controllo: i team trasformano costantemente difetti temporanei del modello in struttura permanente del sistema.
Un modello si comporta male in qualche caso ristretto. Il team aggiunge un guardrail: una toppa al prompt, un controllo nel codice, una strana diramazione che esiste solo per fermare una specifica modalità di fallimento.
Quella toppa è una scommessa sul fatto che la stranezza persisterà. Quasi mai accade.
Tre mesi dopo, il modello cambia. Il comportamento originale scompare. Ma la toppa rimane. Nessuno vuole rimuoverla, perché magari c'era per una ragione.
È così che i prompt di sistema diventano codice legacy.
Possiamo riconoscere facilmente il pericolo quando lo si enuncia in astratto. Ma in pratica, applicare toppe alle attuali tendenze di ragionamento di Sonnet, prompt dopo prompt, è lo stesso schema sotto mentite spoglie.
Documentare il comportamento stabile del sistema ha valore. Applicare toppe alle tendenze di ragionamento di un modello è un tapis roulant. Il modello cambierà sotto i tuoi piedi più velocemente di quanto tu riesca a mantenere le tue toppe.
Un buon caso di prova: permesso negato
Puoi vedere la distinzione chiaramente nella diagnostica degli strumenti. Quando un agente incontra un errore di permesso:
Stile controllo:
TOKEN mancante. Esegui "zero permissions request gmail.send" per risolvere.
Diretto, ma l'agente non impara nulla. La prossima volta che incontra un errore di permesso diverso, è bloccato.
Stile contesto:
process.env.GMAIL_TOKEN → esiste zero connectors inspect gmail → connesso zero permissions inspect gmail.send → negato
Opzioni:
- Richiedere l'approvazione dell'utente per gmail.send
- Usare un percorso già autorizzato, se ne esiste uno
Ora l'agente sa che il token esiste, che il connettore funziona e che quel permesso specifico è negato. Comprende lo stato del sistema e può ragionare su situazioni nuove che chi ha scritto la regola non aveva mai previsto.
L'euristica
Ecco a cosa continuo a tornare:
Ogni volta che stai per scrivere "non", "evita" o "mai" in un prompt. Fermati. Chiediti: quale fatto sta compensando questa regola?
Di solito c'è un fatto mancante. L'agente non capisce in quale ambiente si trova, cosa ha autorizzato l'utente, quali azioni sono irreversibili, o perché questa esecuzione è diversa da una normale interazione di chat.
Scrivi quel fatto. Cancella la regola.
A volte vorrai comunque mantenere il vincolo, soprattutto per azioni distruttive, movimenti di denaro o confini di sicurezza. I controlli rigidi contano ancora.
Ma molte regole dei prompt non sono veri confini. Sono compensazioni per una comprensione mancante. E sono proprio quelle che si accumulano e marciscono.
L'obiettivo
L'obiettivo non è un agente che memorizza una lista di controllo.
L'obiettivo è un agente che comprende la propria situazione abbastanza bene da prendere buone decisioni all'interno di confini chiari.
Una filosofia controlla il comportamento impilando regole. L'altra migliora il comportamento rendendo il mondo leggibile.
La prima tende alla burocrazia. La seconda tende alla comprensione.
Costruisci contesto. Cancella il tessuto cicatriziale. Spedisci agenti capaci di pensare.
