Il prompt di sistema di Claude e i suoi due strati

In ogni conversazione con un assistente AI, oltre alle domande dell’utente e alle risposte del modello, entra un testo che l’utente non scrive e in gran parte non vede, il prompt di sistema della conversazione. Questo articolo lo scompone nei suoi due strati, quello deciso dal fornitore e non modificabile e quello costruito dall’utente con preferenze, istruzioni, server MCP, skill e plugin. Spiega perché la distinzione conta, come i due strati si compongono per stratificazione, e perché quello su cui si può intervenire, lo strato dell’utente, merita attenzione e manutenzione. L’esempio di riferimento è Claude.

Cosa entra davvero in una conversazione

Quando si scrive una domanda in chat e arriva una risposta, viene naturale pensare che nella finestra ci siano solo due voci, quella dell’utente e quella del modello. In realtà, prima ancora che venga digitato il primo carattere, la conversazione è già popolata da un testo che l’utente non ha scritto e che in buona parte non vede.

Quel testo stabilisce chi è il modello, come deve comportarsi, quali strumenti ha a disposizione, che giorno è oggi e altro ancora. È il prompt di sistema della conversazione, e determina buona parte di come andrà lo scambio ben prima che lo scambio cominci.

La formula prompt di sistema della conversazione va intesa in modo un po’ più largo del significato che si tende a dare. Nell’uso corrente «prompt di sistema» indica il blocco di istruzioni nascoste che il fornitore mette a monte, e basta. Qui invece comprende tutto ciò che entra nella finestra di contesto prima dello scambio esplicito di domande e risposte. Una parte è decisa dal fornitore e non si può modificare. Un’altra parte la costruisce l’utente, spesso senza rendersene conto quando collega un servizio o installa un componente. Sono i due strati che questo articolo tiene distinti.

L’uso della parola strati non è casuale perché il meccanismo di composizione delle istruzioni nel prompt di sistema è quello della stratificazione. Si può immaginare che le istruzioni, provenienti da fonti diverse e in tempi diversi, si compongano stratificandosi l’una sopra l’altra seguendo la sequenza delle azioni delle fonti. Un nuovo strato non cancella quelli sottostanti, va immaginato come trasparente e sono solo le istruzioni che agiscono sullo stesso ambito a doversi comporre fra loro tenendo conto sia della gerarchia degli strati, sia della forza delle istruzioni in un certo strato. Un approfondimento dell’ultimo concetto si può trovare in questo articolo.

Per chi li controlla, questi strati si raggruppano in due grandi famiglie, quella del fornitore e quella dell’utente. Il meccanismo dei due strati non è una particolarità di un singolo prodotto. Ogni assistente conversazionale basato su un modello linguistico riceve all’avvio uno strato deciso da chi lo produce e ne affianca uno gestito da chi lo usa. Quello che cambia, anche parecchio, è quanto lo strato utente si possa arricchire. In molti assistenti si ferma a poche istruzioni personali, il tono preferito, qualche indicazione di comportamento. In altri ecosistemi arriva a comprendere il collegamento di servizi esterni e l’installazione di componenti che aggiungono capacità e istruzioni alla conversazione.

Questo articolo usa Claude come esempio, perché la parte governata dall’utente è tra le più sviluppate e quindi la più adatta a mostrare di cosa è fatto lo strato utente. Concetti come i server MCP, le skill e i plugin, che compariranno più avanti, appartengono a questo ecosistema e hanno equivalenti solo parziali altrove. La struttura di fondo, i due strati e il modo in cui si combinano, resta però valida per qualsiasi assistente, ed è il motivo per cui l’esempio di Claude serve a capire un funzionamento generale, non un caso isolato.

L’argomento è proprio questo insieme di istruzioni e definizioni che esistono già all’inizio della conversazione e ne governano lo svolgimento, il testo che orienta il comportamento del modello e la lista degli strumenti che può usare. È la parte che quasi nessuno guarda, e che merita attenzione per un motivo pratico, una sua metà si può ispezionare e modificare.

Lo strato che decide il fornitore

Il primo strato è quello che l’utente non tocca. Lo scrive chi produce il modello, viene inserito all’inizio di ogni conversazione e resta uguale per tutti, salvo gli aggiornamenti periodici decisi dall’azienda. Nel caso di Claude questo strato è in buona parte leggibile, perché Anthropic pubblica il prompt di sistema delle proprie applicazioni web e mobile in una sezione di note di rilascio, aggiornata a ogni nuova versione del modello. Vale per le app di chat. Chi accede via API scrive la propria parte del prompt di sistema, ma non per questo il modello resta senza regole. Infatti i vincoli di sicurezza sono incorporati nel modello durante l’addestramento, e l’uso resta soggetto alle politiche del fornitore. Quello che cambia, via API, è dove risiedono quei vincoli, non il fatto che esistano.

Leggere quel testo è istruttivo, perché mostra che molti comportamenti apparentemente spontanei del modello sono in realtà istruzioni esplicite. In pratica questo strato raccoglie alcune componenti ricorrenti:

• Identità e contesto del prodotto. Quale modello sta rispondendo, come si presenta, dove mandare l’utente per la documentazione. È la parte che dice al modello «sei X, sei fatto da Anthropic», dove X è il modello effettivamente in esecuzione, perché Claude è la famiglia e i modelli che la compongono sono Haiku, Sonnet, Opus e altri. Gli fornisce anche le poche informazioni di prodotto che deve conoscere.
• Regole di comportamento. Le politiche di sicurezza, il modo di trattare le richieste delicate, l’equilibrio sui temi controversi, l’attenzione al benessere di chi scrive. Sono regole non negoziabili per costruzione, nel senso che nessuna istruzione dell’utente le può ribaltare.
• Tono e formato di default. La preferenza per la prosa rispetto agli elenchi puntati, l’uso degli emoji, la brevità. È la base stilistica su cui si innestano le preferenze personali dell’utente, quando ci sono.
• Orchestrazione degli strumenti. Le istruzioni su come e quando usare ricerca web, esecuzione di codice, lettura di file, e le schede tecniche degli strumenti stessi, quelle che descrivono al modello nome, funzione e parametri di ognuno. È di solito il blocco più corposo dell’intero strato.
• Metadati di sessione. La data corrente, il nome dell’utente se disponibile, il modello in esecuzione. Sono le poche informazioni che cambiano da una sessione all’altra e che vengono iniettate al momento.
• Iniezioni dinamiche. Avvisi e promemoria che la piattaforma può aggiungere durante la conversazione, per esempio quando uno scambio si allunga molto o quando un controllo automatico segnala qualcosa.

C’è un limite a quanto se ne può vedere, anzi ce ne sono due. Il primo è che il testo pubblicato da Anthropic è il prompt comportamentale di base, non la fotografia di tutto ciò che entra nella finestra in una sessione reale, dove si aggiungono le schede degli strumenti attivi e i metadati del momento. Il secondo, più sottile, è che quel testo sta in una pagina di documentazione, non nella conversazione. Il modello che si sta usando ce l’ha davanti a ogni scambio, fa parte di ciò che riceve e che orienta le sue risposte. L’utente no, e mentre dialoga non gli viene spontaneo andarlo a cercare altrove. Anche la parte pubblicata resta così fuori dallo sguardo dell’utente proprio nel momento in cui conta, quello dello scambio.

Da tenere ben presente, in genere questo strato costituisce la quota maggiore dell’intero prompt di sistema, spesso diverse volte più esteso della parte governata dall’utente. È il costo fisso della conversazione, quello che si paga sempre e su cui non si può intervenire. Per costituzione, però, è fatto in modo da lasciare all’utente la possibilità di incidere su alcuni aspetti agendo sull’altra metà del prompt di sistema, ed è per questo che ha senso lavorarci, l’unica leva effettivamente a disposizione.

Lo strato che costruisce l’utente

Il secondo strato è quello su cui l’utente può intervenire. A differenza del primo non arriva preconfezionato, si forma con le scelte di chi usa l’assistente, per questo varia da persona a persona e da sessione a sessione. In Claude comprende alcune componenti distinte:

• Le preferenze utente. Sono il livello più semplice e più diffuso e valgono per ogni conversazione. Qui ci sono le informazioni più generali, quelle che valgono sempre, come dire al modello come ci si chiama, che tono usare, quali convenzioni seguire, cosa evitare. È testo che entra nel prompt di sistema a ogni avvio e orienta il comportamento senza aggiungere nuove capacità.
• Le istruzioni di progetto. Valgono solo dentro un progetto specifico e si aggiungono alle preferenze quando si lavora lì, per dare al modello il contesto e le regole di quel lavoro senza doverli ripetere a ogni conversazione. Cosa conviene scriverci è un tema con regole proprie.
• Le istruzioni di Cowork. Sono istruzioni generali che si impostano a parte, nelle preferenze di Cowork, e vengono lette all’avvio di ogni sessione di quell’ambiente.
• I server MCP. MCP sta per Model Context Protocol, uno standard che permette di collegare l’assistente a servizi e strumenti esterni, dalla ricerca web all’accesso ai file locali, da una casella di posta a un database. Ogni server collegato mette a disposizione uno o più strumenti, e ciascuno porta con sé una scheda tecnica, la descrizione che dice al modello nome, funzione e parametri. Alla partenza quelle schede entrano nel contesto, ed è qui che si annida un costo spesso invisibile, un server con ventisei strumenti aggiunge ventisei schede. Collegare molti server significa riempire il contesto di descrizioni ben prima di aver scritto la prima domanda.
• Le skill. Una skill è una cartella di istruzioni e risorse che insegna all’assistente una procedura o una competenza specifica, dallo stile di scrittura di un’azienda al modo di compilare un certo documento. La loro particolarità sta nel modo in cui entrano nel contesto, chiamato caricamento progressivo. All’avvio della sessione il modello legge solo il nome e la descrizione di ogni skill installata, quel tanto che basta a sapere che esiste, cosa fa e quando usarla. Il corpo vero e proprio, che può essere lungo, resta sul disco e viene caricato solo quando la skill serve davvero. Per questo si possono attivare molte skill senza appesantire ogni conversazione, si paga soltanto il costo delle descrizioni, non quello dei contenuti finché non entrano in gioco.
• I plugin. Un plugin è un pacchetto che raggruppa più componenti insieme, tipicamente skill, definizioni di server MCP e altre estensioni, distribuito attraverso un marketplace e installabile in blocco. Semplifica la distribuzione, perché invece di aggiungere manualmente ogni pezzo si installa un insieme già confezionato, ma vale la stessa logica di costo delle sue parti, ciò che contiene entra nel contesto secondo le regole di ognuna.

Non tutte queste voci sono presenti dappertutto, perché lo strato utente cambia con l’ambiente. Le preferenze e le istruzioni di progetto accompagnano le conversazioni e i loro progetti, le istruzioni di Cowork le sessioni dell’ambiente omonimo, pensato per il lavoro autonomo su file e attività.

Esistono anche altri elementi, presenti negli ambienti dedicati al lavoro con il codice. Gli hook, regole che eseguono un’azione in modo automatico e deterministico al verificarsi di una condizione, fuori dal ragionamento del modello. E i file di memoria, dove l’assistente conserva informazioni da una sessione all’altra, con la relativa manutenzione, memorie che invecchiano, file che restano orfani. Non appartengono all’esperienza della chat quotidiana, ma fanno parte a pieno titolo dello strato governato dall’utente là dove sono disponibili.

Il tratto comune di tutte queste componenti è che ognuna, per funzionare, deve dire al modello che esiste, e per dirlo occupa spazio nel contesto. Le preferenze e le istruzioni entrano per intero, le schede degli strumenti MCP entrano per intero, le skill entrano con la sola descrizione finché non servono. Sommate, disegnano l’impronta dello strato utente, la parte del prompt di sistema che porta la firma di chi usa l’assistente.

Perché la distinzione conta

Essere consapevoli della differenza tra ciò che decide il fornitore e ciò che costruisce l’utente ha conseguenze concrete su come si può, e come non si può, influenzare l’assistente.

La prima riguarda la gerarchia. I due strati non sono sullo stesso piano. Lo strato di sistema fissa dei confini che l’utente non può oltrepassare, le regole di sicurezza, l’identità del modello, i vincoli di comportamento non negoziabili. Nessuna preferenza personale, nessuna skill, nessuna istruzione di progetto li può ribaltare. Dentro quei confini, però, lo strato utente ha un potere reale, e arriva a modificare gli stessi comportamenti di default dello strato di sistema. La preferenza per la prosa può diventare una preferenza per gli elenchi, il tono neutro può diventare un tono più diretto, se l’utente lo chiede. La gerarchia non dice quindi «il sistema vince sempre», ma «il sistema fissa i limiti, l’utente governa ciò che sta dentro i paletti imposti dal fornitore».

La seconda riguarda la conoscibilità. Lo strato utente non si lascia leggere in un unico posto. Si compone di sorgenti diverse, le preferenze, le istruzioni di progetto e/o di Cowork, i server collegati, le skill installate, gli eventuali plugin, ognuna di queste vive in un punto suo e si attiva seguendo la configurazione e l’uso del sistema. L’impronta complessiva che tutto questo lascia nel contesto esiste per intero solo dentro una sessione attiva, nel momento in cui la piattaforma assembla i pezzi. Elencare ciò che si è installato non equivale a sapere quanto pesa, né a vedere le sovrapposizioni, le descrizioni doppie, i componenti collegati e poi dimenticati. Per conoscere davvero il proprio strato utente occorre osservarlo mentre è in funzione, non ricostruirlo a memoria da un inventario.

Da qui il punto pratico, quello che rende la distinzione utile e non solo interessante. Dei due strati, uno solo è alla portata dell’utente. Sullo strato di sistema non si può fare nulla, se non conoscerlo per capire entro quali confini si lavora. Sullo strato utente, invece, si può intervenire per intero, aggiungere, togliere, riordinare. Mentre il primo è fisso, il secondo tende a crescere senza controllo, perché ogni servizio collegato e ogni componente installato ci resta, e continua a occupare spazio nel contesto di ogni conversazione anche quando non serve più. Riconoscere che quello strato esiste, e che è il proprio, è il primo passo per trattarlo come qualcosa che si ispeziona e si pota, non come un accumulo silenzioso.

Cosa cambia quando lo si vede

Lo scambio visibile in una chat, le domande e le risposte che scorrono sullo schermo, è la parte più piccola di ciò che occupa la finestra. Attorno a quello scambio c’è un testo che nella conversazione nessuno ha digitato e che spesso pesa più delle parole scambiate, il prompt di sistema nei suoi due strati.

Vederlo cambia il modo di leggere il comportamento dell’assistente. Una risposta che sorprende, un rifiuto inatteso, un tono che stona smettono di sembrare capricci del modello e diventano l’effetto di istruzioni precise, in parte scritte dal fornitore, in parte accumulate dall’utente stesso. Il modello non ha un carattere spontaneo, ha un contesto che gli viene assemblato attorno a ogni avvio, e una parte di quel contesto porta la firma di chi lo usa.

Ne discende una responsabilità piccola ma concreta. Lo strato utente è l’unica parte su cui si può agire, ed è anche quella che si costruisce quasi sempre per addizione, un servizio collegato oggi, un componente installato domani, senza che nessuno tolga mai nulla. Guardarlo ogni tanto, sapere cosa contiene e quanto occupa, è ciò che distingue uno strumento configurato con intenzione da uno che si è soltanto accumulato.

Chi scrive in chat lavora sempre dentro questo doppio strato. Conoscerlo è la condizione per governare la parte che gli appartiene, l’unica su cui si possa davvero intervenire.