--- title: "Context engineering: fonti, memoria e handoff per riprendere il lavoro" source: "https://www.matteovincenti.com/blog/context-engineering-memoria-handoff-wiki" language: it author: "Matteo Vincenti" published: 2026-10-20 updated: 2026-10-24 category: "AI" tags: ["Context engineering", "Memoria AI", "LLM Wiki"] --- # Context engineering: fonti, memoria e handoff per riprendere il lavoro Come organizzare contesto, fonti e handoff per gli agenti AI. Un percorso reale in Notion, dal risultato METR al riuso e alla manutenzione della conoscenza. ![Un telaio conserva l’intreccio verde e la navetta nel punto di ripresa](https://cdn.sanity.io/images/xrqkwry7/production/786063880475abd1f435c59cbff20d3ebd40119a-1728x910.png?w=1400&fit=max&auto=format) Categoria: AI · Tag: Context engineering, Memoria AI, LLM Wiki Per questo blog tengo in Notion le fonti, le ricerche e gli articoli. Una stessa fonte può servire a più testi e tornare utile dopo mesi, quando il risultato che mi interessava è ancora valido ma gli strumenti o le condizioni sono cambiati. Salvare il link permette di ritrovarla. Per riusarla serve conservare anche che cosa dice, in quale contesto e dove l’ho già utilizzata. Le pubblicazioni di METR sulla produttività degli sviluppatori sono un buon caso: il risultato del 2025, gli aggiornamenti metodologici del 2026 e le opinioni su quanto aiutino gli agenti rispondono a domande diverse. Una sintesi troppo sbrigativa può appiattirli in una frase come «l’AI rallenta gli sviluppatori». Poi quella frase entra in un altro articolo e perde anche il collegamento alla ricerca. È qui che il context engineering diventa un problema concreto: scegliere quali informazioni rendere disponibili all’agente per il prossimo passo, fra istruzioni, documenti, strumenti e storia del lavoro. Il contesto è ciò che il modello riceve in quel momento; una pagina salvata nella wiki deve essere recuperata per entrarvi. [Anthropic, Effective context engineering for AI agents](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents). ## Una fonte deve portarsi dietro la domanda a cui risponde Nel luglio 2025 METR pubblicò uno studio randomizzato su sedici sviluppatori esperti e 246 attività dei loro progetti open source. Con gli strumenti AI dell’inizio di quell’anno impiegarono il 19% di tempo in più. Il risultato riguarda quel campione e quelle condizioni: conservarlo come previsione sui miei strumenti di oggi cambierebbe il significato dello studio. [La ricerca METR del luglio 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/). Nel registro Resources AI la scheda della fonte conserva il risultato insieme al suo perimetro. Questa è una trascrizione ridotta dei campi presenti, con i contenuti resi in italiano: _Una fonte deve portarsi dietro la domanda a cui risponde_ | Campo | Contenuto della scheda | | --- | --- | | Titolo | METR — produttività osservata degli sviluppatori, luglio 2025 | | URL | [Pubblicazione originale](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) | | Domanda | Come valutare qualità, costo del lavoro e responsabilità quando un team adotta agenti AI? | | Copertura | Estratti delle sezioni Methodology, Core result e Discussion | | Contesto | Attività reali su progetti open source; strumenti dell’inizio del 2025 | | Sintesi | Nel campione osservato, il tempo di implementazione aumenta del 19% con l’AI | | Limite di riuso | Il risultato storico non è una previsione per gli strumenti correnti o per il team dell’autore | | Tipo di evidenza | Misura riportata dalla fonte | | Articoli collegati | Le due versioni, italiana e inglese, dell’articolo sugli agenti nel team | | Controllata il | 23 ottobre 2026 | Il campo che mi interessa di più è il limite di riuso. Il numero si ricorda facilmente; le condizioni tendono a sparire quando una nota passa da una sintesi all’altra. Tenerle accanto rende più difficile trasferire il 19% a un contesto che lo studio non ha misurato. La copertura aiuta a decidere quando tornare all’originale. Aver letto i risultati e la discussione è diverso dall’aver esaminato ogni dettaglio del paper. La data, invece, indica quando il materiale è stato controllato: non rende automaticamente attuale il comportamento degli strumenti studiati. Per ricostruire questa organizzazione in Notion, crea una raccolta Fonti e usa ogni riga per una pubblicazione. URL, argomento e data di controllo diventano proprietà con cui cercare e filtrare; domanda, passaggio letto e limite di riuso restano nel corpo della scheda, dove hanno spazio per una spiegazione. Prima di aggiungere una fonte cerco l’URL: evito così di mantenere due sintesi dello stesso documento. Poi crea una pagina per la domanda di ricerca e collegala alle schede usate. Nel mio caso è la domanda sull’adozione degli agenti nel team. In quella pagina scrivo la conclusione utile e il motivo per cui la sostengo. Il collegamento all’articolo indica dove quella conclusione viene riusata. Per iniziare bastano la raccolta e queste pagine collegate; aggiungerei altre proprietà quando emerge una ricerca che non riesco a fare. La distinzione conta quando cambia qualcosa: nella scheda della fonte correggo ciò che ho letto, nella sintesi rivaluto ciò che ne deduco, nell’attività registro ciò che resta da fare. Un generico campo «aggiornato» non mi direbbe quale di queste operazioni è avvenuta. ## Dal risultato alla decisione, senza perdere i passaggi Nella ricerca per la revisione dell’[articolo sugli agenti nel team](https://www.matteovincenti.com/blog/agenti-ai-team-qualita-costi-responsabilita), la scheda METR è collegata al dossier e ai due testi candidati. La sintesi utilizzabile è: la sensazione di produrre codice più velocemente può divergere dal tempo necessario a completare il lavoro. Per decidere sull’adozione voglio osservare anche verifiche, correzioni e interventi umani. Nel registro ci sono anche due fonti successive. Nel [febbraio 2026 METR descrive i problemi del nuovo esperimento](https://metr.org/blog/2026-02-24-uplift-update/): cambiano le persone che accettano di partecipare e i task selezionati, mentre il lavoro con agenti paralleli complica il conteggio del tempo. Gli autori considerano quei dati un segnale poco affidabile dell’effetto corrente. Il [sondaggio pubblicato a maggio](https://metr.org/blog/2026-05-11-ai-usage-survey/) raccoglie invece benefici percepiti, con i limiti di un campione di convenienza e delle autovalutazioni. Il risultato del 2025 resta quello. A restringersi è l’inferenza che potrei farne oggi: non posso scegliere un workflow attuale applicandogli quel rallentamento, né sostituirlo con la velocità percepita nel sondaggio. Nelle pagine Notion queste tre fonti sono richiamate nella sezione sulla produttività dell’articolo Team. È il percorso che voglio poter ricostruire: pubblicazione originale, scheda con contesto e limiti, sintesi nella ricerca, riuso nel testo. Quando arriva una nuova evidenza, parto dalla domanda che potrebbe cambiare. Se riguarda soltanto l’implementazione di un client, controllo i passaggi su quel client. Se cambia il modo di misurare il tempo, torno alle sintesi e agli articoli che usano quelle misure. Non riscrivo ogni pagina collegata per il solo fatto che esista una nuova fonte. ## Che cosa entra nella sessione Se devo rivedere quel paragrafo sulla produttività, recupero la domanda dell’articolo, il passaggio da modificare e le tre schede METR. Apro poi gli originali nei punti necessari al confronto. La cronologia di tutte le discussioni editoriali aggiungerebbe molto materiale senza chiarire quale affermazione sto controllando. Per rendere operativo quel recupero, assegnerei un incarico di questo tipo. I riferimenti pubblici permettono di aprire le fonti; il paragrafo corrente dell’articolo va allegato o letto dal suo collegamento. ```txt Task: review the productivity paragraph in the team-adoption article. Read the current paragraph and these sources: - METR, July 2025 experiment: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ - METR, February 2026 methodology update: https://metr.org/blog/2026-02-24-uplift-update/ - METR, May 2026 survey: https://metr.org/blog/2026-05-11-ai-usage-survey/ Question: does the paragraph distinguish the historical measured result from evidence about current tools? Compare the claims, their populations and what was measured. Return a proposed edit only where a source changes a claim. If the paragraph is already accurate, explain why it should stay. Keep unresolved questions visible. ``` La domanda finale restringe la lettura: cerco un eventuale trasferimento improprio del risultato, non un riassunto di tutto ciò che METR ha pubblicato. Se il confronto richiede un dettaglio assente dalla scheda, apro quel passaggio dell’originale. La nota serve a scegliere dove leggere. Questo è il confine tra contesto attivo e conoscenza recuperabile. Nel primo metto ciò che serve alla decisione corrente; la seconda resta raggiungibile attraverso riferimenti precisi. Anthropic descrive il recupero al bisogno come una delle strategie per gestire il contesto. [Context retrieval and agentic search](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents). Un riferimento utile deve suggerire che cosa si troverà. «METR, selezione dei task e tempo con agenti paralleli, febbraio 2026» orienta la ricerca meglio di «link interessante». La ricerca può anche prendere una strada sbagliata. Per questo tengo nella sintesi la domanda e il passaggio che la sostiene: permettono di accorgersi che è stato recuperato il documento giusto per un’altra domanda. ## La wiki conserva conoscenza; l’handoff conserva un punto di lavoro Una fonte può essere utile a più articoli. Il prossimo passo di una revisione, invece, appartiene a un’attività precisa. Confondere i due piani produce pagine piene di istruzioni scadute. La cronologia conserva come siamo arrivati a una scelta, inclusi i tentativi abbandonati. La wiki raccoglie conoscenza riutilizzabile, con le sue fonti. L’handoff è il passaggio di consegne: descrive da dove continuare un lavoro interrotto. Per interrompere il confronto sul paragrafo METR, userei questo handoff. È un esempio costruito sullo stesso materiale, da compilare con il collegamento e la versione del testo su cui si sta lavorando. ```txt Objective: check the METR paragraph in the team-adoption article. Current material: link to the working text, revision and date. Source records: July 2025 experiment, February 2026 update, May 2026 survey, linked from the research page. Established: the 19% slowdown belongs to the 2025 experiment. Open: does the current paragraph extend that finding to today's tools? Next action: open the current text and compare that claim with the three source records; read the originals where needed. Recheck if: the paragraph, the question or a relevant source changes. Expected result: a justified keep/edit decision, with sources. ``` «Materiale corrente» deve puntare al testo effettivo e alla revisione letta. Una data di modifica aiuta a notare un cambiamento; per capire che cosa sia cambiato serve il confronto tra versioni. Per il codice, il riferimento equivalente è il commit con l’eventuale diff non committato: un risultato dei test deve restare collegato al codice controllato. Alla ripresa seguirei questo ordine: 1. **Apro il testo corrente.** Controllo se il paragrafo coincide con quello lasciato e se la richiesta è cambiata. Se ora devo valutare strumenti del 2026, la sola scheda dello studio 2025 non copre più la domanda. 2. **Rileggo la conclusione della ricerca e le fonti interessate.** Il 19% resta un risultato storico. L’aggiornamento di febbraio riguarda le difficoltà del nuovo esperimento; il sondaggio di maggio misura percezioni. La fonte più recente non sostituisce automaticamente quella precedente. 3. **Decido sul passaggio preciso.** Se attribuisce il rallentamento a quel campione, lo mantengo. Se lo estende agli agenti attuali, correggo quell’estensione. Quando manca una misura pertinente, lascio aperta la stima del beneficio corrente. 4. **Aggiorno il punto di lavoro.** Registro il passaggio controllato, le fonti usate, la decisione e ciò che resta aperto. Se cambia la sintesi, seguo i collegamenti verso gli altri articoli che la riusano e controllo i passaggi coinvolti. Nel paragrafo Team collegato sopra, la distinzione fra risultato del 2025 e fonti successive è già presente. Riaprire le fonti serve anche a confermare una scelta: quel passaggio si può mantenere. La domanda su quanto convenga oggi usare un agente resta distinta e richiede osservazioni sul lavoro che voglio valutare. Il confronto completo è nell’[articolo sull’adozione nel team](https://www.matteovincenti.com/blog/agenti-ai-team-qualita-costi-responsabilita). Nell’esperimento descritto da Anthropic sugli [agenti di lunga durata](https://www.anthropic.com/research/effective-harnesses-for-long-running-agents), la nuova sessione legge progressi e cronologia e controlla il funzionamento dell’applicazione prima di continuare. È il passaggio che terrei anche in un altro ambiente: mettere il checkpoint a confronto con ciò che esiste adesso. Un vecchio «test passato» rimane la ricevuta di quella prova; dopo una modifica al contratto può servire un test diverso. ## Compattazione e nuova sessione fanno lavori diversi La compattazione riassume una conversazione per continuare con meno contesto attivo. Le note persistenti restano fuori dalla finestra del modello e vengono recuperate quando servono. Una sintesi aggressiva può perdere proprio il dettaglio da cui dipende il prossimo passo. [Compaction e structured note-taking](https://www.anthropic.com/research/effective-context-engineering-for-ai-agents). Nel caso METR, accorcerei la discussione e gli output ripetitivi conservando domanda, fonti e distinzione fra risultato storico, misura corrente e beneficio percepito. Il passaggio originale resta raggiungibile dal registro. Lo stato del confronto aperto va nell’handoff: non lo aggiungo a ogni scheda della wiki. Anche la delega separa contesti. Posso chiedere a un agente di esaminare le condizioni di uno studio e farmi restituire conclusione, passaggi pertinenti e questioni aperte. Nel contesto principale porto quel rapporto, mentre l’esplorazione dettagliata resta nella sessione delegata. Per usarne una conclusione devo poter risalire alle prove: togliere il dettaglio dall’input non significa cancellarlo dall’archivio. Aprire una nuova sessione rende esplicito il recupero dei materiali. Lo sceglierei quando cambia il compito e la vecchia conversazione contiene soprattutto tentativi superati. Restare nella stessa conversazione può essere più pratico quando il ragionamento è ancora in corso e dipende da passaggi appena discussi. La scelta va provata sul lavoro completo: anche scrivere l’handoff e rileggere le fonti richiede tempo e consumo. In entrambi i casi, ripartire con un altro contesto lascia intatti gli effetti esterni già prodotti. Prima di riprendere una modifica, controllo lo stato del repository o del servizio coinvolto, anziché dedurlo dalla conversazione. ## Una LLM wiki richiede manutenzione Nel suo [progetto LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), Andrej Karpathy descrive una base di conoscenza in cui l’agente integra nuove fonti in pagine collegate e sintesi mantenute. Fonti, conoscenza derivata e regole di manutenzione hanno ruoli distinti. Nel sistema editoriale in Notion, il registro conserva le fonti, le ricerche sviluppano il ragionamento e gli articoli ne usano le conclusioni pertinenti. La manutenzione pesa quanto la prima sintesi. Una pagina duplicata può conservare una conclusione vecchia mentre quella aggiornata vive altrove. Prima di crearne un’altra cerco quindi l’argomento e l’URL; quando aggiorno una conclusione, controllo anche i passaggi degli altri articoli che la usano. Per una fonte usata una volta sola, un link commentato può bastare. La wiki può convivere con la retrieval-augmented generation, cioè la generazione che usa informazioni recuperate da una base esterna. Il [lavoro di Lewis e colleghi su RAG](https://arxiv.org/abs/2005.11401) combina generazione e memoria recuperabile. Una pagina di sintesi può essere a sua volta recuperata, poi rimandare al documento originale per il dettaglio. RAG descrive il meccanismo di recupero e generazione; la wiki aggiunge un’organizzazione mantenuta della conoscenza. Per la domanda su METR partirei dalla sintesi, controllerei il limite che cambia la decisione e aprirei la fonte pertinente. Per una domanda nuova, assente dalla sintesi, tornerei alla ricerca. Le pagine recuperate restano materiale da valutare: un testo al loro interno non concede permessi per inviare dati o modificare servizi. Se l’handoff mi rimanda a decine di pagine prima ancora di indicare il passaggio aperto, lo restringo. La conoscenza può essere ampia; il punto da cui riparto deve essere riconoscibile. Il tempo per preparare e mantenere queste note entra nel costo del lavoro. Nella [ricerca sul costo di Claude e Codex](https://www.matteovincenti.com/blog/ridurre-token-claude-codex-esperimenti) considero anche questo: una nuova sessione conta poco se per renderla operativa devo ricostruire tutto. Qui il criterio con cui valuto la struttura è ciò che riesco a continuare da quelle note.