Articoli
Basta dare le SOP in pasto agli AI Agent: usa RFC 2119 (MUST/SHOULD/MAY) per controllarne il comportamento
Passare le SOP umane direttamente a un LLM porta spesso a un Agent che ci azzecca una volta su quattro. Questo articolo mostra come usare i vincoli MUST, SHOULD e MAY di RFC 2119 per riscrivere System Prompt e Agent Skill, definendo requisiti bloccanti, raccomandazioni forti e discrezionalità, con tre principi pratici per la messa a terra.
· 3 min di lettura
Uno degli errori più comuni quando i team provano a portare un Agent in produzione è prendere una SOP scritta per umani su Word o Notion e darla in pasto così com'è all'LLM, sperando che faccia tutto da solo. Il risultato è una lotteria: una volta gira bene, tre volte va a gambe all'aria.
Il problema non è la capacità del modello, ma il fatto che le SOP umane danno per scontata una marea di "Tacit Knowledge" (conoscenza tacita). Il cervello umano intuisce al volo che "sotto i 500 euro non serve l'approvazione" o che "se questo passaggio lancia un errore si può saltare"; per un LLM, invece, un testo non strutturato non ha una gerarchia di vincoli, quindi improvvisa.
Per rendere deterministico il comportamento di un Agent, il primo passo non è passare a un modello più grande, ma adottare uno standard classico delle specifiche dei protocolli di rete: la gradazione semantica di RFC 2119.
TL;DR: riserva MUST solo a compliance, sicurezza e Schema critici; delega il resto dei confini a SHOULD e MAY; e affida i nodi ad alto rischio alla revisione umana.
Perché proprio RFC 2119?#
Quando scrivi un System Prompt, una Agent Skill o una Workflow Rule, formule vaghe come "fai attenzione", "sarebbe meglio" o "cerca di" non impongono alcun vincolo reale al modello. Usare livelli verbali precisi traccia confini decisionali netti.
MUST / REQUIRED: vincolo rigido, zero compromessi#
- Semantica: assolutamente vietato saltarlo, nessuna eccezione.
- Casi d'uso: validazione dati, controlli di sicurezza, vincoli sullo Schema di output, blocchi su operazioni ad alto rischio.
- Esempio: "Prima di invocare l'API fatture,
MUST verificare se il codice dipendente esiste; se il ritorno è vuoto, MUST interrompere immediatamente l'esecuzione."
SHOULD / RECOMMENDED: fortemente raccomandato, ma deviazioni consentite con motivazione#
- Semantica: da seguire per default a meno di valide ragioni di contesto; se devia, l'Agent deve esplicitare il Reasoning alla base della scelta.
- Casi d'uso: selezione di strategie algoritmiche, preferenze di classificazione, logica di retry.
- Esempio: "Per i Ticket di assistenza clienti,
SHOULD assegnare la priorità al supporto di primo livello; tuttavia, in presenza di contestazioni sui pagamenti, è consentito riassegnare al team finance."
MAY / OPTIONAL: del tutto opzionale, piena discrezionalità#
- Semantica: il modello decide in autonomia se eseguire l'azione in base al contesto o al budget di token disponibile.
- Casi d'uso: note integrative, spunti di approfondimento, formati di log opzionali.
- Esempio: "Nel generare il riepilogo della pratica,
MAY includere 1～2 ID di Ticket storici simili come riferimento."
Tre principi per la messa a terra#
1. Niente muri di MUST: lascia spazio al Reasoning#
Scrivere ogni singola regola come MUST significa trattare l'LLM come un Deterministic Compiler: il rischio è causare conflitti tra regole o un deadlock logico per saturazione del Context. Riserva MUST esclusivamente a compliance, sicurezza e Schema cardine, lasciando i margini a SHOULD.
2. Sfrutta sezioni Markdown ben strutturate#
Organizza il Prompt in questi quattro blocchi per rendere lampante lo Scope di ciascun vincolo:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. Nodi ad alto rischio sempre legati a Human-in-the-loop#
Quando una condizione tocca un confine MUST critico (es. importo di una singola transazione > $5,000, modifiche ai permessi Admin), l'unico comportamento MUST dell'Agent è "mettere in pausa la pipeline e attendere il via libera umano", non decidere al posto delle persone.
Conclusione: dai giocattoli da Demo al Production-Ready#
Tratta l'Agent come una linea di produzione industriale, non come un factotum tuttofare. Stabilendo un contratto di comportamento con RFC 2119, il tuo Agent passerà davvero dall'essere un giocattolo da Demo a un sistema Production-Ready.