Anatomia di un Agente GPT
Una struttura a più file che dimostra di funzionare molto bene
Questo articolo descrive una struttura che uso da tempo per costruire agenti GPT. Ma è bene dirlo subito: non è uno standard pubblicato da qualcun altro, è la ricostruzione, fatta con materiale mio, di come questa architettura è nata, si è consolidata, ed è oggi mantenuta da un agente dedicato a questo scopo dopo aver attraversato diverse versioni, alcuni errori corretti, e almeno un ripensamento profondo.
1. Dall’LLM nudo all’Agente
Un modello linguistico, da solo, non ricorda chi è. Ogni conversazione riparte da zero: nessuna identità stabile, nessuna regola che sopravviva alla sessione precedente, nessuna base di conoscenza propria da cui attingere. È un motore straordinario, ma senza carrozzeria — capace di tutto e di niente in particolare, perché ogni volta va reistruito da capo su cosa deve fare, come deve comportarsi, dove deve fermarsi.
L’agente nasce per colmare esattamente questo vuoto. Un Custom GPT prende quel motore e lo incapsula in qualcosa che persiste: un’identità dichiarata, delle regole operative che non vanno riscritte a ogni turno, una conoscenza specifica che il modello può consultare invece di inventare. Il risultato non è più un generatore di testo generico ma uno strumento specializzato — qualcosa che si comporta in modi più gestibili, e che si può correggere e far evolvere senza doverlo reinventare da zero ogni volta.
Ma “incapsulare” è la parola facile. Il problema vero comincia subito dopo: dove va cosa. Un’identità, delle regole, della conoscenza — messe tutte insieme senza criterio, in un unico blocco di testo, funzionano finché l’agente è semplice e finché nessuno deve più toccarlo. Non appena l’agente cresce, o deve essere aggiornato mesi dopo da chi non lo ricorda a memoria, l’assenza di una struttura si paga. È qui che entra in gioco l’architettura di cui parla questo articolo — e per capire perché ha preso proprio questa forma, bisogna partire da un vincolo che sembra tecnico e minore, e che invece decide quasi tutto il resto.
2. I vincoli tecnici che impongono la forma
Prima di parlare di come è organizzato un agente, bisogna dire qualcosa sul contesto che lo ospita. La piattaforma impone dei limiti precisi, e la struttura che uso è in gran parte una risposta a quei limiti, non una preferenza stilistica.
Il campo istruzioni di un Custom GPT ha un tetto di 8000 caratteri. Superato quel limite, semplicemente non si può salvare altro. Io ne applico uno mio più prudente: tengo le istruzioni entro un margine più stretto, intorno ai 4000 caratteri, per lasciarmi respiro — spazio per aggiungere, correggere, ristrutturare senza sbattere subito contro il limite assoluto.
Poi c’è la base di conoscenza, la KB: qui i vincoli cambiano natura. Si possono caricare fino a 20 file, e ogni file può essere anche piuttosto corposo — la dimensione qui non è il problema. Mentre il campo istruzioni è l’unico contenuto che il modello ha sempre e comunque sotto gli occhi, a ogni turno di ogni conversazione, i file della KB vengono recuperati quando il modello decide di consultarli — un meccanismo che si comporta più come una ricerca che come una lettura garantita. Questo significa che una regola scritta solo in un file della KB potrebbe, in certe conversazioni, semplicemente non emergere mai.
È una distinzione che ho imparato a mie spese, aggiustando nel tempo dove far vivere cosa. La tentazione iniziale è ovvia: tenere le istruzioni minime, spingere tutto il resto nella KB, risparmiare caratteri preziosi. Ma succede regolarmente che una regola pensata come sempre valida, se relegata nella KB, venga applicata in modo incostante — non perché il modello sbagli, ma perché quella regola non gli è arrivata sotto gli occhi in quella conversazione. La correzione, ogni volta, è la stessa: se una norma deve valere sempre, il suo posto è nel campo istruzioni, anche a costo di avvicinarsi al tetto reale di 8000 caratteri invece di restare comodi nel margine di sicurezza.
Da questi due vincoli — un campo istruzioni piccolo ma sempre presente, e una KB capiente ma di consultazione non garantita — discende quasi per intero il criterio che smonteremo nel resto dell’articolo: cosa va dove, e perché.
3. La struttura 5+1
Un agente costruito secondo questo standard è composto da sei file di testo con nomi fissi: instructions.md, appendix.md, Proto-DIR.md, AIR.md, README.md, changelog.md. In fase di deployment instructions.md viene riversato nel campo Instructions del GPT, mentre gli altri cinque vengono caricati come Knowledge. Questa collocazione fisica non è un dettaglio implementativo: è il criterio che decide cosa scrivere dove, come visto nella sezione precedente — instructions.md è l’unico contenuto sempre presente nel contesto del modello, il resto è recuperato su base semantica quando l’agente lo consulta.
I sei file non si dividono per funzione dell’agente, ma per tipo di contenuto. Non esiste un file per “come rispondere alle domande” e uno per “come gestire gli errori”: ogni funzione dell’agente attraversa più file contemporaneamente, e ciascun file raccoglie un solo tipo di materiale — identità e regole operative sintetiche, semantica e schemi, invarianti e modello a stati, permessi e limiti, indice, cronologia. È una divisione orizzontale del contenuto, non verticale per compito.
Di questi sei file, quattro sono normativi: concorrono a determinare il comportamento dell’agente e vengono effettivamente consultati durante il suo funzionamento (instructions.md, appendix.md, Proto-DIR.md, AIR.md). Uno è dichiaratamente non normativo: README.md ha funzione di indice e non entra mai nella logica operativa. Uno, changelog.md, non è normativo né consultato dall’agente in alcuna fase — esiste per chi mantiene il bundle, non per chi lo esegue.
Tra i quattro file normativi esiste una gerarchia esplicita, necessaria perché due file possono in linea di principio dichiarare regole in conflitto tra loro: instructions.md prevale su appendix.md, che prevale su Proto-DIR.md, che prevale su AIR.md. In pratica il conflitto è raro, perché ciascun file governa un dominio proprio e non sovrapposto, ma la gerarchia serve a rendere deterministica anche l’eccezione. La gerarchia è deterministica una volta che le fonti rilevanti sono state recuperate; non rende deterministico il recupero delle fonti. A questa gerarchia si affianca un sistema di riferimento incrociato: un file può rimandare esplicitamente a una sezione di un altro (una regola in Proto-DIR.md può citare uno schema definito in appendix.md) invece di duplicarne il contenuto — ogni informazione ha una sola collocazione canonica.
3.1 instructions.md
Contenuto: identità dell’agente in forma sintetica, missione, regole operative essenziali, e — quando l’agente distingue più modalità di funzionamento — la tabella o il criterio che decide quale modalità applicare a un dato input. Vincolo: deve restare entro il tetto imposto dalla piattaforma (8000 caratteri), tipicamente con un margine di sicurezza interno più stretto.
Il criterio di inclusione non è “importanza” ma persistenza di applicazione: qualunque regola debba valere identicamente in ogni sessione, senza eccezioni legate al fatto che l’agente abbia o meno consultato un altro file, appartiene qui. Il resto — anche se logicamente collegato — appartiene alla base di conoscenza. Non è raro che l’assegnazione iniziale di una regola a instructions.md o alla KB debba essere corretta con l’uso: una regola inserita solo nella KB, se osservata applicarsi in modo incostante, viene promossa a instructions.md.
3.2 appendix.md
Contenuto: la semantica tecnica dell’agente — schemi dei dati, tabelle di classificazione, definizione di eventuali stati interni strutturati, e la logica di elaborazione che richiede una definizione formale piuttosto che una descrizione in prosa. Quando la notazione ATON è in uso, è qui che vivono le dichiarazioni @schema, le tabelle di default, e — nel caso più maturo osservato — anche i blocchi di codice eseguibile quando una norma richiede un calcolo deterministico che il linguaggio naturale non può garantire con la stessa affidabilità.
Il principio strutturale rilevante è che una norma e la sua implementazione, quando entrambe esistono, restano nello stesso file. La ragione è che, tenute in file separati, possono divergere senza che nulla lo segnali: chi corregge la definizione di una regola non ha alcun meccanismo che lo obblighi a correggere anche il codice che quella regola applica, e viceversa. Tenerle a distanza di poche righe nello stesso documento non impedisce l’errore, ma lo rende visibile a una rilettura — cosa che due file distinti, consultati in momenti diversi, non garantiscono.
3.3 Proto-DIR.md
Contenuto: gli invarianti dell’agente — condizioni che valgono sempre, indipendentemente dallo stato in cui si trova — e il modello a stati che descrive le fasi operative dell’agente, le transizioni ammesse tra una fase e l’altra, e le condizioni di uscita da ciascuna. È anche il file dove si dichiara esplicitamente il perimetro del determinismo: quali comportamenti sono garantiti identici a parità di input, quali non lo sono per natura del meccanismo sottostante (per esempio un canale di ricerca non deterministico), e quali non lo sono per scelta di progetto (per esempio una fase di interazione libera con l’utente, dove l’invarianza richiesta non è “stessa risposta” ma “stessa tracciabilità delle fonti”).
Il modello a stati definito qui è ciò che permette di dire con precisione, per ogni possibile situazione, cosa l’agente farà — inclusi i casi di fallimento, che ricevono uno stato di destinazione esplicito invece di essere lasciati alla gestione implicita del modello.
3.4 AIR.md
Contenuto: identità formale dell’agente (nome, versione, tipologia), missione dichiarata in forma di permessi e obiettivi, e — soprattutto — la lista esplicita di ciò che l’agente può fare, ciò che deve fare, e ciò che gli è proibito fare a prescindere da qualunque richiesta ricevuta. Nella sua forma più sviluppata comprende anche le garanzie di determinismo (cosa il sistema promette che sarà sempre vero) e la gestione dei fallimenti a livello di principio, distinta da quella procedurale già coperta in Proto-DIR.md.
La distinzione tra Proto-DIR.md e AIR.md è sottile ma precisa: il primo descrive come l’agente si comporta; il secondo descrive fin dove può spingersi. Una regola operativa (quando fare una certa azione) appartiene al primo; un limite assoluto (non fare mai una certa azione, qualunque sia il contesto) appartiene al secondo.
3.5 README.md
Contenuto: panoramica dell’agente e mappa dei restanti file — cosa contiene ciascuno, a quali sezioni fare riferimento per una data informazione. È l’unico file per cui ogni bundle esaminato dichiara esplicitamente la natura non normativa: nessuna regola scritta solo qui ha effetto sul comportamento dell’agente. Funzione: orientare chi legge il bundle dall’esterno — chi lo mantiene, chi lo audita, chi lo eredita senza aver partecipato alla sua costruzione — non chi lo esegue.
3.6 changelog.md
Contenuto: la cronologia delle versioni, in ordine cumulativo — ogni voce riporta cosa è cambiato, perché, e nel caso di una rimozione, la motivazione esplicita di quella rimozione. Il vincolo distintivo di questo file è che la sua storia non può essere troncata: una nuova versione aggiunge una voce, non sostituisce le precedenti.
Di tutti e sei i file, è l’unico che l’agente non consulta mai durante il proprio funzionamento. Non contribuisce a nessuna decisione operativa, non è mai citato da una regola in instructions.md, appendix.md, Proto-DIR.md o AIR.md. È testimonianza per chi mantiene l’agente, non materiale di lavoro per l’agente stesso — una distinzione che tornerà utile più avanti, quando parleremo dello spazio disponibile nella base di conoscenza.
3.7 Il linguaggio dei file
Tutti e sei i file condividono un formato di base — Markdown, con intestazioni, tabelle e blocchi di codice recintati — ma al suo interno convivono due registri diversi, usati per scopi diversi e non intercambiabili.
Il primo è la prosa naturale, impiegata per tutto ciò che richiede giudizio più che verifica: permessi, limiti, motivazioni, principi. Anche qui, però, la prosa non è libera quanto sembra. Le proposizioni che portano un vincolo normativo usano un piccolo insieme fisso di verbi modali — deve, non deve, dovrebbe, può — ciascuno con un peso distinto e mai intercambiabile: un “deve” dichiara un obbligo che il controllo tratta come bloccante, un “dovrebbe” un’indicazione che ammette eccezione motivata, un “può” un margine di discrezione esplicito. Questa graduazione non è stile: è ciò che permette a chi legge — umano o agente — di sapere, da una singola parola, quanto è rigido un vincolo, senza dover consultare un documento a parte che lo spieghi. Alla stessa logica risponde la terminologia: un concetto ha un solo nome, ripetuto identico in tutti i file in cui compare, mai sostituito da un sinonimo per varietà stilistica. La ragione è la stessa vista a proposito dell’auto-lettura al paragrafo 4.1: un processo di lettura automatica riconosce una corrispondenza esatta, non un’equivalenza di significato.
Il secondo registro è una notazione compatta, riservata al contenuto che deve poter essere letto e verificato in modo strutturato — non solo compreso. Compare sempre dentro blocchi di codice esplicitamente marcati come tali, e assume due forme ricorrenti. La prima è l’enumerazione: un insieme chiuso di valori — gli stati possibili di un processo, le categorie di una classificazione — scritto come una sequenza di righe, ciascuna con un codice, un’etichetta e una breve descrizione, separati da un carattere fisso. La seconda è la dichiarazione di schema: una struttura tipizzata, che elenca i campi di un oggetto con il loro tipo e l’obbligatorietà, in una forma più compatta di uno schema JSON ma con la stessa funzione — dire esattamente quali campi un dato deve avere prima che qualcosa lo produca o lo consumi. Queste dichiarazioni compaiono ovunque una struttura debba essere validata o richiamata da un altro punto del bundle: una voce di cronologia delle modifiche, una direttiva, un record di costruzione.
A questi si affianca una terza convenzione minore ma non trascurabile: un contenuto puramente illustrativo — un esempio di percorso, una sequenza dimostrativa — riceve un proprio tipo di blocco, distinto da quello usato per le dichiarazioni normative. La distinzione grafica non è decorativa: impedisce che un esempio venga letto, da un processo automatico o da un revisore distratto, come se fosse esso stesso una regola.
Anche l’organizzazione interna dei singoli file segue un criterio, non un’abitudine. Un file che raccoglie contenuto relativamente omogeneo tende a un’indicizzazione piatta — una sequenza di sezioni allo stesso livello. Un file che raccoglie contenuto più eterogeneo e articolato tende invece a una struttura più profonda, con raggruppamenti di livello superiore che riuniscono sezioni imparentate. Non è un’incoerenza tra file: è lo stesso principio che governa la ripartizione tra i sei file applicato una seconda volta, all’interno di ciascuno di essi — la struttura riflette cosa il contenuto è, non uno schema imposto dall’esterno a prescindere da cosa contiene.
I due registri — prosa modale e notazione formale — coesistono per la stessa ragione per cui coesistono determinismo dichiarato e superficie conversazionale libera, discussi al paragrafo 4.1: ciò che richiede un giudizio resta in una forma che il giudizio sa maneggiare; ciò che richiede una verifica passa in una forma che la verifica può controllare meccanicamente. Un bundle scritto interamente in prosa perderebbe la seconda proprietà; uno scritto interamente in notazione formale perderebbe la prima.
4. Principi trasversali e governo del bundle
I capitoli precedenti hanno descritto la struttura a sei file come oggetto statico: cosa contiene ciascun file, quali vincoli lo definiscono, come si collocano tra loro. Restano da trattare due questioni che non riguardano il singolo file ma l’insieme, e che finora sono state solo sfiorate. La prima è di natura tecnica: quali proprietà attraversano l’intero bundle, indipendentemente dal file in cui ci si trova. Il confine tra ciò che è deterministico e ciò che non lo è, la capacità dell’agente di leggere e interpretare la propria base di conoscenza all’avvio di una conversazione, il divieto di introdurre sottocartelle o formati eterogenei all’interno della KB, e il criterio per cui i file si dividono per tipo di contenuto e non per funzione dell’agente: sono tutti aspetti che non appartengono a un file particolare ma condizionano il modo in cui tutti e sei vengono scritti e letti. La seconda riguarda un fatto pratico che finora è rimasto sullo sfondo: chi produce e mantiene un bundle di questo tipo. La struttura descritta nei capitoli precedenti non nasce né si aggiorna per iniziativa diretta di chi userà l’agente finale; richiede un agente specializzato in questo compito, capace non solo di costruire un bundle conforme ma di verificare, tra una versione e la successiva, che nulla sia andato perso. I due paragrafi che seguono trattano questi punti nell’ordine indicato.
4.1 Principi trasversali
Quattro proprietà attraversano l’intero bundle senza appartenere a un file specifico. Non sono regole aggiuntive rispetto a quanto già descritto: sono il modo in cui le regole già descritte vengono applicate in modo uniforme su tutti e sei i file.
Get Leone Venticinque’s stories in your inbox
Join Medium for free to get updates from this writer.
Riduzione dell’aleatorietà. All’interno del bundle convivono tre categorie di comportamento; la loro distinzione favorisce una tendenza reale al determinismo. La prima è ciò che è deterministico per costruzione: dato lo stesso input normalizzato, lo stesso instradamento verso lo stesso modulo, e lo stesso stato delle capacità disponibili in quel momento, l’agente in linea di massima produce lo stesso percorso di esecuzione e lo stesso artefatto tipizzato. Questa garanzia riguarda la struttura della risposta, non il suo contenuto testuale letterale: due esecuzioni identiche possono differire nella formulazione delle frasi di transizione senza differire nella decisione presa. La seconda categoria è la non-determinatezza intrinseca al canale sottostante: quando un modulo invoca uno strumento esterno — una ricerca, una chiamata API, un calcolo che dipende da uno stato non controllato dall’agente — il risultato non è riproducibile dall’agente stesso, perché non dipende da esso. In questo caso il bundle non finge un determinismo che non può garantire: dichiara la dipendenza e, dove il controllo è possibile, registra il metodo con cui il dato è stato ottenuto.
In sintesi, mentre la superficie conversazionale — il modo in cui una domanda viene posta, il tono di una spiegazione breve — può variare da un’esecuzione all’altra pur a parità di condizioni, si tende a preservare il risultato che consiste nell’artefatto, nella sua classificazione o in qualunque decisione normativa: la libertà è concessa alla forma dell’esposizione, mai al contenuto della decisione.
Self-read. Il bundle è progettato per essere letto dall’agente che lo usa, non solo dall’operatore umano che lo mantiene. All’apertura di una conversazione l’agente può accedere al contenuto della base di conoscenza e ricavarne i moduli attivi, le sequenze da seguire, gli schemi da rispettare: la capacità di auto-lettura non è un’opzione implementativa ma una condizione di funzionamento, perché senza di essa i file di appendix.md, Proto-DIR.md e AIR.md resterebbero materiale inerte invece che fonte normativa consultata a runtime. Questo requisito retroagisce sullo stile di scrittura dei file — le convenzioni descritte al paragrafo 3.7 rispondono in parte proprio a questa esigenza — ed evita in particolare l’ambiguità che un lettore umano risolverebbe per contesto ma che un processo di lettura automatica non può sciogliere allo stesso modo.
KB piatta. La base di conoscenza non ammette sottocartelle: ogni file è allo stesso livello, ogni file ha un nome fisso, ed è questa uniformità strutturale — più che il numero di file in sé — a rendere il bundle prevedibile: un agente costruito secondo questo criterio si presenta sempre allo stesso modo, indipendentemente da quale sia stato configurato. L’assenza di gerarchie interne è anche ciò che rende praticabile l’auto-lettura descritta al punto precedente: un agente che dovesse navigare una struttura ad albero per ricostruire le proprie regole introdurrebbe un livello di indirection che il modello di esecuzione non prevede.
Livelli orizzontali, percorsi verticali. I sei file dividono il contenuto per tipo — instructions.md il routing sempre attivo, Proto-DIR.md le sequenze, AIR.md l’identità e i limiti, appendix.md gli schemi e i casi — e non per funzione dell’agente. Questo significa che una singola funzione dell’agente non coincide mai con un singolo file: attraversa tutti quelli che la riguardano. Una funzione è quindi un percorso verticale che taglia trasversalmente gli strati orizzontali del bundle: la riga di instructions.md che la instrada, la sequenza di Proto-DIR.md che la esegue, i vincoli di AIR.md che la limitano, lo schema di appendix.md che ne definisce l’input e l’output. Aggiungere o modificare una funzione non significa quindi mai creare un nuovo file: significa aggiungere un segmento a ciascuno dei percorsi verticali che quella funzione attraversa, mantenendo fissa la ripartizione orizzontale che il bundle già possiede.
4.2 Chi costruisce e mantiene il bundle
I capitoli precedenti hanno descritto un artefatto tecnico complesso: sei file interdipendenti, una gerarchia di priorità tra fonti normative, un sistema di riferimenti incrociati, vincoli di dimensione da rispettare senza perdere contenuto normativo. Va detto con chiarezza che produrre e mantenere un bundle di questo tipo non rientra nelle competenze né nel tempo disponibile di un utente medio. Non si tratta di compilare un modulo o di adattare un modello: significa elicitare requisiti in modo sistematico, tradurli in una specifica coerente, distribuirli tra i file secondo il criterio di collocazione descritto al capitolo 3, verificare che nessun vincolo dichiarato in un file contraddica un vincolo dichiarato in un altro, e infine validare che il risultato rispetti i limiti dell’ambiente ospitante prima ancora di essere caricato.
Per questo la costruzione e l’aggiornamento del bundle sono compiti affidati a un agente specializzato in questa attività — un agente che tratta la costruzione di altri agenti come proprio dominio operativo, anziché delegarla a un processo manuale o a un’interazione libera con un modello generico. Un simile agente non si limita a generare i sei file una tantum: gestisce anche il loro aggiornamento nel tempo, che segue un principio diverso dalla costruzione iniziale. Mentre la costruzione parte da una specifica confermata e produce un bundle completo, l’aggiornamento parte da un bundle esistente e vi applica solo le modifiche esplicitamente richieste, preservando per default tutto ciò che non è oggetto di una direttiva di cambiamento. Questa asimmetria non è incidentale: un bundle già in uso da un agente operativo accumula assestamenti, casi limite risolti, formulazioni che si sono rivelate necessarie a seguito di un comportamento indesiderato osservato in produzione. Rigenerare il bundle da zero a ogni modifica rischierebbe di perdere silenziosamente questo patrimonio; applicare solo la variazione richiesta lo protegge.
Proprio perché la preservazione è il comportamento di default, serve un modo per verificare che sia stata rispettata. Qui entra in gioco la seconda funzione richiesta a questo agente specializzato: l’audit tra una versione del bundle e la successiva. L’audit non si basa su ciò che il file di changelog dichiara essere cambiato, ma sul confronto diretto e computato tra le due versioni: la differenza effettiva tra i file prevale sempre sulla differenza dichiarata. Questo accorgimento non è ridondante — è la difesa contro il caso in cui un aggiornamento abbia rimosso o alterato un elemento senza che il changelog lo registri, per omissione o per errore. Un audit che si limitasse a leggere il changelog erediterebbe qualunque imprecisione commessa nello scriverlo; un audit che ricalcola la differenza reale tra le due versioni non dipende da quanto accuratamente il cambiamento è stato descritto a parole.
Questa stessa funzione di verifica pone però un problema di indipendenza del giudizio: un agente non dovrebbe validare la qualità del proprio stesso lavoro appena svolto, per la stessa ragione per cui un autore non è il miglior revisore del proprio testo. Un agente che costruisce o aggiorna bundle e che, nella stessa sessione in cui lo ha appena fatto, deve anche esprimersi in modo indipendente su quel risultato, richiede un meccanismo che impedisca al giudizio di venire condizionato dal lavoro appena eseguito: una sessione che ha appena costruito o aggiornato un bundle non è nella condizione di validarlo con la stessa sessione. Il controllo e l’audit di quel bundle vanno quindi condotti in una sessione distinta, priva del contesto della costruzione appena avvenuta — una lettura a freddo del risultato, indipendente da chi lo ha appena prodotto.
5. Margine, adattamento, altri ambienti
Sei file su un limite massimo di venti lascia un buon margine. Il bundle canonico copre l’intera superficie normativa e informativa dell’agente — instradamento, sequenze, identità e limiti, schemi e casi, panoramica, storico — restando comunque a meno di un terzo della capienza consentita. Ciò ha una funzione precisa: rendere possibile l’aggiunta di elementi che non appartengono al bundle in senso proprio ma che ne estendono le capacità operative, senza dover intaccare la struttura descritta nei capitoli precedenti né rinegoziare i vincoli che la governano. Vi rientrano, ad esempio, librerie di supporto in un linguaggio di programmazione che l’agente può richiamare per eseguire calcoli o trasformazioni che un modello linguistico non esegue in modo affidabile, oppure moduli intercambiabili — pensati per essere sostituiti l’uno con l’altro secondo uno standard di interfaccia condiviso — che orientano in modo mirato un aspetto specifico del comportamento dell’agente senza richiedere una revisione del bundle che li ospita. Il margine esiste perché questi elementi non sono eccezionali: sono una possibilità prevista fin dalla scelta di non saturare lo spazio disponibile con il solo bundle di base.
Su questo stesso terreno si colloca un’osservazione più circoscritta, che riguarda uno solo dei sei file. Il changelog, a differenza degli altri cinque, non viene mai consultato dall’agente in fase operativa: la sua funzione è interamente rivolta a chi legge il bundle dall’esterno, non a chi lo esegue. Questa caratteristica lo rende, tra i sei file, l’unico che può essere spostato fuori dalla base di conoscenza senza alcuna conseguenza sul funzionamento dell’agente — trasferendone il contenuto in un archivio separato, esterno al bundle attivo. Non è una raccomandazione generale: uno storico delle versioni consultabile insieme al resto del bundle resta la condizione preferibile, perché tiene la storia dell’agente nello stesso luogo in cui si trova tutto il resto. È però un’opzione pratica disponibile nel momento specifico in cui gli altri slot della base di conoscenza si sono già riempiti con librerie e moduli aggiuntivi e serve liberare uno spazio senza intervenire sui cinque file che l’agente usa attivamente. In quel caso, e solo in quel caso, rimuovere il changelog dalla base di conoscenza è un modo per risolvere un problema di spazio senza alcun costo funzionale.
Il margine appena descritto dipende da un rapporto specifico tra due grandezze: la dimensione minima necessaria a coprire la superficie normativa dell’agente e il tetto massimo di file consentito dalla piattaforma. Un ambiente diverso da quello qui descritto potrebbe alterare questo rapporto in entrambe le direzioni. Un limite di caratteri per le istruzioni più ampio di quello trattato al capitolo 2 ridurrebbe la pressione che oggi spinge parte del contenuto verso la base di conoscenza, e potrebbe rendere superfluo isolare in un file a parte ciò che qui risiede in appendix.md o in Proto-DIR.md; un limite più stretto avrebbe l’effetto opposto, costringendo a frammentare ulteriormente ciò che qui sta in cinque file normativi. Allo stesso modo, un tetto massimo di file più basso di venti restringerebbe il margine appena descritto fino a renderlo nullo, imponendo scelte più severe su cosa tenere nel bundle e cosa lasciar fuori; un tetto più alto lo amplierebbe, rendendo meno urgente qualunque valvola di sicurezza come quella appena discussa per il changelog. Ciò che non cambierebbe, in nessuno di questi scenari, è il criterio che ha generato la struttura in primo luogo: partire dai vincoli effettivamente imposti dall’ambiente ospitante e distribuire il contenuto in base a essi, piuttosto che importare una struttura pensata per vincoli diversi dai propri. La struttura a sei file descritta in questo articolo è la soluzione che quel criterio produce nelle condizioni specifiche descritte al capitolo 2; ambienti con vincoli diversi produrrebbero, applicando lo stesso criterio, un numero di file e una distribuzione dei contenuti diversi, non necessariamente la stessa struttura.
6. Confronto con strutture alternative
La versione a 5+1 file non è l’unico modo in cui l’ambiente qui descritto può essere organizzato: è una delle risposte possibili ai vincoli esposti al capitolo 2. Il confronto che segue prende quattro impostazioni alternative per la costruzione di agenti in questo stesso ambiente e le valuta sugli stessi criteri già usati per motivare la 5+1: dove va collocato un contenuto che deve valere sempre, come si risolve un conflitto tra fonti, se la struttura resta leggibile dall’agente stesso, come si gestisce il margine di file disponibile, e se un cambiamento tra una versione e la successiva resta verificabile.
6.1 Tutto nelle istruzioni, un solo file
La versione più elementare rinuncia del tutto ai file di conoscenza e affida ogni contenuto al solo testo delle istruzioni, tipicamente ripartito in due blocchi informali — un contesto che descrive chi userà l’agente e per cosa, e una serie di indicazioni su tono e formato della risposta. Entro un budget di poche migliaia di caratteri questa impostazione funziona: non c’è nulla da distribuire, quindi non c’è conflitto tra fonti da risolvere né margine di KB da amministrare. Il limite emerge non appena l’agente richiede più di una manciata di regole comportamentali: senza un deposito esterno in cui collocare schemi, sequenze o casi, ogni aggiunta comprime lo spazio disponibile per tutto il resto, con risultati pessimi per la qualità e l’utilità dell’Agente.
6.2 Pochi grandi file
Un’indicazione diffusa tra chi costruisce Custom GPT è di consolidare invece di frammentare: pochi file di dimensione generosa, anziché molti file piccoli, perché si sostiene in base all’esperienza empirica che il recupero per rilevanza sia più affidabile su blocchi ampi che su frammenti numerosi. Una variante più radicale della stessa logica rinuncia del tutto al recupero nativo e sposta la logica dell’agente in un sistema esterno richiamato tramite chiamate a servizi terzi. La prima variante abbandona la divisione orizzontale per tipo di contenuto: se identità, sequenze e schemi confluiscono in uno o due file soltanto, non c’è più nulla da mettere in ordine di priorità, perché la priorità presuppone fonti distinte tra cui scegliere. La seconda variante risolve il problema dell’inaffidabilità del recupero spostandolo fuori dall’ambiente: a quel punto, però, l’oggetto del confronto cambia natura. Un deposito esterno non è più soggetto al limite di venti file né al criterio di auto-lettura discusso al paragrafo 4.1, perché la logica dell’agente non risiede più nella base di conoscenza consultata dal modello linguistico, ma in un sistema che il modello interroga come farebbe con qualunque altro strumento esterno.
6.3 Istruzioni minime, tutto il resto in kb
Un’impostazione opposta alla precedente propone di ridurre le istruzioni al minimo indispensabile e di spostare in KB anche contenuti come lo stile di risposta o i pattern comportamentali, dato che comunque la base di conoscenza viene recuperata a ogni turno in base alla rilevanza. Questa impostazione inverte il criterio di collocazione stabilito al capitolo 2: un contenuto che deve valere sempre viene qui affidato a un canale che, per definizione, recupera solo ciò che risulta rilevante per la richiesta specifica. Una regola di stile o di comportamento spostata in un file di KB non ha alcuna garanzia di essere effettivamente presente nel contesto al momento in cui servirebbe; il suo rispetto diventa condizionato, non costante. L’impostazione può avere senso per contenuti che sono legittimamente occasionali — un caso d’uso raro, un formato di risposta richiesto solo in circostanze specifiche — ma non per norme che l’agente deve osservare in ogni turno, per le quali il posizionamento nelle istruzioni non è una preferenza stilistica ma la condizione che ne garantisce l’applicazione.
6.4 Struttura numerata per argomento
La proposta più articolata reperibile è un insieme di file numerati, ciascuno dedicato a un argomento — regole fondamentali, tono del brand, procedure operative, esempi, restrizioni, domande frequenti, cronologia delle modifiche — con la priorità tra fonti affidata all’ordine dei nomi file piuttosto che a una gerarchia dichiarata esplicitamente. È l’alternativa più vicina alla 5+1 per numero di file e per l’aver isolato la cronologia in un file a sé, ma il criterio di divisione è diverso: qui ogni file corrisponde a un argomento o a una funzione dell’agente, non a un tipo di contenuto. Per un agente che eroga uno stile di comunicazione e un insieme di procedure semplici, questo funziona: ogni argomento resta contenuto in un unico file, facile da individuare e da aggiornare. Il criterio smette di reggere quando l’agente comprende più attività distinte, ciascuna con una propria identità di vincoli, una propria sequenza e propri schemi: a quel punto il file “procedure operative” tenderebbe a contenere, per ciascuna attività, la stessa mescolanza di identità, sequenza e schema che la divisione per tipo di contenuto tiene volutamente separata — ricreando, argomento per argomento, il problema che quella separazione serve a evitare. Resta inoltre una differenza di natura, non solo di grado: un ordine di numerazione dei file indica in che sequenza consultarli, ma non stabilisce cosa fare quando due file sono in disaccordo sullo stesso punto; una catena di priorità dichiarata, come quella tra i quattro file normativi della 5+1, è invece un criterio di risoluzione del conflitto, non solo un ordine di lettura.
Nessuna delle quattro alternative esaminate tratta esplicitamente il determinismo dell’esecuzione, l’auto-lettura o l’audit tra versioni: sono tutte pensate per agenti la cui identità, il cui tono e il cui repertorio di risposte esauriscono il compito da svolgere. Il confronto non stabilisce quindi che la 5+1 sia una struttura superiore in assoluto, ma che risponde a un problema diverso da quello a cui le altre rispondono: un agente con logica esecutiva propria, versioni successive da mantenere e verificare, e norme che devono restare garantite indipendentemente da cosa l’utente chieda in un turno specifico. Per un agente che non ha queste esigenze, una delle strutture più semplici esaminate qui può essere la scelta corretta; la 5+1 è la risposta a un insieme di vincoli più stringente, non un modello da applicare indipendentemente da quali vincoli si abbiano davanti.
Conclusioni
Le pagine precedenti non descrivono una preferenza tra strutture equivalenti: fanno emergere una prima necessità strutturale e motivano una successiva scelta architetturale. Un limite fisso di caratteri per ciò che deve restare sempre disponibile e un tetto massimo di file per tutto ciò che viene invece recuperato per rilevanza non lasciano, applicati con coerenza, alcuna libertà di collocazione: ogni contenuto normativo va o nell’unico spazio a inclusione garantita, o in uno dei file a inclusione condizionata, e questa alternativa binaria è già sufficiente a generare la partizione tra istruzioni e base di conoscenza descritta al capitolo 2. Da qui discende, per lo stesso principio applicato una seconda volta, la divisione interna alla base di conoscenza per tipo di contenuto anziché per funzione: se un file deve poter essere letto e verificato indipendentemente dagli altri — condizione necessaria perché l’agente lo interpreti da sé e perché un audit ne calcoli la differenza tra due versioni — allora ogni tipo di contenuto normativo richiede un contenitore proprio, sempre lo stesso, non ricreato di volta in volta per ogni nuova funzione che l’agente acquisisce. I vincoli della piattaforma determinano la prima grande partizione tra istruzioni persistenti e conoscenza recuperabile. All’interno della seconda, la 5+1 è la partizione che, attraverso successive iterazioni, si è dimostrata più adatta ai requisiti aggiuntivi di separazione delle responsabilità, auditabilità, manutenzione e crescita modulare.
La preferibilità rispetto ad altre strutture, che l’articolo si proponeva di argomentare fin dal titolo, non poggia allora su un giudizio di eleganza formale. Le strutture realmente in uso per agenti più semplici funzionano perché quei vincoli, in quei contesti, non si presentano con la stessa urgenza — non c’è logica esecutiva propria da preservare tra una versione e l’altra, né una gerarchia di priorità da rendere esplicita tra fonti che potrebbero altrimenti confliggere. Nel momento in cui quelle condizioni compaiono — un agente che esegue sequenze proprie, che deve tendere al determinismo a parità di input, e la cui storia va verificata e non solo dichiarata — le stesse strutture più semplici cessano di reggere, non per un difetto di realizzazione ma perché rispondono a un problema diverso. La 5+1 è preferibile non in assoluto, ma in ogni caso in cui l’insieme di condizioni appena descritto è effettivamente presente: è questa la tesi che il confronto del capitolo 6 ha messo alla prova, e che ha retto proprio nei termini in cui era stata formulata.
Da questa stessa necessità discende, senza bisogno di un argomento ulteriore, il fatto che costruire e mantenere un simile bundle non possa essere delegato a una competenza generica. Tali funzioni devono essere eseguite da un agente specializzato in questo compito, non solo al momento della creazione della struttura ma anche per mantenerne, versione dopo versione, le proprietà che deve avere.
Resta aperto, e deliberatamente non trattato qui, il modo in cui un simile agente di costruzione e manutenzione debba essere a sua volta progettato: è un oggetto distinto dal bundle che produce, con proprie regole di funzionamento, e merita una trattazione a sé anziché una trattazione accessoria in coda a questa. Resta aperta, allo stesso modo, la standardizzazione dei moduli intercambiabili accennati al capitolo 5: se il margine lasciato nella base di conoscenza deve ospitare componenti pensati per essere sostituiti l’uno con l’altro, occorre uno standard di interfaccia condiviso che questo articolo si è limitato a presupporre, non a specificare. E resta aperta, infine, una verifica che nessuna struttura può dichiarare conclusa una volta per tutte: se i vincoli che l’hanno generata — il limite di caratteri, il tetto di file — dovessero cambiare, in questo ambiente o in un altro, la struttura da adottare andrebbe ricavata di nuovo dagli stessi criteri, non ereditata invariata da un contesto che non vale più. È questo, più che la forma a sei file in sé, il risultato che l’articolo consegna: un metodo per derivare una struttura dai vincoli reali, applicabile anche il giorno in cui quei vincoli non saranno più gli stessi.
