> ## Content Index > Fetch the complete content index at: https://adrianoamalfi.com/llms.txt > Use this file to discover other available public pages before exploring further. # Il confine tra deterministico e ragionamento - URL: https://adrianoamalfi.com/confine-deterministico-ragionamento-agenti/ - Published: 2026-07-11T18:04:46.000Z - Updated: 2026-07-26T17:13:31.000Z - Description: Usare LLM per ogni task produce agenti inaffidabili e costosi. La soluzione non è un modello più grosso: è un'architettura ibrida con verifica deterministica. - Author: Adriano Amalfi - Tags: AI Agentica, AI in Produzione, LLM, AI Tools, Opinione C'è un errore che in cui si cade quando si prova a mettere agenti AI in produzione. Funziona più o meno così: prendi un LLM potente, gli dai accesso a qualche tool, lo metti in un loop, scrivi un prompt sofisticato e giri la demo. Funziona. Sembra magia. > Poi lo metti in produzione e si rompe in modi che non avevi previsto. Il problema non è il modello: è aver confuso due categorie di task radicalmente diverse e averle passate entrambe allo stesso LLM. ## Due nature di task, un solo errore Ci sono task che hanno una risposta giusta verificabile: validare un formato JSON, trasformare dati da uno schema a un altro, instradare una richiesta in base a un campo noto, fare il parsing di un log, verificare che un elemento dell'interfaccia esista dopo un click. Li chiamano *task deterministici*: l'output è giusto o sbagliato, punto. Poi ci sono task che richiedono comprensione del contesto, ambiguità, creatività: riassumere una conversazione di supporto, pianificare i passi per risolvere un bug in una codebase sconosciuta, decidere se un'eccezione in una fattura merita escalation. Qui serve **ragionamento**: non c'è una risposta "giusta" predefinita, serve adattamento, serve "intelligenza". Il punto è semplice: quando si usa un LLM per un task deterministico, stai pagando token per ottenere un risultato peggiore, più lento e meno affidabile di una funzione da 10 righe di codice. Sprecare un LLM per fare il parser di un log è come usare un chirurgo per mettere un cerotto. Non è che il chirurgo non sappia farlo: è lo strumento sbagliato, al costo sbagliato, con una superficie di errore inutilmente ampia. ## Cosa si rompe davvero quando metti un LLM ovunque Nei progetti reali, i fallimenti seguono uno schema prevedibile. Il primo a cedere non è quasi mai la qualità del modello: è la *memoria*. Le assunzioni vecchie inquinano i task nuovi, il contesto si gonfia e l'agente diventa "confidentemente sbagliato" in modi difficili da debuggare. Chi ha costruito agenti in produzione lo sa: gestire la memoria spesso migliora i risultati più di qualsiasi tweak al modello. Poi si rompono i *tool*. La maggior parte delle architetture agentiche assume che i tool siano deterministici ed economici. Non lo sono. Le API falliscono, restituiscono dati parziali, cambiano formato, vanno in timeout. Un agente che non ha strategie per il fallimento dei tool è un incidente che attende solo il momento di materializzarsi. E poi c'è il problema della *fiducia*, che si degrada più in fretta di quanto immagini. Basta **una** decisione sicura ma sbagliata perché un utente declassi mentalmente l'agente. Recuperare quella fiducia è molto più difficile che prevenire il fallimento, e prevenire il fallimento significa progettare per il fallimento deterministico, non per la speranza probabilistica. Il problema non è l'intelligenza: è la *responsabilità*. Nei sistemi di produzione, l'AI può essere usato come interprete semantico o generatore di segnali di rischio, ma le decisioni vere devono restare deterministiche, riproducibili, verificabili e annullabili da un umano. Anthropic, nel suo pezzo canonico [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents?ref=adrianoamalfi.com), lo dice senza giri di parole: la soluzione più semplice è quella giusta, e a volte significa non costruire affatto sistemi agentici per task con azioni predeterminati e risultati prevedibili. ## L'architettura ibrida Il pattern che funziona meglio in produzione è l'architettura *planner / executor / verifier*. Il **planner** (un LLM adatto) produce un piano e definisce cosa deve essere vero dopo ogni passo. L'**executor** (che può essere un LLM piccolo o addirittura codice tradizionale per il singolo task) esegue azioni concrete. Il *verifier* (deterministico, non un LLM) controlla che lo stato atteso sia effettivamente raggiunto. Se l'asserzione fallisce, il passo fallisce con artefatti di debug, senza derive silenziose. Il caso più interessante è quello di [Predicate su Amazon](https://sentienceapi.com/blog/verification-layer-amazon-case-study?ref=adrianoamalfi.com): un agente di shopping end-to-end (cerca prodotto, clicca primo risultato, aggiungi al carrello, vai al checkout) completato con *7 passi su 7*, usando un *modello locale da \~3B parametri* come executor, con un *costo incrementale di $0.001*. Il planner era DeepSeek-R1, il verifier era codice deterministico con asserzioni in stile Jest. | Approccio | Passi completati | Token | Tempo | | -------------------------------------------- | ---------------- | ------ | ------ | | Cloud LLM (GLM-4.6) con verifica strutturata | 1/1 run | 19.956 | \~60s | | Locale (DeepSeek-R1 + Qwen 3B) con verifica | 7/7 passi | 11.114 | \~405s | La tabella confronta due approcci entrambi con verifica strutturata: uno cloud e uno locale, un task singolo e uno multi-step con gating a ogni passo. Il tempo è più alto sull'inferenza locale (Apple Silicon via MLX), ma il punto è che un *modello minuscolo*, vincolato dentro un loop di verifica deterministica, completa un task multi-step su un sito reale senza un singolo fallimento silenzioso. Un approccio puramente basato su visione o su LLM "intelligenti" avrebbe, probabilmente, fallito. Nel playground di Predicate, [gli agenti vision-only hanno fallito sistematicamente](https://github.com/PredicateSystems/predicate-sdk-playground?ref=adrianoamalfi.com) sulle stesse task (0-30% di successo contro 100%). Poi c'è la riduzione dei token: *\~43% in meno* rispetto a un approccio basato su HTML grezzo o screenshot. Non è un'ottimizzazione: è la differenza tra un sistema che ha senso economicamente e uno che non ce l'ha. Come nota il report di Predicate, lo snapshot struttura-first con filtro dei ruoli ha ridotto il volume del prompt di circa il 43% nel baseline cloud, mantenendo lo stesso loop di verifica deterministica. ## Il verifier non può essere un LLM Questo è il punto dove più team sbagliano. Dopo aver capito che serve un layer di verifica, molti costruiscono un "agente verificatore" che è... un altro LLM. È come chiedere al sospettato di fare l'investigatore. Il verifier deve essere deterministico. Nel caso Predicate, è letteralmente codice che esegue asserzioni su snapshot strutturati del DOM: `exists()`, `url_contains()`, `text_contains()`. Se lo stato atteso non viene raggiunto entro un timeout configurabile, il passo fallisce con artefatti. L'agente non decide se ha avuto successo: lo **prova**. Vale la pena guardare Tracecore, un [runtime deterministico per la valutazione di agenti](https://github.com/justindobbs/Tracecore?ref=adrianoamalfi.com) che congela input, budget e validatori per garantire riproducibilità. Il principio è lo stesso: la validazione è binaria e non negoziabile. Un agente non "probabilmente" ha completato un task: o lo ha completato secondo criteri espliciti, o no. Se il verifier è un altro LLM, non hai un sistema di verifica: hai due opinioni. La verifica è solo codice deterministico. Il codice non "pensa" che lo stato sia corretto: lo \*prova\* con asserzioni binarie. Un layer di verifica probabilistico amplifica l'errore invece di contenerlo. ## Cosa cambia nel modo di progettare agenti Se accetti questa distinzione, cambiano quattro cose pratiche: - ***Tool design come contratto.*** Un tool non è solo una funzione esposta a un LLM: è un contratto. Va progettato con la stessa cura che metteresti in una API pubblica. Anthropic lo dice esplicitamente nella [sezione sul prompt engineering dei tool](https://www.anthropic.com/engineering/building-effective-agents?ref=adrianoamalfi.com): dedica alle interfacce agente-computer (ACI) la stessa cura che riserveresti alle interfacce uomo-computer (HCI). Tool mal progettati generano più errori dei prompt mal scritti. - ***Pre-action authorization.*** Per task ad alto rischio, il verificatore non basta: serve un gate **prima** dell'esecuzione. Predicate ha mostrato un esempio concreto con un [demo di operazioni finanziarie](https://github.com/PredicateSystems/account-payable-multi-ai-agent-demo?ref=adrianoamalfi.com): quando l'agente tenta di autorizzare un pagamento da $50.000, un **policy engine** (non un LLM) blocca l'azione. Nessuna tecnica di prompt injection, logica di retry o ragionamento creativo può aggirare il blocco. - ***Costo per task come metrica primaria.*** Un agente che costa $10 a task o impiega 30 secondi per risposta è inutilizzabile nella maggior parte dei sistemi reali, indipendentemente da quanto sia "intelligente". La vera ottimizzazione non è ridurre i token del prompt: è eliminare interi passi di ragionamento non necessari, sostituendoli con codice deterministico. - ***Separazione delle responsabilità.*** Il planner ragiona, l'executor agisce, il verifier controlla. Tre ruoli, tre componenti potenzialmente diversi. Non c'è nessuna ragione per cui lo stesso LLM debba fare tutto. E infatti non dovrebbe. ## Il mercato è pieno di demo spettacolari e deployment falliti. Il pattern è sempre lo stesso: l'agente "funziona" in demo perché il task è abbastanza semplice o il contesto abbastanza prevedibile da mascherare la fragilità dell'approccio. In produzione, dove le API falliscono, le pagine cambiano, il contesto si accumula e gli utenti perdono fiducia al primo errore, il castello crolla. La vera competenza nell'AI agentica, nel 2026, non è scrivere prompt più creativi o incollare insieme più framework. È sapere esattamente **quando non usare un LLM**. È riconoscere che validare un formato JSON con una regex è più veloce, più economico e più affidabile che chiedere a un modello da 70 miliardi di parametri "sei sicuro che questo sia JSON valido?" Non è una posizione contro gli LLM: è una posizione a favore dell'architettura. Il futuro degli agenti non appartiene a chi ha il modello più grosso: appartiene a chi sa costruire il sistema di verifica più solido intorno a un modello abbastanza piccolo.