"Prompt engineer" non è mai stato un titolo di lavoro preciso, ma per un po' non ce n'è stato bisogno. Se il tuo intero lavoro consisteva nell'ottenere un'unica buona risposta da un'unica chiamata di inferenza, un solo insieme di competenze bastava: formulare bene l'istruzione, fornire un paio di esempi, magari aggiungere del testo recuperato, fatto. Quell'insieme di competenze conta ancora. Ma non copre più ciò che significa "costruire un agente" a metà del 2026, e il divario si manifesta come una modalità di fallimento specifica e riconoscibile: agenti che funzionano alla grande in una demo e poi degradano silenziosamente, si contraddicono, o dimenticano quello che l'utente ha detto loro due sessioni prima.
Un articolo recente di Machine Learning Mastery individua questo divario in modo diretto, ed è utile soffermarcisi perché corrisponde in modo netto a due lavori diversi per cui potresti effettivamente essere assunto. Context engineering è ciò che avviene all'interno di un'unica chiamata di inferenza: decidere cosa entra nella finestra di contesto, dove va collocato strutturalmente, e cosa viene compresso o scartato affinché il modello non anneghi in token irrilevanti. Memory engineering è un problema diverso che esiste solo tra una chiamata e l'altra: cosa viene messo per iscritto dopo la fine di una sessione, dove viene memorizzato, come viene recuperato la volta successiva, e come viene mantenuto (aggiornato, deduplicato, fatto scadere) affinché non marcisca. Secondo quell'articolo, i fallimenti che emergono nei flussi di lavoro degli agenti lunghi e multi-sessione derivano più spesso dalla confusione tra questi due compiti, o dal saltarne uno — specialmente in quello che chiamano il "confine del recupero" (retrieval boundary), il momento in cui un agente deve decidere se qualcosa di cui ha bisogno è già davanti a sé o deve essere recuperato dalla memoria.
Perché confonderli è il vero bug, non un dettaglio
Pensa a cosa sta ottimizzando ciascuna disciplina. Il context engineering ottimizza una finestra unica, delimitata e usa e getta — mettere la porzione giusta di informazioni davanti al modello proprio ora, per questo unico scambio, e poi buttare via il resto. Il memory engineering ottimizza un archivio duraturo che deve sopravvivere tra le sessioni, restare coerente man mano che arrivano nuove informazioni, e rispondere a una domanda molto più difficile: non "cosa è rilevante per questo prompt" ma "cosa vale la pena conservare, e per quanto tempo".
Sono problemi di progettazione diversi, con modalità di fallimento diverse. Un errore di context engineering peggiora una singola risposta. Un errore di memory engineering si accumula — le scritture sbagliate si sommano, i fatti obsoleti vengono recuperati come se fossero attuali, e nessuno se ne accorge finché l'agente non ripete con sicurezza qualcosa che era stato corretto tre sessioni prima. Se una sola persona (o un solo template di prompt) svolge silenziosamente entrambi i compiti senza distinguerli, il livello di memoria tende a ereditare abitudini di context engineering che non dovrebbe avere: riempire eccessivamente l'archivio come si riempirebbe eccessivamente una finestra, oppure trattare il recupero come un problema di classificazione per rilevanza quando in realtà è un problema di cura e manutenzione. È questa la confusione a cui punta la rassegna di ricerca, e coincide con qualcosa che i professionisti già descrivono aneddoticamente: agenti impressionanti in una singola sessione e inaffidabili entro la quinta.
Come appare davvero ciascuno dei due lavori nella pratica quotidiana
Se stai cercando di capire quale dei due stai già facendo, o verso quale vorresti orientarti, il lavoro quotidiano è abbastanza diverso da poterli distinguere:
Context engineering, in pratica: decidere quale sottoinsieme delle informazioni disponibili (documenti, output degli strumenti, turni precedenti) appartenga davvero a questa chiamata; scegliere in che punto del prompt collocarlo, dato che la posizione influisce su come il modello lo pesa; scrivere passaggi di compressione o riassunto affinché una lunga traccia di uno strumento non consumi l'intero budget; e calibrare tutto questo per compito, dato che un agente di debugging e un agente di scrittura vogliono forme di contesto diverse anche sullo stesso modello di base.
Memory engineering, in pratica: definire una politica di scrittura (cosa vale la pena rendere persistente dopo una sessione — non tutto lo è); scegliere un livello di archiviazione (un vector store, un database strutturato, semplici file, qualche soluzione ibrida) ed essere onesti sui compromessi di ciascuno; costruire la strategia di recupero che decide cosa torna fuori e quando; e occuparsi della manutenzione continua — potare, unire fatti duplicati, gestire le contraddizioni quando l'utente cambia idea. Quest'ultima parte, la manutenzione, è quella che viene saltata più spesso, perché non è visibile finché un agente non è in funzione da settimane.
Si può notare che il settore sta iniziando a separare queste responsabilità in modo strutturale, non solo concettuale. La guida di Lenny's Newsletter su come costruire un harness di debugging sul Claude Agent SDK tratta i permessi, gli adattatori per gli strumenti e l'"harness" circostante come una superficie di ingegneria a sé, distinta dal prompting al suo interno — lo stesso istinto, applicato a una giuntura diversa. E le nuove funzionalità "Managed Agents" della Gemini API di Google — esecuzione in background, rinnovo delle credenziali tra un'interazione e l'altra — sono di fatto un'ammissione da parte del fornitore della piattaforma che lo stato persistente tra le sessioni è ormai un'infrastruttura da progettare, non un effetto collaterale di una finestra di contesto abbastanza lunga. Qualcuno deve farsi carico di quella progettazione. Al momento, in molti team, nessuno lo fa esplicitamente.
Perché questo conta per il tuo titolo di lavoro, non solo per il tuo codice
Se sei all'inizio o a metà carriera e nel tuo curriculum compare "prompt engineer" o "AI engineer", vale la pena chiedersi per quale di questi due lavori puoi effettivamente mostrare prove concrete — perché i ruoli generalisti legati agli agenti AI stanno iniziando a frammentarsi in ruoli più specifici, così come "webmaster" alla fine si è diviso in frontend, backend e DevOps. Questa è una cautela, non un titolo a effetto: non ho ancora visto dati concreti di assunzione che confermino "memory engineer" come titolo autonomo, quindi va presa come una lettura di dove sta andando il lavoro, non come un'affermazione che gli annunci di lavoro siano già organizzati così. Ma la pressione di fondo è reale e riconducibile alla rassegna citata sopra: i team che lavorano sugli agenti si stanno scontrando con un fallimento specifico e definibile (il degrado multi-sessione) che ha una causa specifica e definibile (la confusione tra due discipline), e questa combinazione è di solito ciò che trasforma un ruolo sfumato in due ruoli netti.
La mossa pratica non è inventarsi un titolo. È essere in grado di rispondere, concretamente, a quale problema hai effettivamente risolto. Hai rilasciato qualcosa in cui hai progettato una politica di scrittura — una regola su cosa un agente affida alla memoria e cosa scarta? Hai risolto un fallimento al confine del recupero, in cui un agente aveva bisogno di qualcosa dall'archivio e o non l'ha recuperato o ha recuperato la versione sbagliata? Sono affermazioni verificabili che puoi fare in un colloquio, supportate da un repository o da un post-mortem, e dicono qualcosa che un generico "scrivo buoni prompt" non dice: che capisci la differenza tra migliorare una singola risposta e rendere un agente affidabile nel tempo.
Un avvertimento
Non ridefinirti "memory engineer" solo perché una volta hai aggiunto un vector database a un progetto. La disciplina a cui punta la ricerca comprende anche la metà meno affascinante — manutenzione, scadenza, gestione delle contraddizioni — ed è proprio quella metà a prevenire davvero la modalità di fallimento descritta sopra. Se il tuo progetto dimostrativo è un sistema che scrive in memoria ma in cui nulla viene mai potato o corretto, hai costruito solo metà del lavoro di un memory engineer, e il problema del "fallimento dopo la terza sessione" ti aspetta ancora nell'altra metà.