Il marketing context engineering stabilisce che cosa legge un modello di IA prima di scrivere per il vostro brand, lo carica tramite codice e verifica la bozza sullo stesso materiale. Come funziona, quanto costa e dove si ferma.
Il marketing context engineering è la pratica di decidere quali fatti, regole, esempi e limiti un modello di IA legge prima di redigere materiale di marketing per un brand, caricandoli nel codice anziché tramite istruzioni, e di verificare ogni bozza rispetto allo stesso materiale. Trasforma l'IA generativa da collaboratore imprevedibile in un partner creativo di cui un team controlla gli input.
Il context engineering è la disciplina che trasforma l'IA generativa da collaboratore imprevedibile in un partner creativo di cui controllate gli input. Applicato al marketing, decide quali fatti, regole, esempi e limiti un modello legge prima di redigere un annuncio, un'email o una landing page per il vostro brand, e verifica la bozza rispetto allo stesso materiale prima che qualcuno la pubblichi. Il termine si è diffuso tra i team che sviluppano agenti di IA, e oggi i team di marketing incontrano lo stesso problema dall'altro lato, nelle bozze che i loro assistenti consegnano.
Il prompt engineering lavora sull'istruzione, la frase che dice cosa scrivere. Il context engineering lavora su tutto ciò che il modello legge insieme a quell'istruzione: i claim approvati sul vostro prodotto, le parole che il vostro brand non usa mai, il prezzo attuale, due esempi di annunci che hanno funzionato, la regola secondo cui un numero di clienti richiede una data. Un prompt ben scritto non può fornire un fatto che il modello non ha mai ricevuto, ed è per questo che i team che perfezionano i loro prompt passano comunque il tempo di revisione a correggere gli stessi errori.
Un modello scrive della vostra azienda a partire da due sole fonti: ciò che gli fornisce la richiesta e ciò che ha assorbito durante l'addestramento. Per un'azienda nota quell'addestramento è ampio e superato, per una più piccola è quasi vuoto. Quando manca il fatto giusto, il modello produce qualcosa di plausibile, e il caso più evidente è la prova a sostegno: chiedete un annuncio con una prova convincente e compare un numero, perché è così che appare una prova convincente.
Per misurarlo abbiamo costruito un esempio pratico a partire dai documenti pubblici di una società di software quotata. Una prima bozza simulata ha arrotondato il numero di clienti a «300'000+» e ha collocato l'azienda in «140 paesi». Le fonti indicavano 306'446 clienti al 30 giugno 2026 e più di 135 paesi. Entrambi gli errori supererebbero una lettura rapida, e solo un controllo rispetto al file delle prove li ha individuati.
La stessa causa produce altre tre correzioni che i team di marketing fanno ogni settimana. Senza regole di tono scritte ed esempi abbinati, ogni bozza suona come il brand medio del modello. Un prodotto rinominato dopo l'ultimo brand book, o un prezzo cambiato il mese scorso, sopravvive in qualunque fonte il modello abbia assorbito. E le regole che esistono solo nella testa di qualcuno, come quali claim richiedono una revisione legale o chi approva un annuncio a pagamento, non possono essere seguite da un modello più di quanto lo possa fare un nuovo collega.
La prima soluzione abituale è incollare il brand book nel prompt, e si scontra con tre limiti. Il primo è il costo: nel nostro esempio il contesto completo del brand conteneva circa 36'000 token e le regole condivise dei compiti altri 22'000, quindi inviare tutto costa circa 58'000 token per richiesta, mentre il pacchetto costruito per un annuncio LinkedIn arrivava a circa 10'100 token, circa l'83 percento in meno, e conteneva comunque due annunci di esempio approvati. Il secondo è l'attenzione, perché un modello che legge un documento di 30 pagine non ha modo di sapere che la policy sui claim prevale su uno slogan di esempio a pagina 22. Il terzo è la prova: con una cartella allegata, nessuno può dire in seguito quale versione di un documento il modello abbia effettivamente letto.
Il marketing context engineering risponde a questi tre limiti con poche regole, ciascuna delle quali previene un errore. Ogni fatto vive in un solo file, così un prezzo corretto non può sopravvivere altrove nella sua vecchia forma. Ogni affermazione ha uno stato, approvato, riferimento, bozza, ipotesi, proposto o deprecato, e solo i contenuti approvati e di riferimento possono sostenere un claim nei testi esterni, il che permette a un team di partire con ipotesi etichettate senza che nessuna arrivi in un annuncio come fatto. Ogni claim cita la frase da cui proviene, con la sua fonte e la data in cui è stata letta.
Il caricamento e la verifica avvengono nel codice anziché come istruzioni al modello. Una richiesta viene classificata, il codice seleziona i cinque o dieci file di cui quel compito ha bisogno, fino a un singolo prodotto e ai claim relativi, e registra ogni file con il suo percorso, la sua versione e il suo hash SHA-256. La bozza viene poi verificata sugli stessi file per limiti di caratteri, parole vietate, grafia dei nomi, stato dei claim e numeri, e una persona approva tutto ciò che esce dall'azienda. Un'istruzione che chiede a un modello di leggere le linee guida del brand dipende dal fatto che il modello lo faccia, mentre il codice che inserisce le linee guida nel prompt e verifica il risultato no.
Il context engineering elimina gli errori causati da informazioni mancanti o non etichettate, e si ferma lì. Non rende persuasiva un'offerta debole e non sostituisce chi conosce il cliente. Nel nostro esempio una bozza che aveva superato tutti i controlli del codice ha comunque ottenuto 3 su 5 per pertinenza rispetto al pubblico, perché la persona per cui era scritta era stata costruita a partire da documenti pubblici. Solo interviste e dati del CRM possono correggerlo, quindi un buon sistema segnala la lacuna come domanda aperta invece di scriverci intorno.
Potete verificare in un pomeriggio quanto il vostro team sia lontano da questo. Prendete le ultime dieci bozze di IA che il vostro team ha corretto e contate quante correzioni riguardavano fatti, nomi o prezzi che il modello non aveva mai ricevuto. Poi scegliete un claim approvato, come un numero di clienti, e trovate tutti i posti in cui si trova: se la risposta è più di un file, le copie divergeranno. Infine, aprite un contenuto pubblicato e provate a indicare la versione del documento che il modello ha letto quando l'ha redatto.
Se la maggior parte delle correzioni riguarda fatti mancanti, la soluzione sta nel contesto e non nel prompt o nel modello. Lo stesso ragionamento vale per qualsiasi team che affida la scrittura a un assistente, dal sales enablement alle risposte predefinite del supporto, perché ognuno incontra lo stesso divario tra ciò che il modello sa e ciò che l'azienda ha approvato. Abbiamo costruito Torke Context per colmare questo divario per i team di marketing, e la pagina degli impegni descrive le regole che segue.
Ogni risposta sta in piedi da sola: potete inoltrarla a un collega, e un assistente IA a cui viene posta la stessa domanda può citarla così com'è.
Il prompt engineering lavora sull'istruzione che dice cosa scrivere. Il context engineering lavora su tutto ciò che il modello legge insieme a essa, come claim approvati, regole sulle parole, prezzi ed esempi, e sul codice che carica quel materiale e verifica la bozza.
Costa di più, non dà al modello alcun modo di capire quale regola prevale su quale, e nessuno può dimostrare in seguito quale versione il modello abbia letto. Nell'esempio pratico di Torke un contesto completo del brand costava circa 58'000 token per richiesta, contro circa 10'100 per un pacchetto costruito per un annuncio LinkedIn.
No. Elimina gli errori causati da informazioni mancanti o non etichettate. Un'offerta debole resta debole, e una persona costruita senza interviste ai clienti produce comunque bozze che mancano il pubblico.
Diteci che cosa vende il vostro team, chi lo acquista e dove le trattative si fermano. Riceverete una risposta scritta che indica quale modalità di lavoro fa per voi o se una Diagnosi ha senso, e, se nessuna delle due è adatta, il motivo.