Marzo 2026. Un nostro test su una versione interna di BP — l'assistente per business plan in arrivo nei prossimi mesi. Chiediamo all'agente: "Calcola il DSCR del piano dell'azienda XYZ per il primo anno."
L'agente risponde: "Il DSCR del primo anno è 1.42, in linea con i benchmark di settore."
Risposta perfettamente formulata. Toni professionali. Numero credibile.
Numero sbagliato.
Quello vero, calcolato a mano, era 0.87. Il piano aveva un problema strutturale di copertura del servizio del debito. Un valore di DSCR sotto 1 significa che l'azienda, a regime, non genera abbastanza cassa per pagare interessi e quote capitale dei finanziamenti. È esattamente il tipo di anomalia che un consulente esperto vede in dieci secondi, e che un business plan ben fatto deve segnalare con un punto esclamativo grosso.
L'agente l'aveva mancato. Non perché il prompt fosse scritto male. Era scritto benissimo. L'aveva mancato perché nel contesto che gli avevamo passato non c'erano i dati di cassa aggiornati. C'era una versione di tre giorni prima, congelata in cache, perfettamente plausibile e completamente fuori sincrono.
Questo è il problema che vogliamo raccontarvi oggi. Per due anni l'industria — noi inclusi — ha parlato di prompt engineering come della disciplina centrale dell'IA aziendale. Costruendo prodotti veri, abbiamo capito che è la disciplina giusta che risolve il problema sbagliato.
Quella vera si chiama context engineering. E nel 2026 è quella che separa i progetti AI che funzionano da quelli che girano benissimo in demo e male in produzione.
La differenza in due righe
Prompt engineering: come formulate la domanda al modello.
Context engineering: cosa il modello sa nel momento esatto in cui risponde alla domanda.
Detta così sembra una sottigliezza. Non lo è.
Pensateci come a un avvocato. Potete scrivere una richiesta legale perfetta, con tutti i tecnicismi, le formule rituali, il tono giusto (prompt perfetto). Ma se il giorno in cui l'avvocato la legge è ancora aggiornato sulla legge del 2018, vi darà un parere obsoleto. Quello che conta non è solo come gli avete chiesto la cosa. È cosa ha in testa quando ve la prepara.
Lo stesso vale per un LLM in produzione. Il prompt è la richiesta. Il contesto — i documenti che ha "in vista", i dati che gli passate, gli strumenti che può chiamare — è la sua "testa" in quel momento.
I cinque problemi reali del contesto
Quando dite "contesto" a una sala di tecnici nel 2024, intendono "i token che precedono nel prompt". Quando lo dite a una sala di tecnici nel 2026, intendono cinque cose insieme:
1. Cosa metti nel contesto. Quali pezzi della vostra documentazione, dei vostri dati, dei vostri prodotti, il modello vede in quel momento. Non tutto — gli LLM hanno una memoria di lavoro limitata (la context window), e troppo contesto degrada la qualità della risposta come troppe slide degradano una presentazione.
2. Da dove lo prendi. Database vostro, vector database (vedi il pezzo della scorsa settimana sull'Embedding), API in tempo reale, cache locale, file su disco, internet (rischioso). Ogni fonte ha un suo SLA, un suo costo, una sua latenza.
3. Quanto è fresco. Quando è stato aggiornato l'ultima volta? Stiamo parlando di dati di stamattina o di tre settimane fa? In un agente che deve dirvi se un evento ha posti disponibili (Tuken, per dire), una differenza di trenta secondi è già grave.
4. Chi ha il permesso di vederlo. Se l'agente parla con il commerciale, può vedere i margini? Se parla col cliente, no. Il context engineering è anche il modo in cui il sistema filtra il contesto in base a chi sta chiedendo.
5. Cosa fa quando manca. Se l'informazione non c'è, il modello deve dire "non lo so" o deve provare a estrapolare? Se prova a estrapolare, abbiamo l'allucinazione di cui tutti si lamentano. Se dice "non lo so", abbiamo un agente onesto ma frustrante. La risposta giusta è quasi sempre nel mezzo, e quella è una scelta di prodotto, non una scelta tecnica.
Le aziende che si fanno queste cinque domande prima di mettere in produzione un agente, hanno agenti che funzionano. Quelle che le ignorano hanno demo bellissime e disastri tre settimane dopo il go-live.
Tre cose che abbiamo imparato lavorandoci
In ordine di crescente scomodità.
Prima cosa. Il grosso del tempo di sviluppo di un agente AI moderno non è scritto nel prompt. È scritto nelle pipeline di contesto: il codice che decide cosa dare in pasto al modello, quando, in che ordine, con che freschezza. È il 70-80% del lavoro tecnico vero. Il prompt — quella stringa che state vedendo in mente — è il 5%.
Seconda cosa. Il debug di un agente che sbaglia è quasi sempre un problema di contesto, non di prompt. Quando un agente "allucina", nel 90% dei casi non è perché il modello è "fuori" — è perché gli avete passato un contesto incompleto, vecchio, o ambiguo. Cambiare il prompt non risolve. Cambiare cosa il modello vede sì.
Terza cosa (la peggiore). Il context engineering è la parte del prodotto più difficile da comunicare al cliente. Se vendete un'AI a un'azienda, il prompt è quello che capiscono al volo. Il contesto è invisibile. E quando spiegate che "il vostro investimento serve a costruire la pipeline di contesto, non a scrivere prompt più lunghi", molti annuiscono e poi vi chiedono "ma in concreto cosa fa?" Risposta: fa la differenza tra "questa AI risponde a caso" e "questa AI mi serve davvero". Ma è una vendita più difficile.
Cosa cambia per chi compra AI nel 2026
Se siete un'azienda che sta valutando un fornitore di AI nel 2026, il vostro filtro deve cambiare.
Le domande del 2024 erano: che modello usate? Quanti token per chiamata? Quanto tempo richiede l'integrazione? Avete esperienza nel nostro settore?
Le domande del 2026 sono diverse:
- Da dove prendete il contesto, e con che strategia di aggiornamento? (Se la risposta è "carichiamo i vostri documenti una volta", correte.)
- Come gestite i permessi sul contesto? (Se la risposta è "vediamo dopo", correte.)
- Cosa fa l'agente quando il contesto manca o è ambiguo? (Se la risposta è "il modello capisce da solo", correte velocemente.)
- Avete una pipeline di osservabilità del contesto? (Cioè: quando un utente si lamenta di una risposta sbagliata, riuscite a ricostruire quale contesto ha visto il modello in quel momento? Se non riuscite, non potete correggere. Se non potete correggere, vi state pagando un'illusione di controllo.)
Quattro domande. Se il fornitore esita su una, fate due passi indietro. Se esita su due, ringraziate e cercate qualcun altro.
Quello che stiamo costruendo dentro casa
Per onestà: siamo i primi a non aver tutte le risposte. Su BP, la pipeline di contesto è la cosa che abbiamo riscritto già tre volte. Inizialmente si caricavano i documenti di anagrafica una volta e basta. Risultato: un piano che non aggiornava i dati di cassa, e il DSCR sbagliato di cui sopra. Adesso il contesto si rigenera ad ogni interazione critica, ha un sistema di freschezza esplicito, e l'agente sa dirti quando sono stati aggiornati i dati che sta usando per rispondere. Un livello di trasparenza che, mese scorso, abbiamo iniziato a chiamare "data provenance" — termine vecchio nel mondo dati, nuovo nel mondo agenti AI.
Su Tuken, il problema è diverso: il contesto cambia in tempo reale (un evento si riempie, un pacchetto si esaurisce). Lì abbiamo dovuto inventare un meccanismo per cui il modello sa che "questa informazione vale solo per i prossimi 30 secondi". Roba che nel mondo SaaS classico chiameremmo time-to-live di una cache. Nel contesto AI è ancora terra nuova.
Su Blogger — la piattaforma di publishing AI-native in private beta — il problema è ancora diverso: il contesto che conta è la linea editoriale e gli articoli precedenti del cliente. Lì stiamo sperimentando un context engineering "narrativo", in cui l'agente capisce il tono del cliente non perché glielo descrive un manuale, ma perché vede gli ultimi articoli e li legge come farebbe un redattore nuovo.
Tre prodotti, tre approcci di context engineering completamente diversi. Stessa lezione: il prompt vale poco; il contesto vale tutto.
La regola operativa
Distillata in una riga: non spendete il budget AI in prompt più lunghi. Spendetelo in pipeline di contesto.
Più precisamente: il prompt deve essere chiaro e ben strutturato — ma una volta scritto, ottimizzare oltre quel punto dà rendimenti decrescenti. Il vero ROI del 2026 è costruire un sistema che decide bene cosa il modello vede al momento della risposta. Quel sistema è il vero prodotto.
Chi lo capisce ora, costruirà i prodotti AI di valore dei prossimi tre anni. Chi continua a girarli attorno con il prompt più ricco, costruirà demo che impressionano i comitati interni e collassano in produzione.
Sono due strade diverse. Sceglietene una in piena coscienza.
Lunedì 15 giugno usciamo dalla tecnica e torniamo al marketing: Cookieless è realtà, e nessuno ne sta parlando. Chrome ha completato la transizione. Cosa significa concretamente, oggi, per un e-commerce italiano che fatturava grazie al retargeting.
A lunedì.
Avete un agente AI in produzione (o in preventivo) e non siete sicuri che il context engineering sia all'altezza? Su intelligenza artificiale per il business facciamo audit operativi di pipeline AI. Mezza giornata, output operativo, niente diapositive. Parliamone.