Il pattern di base lo conosci già: il loop tool-use. Claude valuta, chiede tool, riceve i risultati, ripete, e il ciclo finisce quando produce una risposta senza chiamate a tool. Tutto quello che segue sono strutture da montare attorno a quel loop per farlo reggere su compiti lunghi.
Generator-verifier: serve una seconda lente, non un secondo giro
In Building effective agents il pattern si chiama evaluator-optimizer: «In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop». Il blog di Anthropic sui pattern di coordinamento lo elenca come generator-verifier: un agente produce, un altro valuta contro criteri espliciti e rimanda indietro il feedback.
Quando conviene è dichiarato: «This workflow is particularly effective when we have clear evaluation criteria, and when iterative refinement provides measurable value». Tradotto in pratica: se non sai scrivere la rubrica del verificatore, il pattern non ti serve, perché il secondo modello si limiterà a riformulare il primo. Il segnale di buon fit è che una persona, guardando l’output, saprebbe articolare un feedback che lo migliora davvero.
L’errore tipico è dare al verificatore lo stesso contesto e lo stesso prompt del generatore: due lenti identiche vedono gli stessi difetti e il loop consuma turni senza guadagno. Il verificatore va costruito con criteri propri e, dove possibile, con strumenti diversi: una suite di test che gira, un linter, uno schema da validare.
Subagenti: si isola il contesto, non si spezza il compito
Nel Claude Agent SDK un subagente è un’istanza separata, e il dettaglio che decide il design è questo: il suo contesto parte pulito e l’unico contenuto che passa dal padre al figlio è la stringa di prompt del tool Agent. Percorsi dei file, messaggi di errore, decisioni già prese — se non li scrivi lì dentro, il subagente non li ha. Al ritorno il padre riceve solo il messaggio finale come risultato del tool, non l’intero transcript.
L’asimmetria è il punto: il contesto del padre cresce del riassunto, non delle decine di file letti. Il secondo beneficio è la restrizione dei tool. Un subagente definito con tools limitato a Read, Grep e Glob non ha gli altri in sessione: non c’è permesso da negare, semplicemente non esistono per lui.
Perché un albero di agenti non esploda ci sono tre leve, e vanno sapute a memoria.
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH profondità di annidamento, default 3
CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS subagenti in parallelo, default 20
maxBudgetUsd / max_budget_usd tetto di spesa, nessuno per default
Il tetto di spesa conta anche le richieste dei subagenti: al limite, lo spawn fallisce con Budget limit reached e i subagenti in background vengono fermati.
Memoria e finestra di contesto: tre meccanismi da non confondere
Sono tre cose diverse e l’esame le contrappone.
Il memory tool è uno store fuori dalla conversazione. Si dichiara con una sola entry e opera client-side: Claude chiede l’operazione, la tua applicazione la esegue e restituisce l’esito in un blocco tool_result. Il percorso /memories è un prefisso che il tuo handler mappa su storage reale, quindi la sicurezza è tutta tua — valida ogni path, perché una richiesta che risale le directory può uscire dalla radice.
{"type": "memory_20250818", "name": "memory"}
Il context editing toglie contenuto dalla storia. La strategia clear_tool_uses_20250919 cancella i tool result più vecchi in ordine cronologico e si regola con trigger, keep, clear_at_least ed exclude_tools. Il terzo parametro è quello che si dimentica: cancellare invalida il prefisso in cache, perciò conviene cancellare abbastanza da ripagare la riscrittura della cache invece di sbriciolarla a ogni turno.
La compaction, con la strategia compact_20260112, non cancella: riassume. Genera un blocco di sommario quando i token in ingresso superano la soglia configurata, e la conversazione prosegue da lì.
Non si escludono a vicenda. Per un agente lungo la combinazione sensata è compaction o context editing per tenere piccola la finestra attiva, più il memory tool per ciò che deve sopravvivere al riassunto: quello che il compattatore non conserva è perso, e le istruzioni date solo nel primo prompt sono le prime a sparire.
Framework di astrazione: cosa cita la pagina oggi
Qui serve attenzione, perché la fonte è cambiata. La Exam Guide nomina Strands, LangGraph e PydanticAI come esempi di framework agentici. La pagina Building effective agents oggi elenca invece il Claude Agent SDK, lo Strands Agents SDK by AWS, Rivet (un builder di workflow LLM con GUI drag and drop) e Vellum: LangGraph e PydanticAI non vi compaiono più. Sappi riconoscere i nomi della guida, ma quando descrivi lo stato dell’arte cita l’elenco attuale.
Il consiglio della pagina conta più dell’elenco: «We suggest that developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code». Il rischio dei framework è che aggiungano livelli di astrazione che nascondono prompt e risposte, rendendo il debug più difficile, e che invoglino a complicare dove basterebbe meno. Se ne usi uno, assicurati di sapere cosa fa il codice sotto.