Intelligenza Artificiale
Architetture AI on-premise, LLM locali, RAG, agenti autonomi. Progettazione e sviluppo di sistemi agentici governati.
Scopri →
Admina Enterprise
Governance AI Open Source: audit trail, PII redaction, policy bidirezionali ALLOW/BLOCK/REDACT su ogni chiamata e tool.
Scopri Admina →
Cybersecurity
Sicurezza degli agenti: prompt injection, least privilege, sandboxing, human-in-the-loop, compliance NIS2.
Scopri →
Ricerca & Sviluppo
Ricerca applicata su sistemi agentici, orchestrazione multi-agente e valutazione.
Scopri →Serie in 3 parti. (1) anatomia del ciclo · (2) contesto, pattern e multi-agente · (3) sicurezza e governance (dal 10 luglio). Questa è la parte 2: si presuppone il ciclo base della parte 1.
Nella parte 1 abbiamo visto lo scheletro: obiettivo, decide, agisce, esegue, osserva, ripete. Funziona per compiti brevi. Farlo durare, e renderlo capace di problemi grossi, è un altro lavoro: comincia dal contesto.
Context engineering: il vero collo di bottiglia
Ogni passo appende al contesto la risposta del modello e i risultati degli strumenti. Il contesto cresce in modo monotòno, e questo è il limite pratico dei task a orizzonte lungo: un’attività di venti passi con output di strumenti corposi satura la finestra prima di concludere. Peggio: oltre una certa soglia, troppo contesto degrada il ragionamento (il modello “annega” nella cronologia). Non conta il volume, conta la rilevanza. Le strategie di context engineering sono ciò che rende un agente capace di durare:
- Troncamento: si scartano i messaggi più vecchi. Semplice, ma si perde memoria.
- Compattazione / sintesi: si comprime la cronologia in un riassunto strutturato, mantenendo decisioni e fatti chiave. Un LLM che riassume sé stesso.
- Stato esternalizzato: si scrive lo stato su file o database e nel contesto si tengono solo i puntatori. L’agente rilegge on demand ciò che serve, invece di trascinarsi tutto dietro.
- Retrieval (RAG): si recupera solo il pezzo di conoscenza rilevante al passo corrente, invece di precaricare tutto.
- Offload a sub-agenti: un sub-agente esegue una ricerca costosa e restituisce al genitore un risultato distillato, tenendo piccolo il contesto del genitore.
C’è poi il conto economico: costo e latenza di ogni passo crescono con la lunghezza del contesto, e il contesto cresce a ogni passo. Il prompt caching (riuso della porzione stabile del contesto tra le chiamate) riduce drasticamente, fino al 90% a seconda del provider, il costo dei token di input riletti a ogni passo, che in un loop lungo dominano il conto; output e porzioni non in cache restano a prezzo pieno.
Oltre il ciclo reattivo: pianificare, riflettere, verificare
Il ciclo minimo è reattivo: decide un passo alla volta guardando l’ultima osservazione. Funziona per task brevi, meno per quelli lunghi. Sopra al loop si costruiscono pattern più robusti:
- ReAct (reason + act): il modello alterna ragionamento esplicito e azione, tenendo uno scratchpad di pensiero che precede ogni tool call.
- Plan-and-Execute: prima si genera un piano (una lista di sotto-obiettivi), poi lo si esegue passo per passo, ripianificando quando un’osservazione smentisce le assunzioni. Il piano è memoria strutturata che tiene la rotta su orizzonti lunghi.
- Reflexion / self-critique: dopo un tentativo, un passo critico rivede il risultato, individua l’errore e ritenta; la riflessione resta in memoria e guida i tentativi successivi. È un loop di correzione sopra il loop d’azione.
- Verifica: genera → verifica → correggi. Un secondo agente (o lo stesso, con un altro prompt) controlla in modo avversariale l’output prima di accettarlo. La verifica indipendente è ciò che alza l’affidabilità sopra il “sembra giusto”.
Multi-agente: loop di loop
Quando un compito è troppo grande per un singolo contesto, si passa a più agenti: un orchestratore genera sotto-agenti, ciascuno con il proprio loop e il proprio contesto isolato, e ne aggrega i risultati. Dal punto di vista dell’orchestratore, un sub-agente è uno strumento come un altro: gli passa un compito, riceve un risultato distillato. I vantaggi sono parallelismo (fan-out su sotto-problemi indipendenti), isolamento del contesto e specializzazione; i costi sono coordinamento e duplicazione del contesto. È il principio dietro le modalità “ultra” con sub-agenti che stanno comparendo nei modelli di frontiera (ne abbiamo parlato a proposito di GPT-5.6 Sol).
Robustezza: errori, retry, idempotenza
Nel mondo reale gli strumenti falliscono: timeout, eccezioni, risposte malformate. In un agente ben costruito un fallimento non è fatale: diventa un’osservazione che rientra nel contesto, e il modello può recuperare (riprovare, cambiare approccio, chiedere aiuto). Tre accortezze:
- Retry con backoff e un tetto: non riprovare all’infinito.
- Idempotenza degli strumenti con effetti collaterali: un retry non deve creare due ordini, inviare due email, applicare due volte la stessa patch. Chiavi di idempotenza o controlli di stato prima dell’azione.
- Contenimento: un errore in un sub-agente non deve far cadere l’intero albero.
Determinismo, latenza, costo
Il campionamento rende l’output non deterministico. Per riproducibilità si usano temperature=0 e, dove disponibili, i seed; ma anche così il determinismo resta un best effort: batching dinamico, aritmetica floating point su GPU e aggiornamenti dell’infrastruttura del provider possono far variare l’output a parità di input. La latenza di un loop è la somma, passo per passo, di latenza del modello e degli strumenti: un agente da dieci iterazioni moltiplica per dieci. Il costo è la somma dei token su tutti i passi, con il contesto che cresce a ogni giro. Streaming, prompt caching, esecuzione speculativa e chiamate parallele sono ciò che rende un agente utilizzabile in produzione invece che una demo.
Contesto, pattern e orchestrazione rendono un agente capace. Ma un agente capace che tocca dati e azioni reali è anche una superficie d’attacco: è il tema della parte 3.
Torna alla parte 1: anatomia del ciclo. La parte 3 (sicurezza e governance) arriva il 10 luglio.