# Userbot 3.0: perché siamo passati da un bot “a struttura fissa” a una piattaforma di Agenti AI scalabile Perché Userbot è passato dalla 2.0 alla 3.0: i limiti di una struttura fissa e i principi della nuova architettura, cioè composizione, azioni affidabili in produzione e libertà dal lock-in. - URL: https://userbot.ai/blog/da-userbot-v2-a-v3-piattaforma-agenti-ai-scalabile - Autore: Marco Mantovani, CTO di Userbot - Pubblicato: 2026-02-24 - Aggiornato: 2026-03-04 - Tema: Agenti e automazione - Editore: Userbot (https://userbot.ai) ## In breve - Userbot 3.0 è un salto architetturale verso l’Agentic AI: da una struttura predefinita a una piattaforma componibile di blocchi con responsabilità chiare, collegati da un orchestrator. - Con la 2.0 ogni eccezione diventava un nuovo ramo da mantenere, con più rischio di regressioni; la 3.0 gestisce la complessità modularizzando invece di aggiungere rami. - Le azioni sui sistemi esterni seguono contratti chiari: validazione dello schema, classificazione degli errori, timeout, retry con backoff e idempotenza per evitare ticket duplicati. - Contro il lock-in l’architettura separa quattro layer (policy, knowledge, execution e model), così il modello LLM resta un componente sostituibile senza riscrivere le automazioni. **Userbot 2.0 ha fatto il suo lavoro:**ha portato l’AI conversazionale in produzione in modo rapido e affidabile. Ma negli ultimi mesi – parlando con chi costruisce e gestisce agenti ogni giorno – è emersa una verità semplice: quando l’AI diventa parte dei processi, la conversazione smette di essere “un flusso” e diventa “un sistema”. In pratica, il problema non è più “generare testo”, ma costruire un **runtime** che gestisca tre piani in modo deterministico: **decisione** (routing/intent), **conoscenza** (retrieval su fonti controllate) ed **esecuzione** (azioni su sistemi esterni). Quando l’AI entra nei processi, serve un’architettura dove il modello è solo un componente: attorno devono esserci **state management**, **policy**, gestione degli errori e una pipeline di esecuzione ripetibile. E un sistema, in azienda, deve fare tre cose molto bene: - **adattarsi** a casi d’uso diversi senza diventare fragile; - **scalare** su volumi, canali e integrazioni senza esplodere in manutenzione; - **restare stabile**anche quando sotto cambiano modelli, policy e contenuti. Il punto è ridurre la dipendenza da una “logica monolitica” e passare a una struttura **componibile**: piccoli blocchi con responsabilità chiara (routing, retrieval, data collection, action execution) collegati da un **orchestrator**. È un cambio simile a quello che succede quando si passa da un’applicazione monolitica a servizi/componenti: meno branching nel codice conversazionale, più **riuso**, più **testabilità**, meno regressioni. È su questi tre punti che una struttura troppo rigida mostra i suoi limiti. Ed è esattamente per questo che abbiamo costruito Userbot 3.0: non come “una 2.0 con più feature”, ma come un salto architetturale verso l’Agentic AI. ## ****Il vero motivo del salto: la realtà non è “standard”**** All’inizio è facile pensare che basti “un bot che risponde bene”. Poi arrivano gli utenti reali, con richieste reali, e succede sempre la stessa cosa: il 20% dei casi genera l’80% del lavoro. Con Userbot 2.0, la struttura era chiara e funzionale. Ma era anche più “predefinita”: quando aumentavano eccezioni e varianti, il sistema tendeva a irrigidirsi. E quando un sistema si irrigidisce, accade un pattern che ogni team riconosce: - ogni ramo richiede manutenzione; - ogni nuovo scenario diventa un ramo dedicato; - ogni manutenzione aumenta il rischio di regressioni; - ogni regressione riduce la fiducia nell’automazione. A quel punto, l’AI smette di essere un acceleratore e diventa un “progetto da tenere in piedi”. Userbot 3.0 nasce per evitare proprio questo. Abbiamo lanciato Userbot 3.0 perché, crescendo, abbiamo visto lo stesso bisogno ripetersi: l’AI doveva essere più flessibile senza diventare più fragile. Userbot 3.0 è il nostro modo di rendere l’Agentic AI operabile: *un sistema malleabile, scalabile e governabile* che ti permette di costruire automazioni reali, con più autonomia ma anche con più controllo. ## ****La base solida di Userbot 2.0 (e dove iniziava a stringere)**** Vogliamo essere chiari: la versione 2.0 ha funzionato. E continua a essere una base solida per molti scenari. Su progetti più articolati abbiamo visto emergere quattro “frizioni” ricorrenti: - **Diversità di use case**: customer service, sales, HR, IT e operations hanno bisogni diversi. Non basta cambiare tono o FAQ. - **Azioni e integrazioni**: quando la chat deve aprire ticket, interrogare CRM/ERP, aggiornare dati, gestire errori, la logica diventa processo. - **Evoluzione continua**: cambiano contenuti, policy, prodotti e (soprattutto) i modelli LLM. In produzione serve governare il cambiamento. - **Scalabilità organizzativa**: più team vogliono costruire automazioni in parallelo. Servono componenti riusabili e un modo chiaro di “mettere ordine”. In sintesi: Userbot 2.0 era “veloce da avviare”. Ma adesso doveva essere “facile da far crescere”. ## ****I principi di Userbot 3.0**** Userbot 3.0 è stata progettata attorno a un’idea semplice ma “da engineering”: **la complessità non si scala aggiungendo rami**, si scala **modularizzando**. In Userbot 2.0, quando aumentavano eccezioni e varianti, il rischio era il classico: branching che cresce, logica duplicata, regressioni e manutenzione che esplode. Nella nuova versione il focus diventa l’opposto: **rendere il sistema componibile**, con componenti isolabili, riusabili e misurabili. ### I principi che hanno guidato la nascita di Userbot 3.0 #### Composizione ![](https://a.storyblok.com/f/296172060779225/a860bb9f75/image.png/m/1400x0/filters:format(webp):quality(86)) In Userbot 3.0 abbiamo spostato l’attenzione dal “costruire un bot” al “**costruire un insieme di capability**” che possono essere combinate in modi diversi a seconda del caso d’uso. Il motivo è molto pratico: un bot monolitico (prompt + logica + eccezioni) tende a crescere per accumulo, funziona bene finché gli scenari sono pochi e stabili, ma quando arrivano varianti, eccezioni, canali diversi e richieste ibride, la logica si espande in rami e workaround. A quel punto il problema non è più “fare una risposta migliore”, ma **evitare che ogni modifica introduca regressioni**. La composizione risolve questo punto alla radice perché introduce separazione di responsabilità; il sistema non “pensa e fa tutto insieme”: prima decide che tipo di richiesta è e quale percorso seguire, poi recupera informazioni dalle fonti autorizzate, poi raccoglie ed eventualmente valida i dati strutturati necessari, quindi esegue azioni tramite integrazioni con contratti chiari, e solo alla fine compone la risposta. Questo rende l’automazione più robusta perché ogni parte può essere migliorata o sostituita senza toccare le altre: ad esempio puoi cambiare strategia di retrieval o cambiare un’integrazione senza dover riscrivere l’intero comportamento del bot. In termini di engineering, è lo stesso vantaggio che si ottiene passando da una logica monolitica a componenti: aumentano riuso e testabilità, si riducono duplicazioni e branching combinatorio, e soprattutto si abbassa il costo del cambiamento. Ed è proprio questo che rende la versione 3.0 più “scalabile” nel senso reale del termine: non solo regge più volumi, ma regge più varianti nel tempo, con meno manutenzione e più controllo. #### **Agentic by design: decisione + azione, con un execution layer “da produzione”** In Userbot 3.0 “agentico” non significa avere un bot che improvvisa di più. Significa avere un sistema che, oltre a generare una risposta, è in grado di **prendere decisioni operative** e **portarle a termine** in modo controllato. In Userbot 2.0 molte esperienze conversazionali erano ottime quando l’obiettivo era informare o guidare l’utente. Ma appena la chat deve diventare parte del processo — aprire ticket, interrogare un CRM, aggiornare un record, verificare uno stato, gestire un cambio piano — non basta più “dire cosa fare”: serve poterlo **fare davvero**, e farlo con le stesse aspettative che hai per un software di produzione. La parte davvero tecnica è che l’azione non può essere “free-form”. Se un agente deve chiamare un’API, deve farlo con **contratti chiari**: parametri validati, output strutturato, gestione degli errori. Qui entrano concetti tipici del backend engineering: **schema validation** (per evitare chiamate con payload incompleti), **classificazione degli errori** (transitorio vs definitivo), **timeout** per non bloccare l’esperienza, **retry con backoff** quando ha senso, e soprattutto **idempotenza** per evitare effetti collaterali quando l’utente ripete la richiesta o quando una chiamata viene ritentata. In altre parole: l’agente non deve solo “sapere cosa fare”, deve poterlo fare senza generare ticket duplicati, aggiornamenti ripetuti o stati incoerenti. Il risultato è che la conversazione smette di essere solo un canale e diventa un’interfaccia operativa: **non solo risponde**, ma **esegue**, con un livello di affidabilità e governabilità che ha senso in produzione. #### **Libertà dai lock-in: progettare per cambiare modello senza cambiare comportamento** In produzione, il problema non è scegliere “il modello migliore”. Il problema è accettare una realtà tecnica: **i modelli cambiano**. Cambiano le versioni, cambiano i costi, cambiano le policy, cambiano le latenze, cambiano le prestazioni su certe lingue o domini. A volte un provider degrada, a volte un update migliora il reasoning ma peggiora la rigidità su output strutturati, a volte una policy nuova introduce rifiuti o risposte più conservative. Se la tua automazione è “incollata” a un singolo modello — o peggio, se il comportamento emerge direttamente dal modello senza strati di controllo — ogni variazione diventa un rischio operativo. Per questo in Userbot 3.0 la libertà dal lock-in non è un tema commerciale, è un principio architetturale: **separare ciò che vuoi mantenere stabile da ciò che sai che cambierà**. Il “comportamento” desiderato (regole, limiti, escalation, formati, vincoli sulle azioni) deve vivere in un layer governato — policy e contratti — mentre il modello deve restare un componente sostituibile. In pratica, l’obiettivo è ottenere **stabilità comportamentale**: poter aggiornare o sostituire il modello senza riscrivere automazioni, senza toccare integrazioni e senza cambiare l’esperienza utente. ![](https://a.storyblok.com/f/296172060779225/cac4a474cd/scr-20260304-jdck-2.png/m/1400x0/filters:format(webp):quality(86)) Tecnicamente, questo si ottiene con una separazione netta tra quattro layer: - **Policy/guardrail**: ciò che non deve cambiare (regole, compliance, limiti operativi, condizioni di escalation, “do/don’t” dell’agente). - **Knowledge layer**: ciò che deve essere verificabile (fonti, retrieval, priorità e whitelisting delle sorgenti, gestione della freschezza dei contenuti). - **Execution layer**: ciò che deve essere deterministico (tool/API con input validati, output strutturati, gestione errori, idempotenza, side effects). - **Model layer**: ciò che deve poter variare (uno o più LLM scelti per task, provider, versione, costo e latenza). Quando questi layer sono separati, il modello smette di essere il punto in cui “vive tutto” e diventa il punto in cui “si fa inference” dentro un perimetro. Questo cambia drasticamente il rischio di regressioni: se domani cambi provider o versione, l’agente non “si reinventa” le regole, perché le regole non sono delegate al modello; e non “si reinventa” le azioni, perché le azioni sono vincolate da contratti e validazioni. È anche il prerequisito per una vera architettura **multi-modello**: puoi instradare ogni task verso il modello più adatto senza cambiare il resto del sistema. Invece di una scelta binaria (“questo è il modello”), hai una strategia di routing che può evolvere: modelli diversi per intent detection, reasoning, estrazione strutturata, riepiloghi, traduzione, con fallback quando un provider degrada o quando serve stare sotto un budget di costo/latenza. Ma soprattutto: puoi farlo senza riscrivere workflow e integrazioni, perché ciò che rende l’automazione “corretta” non è il modello in sé, è l’architettura che lo incapsula. In altre parole, la libertà dal lock-in non è solo la possibilità di cambiare modello: è la capacità di farlo **in modo sicuro**, con comportamento stabile, metriche sotto controllo e regressioni minimizzate. Ed è esattamente questo che serve quando l’AI diventa parte dei processi: non una demo che funziona oggi, ma un sistema che continua a funzionare domani anche se sotto cambiano i modelli.