Il tuo agente AI non è rotto. È l'architettura che non va.

I post-mortem che sentiamo più spesso seguono sempre lo stesso schema: un'azienda distribuisce un agente AI, nelle demo funziona bene, poi in produzione comincia a fare cose strane. Salta passaggi. Dà risposte diverse alla stessa domanda. Ogni tanto compie un'azione che, se l'avesse fatta un dipendente, sarebbe costata il posto. Il riflesso naturale è dare la colpa al modello e cercare qualcosa di più potente.

Quasi sempre, quel riflesso porta fuori strada.

Il team di ingegneria di Salesforce lo ha documentato con precisione in un agente di ottimizzazione dei costi cloud che ha costruito e messo in produzione. Circa l'86% dei loro container sottoutilizzava la CPU, e l'agente doveva trovare il file di configurazione giusto e correggere l'allocazione. Continuava a produrre risposte diverse alla stessa richiesta. La soluzione non è stato un modello nuovo né un prompt più raffinato. È stato un cambiamento architetturale: hanno smesso di chiedere all'LLM di fare tutto e hanno iniziato a instradare il lavoro allo strumento giusto. Il ragionamento ambiguo (quale file di configurazione è effettivamente in controllo?) restava all'LLM. L'aritmetica precisa (qual è il valore ottimale della CPU?) andava a un solver deterministico. Stesso input, stesso output. Sempre. La descrizione completa dei cinque pattern estratti è qui: [https://engineering.salesforce.com/how-to-build-reliable-ai-agents-5-engineering-patterns-from-a-production-system/](https://engineering.salesforce.com/how-to-build-reliable-ai-agents-5-engineering-patterns-from-a-production-system/)

Separatamente, un benchmark Salesforce chiamato CRMArena Pro ha testato agenti LLM su compiti CRM realistici, e i risultati sono stati negativi in un modo molto specifico. Gli agenti hanno fallito non solo sulla precisione, ma anche sulla riservatezza, facendo trapelare dati tra account utente diversi. Non è un problema di intelligenza del modello. È un problema di policy enforcement mancante. The Register ne ha scritto qui: [https://www.theregister.com/2025/06/16/salesforce_llm_agents_benchmark/](https://www.theregister.com/2025/06/16/salesforce_llm_agents_benchmark/)

Come appare concretamente un'architettura approssimativa

In pratica, vediamo ripetersi sempre gli stessi tre errori:

• Chiedere all'LLM di fare calcoli, applicare regole e ragionare, tutto nello stesso passaggio. I modelli linguistici sono probabilistici. Sono eccellenti nel navigare l'ambiguità e produrre testo plausibile. Non sono calcolatrici, né motori di policy. Mescolare queste responsabilità in un unico prompt non è una scorciatoia: è un guasto che aspetta solo di manifestarsi sotto carico.

• Trattare il contesto come un dettaglio secondario. Inserire ogni informazione disponibile nella finestra di contesto sembra accurato. In realtà è uno dei modi più affidabili per degradare la qualità dell'output. Il team di Salesforce indica esplicitamente la gestione del contesto come una scelta architetturale, non un ritocco al prompt.

• Usare un altro LLM per validare l'output di un LLM. Un agente revisore che controlla il lavoro di un agente esecutore sembra sensato. Ma se entrambi condividono gli stessi punti deboli, si aggiungono latenza e costi senza aggiungere correttezza. La validazione vera usa criteri oggettivi: il codice compila, l'aggiornamento del record va a buon fine, l'output soddisfa uno schema deterministico?

Un recente paper di Alibaba lo rende concreto. Il framework "Blueprint First, Model Second" mette codice Python ordinario al comando della logica di flusso, e chiama l'LLM solo nei passi che richiedono davvero ragionamento flessibile. Sul benchmark TravelPlanner, le violazioni di vincoli sono calate del 96% rispetto all'approccio precedente. Il principio è semplice: il codice è il responsabile, l'LLM è uno specialista convocato quando serve. [https://arxiv.org/abs/2508.02721](https://arxiv.org/abs/2508.02721)

Il paper LedgerAgent porta la stessa idea nel tool-calling per il customer service: ogni volta che uno strumento restituisce dati, i risultati vanno in un archivio strutturato tipizzato, non di nuovo in testo libero nel prompt, e un policy gate controlla ogni azione di scrittura prima che venga eseguita. Su scenari di compagnie aeree, retail, telecomunicazioni e telemedicina, i tassi di successo sono migliorati di 6-16 punti senza chiamate LLM aggiuntive. [https://arxiv.org/abs/2606.20529](https://arxiv.org/abs/2606.20529)

Cosa pensiamo noi

Osserviamo da abbastanza tempo la risposta "aggiorna il modello" ai fallimenti degli agenti per sapere che è quasi sempre un diversivo. GPT-4 che fa la tua aritmetica non è più affidabile di GPT-3.5 che fa la tua aritmetica; una funzione deterministica che fa la tua aritmetica è affidabile ogni volta.

Per i deployment nelle PMI in particolare, le conseguenze di un'architettura approssimativa sono più alte di quanto si pensi di solito. Un data leak tra account CRM, un flusso che salta un passaggio di compliance, un agente che dà a un cliente l'importo sbagliato per un rimborso perché l'aritmetica in virgola mobile è passata attraverso un modello linguistico: nessuno di questi problemi si risolve con una revisione del prompt o un cambio di modello. Richiedono risposte strutturali. Separa il livello di ragionamento da quello di calcolo. Imponi le policy con codice, non con istruzioni all'LLM. Valida gli output con criteri oggettivi.

Le prove in produzione di Salesforce puntano in un'unica direzione. Il divario di affidabilità nei sistemi agentici è un problema di ingegneria.

Da tenere d'occhio

Il pattern da seguire è la formalizzazione di "shell deterministiche" attorno ai core LLM, siano esse blueprint Python, ledger tipizzati o policy gate. Con la maturazione di Agentforce e piattaforme simili, ci aspettiamo che questi pattern diventino primitive di primo livello, non workaround. I team che li costruiscono a mano oggi avranno un vantaggio significativo quando le piattaforme li adotteranno come standard.