Ogni sistema che ho costruito è partito da un numero che il business voleva spostare: ticket al giorno, lead al mese, siti al mese, minuti alla prima risposta. L'architettura segue il numero, non il contrario.

Prompt, retrieval, orchestrazione, integrazioni, server, sicurezza, documentazione. Se gira in produzione è mio finché non è monitorato, testato e consegnato con i documenti di cui ha bisogno chi viene dopo.

Valutazioni Langfuse su retrieval e risposte, CSAT, un confronto di ogni nuova versione del flusso con la precedente prima del rilascio, e un ciclo settimanale di miglioramento sulle conversazioni reali. Un punteggio RAG passato da meno di 0,6 a 0,9 è il tipo di prova che cerco.

Prima di costruire guardo il miglior prodotto della categoria, Intercom per il widget di supporto, Zendesk per il CRM, e scrivo cosa significa batterlo per questo cliente. Poi i blocchi, le milestone e i test di QA seguono quella lista.

Circa 50 operatori di supporto gestivano a mano più o meno 4.000 ticket al giorno, con picchi di oltre cento conversazioni in cinque-dieci minuti. Sotto carico la prima risposta arrivava fino a 18 minuti dopo e la soddisfazione dei clienti era ferma a 2,5 su 5. Ogni ticket, anche il più banale, costava tempo umano, e le conoscenze necessarie per rispondere erano sparse tra il CRM e anni di storico dei messaggi. Il brief: un widget che risolva da solo la maggior parte dei ticket, nella lingua del cliente, e lasci agli operatori solo i casi che richiedono giudizio. Il benchmark che mi sono dato prima di costruire era Intercom.

Un widget di chat sul sito del cliente, distribuito tramite Google Tag Manager, che capisce la richiesta in qualsiasi lingua, controlla l'account del cliente quando è autenticato, risponde da una knowledge base costruita sul CRM e sullo storico dei messaggi del cliente stesso, e passa i casi complessi a un operatore in Zendesk con l'intera trascrizione e il contesto dell'account allegati. n8n orchestra i flussi principale, di escalation e di reporting; LangGraph esegue la logica ciclica per intento, così il grafo decide passo dopo passo se rispondere, chiedere, verificare o fare escalation. Ogni agente ha il proprio prompt, GPT-4o mini come modello principale e Gemini 2.5 tramite OpenRouter come fallback. Pinecone contiene la knowledge base, MongoDB la memoria condivisa, Redis la cache. Ho configurato e messo in sicurezza i server personalmente: tutto gira in Docker sull'infrastruttura del progetto, con monitoraggio sui server e su ogni nodo n8n, così i bug emergono prima che il business se ne accorga.

• Un prompt, un modello principale e un modello di fallback per ogni agente. Il widget stesso ha una versione di fallback per quando il percorso AI non è disponibile.
• GPT-4o mini per costi e latenza: risposta media ~3 s, conversazioni lunghe entro circa 7 s, picco 9 s.
• La memoria condivisa in MongoDB alimenta un ciclo settimanale di miglioramento sul traffico reale: qualità delle risposte, prompt, CSAT, sicurezza dell'LLM.
• Ogni nuova versione di un flusso viene confrontata con la precedente prima del rilascio, nodo per nodo, così i cambiamenti di comportamento si intercettano prima che li vedano i clienti.
• Vision e OCR: un cliente invia una foto, per esempio una ricevuta; i dati vengono estratti, salvati in MongoDB e usati dagli agenti.

• Server costruiti e messi in sicurezza da zero; il percorso dei dati tra orchestratore, server e browser è protetto end to end.
• Penetration test eseguiti con agenti che ho costruito con regole basate sul modello dei permessi, test grey-box su API, latenza e punti di ingresso dell'infrastruttura, revisione del team di sicurezza interno e un test black-box da parte di un'azienda esterna. Ogni finding corretto da me.
• Difesa dalla prompt injection e controllo di ciò che arriva al modello; i dati sensibili non lasciano il perimetro senza un motivo.

• Progetto in solitaria, più di sei mesi fino al rilascio, diviso in blocchi: ogni blocco consegnato con il proprio QA, monitoraggio e documentazione.
• Tutte le automazioni versionate su GitHub con pipeline CI/CD.
• Consegne finali: documentazione delle API, un playbook per il team di customer service e il documento tecnico di progetto.

Il team di supporto di 50 persone non è stato tagliato. È stato formato sul nuovo flusso e in parte offerto ad altre aziende come servizio, così il business ha trasformato un centro di costo in una nuova linea di ricavi.

Migrazione a Qwen 3 da Hugging Face con Qdrant, costruita con i team ML e DevOps, per privacy, latenza, controllo e la possibilità di migliorare il modello. Il modello locale fa anche da filtro sui dati inviati agli LLM esterni. Fine-tuning in preparazione, poi lo stesso modello servirà i team interni e il widget stesso.

I brand avevano bisogno di decine di siti web ogni mese per crescere in visibilità e portare traffico alla pagina principale: siti satellite intorno a uno o due brand, ciascuno abbastanza specifico da essere indicizzato e letto. Non c'era un team di contenuti per ricercarli, scriverli, progettarli, illustrarli e costruirli, e ogni sito doveva essere abbastanza specifico da essere indicizzato e abbastanza economico da farne decine al mese.

Una pipeline di agenti Hermes, self-hosted sul server aziendale, con un agente dedicato alla ricerca, uno allo scraping e alla composizione, uno al design, e uno script finale che pubblica. Due vie d'ingresso. Da un URL di esempio: gli agenti ricercano e scrapano un sito simile e ne compongono uno nuovo ispirato a quello. Da zero: la richiesta entra via MCP da Claude Code o Codex, la ricerca gira su Perplexity e sull'Anthropic API, il sistema scrapa ciò che l'operatore ha chiesto, poi conduce una breve intervista per raccogliere i fatti che solo un umano conosce, e costruisce il sito. GPT-6 Astra genera le immagini. Un clic clona un sito con un design leggermente diverso, o completamente diverso. Un database di ogni esecuzione cresce con l'uso e rende la seconda modalità migliore nel tempo. L'output è HTML statico, esportato e distribuito sui server del cliente tramite lo script DevOps.

I template danno lo stesso sito ogni volta, e i motori di ricerca lo sanno. Gli agenti ricercano l'argomento, intervistano l'operatore e scrivono per quell'argomento, così ogni sito è specifico, leggibile e indicizzabile. Il costo resta intorno ai cinque euro perché i passaggi costosi, ricerca e immagini, sono messi in cache nel database delle esecuzioni e riutilizzati.

• Ricerca delle keyword e mappatura keyword-pagina; title tag e meta description; gerarchia H1, H2, H3.
• URL puliti, tag canonical, sitemap.xml, robots.txt; link interni.
• Alt text e immagini leggere e ottimizzate per il crawling; Core Web Vitals; mobile first.
• Dati strutturati in schema.org JSON-LD; Open Graph.
• GEO, Generative Engine Optimization: sezioni FAQ e llms.txt perché i motori di ricerca AI possano leggere e citare il sito; hreflang per i siti multilingua.

Circa cento siti al mese, cinque-dieci minuti ciascuno, intorno ai cinque euro per sito. I siti sono satelliti di uno o due brand e portano traffico alla pagina principale del brand; il traffico si misura a livello di brand.

Supporto, vendite e management lavoravano su strumenti separati e vedevano lo stesso cliente da angolazioni diverse. Gli eventi di business, segnali di frode, pagamenti e rimborsi, account bloccati, attività di affiliati e influencer, arrivavano alle persone in ritardo, tramite report, invece che nel momento in cui accadevano. Il brief: una sola piattaforma per tutti e tre i team, con Zendesk come benchmark da battere, costruita sui server dell'azienda.

Una sola piattaforma per supporto, vendite e management: gli stessi clienti, alert in tempo reale, voce, SMS e Telegram da un unico schermo, una knowledge base in stile Notion integrata nel prodotto, analytics su AWS e Tableau, e un livello AI che instrada le richieste e risponde dalla knowledge base. Architettura definita insieme a DevOps, al reparto sviluppo e al PM e Quality Manager del cliente; microservizi Kubernetes sui server aziendali, un servizio per motore, front end interamente in TypeScript con parti in Java. Guido tre AI engineer: sprint di due settimane con una riserva di circa dieci ore per le correzioni urgenti, test di QA alla fine di ogni milestone rispetto al benchmark, miglioramenti in asincrono, gestione dei blocchi, problem solving quotidiano con Customer Service, Quality Manager e QA manager.

• Backend e front end.
• Gestione accessi: ruoli e permessi.
• Area di lavoro per gli operatori del supporto.
• Analytics collegate ad AWS e un'area di lavoro Tableau.
• Alert di business integrati nel CRM dai dati di reparto su AWS.
• Alert in tempo reale su Kafka, costruiti con un ML engineer.
• Knowledge base integrata, voce e SMS tramite Voiso, Telegram per la comunicazione con i clienti.

Blocchi con milestone; un test di QA alla fine di ogni milestone e un confronto con il benchmark; miglioramenti gestiti in asincrono; blocchi rimossi ogni giorno. Sprint di due settimane per engineer, mentalità Agile e una piccola riserva in ogni sprint per ciò che si rompe.

Un agente con routing intelligente, una knowledge base con ricerca semantica e un'estensione browser dell'agente che esegue i compiti di routine per gli operatori. Il CRM serve customer service, management e vendite, quindi lo stesso agente lavora sulle richieste di supporto e sulla produzione di lead.

Un LLM on-premise (Qwen 3) con accesso completo ai dati del CRM e alla piattaforma interna dei dati cliente; un agente con la propria knowledge base che aiuta il supporto a rispondere più in fretta; l'estensione browser con cui il supporto imposta azioni che vengono eseguite automaticamente per il cliente.

I dipendenti facevano a HR, Finance e Legal le stesse domande di routine ogni giorno: giorni di ferie, limiti di spesa, quale modello usare. Ogni risposta toglieva tempo a chi doveva darla, e le conoscenze vivevano in documenti che nessuno apriva. Sul sito aziendale i visitatori non avevano self-service né un modo semplice per lasciare una richiesta. L'azienda viveva già in Microsoft 365, quindi anche la risposta doveva vivere lì.

Un assistente per reparto, nel canale Teams dove le persone già lavorano. L'agente HR contiene tutta la conoscenza HR condivisa, risponde alle domande frequenti e registra tutto; Finance e Legal seguono la stessa logica. Agenti costruiti in Microsoft Copilot Studio, ancorati ai documenti SharePoint, con Azure OpenAI per i modelli e Databricks per log, condivisione dei dati e miglioramento continuo. Lo stesso stack alimenta un assistente sul sito aziendale: informazioni generali, collegato direttamente a SharePoint e Databricks, con un passaggio lead che chiede al visitatore di inviare la richiesta via email quando la conversazione mostra un'intenzione. Costruito subito dopo il widget di supporto, da solo, per uno stakeholder interno di Acrh Software.

Il cliente viveva già in Microsoft 365: Teams, SharePoint, Azure. Costruire dove le persone già si trovano ha eliminato l'attrito di adozione; nessuno ha dovuto imparare un nuovo strumento. L'ancoraggio a SharePoint mantiene ogni risposta con la sua fonte e verificabile, e Databricks conserva i log che alimentano il ciclo di miglioramento.

• HR: ferie, policy, domande di onboarding, con dietro tutta la conoscenza HR condivisa.
• Finance: regole di spesa, limiti, procedure.
• Legal: modelli, versioni, quando una clausola richiede revisione umana.
• Ogni conversazione registrata, così i reparti vedono cosa chiedono davvero le persone e correggono i documenti, non solo le risposte.

L'assistente prima risponde e chiede la richiesta via email solo quando il visitatore mostra un'intenzione d'acquisto. I lead arrivano alle vendite con la conversazione allegata, così la prima risposta umana conosce già il contesto.

I lead arrivavano via email e venivano letti in ritardo. Cinque sales manager passavano la giornata su qualificazioni di routine, copiando nomi e numeri di telefono, e perdevano acquirenti già passati all'agenzia successiva. Il cliente voleva un'innovazione visibile sul sito e, soprattutto, lead che arrivino puliti e ricevano risposta immediata.

Un widget conversazionale integrato nel sito del cliente con tutte le informazioni sugli immobili e sugli edifici in vendita. Il codice e il prompt del bot vivono su Replit, OpenAI è il modello, la conversazione è disegnata in Voiceflow, Airtable è il CRM, Make esegue le automazioni. Il widget raccoglie nome, telefono ed email dell'acquirente, il campo chiave. Flusso uno: nel momento in cui un lead viene salvato, il manager riceve una notifica Telegram con il lead. Flusso due: l'acquirente riceve un'email personalizzata con le disponibilità in linea con la sua richiesta e un pulsante per prenotare un appuntamento. Flusso tre: il clic apre una richiesta su Google Calendar e Meet del manager, il manager accetta, l'acquirente riceve la conferma. I messaggi proattivi partono quando il visitatore clicca pulsanti chiave, cosa che ha alzato i lead di altri cinque punti.

L'email era il campo chiave: il follow-up con le case in linea con la richiesta vendeva mentre il manager era occupato. I messaggi proattivi sui clic chiave, calcolatore del mutuo, planimetria, hanno aggiunto da soli cinque punti di lead. E i manager hanno smesso di copiare dati a mano, perché arrivavano già strutturati.

• Automazioni di contenuti e auto-posting su Facebook, Instagram, VK e X tramite Make, per l'agenzia e per i clienti.
• L'intero modo di lavorare dell'agenzia ricostruito in ClickUp mentre il team cresceva da 50 a 200 persone: integrazioni HR con onboarding e offboarding automatici, analytics dal CRM clienti dentro ClickUp, conversazioni strutturate con ruoli e permessi, un task manager e una piattaforma su misura per pianificazione e riunioni.
• Più di 20 siti web per clienti costruiti end to end in JavaScript, Next.js e Astro, con connessioni API al CRM, distribuiti sui server dei clienti.

I clienti dovevano rispondere ai propri clienti a qualsiasi ora e qualificare ogni contatto senza assumere personale. Le conversazioni schizzavano con ogni campagna pubblicitaria, e un messaggio perso era un cliente perso. Era il progetto più richiesto in agenzia, e ogni cliente aveva uno stakeholder diverso, un canale diverso e una definizione diversa di buon lead.

Un bot che parte da una parola chiave su WhatsApp, Instagram o Telegram, esegue un flusso definito con un LLM all'interno, qualifica il contatto con un prompt preciso scritto per quel cliente e lo archivia in un CRM su misura costruito in Google Apps Script, dove il lead passa da freddo a tiepido a caldo sui passaggi completati. I bot servivano sia il customer service, parlando direttamente con l'utente finale, sia il supporto al team del cliente. Dal 2022 gli stessi clienti hanno avuto agenti vocali: una receptionist vocale e un agente HR che raccoglie i dati dei candidati, costruiti su Twilio ed ElevenLabs; agenti outbound su Vapi e Retell che chiamano i lead dalle liste del cliente e fanno le domande di qualificazione. Orchestrazione in Make e n8n con codice su misura; modelli di OpenAI, Anthropic e OpenRouter.

• Un prompt per cliente, con i criteri di qualificazione scritti come domande esplicite, mai lasciati al giudizio del modello.
• Gli stadi della pipeline cambiano solo sui passaggi completati: un lead non può diventare caldo senza recapiti.
• Ogni bot gira 24/7; quando una campagna fa un picco, le conversazioni crescono senza che un canale resti scoperto.

• Receptionist vocale su Twilio ed ElevenLabs: risponde, instrada, prende il messaggio.
• Agente vocale HR: raccoglie i dati dei candidati in una conversazione che segue il prompt.
• Agenti outbound su Vapi e Retell: chiamano i lead, fanno le domande di qualificazione, passano il risultato al CRM.
• Un agente Sales, e un agente Finance che elabora dati interni, sulla stessa orchestrazione.

Gruppo automotive a Roma, più di 1.000 dipendenti, una flotta di circa 200.000 veicoli. Dashboard KPI in Power BI costruite su SQL, estrazioni AWS e API interne con il reparto IT, per tutto il reparto vendite e per il management con alert. Stock fermo ridotto del 25% perché i dati si muovevano più in fretta e l'usato si vendeva prima. Controllo KPI e fatture per un fornitore da due-tre milioni di euro l'anno. Quattro nuovi analisti inseriti e formati.