La differenza tra il CMS tradizionale e l’agente AI

Quando un utente fa uso di un CMS, il sistema non gli chiede “Perché stai cambiando questo titolo?”: registra il cambiamento e basta. L’intenzione resta implicita nel contesto: era una bozza, ora è pubblicato; era un testo di esempio, ora è quello definitivo. Il CMS non ha bisogno di “capire”: l’ambito di ogni modifica è definito dall’interfaccia stessa. Stai modificando quel campo di quella pagina. L’interfaccia rende visibile l’ambito dell’operazione.

Con un agente AI la dinamica si rovescia. L’agente vede il contesto più ampio: “sa” che quella pagina esiste in tre lingue, che quel componente è usato in altri quattro posti, che il tono editoriale del sito segue certe convenzioni. Questa visione d’insieme è la sua forza, ed è esattamente ciò che rende pericolosa un’istruzione formulata male.

In un sistema agentico, l’ambito di un cambiamento non è definito dalla UI. È definito da come l’agente interpreta il prompt. E qui nasce il problema che questo articolo esplora: “Aggiorna il tono” può significare un file o l’intero sito, a seconda dell’interpretazione. Il rischio principale dei sistemi agentici per la gestione di contenuti non è che scrivano male ma è un’azione con scope implicito che si rivela più ampio di quanto voluto.

Un esempio concreto

Facciamo un esempio. Con i colleghi di Agile Reloaded sto lavorando alla creazione dei contenuti del sito di TechReloaded e fra questi ci sono le pagine relative al progetto ARchetipo. In tale contesto, un comando come

“Aggiorna la descrizione di ARchetipo.”

sembra un’istruzione chiara, ma non lo è. Nel sito la descrizione del progetto compare in molti punti differenti: nella pagina prodotto italiana, nella sua traduzione inglese, nella pagina della documentazione, nell’homepage (dentro il box dell’hero), in almeno due articoli del blog, e nella variante ai/ del sito pensata per i crawler AI. Più sorgenti e varianti, con funzioni editoriali diverse.

Un agente “diligente” che interpreta l’istruzione in senso ampio aggiorna tutte queste occorrenze. Un agente “prudente” ne aggiorna una: quello che gli sembra “la” pagina di ARchetipo. Entrambi hanno eseguito l’istruzione ma nessuno dei due ha fatto necessariamente quello che l’utente voleva.

In un flusso di modifica pagina per pagina, il perimetro è più esplicito: l’utente editor apre la pagina prodotto, modifica il campo descrizione, salva le modifiche. Se vuole cambiare anche l’homepage, apre l’homepage. Modificare pagine diverse richiede azioni distinte. La granularità dell’interfaccia è il meccanismo di controllo dello scope.

Togliere quell’interfaccia — che è l’intera promessa del CMS agentico — significa dover ricostruire il controllo dello scope da qualche altra parte.

Configurare un collaboratore editoriale

Chiedere chiarimenti davanti a una richiesta ambigua è qualcosa che dovrebbe fare qualsiasi buon agente. Per un CMS agentico, però, possiamo progettare un comportamento più specifico: raccogliere le decisioni editoriali ricorrenti durante l’installazione e conservarle come regole del sito, modificabili con una successiva riconfigurazione.

L’editor non dovrebbe conoscere YAML, percorsi o nomi dei componenti. Dovrebbe rispondere a domande sul proprio lavoro: quali contenuti devono restare aggiornati, quali conservano valore storico, quali cambiamenti può delegare, quali fonti fanno fede. Il sistema tradurrebbe quelle risposte in una configurazione leggibile dall’agente.

Il valore specifico sarebbe la continuità: una risposta data dall’editor diventerebbe una regola consultata nelle sessioni successive. L’intervista avrebbe inoltre un vocabolario da CMS — pagine prodotto, articoli pubblicati, traduzioni, fonti, bozze e pubblicazione — e userebbe esempi del sito. Questo è un requisito di prodotto più concreto del generico invito all’agente a “fare le domande giuste”.

Un’intervista basata su casi reali

Su un sito esistente, Websmith dovrebbe prima leggere la configurazione e individuare i contenuti, poi presentare all’editor esempi riconoscibili. Su un sito nuovo partirebbe dai tipi di contenuto previsti, lasciando da completare le associazioni alle pagine quando saranno disponibili.

Le domande seguenti sono un esempio di intervista, con risposte ipotetiche: non descrivono decisioni già adottate per TechReloaded.

Domanda all’editor: Quando cambia la descrizione di un prodotto, quali contenuti devono riflettere la versione corrente?

Esempio di risposta: La pagina prodotto e il riepilogo in homepage.

Regola da ricavare: Collega quei contenuti in un gruppo di aggiornamento; adatta il riepilogo al suo spazio senza aggiungere informazioni.

Domanda all’editor: Gli articoli di blog già pubblicati che citano il prodotto devono essere riscritti quando cambia la sua presentazione?

Esempio di risposta: No, raccontano il prodotto com’era allora. Per correggere un errore, proponimi una rettifica.

Regola da ricavare: Escludi gli articoli storici dagli aggiornamenti ordinari; prepara una proposta per le rettifiche.

Domanda all’editor: Da dove devono arrivare le informazioni su funzionalità, disponibilità e risultati del prodotto?

Esempio di risposta: Dal materiale che approvo e dalla pagina prodotto corrente. Se manca un dato, chiedimelo.

Regola da ricavare: Usa soltanto le fonti approvate; non dedurre nuove promesse da una richiesta di riscrittura.

Domanda all’editor: Quali interventi vuoi delegare senza rivedere ogni proposta?

Esempio di risposta: Sostituzioni precise e adattamenti fedeli ai riepiloghi. Voglio vedere prima nuovi messaggi di posizionamento o promesse commerciali.

Regola da ricavare: Esegui le modifiche delimitate e gli adattamenti autorizzati; prepara una bozza per nuove scelte di posizionamento.

Domanda all’editor: Come vuoi che il sito si rivolga al lettore? Mi mostri un testo adatto e uno da evitare?

Esempio di risposta: Diretto e concreto. Va bene “Automatizza questi tre passaggi”; da evitare “Rivoluziona il tuo business”.

Regola da ricavare: Conserva indicazioni di tono ed esempi, utilizzabili per scrittura e revisione.

Domanda all’editor: Dopo aver preparato e verificato le modifiche, vuoi anche pubblicarle?

Esempio di risposta: Voglio vedere un’anteprima e autorizzare la pubblicazione.

Regola da ricavare: Distingui l’autorizzazione a modificare le sorgenti da quella a pubblicare.

Le domande sulle traduzioni devono partire dal contratto già presente. Se il sito impone l’aggiornamento delle traduzioni esistenti, l’intervista lo riassume senza richiedere la stessa autorizzazione a ogni modifica. Se l’editor vuole cambiare quella politica, si tratta di una riconfigurazione da rendere coerente anche con la guida del sito.

Una risposta come “aggiorna tutto” merita una domanda di approfondimento: comprende anche articoli datati e documentazione di vecchie versioni? L’intervista deve far emergere queste differenze, senza trasformare una risposta vaga in un’autorizzazione estesa.

Dalle risposte a una configurazione

Le risposte possono essere rappresentate in una sezione editorial del file websmith.yaml del sito. Ecco un esempio di come tradurre le scelte dell’intervista in regole strutturate:

editorial:
revision: 1

update_groups:
archetipo_description:
source:
page_id: archetipo
target: product_description
summaries:
- page_id: home
target: archetipo_summary
adaptation: preserve_facts_and_fit_target
historical_articles: exclude_unless_explicitly_requested

facts:
sources: [approved_editor_material, current_product_page]
missing_information: ask_editor

autonomy:
exact_replacement: apply
faithful_summary_update: apply
positioning_or_new_claims: propose_draft
historical_correction: propose_draft
unresolved_scope: ask_editor

voice:
style: diretto e concreto
preferred_example: "Automatizza questi tre passaggi"
avoid_example: "Rivoluziona il tuo business"

translations:
policy: inherit_site_contract

publication:
mode: preview_then_explicit_approval

Corrispondenze esplicite e nomi illustrativi

Le corrispondenze con le risposte sono esplicite: la prima definisce update_groups, la seconda il trattamento dei contenuti storici, la terza facts, la quarta autonomy, la quinta voice e l’ultima publication.

Anche i nomi home, product_description e archetipo_summary sono illustrativi. Durante la configurazione il sistema dovrebbe risolverli in identificativi e destinazioni reali delle sorgenti, mostrarli attraverso un’anteprima riconoscibile e verificare che esistano. Una regola “Aggiorna il riepilogo” senza sapere quale riepilogo resta ambigua. La pagina della documentazione, per esempio, non entrerebbe automaticamente nel gruppo solo perché cita ARchetipo.

Questa configurazione appartiene al sito. AGENTS.md conserva le regole comuni di Websmith; il manifest contiene le scelte editoriali locali senza duplicare lingue o dettagli visivi già definiti altrove. Il renderer continua a trasformare sorgenti in HTML in modo deterministico: non decide il tono, non inventa fatti e non traduce contenuti. Queste sono responsabilità del flusso agentico che prepara le sorgenti.

Verificare che la regola significhi ciò che l’editor intende

Prima di adottare la configurazione, Websmith dovrebbe restituire le risposte sotto forma di comportamenti concreti:

Se mi dai una nuova descrizione approvata di ARchetipo,
aggiornerò la pagina prodotto e ne adatterò il riepilogo in homepage.
Aggiornerò le traduzioni previste dal sito. Gli articoli storici manterranno
il testo originale. Ti mostrerò l’anteprima prima della pubblicazione.

Poi dovrebbe provare un caso di confine:

Se mi chiedi di presentare ARchetipo come “il più veloce sul mercato”
senza fornire una fonte approvata, ti chiederò su quali dati
basare questa affermazione.

L’editor può così correggere un comportamento comprensibile, senza dover interpretare faithful_summary_update. La conferma iniziale riguarda una delega riutilizzabile; non è un giro di conferma aggiunto a ogni sostituzione di testo.

In riconfigurazione, il sistema dovrebbe mostrare cosa cambia rispetto alle regole precedenti e ripetere gli esempi interessati. La nuova politica vale per le operazioni successive: adottarla non autorizza da solo una riscrittura retroattiva dei contenuti. Una richiesta occasionale, come “Aggiorna anche questo vecchio articolo”, vale per quel lavoro e non modifica automaticamente la regola permanente.

La stessa richiesta, dopo l’intervista

Riprendiamo “Aggiorna la descrizione di Archetipo”, questa volta accompagnata da un nuovo testo approvato. Con la configurazione dell’esempio, l’agente può comunicare:

Aggiorno la descrizione nella pagina prodotto e il riepilogo
in homepage, con le traduzioni previste. Applico la regola concordata
per i contenuti storici e preparo l’anteprima.

Non deve chiedere nuovamente quali pagine mantenere allineate: la risposta è nel gruppo configurato. Se invece la richiesta non contiene il nuovo testo né una fonte con le informazioni aggiornate, deve chiedere cosa è cambiato nel prodotto. La configurazione chiarisce le decisioni ricorrenti; non fornisce informazioni che l’editor non ha ancora dato.

Una richiesta precisa — «Cambia “Scopri di più” in “Leggi la documentazione” nel bottone della pagina prodotto» — resta limitata a quell’elemento e alle traduzioni dovute. Il gruppo delle descrizioni non si attiva per qualsiasi intervento sulla pagina prodotto. Una richiesta esplicitamente limitata a una pagina prevale sul normale ambito di propagazione editoriale, mentre restano applicabili gli obblighi tecnici del sito.

L’autonomia dipende dalle decisioni che l’editor ha delegato attraverso la richiesta corrente e le regole concordate durante l’intervista. Una sostituzione precisa su venti pagine può essere interamente autorizzata; una nuova promessa commerciale in una sola frase può richiedere una proposta. Il numero di pagine coinvolte, da solo, non determina la necessità di chiedere conferma.

Le regole devono avere un’applicazione verificabile

Scrivere un file YAML non basta a cambiare il comportamento di un agente. Il flusso dovrebbe caricare la politica del sito prima di pianificare le modifiche, risolvere le pagine e i blocchi coinvolti, applicare le autorizzazioni già date e chiedere soltanto le informazioni ancora necessarie.

Prima della consegna, un controllo dovrebbe confrontare le sorgenti modificate con l’ambito risolto. Riferimenti inesistenti, destinazioni ambigue o modifiche a pagine estranee al piano sono verificabili in modo meccanico. Restano invece di carattere editoriale i giudizi del tipo “Questo riepilogo preserva davvero il significato?” o “Questa frase introduce una promessa nuova?”. Questi richiedono una revisione del contenuto, non soltanto una validazione dello schema.

La pubblicazione richiede un controllo separato nel flusso che la esegue. Se un push avvia il deploy, la regola di approvazione va applicata prima di quel push: il renderer non può farla rispettare attraverso la sola generazione dell’HTML.

Il vantaggio di questo flusso è ridurre le domande ripetute e rendere verificabili le decisioni delegabili, conservando un punto di confronto per quelle nuove.

Il versionamento per tenere traccia delle decisioni applicate

Le decisioni concordate durante l’intervista possono lasciare una traccia anche nel messaggio del commit Git, cioè la descrizione che accompagna il salvataggio delle modifiche nella cronologia del progetto. Un commit registra una versione del lavoro; non coincide necessariamente con la pubblicazione del sito.

Il messaggio può descrivere il risultato, la richiesta che lo ha motivato e le regole editoriali applicate. Per una sostituzione puntuale basta un esempio semplice:

Cambia l'etichetta del bottone nella pagina ARchetipo

Sostituisce “Scopri di più” con “Leggi la documentazione”,
come richiesto dall'editor, e aggiorna le traduzioni previste.

Per un aggiornamento coordinato, è utile conservare anche il riferimento
alla politica del sito:

Aggiorna la descrizione di ARchetipo e il riepilogo in homepage

Applica il nuovo testo fornito dall'editor al gruppo
archetipo_description, secondo la politica editoriale revisione 1.
Adatta il riepilogo e aggiorna le traduzioni previste.
Gli articoli storici restano invariati, come stabilito dalla politica.

Chi consulta la cronologia può così ricostruire perché la stessa richiesta abbia coinvolto alcune pagine e non altre. Il riferimento alla revisione della politica permette di risalire alle regole valide al momento dell’intervento, anche se vengono riconfigurate in seguito: anche websmith.yaml deve quindi essere conservato nella cronologia Git.

Il messaggio documenta il lavoro a posteriori. Il comportamento dell’agente è guidato prima dell’intervento dalla richiesta e dalle regole concordate; il commit ne conserva la traccia. La descrizione non dimostra, da sola, che le regole siano state rispettate o che la pubblicazione sia stata autorizzata: questi controlli appartengono al flusso operativo.

Le attenzioni che questo modello richiede

Un approccio basato su questo modello richiede ovviamente una serie di attenzioni. Vediamole nel dettaglio.

La qualità dell’intervista

Deve usare esempi del sito e approfondire le risposte ambigue, senza diventare un questionario interminabile. Si può partire dalle decisioni più frequenti e proporre nuove regole quando un dubbio si ripresenta, chiedendo all’editor se la risposta debba valere anche in futuro.

La manutenzione delle associazioni

Se una pagina viene rimossa o un blocco cambia struttura, il gruppo di aggiornamento deve risultare non valido. L’agente deve segnalare il riferimento da correggere, invece di scegliere silenziosamente un’altra destinazione.

I conflitti e i casi non previsti

Le preferenze locali devono restare coerenti con il contratto comune. Una riconfigurazione incompatibile va spiegata prima di attivarla. Quando una richiesta non rientra nelle regole esistenti, il sistema deve formulare una domanda sul caso concreto, senza attribuirsi una delega nuova.

La verifica del risultato

Possiamo controllare quali file sono stati modificati e se una destinazione esiste; non possiamo dimostrare con lo stesso controllo che una riscrittura rispetti il tono o il significato. Il progetto deve rendere visibile questa distinzione, senza presentare la configurazione come garanzia di comprensione dell’intenzione.

Conclusioni

Il prossimo articolo della serie affronta il luogo dove tutte queste decisioni lasciano traccia: git come workflow editoriale nativo. Il commit conserva la traccia delle modifiche e delle regole applicate, il branch raccoglie il lavoro proposto e la pull request può diventare il luogo dove un cambiamento editoriale si discute prima di andare online, senza che chi gestisce i contenuti debba sapere cosa significa “rebase”.

Nota

Il codice di Websmith al momento non è pubblico. ma i principi descritti in questo articolo sono applicabili a qualsiasi sistema che combina agenti AI con contenuti statici.

Domande e commenti possono essere inviati via email a info@techreloaded.it