La Context Engineering è il nuovo systems design per l’AI

C’è un cambiamento architetturale sotto gli occhi di tutti

Negli ultimi anni, la maggior parte delle persone ha trattato l’AI come una semplice API.

Mandi un prompt, ricevi una risposta e, se vuoi fare il ricercato, ci aggiungi retry e un po’ di logging e lo chiami sistema. Questo ha funzionato per le demo. È ciò che ha permesso a quest’ondata di arrivare così in fretta. Ma lo schema smette di funzionare nel momento in cui provi a costruire qualcosa che deve operare nel tempo.

I sistemi di AI in produzione si comportano più come processi che come API.

Nel momento in cui introduci la continuità, tutto cambia. Non hai più a che fare con una singola richiesta e risposta. Hai a che fare con una sequenza di interazioni che dipendono l’una dall’altra. Ti servono memoria e stato, e devi decidere cosa conta ora, cosa contava cinque minuti fa e cosa dovrebbe contare ancora domani.

E una volta oltrepassato quel confine, capisci che non si tratta di prompt engineering su larga scala.

Questa è progettazione di sistemi.

Quello che stai davvero costruendo non è un prompt migliore. Stai costruendo un sistema che determina come il contesto viene filtrato ed evolve nel tempo. Questa è la disciplina che sta emergendo. Questa è la context engineering.

Il contesto non è il prompt

Apri qualsiasi agente in produzione nel debugger e guarda cosa viene effettivamente inviato al modello in un dato turno. Quasi mai è solo il messaggio dell’utente. Una richiesta tipica assomiglia a questo:

Il messaggio dell’utente è la parte più piccola del payload. Ogni altro blocco è stato filtrato e iniettato nel prompt. Quei blocchi sono l’output di una pipeline che hai progettato, anche se non ti eri reso conto di starne progettando una.

Quella pipeline è il vero prodotto. Il modello è il runtime. La context engineering è la progettazione della pipeline.

Una volta accettata questa distinzione, l’architettura appare molto diversa.

La memoria non è una cosa sola

"Aggiungi memoria" è il nuovo "aggiungi caching". Sembra una feature, ma in realtà sono diversi sistemi che condividono lo stesso nome. Se non li separi, finirai con un unico blob store che risponde male a ogni domanda. Smemorato in alcuni punti, ossessivo in altri.

La prima suddivisione è quella che la scienza cognitiva ci ha già dato, e su cui la maggior parte dei practitioner sta convergendo: memoria a breve termine (STM) e memoria a lungo termine (LTM). La memoria a breve termine è tutto ciò che è attualmente dentro la context window, l’insieme di lavoro che il modello può vedere in questo turno.

La memoria a lungo termine è tutto ciò che sopravvive oltre una singola chiamata: fatti, artefatti, piani, decisioni pregresse, output degli strumenti e regole. La memoria a breve termine è un problema di budget. La memoria a lungo termine è un problema di sistemi.

I cinque tipi seguenti sono tutti memoria a lungo termine, organizzati in base al loro scopo e a come andrebbero archiviati. Corrispondono alla tassonomia canonica semantica, episodica e procedurale che vedrai in frame ispirati alla scienza cognitiva come CoALA. Sto suddividendo due di queste categorie perché in produzione devono essere governate in modo diverso.

Memoria di policy

Regole e vincoli normativi. Tipicamente globali o con ambito tenant. Versionate e rigidamente controllate. Questo è ciò che il sistema è autorizzato a fare: regole di conformità, guardrail di brand, confini di sicurezza. Cambia raramente e deliberatamente. Questa è la memoria procedurale in senso cognitivo, le regole e i workflow che plasmano il comportamento tra sessioni. La stessa categoria che contiene file come CLAUDE.md o AGENTS.md negli agenti incentrati sul filesystem.

Memoria di preferenze

Parametri di personalizzazione stabili. Di solito con ambito utente. Questo utente vuole risposte JSON, quell’altro preferisce i punti elenco, questo tenant formatta le date in DD/MM/YYYY. La memoria di preferenze fa sì che il sistema sembri su misura senza doverglielo ripetere a ogni sessione. Insieme alla memoria dei fatti qui sotto, costituisce il livello semantico: asserzioni durevoli e interrogabili sul mondo e sulle cose che contiene.

Memoria dei fatti

Asserzioni durevoli che l’agente può riutilizzare. Devono includere la provenienza. “Il DB di produzione del cliente è in us-east-1” è un fatto. Così come “il loro anno fiscale inizia ad aprile.” I fatti sono dove vive il vantaggio composto, e dove stanno i problemi di design più difficili, perché ogni fatto che scrivi è una scommessa sul futuro. Distinguo i fatti dalle preferenze perché hanno percorsi di scrittura, profili di decadimento e requisiti di governance diversi, anche se a livello cognitivo entrambe sono memoria semantica.

Memoria episodica

Riepiloghi strutturati del lavoro completato. Cose come “caso risolto” o “migrazione completata.” Artefatti riutilizzabili che il sistema ha distillato dalle tracce. La memoria episodica permette al sistema di riconoscere lo abbiamo già fatto e di recuperare la forma della soluzione precedente.

Memoria di traccia

Eventi di esecuzione grezzi, append-only. Questo è il tuo flight recorder. È ad alto volume, utile soprattutto per retrieval e replay, e non è il posto giusto dove guardare quando vuoi sapere com’è un utente, ma solo cosa ha fatto. La distinzione conta perché la maggior parte dei team confonde le due cose e finisce per fare ricerca semantica sui log di esecuzione per inferire preferenze.

In una tassonomia più grossolana, sia la memoria episodica sia quella di traccia ricadono sotto l’ombrello episodico, includendo trascrizioni di conversazioni, output degli strumenti e storici delle run. Le separo perché in produzione il flusso grezzo e il riepilogo distillato hanno pattern di accesso, politiche di retention e profili di costo completamente diversi. Trattarle come un’unica cosa è il modo in cui i team finiscono per pagare prezzi da database vettoriale per fare grep sui log.

La working memory non è in questo elenco perché non è memoria a lungo termine. È la context window stessa, l’insieme di lavoro che il modello può effettivamente vedere nel turno corrente. La working memory è reale e importante, e molta della parte più difficile del lavoro di ML applicato oggi vive lì: compressione del prompt, riuso della KV-cache, attenzione a finestra scorrevole, la matematica del budget su cosa ha diritto a occupare quei token.

Ma per definizione è transitoria, e confonderla con gli archivi persistenti sopra è ciò che produce architetture in cui il taccuino e il system of record condividono un database. Non dovrebbero. La working memory viene assemblata a ogni turno dalla memoria a lungo termine e scartata a meno che non venga esplicitamente promossa. Il passaggio di promozione è dove i due livelli si incontrano, ed è dove avviene la maggior parte del lavoro di design interessante.

Quando qualcuno dice “il nostro agente ha memoria”, chiedi a quale di queste cinque si riferisce. Se la risposta è “buttiamo tutto in un vector store”, hai appena trovato il motivo per cui il loro agente sembra smemorato in certi punti e ossessivo in altri.

Il loop, e cosa si rompe al suo interno

Ogni sistema di AI in produzione alla fine converge sulla stessa forma: un loop.

La forma non è controversa. La maggior parte delle descrizioni del loop di un agente si riduce agli stessi cinque passaggi: assemblare il contesto, chiamare il modello, agire, osservare i risultati e aggiornare la memoria, poi ripetere. Etichetto le fasi in modo leggermente diverso perché voglio separare le due metà di “assemblare il contesto” (cosa assorbi vs cosa selezioni) e perché penso che la promozione meriti un nome a sé invece di essere fusa in “aggiorna la memoria”.

Ma l’anatomia sottostante è la stessa, e vedrai gli stessi cinque punti di inflessione che tu ci arrivi dal runtime dell’agente, dal database o dal prompt.

ReAct ha reso popolare l’alternanza di ragionamento e azione nel 2022; i sistemi di agenti in produzione da allora hanno esteso quel pattern nel loop più ampio sopra. Il diagramma è utile, ma conoscere la modalità di guasto di ogni fase è ciò che ti dice dove investire il tempo di ingegneria.

Injest

Ingest fallisce quando accetti troppo. Ingest è la prima metà dell’assemblaggio del contesto: assorbire input grezzi dall’ambiente. Trattare ogni evento come potenziale contesto crea rumore che il retrieval dovrà annullare più tardi. La disciplina qui è al confine. Cosa stai rifiutando di assorbire?

Retrieve

Retrieve fallisce in silenzio. Retrieve è la seconda metà dell’assemblaggio del contesto: selezionare quale sottoinsieme della memoria a lungo termine conta ora. Non lancia un’eccezione quando restituisce il chunk sbagliato, fa solo sembrare il modello leggermente fuori fuoco. È la fase più sotto-investita del loop, e quella che correla più strettamente con la qualità percepita del sistema.

La pura ricerca semantica è una prima bozza. Per la maggior parte dei sistemi in produzione, la baseline è filtraggio per metadati più retrieval ibrido lessicale/semantico con reranking; oltre questo, decomposizione della query, traversata di grafi e retrieval multi-hop aiutano quando i task sono composizionali, ma devono restare entro i limiti di latenza e dei budget di valutazione.

Infer & Act

Infer & Act fallisce quando il contesto guida il comportamento sbagliato. Qui chiamare il modello e intraprendere azioni sono fusi in una sola fase, perché la pianificazione e l’invocazione degli strumenti sono entrambe conseguenze di ciò che il contesto assemblato ha portato il modello a decidere di fare. È qui che mordono le modalità di fallimento del long context: lost-in-the-middle, bias di recenza, marcescenza del contesto.

L’intuizione è che più contesto dovrebbe migliorare le risposte in modo monotono. Stai dando al modello più informazioni con cui lavorare, quindi penseresti che debba fare meglio. In pratica, più token spesso peggiorano il modello. Il budgeting del contesto ora è una disciplina reale, e l’istinto predefinito “diamo al modello tutto quello che abbiamo” è la risposta sbagliata di default.

Evaluate

Evaluate è la fase che la maggior parte dei sistemi non ha affatto. Introduce feedback nel sistema osservando l’esito delle sue azioni. Vuoi sapere se la risposta è stata utile, se il workflow è riuscito e se l’utente ha dovuto correggerla.

Anche quando il feedback non è catturato esplicitamente, i segnali esistono comunque. Alcuni che funzionano bene in produzione: tempo al messaggio successivo (un rapido follow-up di solito significa che la risposta non ha colpito), distanza di edit tra il tuo output e la versione che l’utente ha effettivamente inviato o salvato (piccole modifiche sono rumore, grandi modifiche sono correzione) e abbandono entro N secondi da un risultato di uno strumento (l’utente ha guardato ciò che hai prodotto ed è andato via).

Nessuno di questi richiede che l’utente valuti qualcosa. Richiedono solo di strumentare ciò che già accade. Questi segnali impliciti sono ovunque, ma nulla nello stack li ascolta. Senza questo passaggio, il loop non si chiude: il sistema gira ma non impara mai da ciò che produce.

Promote

Promote è la fase che è più facile costruire nel modo sbagliato. Promote è la metà di aggiorna la memoria che gestisce la scrittura nella memoria a lungo termine. La maggior parte dei team sbaglia per eccesso, riversando tutto indietro e avvelenando lo store stesso. Quello che ti serve è una policy reale, scritta, che risponda a sei domande:

• Cosa viene scritto?
• A quale granularità?
• In quale tipo di memoria?
• Con quale provenienza?
• Con quale decadimento?
• Sotto quale autorità?

Questo è il passaggio più difficile da fare bene, ed è anche il più cruciale.

Le pipeline finiscono. I loop compongono. La differenza è Promote.

Gli anti-pattern che probabilmente stai rilasciando

Se costruisci agenti da più di qualche mese, quasi sicuramente ne hai rilasciati diversi tra questi. Le prime sperimentazioni del mio team sono inciampate in ognuno di essi, ed è così che so come appaiono dall’interno.

• Scaricare il transcript completo a ogni turno: È il modo pigro di preservare lo stato. È disastrosamente costoso, porta rapidamente alla marcescenza del contesto e degrada la qualità delle risposte in modi che non emergono finché gli utenti non si lamentano. Un summarizer di compattazione in background non è opzionale su scala, e la cache del prompt dovrebbe essere riservata a prefissi stabili (system prompt, definizioni degli strumenti, blocchi di policy statici) con payload di retrieval volatili posizionati dopo le sezioni in cache.
• Sovraccarico di contesto nella tua strategia di retrieval: L’equivalente lato retrieval è trattare il retrieval come un lavandino, tirando fuori i primi 20 chunk sperando che il modello li sistemi. Invece li fa una media, che è peggio che scegliere cinque chunk buoni.
• Trattare il taccuino come memoria: Succede quando i risultati delle chiamate agli strumenti, il ragionamento intermedio e gli asset generati finiscono a lungo termine perché nulla li scarta esplicitamente. La tua “memoria” è soprattutto scarto.
• Un unico store per ogni tipo di memoria: Quando i sistemi usano un singolo indice vettoriale per tutto: tracce, fatti, preferenze, policy e riepiloghi episodici in un unico store, il retrieval non riesce a disambiguarli e nemmeno il modello ci riesce.
• Memoria che non dimentica mai: Il fallimento opposto è una memoria che non dimentica mai: niente TTL, niente decadimento, nessuna eviction. Dopo pochi mesi diventa un passivo più che un asset. Alcuni dei comportamenti migliori che puoi aggiungere a un sistema sono policy di dimenticanza aggressive.
• Promuovere in base al pollice in su dell’utente: È una trappola perché il segnale di feedback più forte è anche il più raro e distorto. I sistemi che promuovono solo su segnali positivi espliciti imparano a ottimizzare per il click del pulsante anziché per la qualità reale.
• Nessun replay: Senza funzionalità di replay, il debugging diventa congettura. Non puoi riprodurre la sessione di ieri perché lo store di memoria è andato avanti. Questa è la classe di bug che rovina i post-mortem.

Perché questa è progettazione di sistemi, non vibes

La parte che merita il nome “progettazione di sistemi” non è il modello mentale. Sono i trade-off, e ognuno di essi ha una risposta sbagliata più economica da spedire e più costosa da mantenere.

L’economia dei token ora guida l’architettura delle richieste

I cache hit sul prompt costano una frazione dei cache miss, spesso solo il 10% del prezzo standard di input sull’API di Anthropic e sui modelli più recenti di OpenAI, e il 25% su Gemini di Google. Questi prezzi hanno rimodellato cosa conviene mettere dove in una richiesta, e prefissi cache-friendly, schemi di strumenti stabili e istruzioni di sistema fissate non sono più scelte cosmetiche.

Questo fissa il tetto di risparmio tra 4x e 10x sui token di input, a seconda del provider, prima ancora di contare il compounding strutturale nei carichi agentici, dove lo stesso prefisso viene reinviato a ogni step. Se imposti bene la strategia di cache, un agente ben architettato costa diverse volte meno di uno mal architettato a parità di lavoro. È la cosa più simile che l’ingegneria AI abbia a un problema di cache-line, e la maggior parte dei team lo tratta come una decisione di CSS.

Il retrieval è un problema di architettura

Il piano di produzione è ibrido (lessicale più semantico), con reranking e riscrittura della query. Il soffitto è il retrieval agentico, dove il modello emette e affina le proprie ricerche all’interno del loop. La distanza tra i due è enorme, invisibile nei benchmark e visibile in ogni interazione utente. Se il tuo retrieval è una singola chiamata top-k, è il retrieval il motivo per cui il tuo agente sembra stupido.

Il perimetro del contesto è un confine di sicurezza

Isolamento multi-tenant, sandboxing dei sotto-agenti, leakage cross-session. Non sono esercizi di hardening da fare dopo. Se un sotto-agente può vedere di default l’insieme di lavoro del parent, hai un problema in attesa di accadere: l’unica domanda è se lo troverai tu prima o un avversario.

La valutazione è più difficile che in qualsiasi classe di sistemi precedente

Sistemi stateful, stocastici e dipendenti dal percorso non si unit-testano. Ti servono valutazioni basate sulle tracce, set dorati per il retrieval, replay offline contro snapshot versionati della memoria e valutatori LLM-as-judge a loro volta versionati. La maggior parte dei team non ha nulla di tutto ciò e vola alla cieca. Scoprono che l’ultimo deploy ha fatto regredire la qualità quando glielo dice un utente.

La governance non è opzionale, ed è tecnicamente più difficile di quanto pensi

Il diritto all’oblio secondo il GDPR diventa non banale nel momento in cui “la cosa che sa dell’utente” è un fatto derivato da cento interazioni. Cosa significa eliminare i dati di un utente da un sistema che li ha già assorbiti nella memoria dei fatti? L’AI Act dell’UE aggiunge un ulteriore livello, con la maggior parte degli obblighi (inclusi governance dei dati, supervisione umana e requisiti di trasparenza per i sistemi ad alto rischio) in vigore da agosto 2026.

I team che spediranno prodotti AI in Europa nella seconda metà del 2026 avranno bisogno di risposte a domande che il settore non ha ancora risolto collettivamente: come rimuovere in modo dimostrabile il contributo di un utente a un fatto derivato, come auditare la lineage di una promozione di memoria, come dimostrare che uno store di memoria ha l’ambito che dichiari.

Le risposte di nessuno sono ancora buone. Deve comunque funzionare, e i regolatori non aspetteranno che l’industria lo capisca.

Ecco perché la context engineering riguarda la progettazione di sistemi e non il prompt engineering. Quasi tutto il lavoro interessante avviene nelle connessioni tra sistemi, dove il contesto passa da una fase all’altra. Quasi nulla è nel prompt in sé. E quasi ogni trade-off sopra ha una scorciatoia apparentemente economica che si accumula in debito tecnico che ripagherai nel momento peggiore.

Dove sta convergendo il livello della memoria

Una volta accettato che la memoria è cinque cose diverse con diversi pattern di accesso, la domanda ovvia è: dove vive tutto questo?

Il retrieval ibrido, cioè lessicale più semantico in un unico sistema, è in gran parte un problema risolto a questo punto. Elasticsearch, OpenSearch, LanceDB, Pinecone, Weaviate e le estensioni vettoriali di Postgres lo supportano in qualche forma, e il gap di qualità di produzione tra loro è più stretto di quanto suggerisca il marketing dei vendor. Se l’intero livello di memoria fosse solo “embedding e full-text search”, la questione architetturale sarebbe noiosa.

Non lo è, perché la memoria non è solo retrieval. Guarda di nuovo i cinque tipi e nota di cosa ha effettivamente bisogno ciascuno dal proprio store.

L’architettura accidentale in cui finisci separa questi lungo l’asse che fa più male. I dati relazionali vivono in Postgres o un equivalente gestito. Il retrieval ibrido vive in Elasticsearch, OpenSearch o in un vector store dedicato come Pinecone, Weaviate o LanceDB.

Le tracce finiscono in S3 o in un database di serie temporali. Ciascuno è una scelta forte per il lavoro per cui è stato costruito, e molti stack di produzione li usano bene. Il problema non è il singolo componente. È che ogni percorso di retrieval significativo diventa una join tra sistemi: “trova fatti rilevanti per questa query, filtrati dalle policy che si applicano a questo tenant, con ambito agli utenti che questo agente è autorizzato a vedere.” Quella join attraversa tre confini: fiducia, transazione e latenza. Ogni volta che il contesto attraversa uno di questi confini, reintroduci esattamente il problema di consistenza che cercavi di evitare.

Qui cambia il quadro architetturale. Il retrieval ibrido nello stesso store dei dati relazionali è la capacità distintiva, ed è un problema diverso dal solo retrieval ibrido. Il retrieval ibrido come feature è sempre più disponibile ovunque.

Meno comune è co-porre dati relazionali, documentali e vettoriali sotto un unico confine transazionale e di sicurezza, così che memoria di policy, preferenze, fatti ed episodica possano essere interrogate insieme con garanzie ACID invece che riconciliate tra sistemi.

Oracle AI Database è un esempio di questo approccio convergente e multimodello: tabelle relazionali, documenti JSON e embedding vettoriali vivono in un unico motore, interrogabili insieme in una singola istruzione SQL, all’interno di una singola transazione. Una volta che prendi sul serio la tassonomia a cinque tipi e inizi a tracciare le join tra policy, preferenze e fatti, la domanda si sposta da quale motore di retrieval sia migliore a dove debbano vivere i dati relazionali che governano quel retrieval.

In pratica, questo si traduce in un’unica istruzione SQL che fa join tra dati di policy relazionali, preferenze codificate in JSON e similarità vettoriale sulla memoria dei fatti. La query che altrimenti coprirebbe tre sistemi si riduce a una:

-- Find facts relevant to this question, scoped to the policies
-- and preferences that apply to this user, in a single query.
SELECT f.fact_text, f.provenance, f.created_at
FROM   fact_memory f
JOIN   user_preferences p
       ON p.user_id = :current_user
JOIN   tenant_policies t
       ON t.tenant_id = p.tenant_id
      AND t.is_active = 'Y'
WHERE  f.tenant_id = p.tenant_id
  AND  JSON_VALUE(p.prefs, '$.allow_personalization') = 'true'
  AND  f.access_level <= t.max_access_level
ORDER BY VECTOR_DISTANCE(
           f.embedding,
           VECTOR_EMBEDDING(MINILM USING :query AS DATA),
           COSINE
         )
FETCH FIRST 5 ROWS ONLY;

Quella singola istruzione fa quattro cose insieme: applica la policy del tenant, rispetta le preferenze dell’utente, applica controlli di accesso per fatto e classifica per similarità semantica. In un’architettura federata, sono quattro andate e ritorno su tre store diversi, con un modello di consistenza che devi difendere da solo.

Qui è un solo piano di query, un solo confine transazionale, un solo posto da auditare. Le stesse garanzie ACID che hanno reso i database il system of record per lo stato condiviso dagli anni ’70, ora applicate a una memoria che include anche vettori accanto alle righe.

Esempi funzionanti di questo pattern, incluso RAG agentico con ricerca ibrida e un notebook sull’architettura della memoria per la context engineering, sono disponibili nell’AI Developer Hub di Oracle su GitHub.

Vorrai comunque store specializzati per alcune cose. La memoria di traccia ad alto volume ha caratteristiche di durabilità e costo diverse dal tuo database operativo. Lo storage a blob per asset di grandi dimensioni come documenti, immagini e artefatti di modelli appartiene a un posto creato per quello. Un database documentale dedicato può ancora avere senso per workflow documentali blindati in cui ti servono feature specifiche di quella categoria.

Il punto non è che una piattaforma unificata elimini ogni altro store. Il punto è che elimina la join più costosa: quella tra i dati relazionali che governano cosa l’agente è autorizzato a fare e i dati vettoriali che plasmano cosa l’agente fa effettivamente. Quando questi due sono co-localizzati, il problema architetturale si sposta da “come tengo questi store in sync” a “come progetto buone policy di memoria”, che è il problema che davvero conta.

Sette previsioni su cosa arriva dopo

Le sezioni sopra descrivono dove siamo. Queste sono scommesse su dove stiamo andando. Sono volutamente orientate. Non essere d’accordo con quelle con cui non sei d’accordo.

1. Il modello non diventa la memoria

La storia allettante è che i provider di modelli assorbano la memoria nel modello stesso. Le context window si allungano, la cache diventa più intelligente e il livello di memoria esterno diventa inutile. Non succederà. Le context window continueranno a crescere, ma richiederanno comunque il priming a ogni turno. Il modello resta stateless a ogni sessione, e il livello di memoria esterno resta il system of record. Ciò che cambia è che la memoria esterna diventa molto più intelligente (oggi vector store e piattaforme ibride, in futuro cose che non abbiamo ancora costruito), e la context engineering diventa l’arte di decidere cosa il modello vede, quando e perché. Se un provider di frontiera rilascia una primitive che sostituisce in modo credibile un sistema di memoria esterno per l’uso in produzione, questa previsione è sbagliata. Scommetterei contro.

2. L’infrastruttura di memoria supera l’inferenza nella spesa per i prodotti AI maturi

I costi di inferenza stanno calando di circa un ordine di grandezza ogni 18 mesi. Storage, retrieval, generazione di embedding, reranking e assemblaggio del contesto per richiesta no. Scalano con numero di utenti, profondità di sessione e storico delle interazioni, tutti in crescita. La voce dominante in bolletta cloud si sposta dai token GPU all’infrastruttura vettoriale e ibrida per il retrieval. Questo rimodella la questione build-vs-buy. L’infrastruttura di memoria non si commoditizza come fa il livello dei modelli. I team che vincono nel lungo periodo sono quelli che trattano l’infrastruttura di memoria come un investimento di prima classe fin dal giorno uno.

3. Il RAG classico diventa l’architettura legacy

“Fai l’embedding dei documenti, top-k sulla query utente, metti tutto nel prompt” è il COBOL dell’architettura AI. Funziona, è ovunque, e sarà imbarazzante col senno di poi. Il sostituto è già visibile: il retrieval agentico, in cui il modello pianifica le proprie ricerche, emette query multi-step, legge i risultati intermedi e decide cosa recuperare dopo. Assomiglia meno a una lookup su database e più a un processo di ricerca. I team che oggi costruiscono pipeline RAG statiche sono su un percorso di migrazione, che lo sappiano o no.

4. La memoria diventa la superficie d’attacco

Gli attacchi alla memoria si compongono in un modo che il prompt injection non fa. Un avversario che può scrivere in uno store di memoria di lunga durata, direttamente o tramite un canale di input che non ritenevi privilegiato, può plasmare il comportamento del sistema per ogni utente futuro che toccherà. L’esfiltrazione funziona allo stesso modo al contrario: contesto di una sessione che trapela in un’altra perché il modello di scoping era approssimativo. Il primo serio incidente reale di avvelenamento della memoria sta arrivando. Seguirà la corsa del settore su provenienza, attestazione e controllo di accesso per fatto.

5. I confini di privacy del contesto diventano un requisito di conformità

Il passo logico successivo da “lo scoping del contesto è un confine di sicurezza” è l’isolamento crittografico dei segmenti di memoria, così che gli agenti possano rivelare il contesto solo in base alla necessità di conoscere. Conta nel momento in cui hai sotto-agenti con livelli di fiducia diversi, o regimi normativi che richiedono uno scoping dimostrabile dei fatti sensibili. Aspettati che la prima audit in un’industria regolamentata che cita “isolamento insufficiente tra gli scope di memoria degli agenti” faccia da catalizzatore, con i framework di conformità subito dietro. I team che hanno già in roadmap lo scoping crittografico vinceranno le RFP che lo richiedono. Chi non ce l’ha lo aggiungerà in corsa contro il tempo.

6. La coerenza multi-agente diventa una capacità nominata e attesa

Oggi, un agente di fatturazione e uno di supporto che toccano lo stesso account cliente possono produrre risposte contraddittorie perché hanno pescato slice di memoria diverse e nulla le riconcilia. È tollerabile ora perché la maggior parte dei deployment in produzione è a singolo agente. Man mano che i sistemi multi-agente entrano in produzione su larga scala, gli utenti inizieranno a cogliere le contraddizioni e la “coerenza contestuale” diventerà una capacità nominata su cui le piattaforme competono. Comparirà prima nelle matrici di confronto dei vendor, poi nelle checklist di procurement enterprise. Risolverla presto diventa un differenziatore. Ignorarla significa gestire ticket di supporto su perché due tuoi agenti non sono d’accordo sullo stesso cliente.

7. “Contesto utile pro capite” diventa una metrica misurata

I benchmark si sposteranno dai modelli ai sistemi completi, e la metrica di punta sarà qualcosa come contesto utile portato per utente, per interazione. È il numero che predice davvero la retention dell’utente e il divario tra un prodotto che sembra conoscerti e uno che sembra resettarsi ogni martedì. Cercalo nelle presentazioni agli investitori prima che compaia negli articoli accademici. Una metrica correlata, costo per token di contesto utile, diventerà una questione di unit economics su cui vale la pena rispondere.

Cosa fare lunedì

Se sei nuovo a questo e vuoi un punto di partenza: smetti di trattare la memoria come una cosa sola. Scegli un agente in produzione a cui hai accesso, etichetta che tipo di memoria contiene ciascuno dei suoi store e nota quante volte uno store viene usato per tre lavori.

Se stai già costruendo agenti: strumenta il loop. In particolare, strumenta il segnale tra retrieval e promozione. Ho visto molti team che sanno dirti cosa il loro sistema ha recuperato in un dato turno. Molti meno sanno dirti quali di quei ricordi recuperati il modello ha effettivamente usato, e quasi nessuno sa dirti perché un certo ricordo sia stato promosso in primo luogo.

Sapere quali memorie sono state usate è ciò che ti permette di rinforzarle al prossimo passo di promozione, che è come un sistema di memoria smette di essere un log write-once e inizia davvero a imparare.

Quel loop di feedback è dove vive il vantaggio composto, ed è dove si sta svolgendo il lavoro interessante nel prossimo tratto di questa disciplina.

Ogni team ottiene gli stessi modelli di frontiera su una timeline più o meno identica. Ciò che nessun altro può copiare è il livello di memoria che costruisci attorno a loro: quello plasmato dai tuoi utenti, dalle tue decisioni e dal tuo giudizio su cosa valga la pena ricordare.

I modelli sono condivisi. Il sistema di memoria è tuo.