Context engineering: compaction, passaggi di consegne, reset e thinking effort

Panoramica

Il context engineering e la gestione attiva di cio che l'agente tiene in questo istante. Quattro leve fanno l'essenziale del lavoro. La compaction riassume una lunga conversazione per liberare la finestra, ma la versione automatica lascia cadere in silenzio cose che ti importavano, quindi la piloti. Un passaggio di consegne trasmette un riassunto pulito a una sessione fresca. Un reset butta un contesto confuso e riparte da un prompt netto. E il thinking effort scambia costi contro profondita sui problemi davvero duri. Padroneggia questi quattro, e i lunghi compiti restano affilati, invece di derivare nella confusione.

Cosa imparerai

Imparerai perche l'auto-compaction e una trappola e come comprimere alle tue condizioni, come re-iniettare il tuo obiettivo perche l'agente non derivi dopo un riassunto, come scrivere un documento di passaggio di consegne che lascia una sessione fresca continuare senza perdere il filo, come riconoscere quando un reset batte una nuova tornata di rattoppi, e come regolare il thinking effort per pagare un reasoning profondo solo quando il compito lo merita.

Prerequisiti

La lezione su token, contesto e performance cliff del Corso 1 e una vera esperienza di compiti multi-passo, abbastanza lunga da aver sentito una sessione diventare confusa. Queste tecniche contano solo una volta che le sessioni sono lunghe, quindi la lezione sui sub-agent appena prima e un'introduzione naturale - i sub-agent gestiscono il contesto tra agenti, questa lezione lo gestisce all'interno di uno.

Il problema

Sei profondamente in un lungo compito. Il context window si riempie, e a un certo punto l'harness comprime automaticamente - riassume la conversazione finora per far spazio. D'improvviso, l'agente sembra diverso. Ha dimenticato una decisione che hai preso presto, o ottimizza ormai l'obiettivo sbagliato, o contraddice con sicurezza qualcosa che approvava un'ora fa. L'auto-compaction ha fatto il suo lavoro meccanicamente: ha fatto spazio. Ma ha riassunto secondo le sue priorita, non le tue, e ha lasciato cadere in silenzio il vincolo che ti importava di piu. Non hai scelto tu cosa resta, quindi hai perso il filo senza accorgertene.

Perche l'auto-compaction nuoce, e pilotarla

L'auto-compaction non e malevola, e solo con perdita e mal tempificata. Scatta quando la finestra e quasi piena, il che e quasi sempre il momento peggiore, in pieno ragionamento, e comprime tutto secondo un'euristica generica che non conosce il tuo vero obiettivo. Il risultato e una perdita di qualita sottile che spesso noti solo dopo che l'agente e derivato. La soluzione e prendere il controllo del momento e del contenuto. Comprimi deliberatamente, a un punto di rottura pulito tra sotto-attivita piuttosto che nel bel mezzo di un passo. E subito dopo ogni compaction, re-inietta il tuo obiettivo: riformula l'obiettivo, i vincoli centrali e lo stato attuale in qualche riga. Questo solo paragrafo ri-ancora l'agente e disfa l'essenziale di cio che la compaction ha confuso.

• Comprimi a un punto di rottura pulito che scegli tu, non quando la finestra lo forza nel bel mezzo del compito.
• Dopo la compaction, re-inietta l'obiettivo: riformula lo scopo, i vincoli non negoziabili e dove sei arrivato.
• Dopo un riassunto, sta' in guardia dalla deriva - quando le risposte dell'agente sembrano sbagliate, un vincolo perso e la causa abituale.
• Un CLAUDE.md aiuta anche qui: le regole del file sopravvivono perche vengono ricaricate, contrariamente ai punti sepolti nella chat.

Documenti di passaggio di consegne

A volte la mossa piu pulita non e comprimere ma passare la mano a una sessione fresca dalla finestra pulita. Lo strumento per questo e un documento di passaggio di consegne: un breve file markdown che fai scrivere all'agente e che annota tutto cio di cui la prossima sessione ha bisogno. Fatto bene, un nuovo agente legge il passaggio ed e subito informato quanto il vecchio, ma con un contesto vuoto e affilato. E di gran lunga il modo piu affidabile di condurre un lavoro fin troppo lungo per una finestra, senza la degradazione di qualita, ed e anche un protocollo che puoi dare a un compagno di squadra.

# Handover: Checkout flow refactor

## Goal
Move checkout from the old form to Stripe embedded checkout. Must keep the
existing success page and not change the cart.

## Done so far
- Added the Stripe SDK and the new checkout component.
- Wired the create-session endpoint (see src/api/checkout.ts).

## Current state / next step
- The embedded form renders but the redirect after payment 404s.
- Next: fix the return_url in checkout.ts to point at /order/success.

## Constraints (do not forget)
- TypeScript only, run the quality gate before pushing.
- Never log the Stripe secret key.

Chiedi all'agente di scriverlo prima di terminare una lunga sessione, poi incollalo in una chat fresca per continuare. La nuova sessione parte con una finestra pulita e un brief preciso, il che e quasi sempre piu affilato che spingere una sessione gonfia per una tornata di piu.

Quando reimpostare

Un reset consiste nel ripartire da un prompt fresco e focalizzato abbandonando il contesto attuale. Suona come buttare lavoro, ma e spesso il cammino piu rapido verso avanti. Quando un agente cicla sullo stesso fix fallito, si contraddice o porta un contesto cosi gonfio che ogni risposta e mediocre, piu rattoppi aiuta raramente - stai litigando con una finestra confusa. Reimposta invece. Prendi cio che hai imparato, scrivi un prompt netto o un passaggio di consegne e riparti pulito. Il segnale e semplice: se hai spiegato due volte la stessa cosa e ancora non passa, il contesto e il problema, non l'istruzione. Un reset lo ripulisce.

Thinking effort

Il thinking effort e la quantita di ragionamento deliberato che il modello fa prima di rispondere. Piu effort significa che lavora il problema piu attentamente, il che costa piu token e tempo, ma alza la qualita sui compiti davvero duri - debugging delicato, decisioni di architettura, logica sottile. Meno effort va bene per il lavoro di routine dove un reasoning profondo e denaro sprecato. La regola pratica riflette la scelta di modello del Corso 1: alza l'effort per il 20 percento duro che ne ha davvero bisogno, e tienilo basso per l'80 percento facile. Puoi fissare un default e alzarlo per compito. Pagare un reasoning massimo per un rinominare o una passata di formattazione e lo stesso errore di far applicare un cerotto da una chirurga.

• Effort alto: debugging duro, architettura, logica sottile - i casi in cui un ragionamento attento cambia la risposta.
• Effort basso: modifiche di routine, formattazione, refactor semplici - la profondita e qui denaro sprecato.
• Adatta l'effort alla difficolta, esattamente come adatti il livello di modello alla difficolta.
• L'effort e un modello potente si sommano: riserva entrambi ai problemi davvero duri.

Errori frequenti

I ricorrenti: lasciare che l'auto-compaction scatti e non re-iniettare mai l'obiettivo, cosicche l'agente deriva in silenzio; spingere una sessione confusa e gonfia tornata dopo tornata quando un reset sarebbe stato piu rapido; non scrivere mai un passaggio di consegne, cosicche ogni lungo compito marcisce invece di continuare pulito; e bruciare un thinking effort massimo su lavoro banale chiedendoti perche la fattura e alta. Il meta-errore e trattare il contesto come qualcosa che ti capita, invece di qualcosa che ingegnerizzi attivamente.

ROI business

Il context engineering e cio che rende il grosso lavoro agentico di piu ore davvero affidabile invece di uno lento scivolamento nella confusione. Comprimere alle tue condizioni, passare la mano pulita e reimpostare al momento giusto tengono la qualita dell'output alta su compiti molto piu grandi di una finestra - il che significa meno rilavorazione e meno bug sottili di un agente che deriva. Adattare il thinking effort alla difficolta pilota i costi direttamente. Per un fondatore che conduce veri workflow, queste abitudini sono la differenza tra un lavoro agentico che scala e un lavoro agentico che marcisce in silenzio man mano che gira.

Checklist

Sei pronto ad andare avanti quando ognuno di questi punti e vero. L'ultima lezione assembla il setup pro che rende tutto cio fluido nel quotidiano.

• Sai spiegare perche l'auto-compaction nuoce e cosa fa la re-iniezione dell'obiettivo.
• Sai far scrivere un documento di passaggio di consegne all'agente e continuare in una sessione fresca.
• Conosci i segnali che vogliono dire reset piuttosto che rattoppo.
• Adatti il thinking effort alla difficolta del compito, invece di massimizzarlo sempre.

Risorse

Tieni nei preferiti la documentazione di Claude Code sulla gestione del contesto e i comandi compact e clear per il comportamento e i flag aggiornati. Tieni un template di passaggio di consegne nella tua libreria di risorse, perche scriverne uno sia un'abitudine di due minuti. Il tuo CLAUDE.md e la tua assicurazione contro la perdita da compaction, perche le regole del file vengono ricaricate, mentre i punti sepolti nella chat no.

La tua missione

Al tuo prossimo lungo compito, fai due cose deliberatamente. Quando la finestra si riempie, comprimi tu stesso a un punto di rottura pulito poi re-inietta il tuo obiettivo in un breve paragrafo. Piu tardi, fai scrivere un documento di passaggio di consegne all'agente, apri una sessione fresca, incollalo e continua. Nota quanto la sessione fresca sembra piu affilata. Hai appena ingegnerizzato il tuo contesto, invece di lasciarlo ingegnerizzare te.

Prossima lezione

Sai gestire regole, skill, hook, MCP, lavoro multi-agente e contesto. L'ultima lezione di questo corso assembla il setup pro che collega tutto: una Status Line personalizzata, il pugno di flag CLI che usi ogni giorno, e lanciare sessioni dal tuo telefono o dal cloud, perche costruire non sia legato a una scrivania.