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