Il confine tra deterministico e ragionamento

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, 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: 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.

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 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 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.

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: 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: 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.