Come ho esteso un sito Drupal esistente con agenti AI?

Il titolare di un laboratorio di stampa 3D non riusciva più a stare dietro alle richieste dei clienti. Il tempo non finiva nelle stampe. Finiva nel ricopiare un indirizzo sul portale di GLS, nel ritrovare in una chat di WhatsApp una misura mandata giorni prima, nell'aprire lo slicer solo per sapere quanto dura una stampa. Con questo problema è venuto da me.

Così ho analizzato il flusso di lavoro del laboratorio, dal primo messaggio del cliente al pacco consegnato, e l'ho spezzato in dodici operazioni. Sono partito da quelle che si ripetono a ogni ordine, e per ognuna ho scelto la tecnologia adatta: un agente deterministico, un agente AI, un'app per Mac.

Oggi al titolare restano tre operazioni: disegnare il pezzo, avviare la stampa, controllare il risultato. Sono il suo mestiere.

Al centro c'è Drupal 11, il CMS che il laboratorio già usava con i clienti, e resta l'unica fonte di ordini e stati. Ciò che arriva a un cliente o al pubblico parte dopo un sì del titolare.

Cosa fa Drupal per un cliente?

Drupal qui fa un e-commerce particolare: raccoglie requisiti, più che vendere da un catalogo. Il cliente racconta cosa gli serve, e molti pezzi nascono su misura per lui e restano privati. Nella sua pagina segue i passi della lavorazione: quali pezzi sono già stampati, cosa manca, il pagamento e il tracking della spedizione.

Drupal fissa l'accordo: ciò che il cliente ha chiesto resta scritto con le sue immagini, e ogni richiesta nuova diventa una riga nuova con il suo prezzo. Il pagamento passa fuori da Drupal e lo registra il titolare.

Il modello dati regge tutto il resto: una richiesta è un nodo, ogni riga è un paragrafo, e il pezzo è un nodo condiviso fra più richieste. Prezzo, colore, quantità e note stanno sulla riga. Al 5 novembre 2026 Drupal conteneva oltre 150 richieste da più di 70 clienti, circa 700 righe d'ordine e quasi 400 pezzi.

Dove andava il tempo del laboratorio?

Ogni ordine attraversava dodici passi, e il titolare li copriva tutti da solo:

Il passo più lento era il primo. Per disegnare un pezzo servono misure, foto e risposte del cliente, e una richiesta incompleta si ferma prima del preventivo. Prezzo e accordi finali scivolavano spesso su WhatsApp, lontano da Drupal.

Con quale regola ho diviso i compiti?

Per ogni operazione mi sono chiesto cosa serve per farla bene, e la risposta ha deciso la tecnologia.

La regola mette l'AI dove serve linguaggio e un agente deterministico dove serve un risultato sempre uguale. Il resto del lavoro è integrazione: collegare programmi, macchine e servizi che esistevano già.

Chi fa cosa adesso?

Qui sotto vedi come il laboratorio gestiva le richieste prima e come le gestisce adesso. L'animazione parte da sola: con Riguarda la rivedi, con Velocità la rallenti.

Gli agenti girano su modelli locali, sul server del laboratorio. Ogni agente ha un ruolo, un compito e un limite scritto:

Accanto agli agenti lavora un'app per Mac, scritta in Swift. È un involucro sottile: apre le pagine di Drupal in una finestra e aggiunge solo i collegamenti con i programmi e le macchine del laboratorio. Quando Drupal cambia, l'app mostra già la versione nuova, senza reinstallarla.

• File del pezzo: si collega a Fusion 360 ed esporta STL e STEP sul pezzo in Drupal, che diventa l'unica fonte dei file.
• Tempi e impostazioni: passa il file a Bambu Studio o PrusaSlicer per lo slicing, il passaggio in cui il software di stampa trasforma il modello 3D nelle istruzioni per la macchina. Drupal salva tempo e parametri per colore, marca e materiale.
• Batch di stampa: prende i pezzi proposti da Sambuco, anche di ordini diversi con lo stesso filamento, li dispone sul piatto nello slicer e li manda alla stampante.
• Stato della stampa: mostra a che punto è ogni piatto.
• Pannello della segretaria: mostra i requisiti raccolti da Mora quando il titolare si siede a progettare.
• Spedizione: compila le pagine di GLS e del broker spedire.com con i dati dell'ordine, e il titolare controlla prima di confermare.
• Etichette: stampa il segnacollo sulla stampante di etichette e la bolla sulla stampante normale, con lo stesso comando per ogni corriere.
• Tracking: quando il corriere rilascia il codice, l'app lo prende e lo inserisce nell'ordine dopo la conferma del titolare, e il cliente lo riceve su WhatsApp e per email.
• Social: compila il reel per ogni canale e lo porta all'approvazione del titolare.

Sul server, il salvataggio di un STL genera da solo il video del pezzo, che serve ai social.

Al titolare restano il progetto in Fusion 360, l'avvio della stampa, il controllo della qualità, il materiale grezzo per i social e le approvazioni.

Quali scelte ho verificato con i fatti?

Approvazione a mano invece di una soglia. La soglia automatica sembrava la soluzione più comoda, e l'ho scartata dopo averla misurata: il classificatore, cioè il modello che decide di che tipo è un messaggio, accompagna ogni risposta con un punteggio di sicurezza da 0 a 1. Quel punteggio stava quasi sempre fra 0,8 e 0,95 anche quando la risposta era sbagliata, quindi non serviva a separare le risposte giuste da quelle sbagliate. Una proposta ha identificativo, contenuto intero, autore e scadenza. Se il testo cambia, l'approvazione decade. Fa eccezione un solo caso: i messaggi di spedizione a testo fisso, approvati una volta per tutti gli invii.

Il piano di produzione è deterministico. Sambuco ordina per data di consegna, stato di stampa e tempo. Un calcolo deterministico si controlla con un test, e qui serve quello.

Un agente deterministico instrada, il modello scrive. Drupal usa la sua suite AI, che separa il CMS dal modello. Un gateway come LiteLLM collegherebbe fornitori diversi, locali o in cloud, come Anthropic, OpenAI e Google Gemini. Ho valutato il suo modulo Drupal e l'ho lasciato fuori, perché non è coperto dalle security advisory di drupal.org. Il gateway è il server del laboratorio: Drupal parla solo con lui, e lui smista le richieste ai modelli. Lì cambio modello e regole della chat quando serve, senza toccare Drupal. Il prezzo è un po' di lentezza, accettata in cambio del controllo. All'inizio l'instradamento lo decideva il modello, e i modelli locali sbagliavano sempre sugli stessi casi. Ora un classificatore sceglie fra voci chiuse, un workflow instrada e il modello scrive dentro il passo assegnato.

WhatsApp dall'API ufficiale. Ogni invio di Mora ha un conteggio con il costo stimato, e il tetto iniziale è di 10 euro al mese: raggiunto il tetto, Mora si ferma e avvisa il titolare.

Spedizioni dalle interfacce già in uso. GLS e il broker spedire.com offrono API a pagamento o assenti per un laboratorio di queste dimensioni. L'app compila le stesse pagine che il titolare compilava a mano, con indirizzi presi dall'ordine, e l'errore di battitura sparisce.

Una sola fonte per i file. STL e STEP stanno sul pezzo. Il 3MF prodotto dallo slicing appartiene alla stampa, perché cambia con colore, marca, materiale e stampante.

Cosa succede quando un agente sbaglia?

Un modello sbaglia, e il sistema è costruito perché l'errore non arrivi al cliente. Ogni messaggio verso un cliente o verso il pubblico è una proposta, e parte solo con il sì del titolare. Il modello sceglie fra voci chiuse e scrive dentro il passo assegnato, e un agente deterministico controlla il formato di ogni sua risposta.

Quando il titolare corregge una proposta, la coppia fra testo sbagliato e testo corretto entra nella memoria RAG comune. Alla richiesta simile successiva l'agente ritrova quella correzione e la usa come esempio. Il modello resta lo stesso: cambia ciò che ricorda.

I casi su cui un agente ha sbagliato diventano prove fisse, da rilanciare a ogni cambio di modello o di istruzioni. Ogni decisione registra modello, richiesta, risposta e chi l'ha approvata, così si interviene su un caso preciso.

Perché Drupal sta al centro di tutto?

Drupal è la fonte di verità e il collettore di tutto il sistema. Il Drupal del laboratorio aveva già un modello dati solido, e per questo non l'ho riscritto: l'ho trasformato in una piattaforma, con una dashboard nuova per il titolare, una PWA per telefono e computer e un collegamento al sistema locale degli agenti. Dentro Drupal stanno i fatti approvati, fuori sta il lavoro in corso:

1. Ordini e stati esistono solo nel database Drupal.
2. Agenti e app passano dalle interfacce di Drupal, che applicano permessi e regole.
3. Una cache accelera una lettura, e in caso di differenza vale Drupal.
4. Se Drupal è irraggiungibile, l'agente lo dice e mostra solo ciò che sa di certo.

Il sistema locale gira su un server del laboratorio: piccoli servizi Python, modelli serviti da Ollama e una memoria RAG comune, da cui ogni agente legge storico dei clienti, schede e fascicoli dei pezzi. Drupal sta su un hosting condiviso, e la connessione con il server è chiusa su più livelli, non con un controllo solo: ogni chiamata porta un certificato client in mTLS, il proxy davanti ai modelli lascia passare due sole operazioni e al massimo 30 richieste al minuto, e indirizzo e certificati stanno nelle impostazioni dell'ambiente, fuori dalla configurazione esportata. Sulla riga d'ordine entra un solo campo nuovo, il numero del fascicolo.

Dashboard, PWA e app per Mac mostrano le stesse pagine di Drupal. Non esiste un'app mobile separata né un secondo programma da aggiornare: il titolare cambia una pagina in Drupal, e la versione nuova compare su telefono, computer e Mac.

Da dove partire con un sito Drupal esistente?

Si parte dalla filiera, prima che dalla tecnologia. Questo è l'ordine che seguirei di nuovo:

1. Scrivi ogni passo del lavoro, dal primo contatto alla consegna.
2. Per ogni passo chiediti cosa serve: un calcolo, del linguaggio, un programma o una macchina, oppure l'esperienza di chi fa il lavoro.
3. Assegna la tecnologia con quella risposta.
4. Metti un'approvazione su ogni passo che arriva a una persona.
5. Comincia dal passo in cui il lavoro si ferma, con esempi veri.
6. Aggiungi il passo successivo quando il primo regge.

Questo è il primo articolo di una serie in cinque parti. Le successive entrano nel dettaglio di WhatsApp, della PWA e dell'infrastruttura:

1. Come ho esteso un sito Drupal esistente con agenti AI (questo articolo)
2. La raccolta requisiti con un agente su WhatsApp
3. La PWA e il coordinatore come unico interlocutore
4. L'infrastruttura dietro Drupal
5. I numeri a progetto finito

Il metodo con cui ho scritto il codice è in Come lavoro con l'AI nello sviluppo.

Che cosa diventa un sito Drupal, quando lavora ogni giorno?

Un sito che racconta chi sei e cosa fai è il punto di partenza. Il valore arriva quando la stessa struttura diventa lo strumento che il titolare apre ogni mattina e lo alleggerisce delle cose che si ripetono. Con Drupal è stato possibile perché il modello dati c'era già: è bastato collegarlo al resto.

Questo progetto mi ha portato oltre il PHP di tutti i giorni. Gli agenti sono in Python, l'app per Mac è in Swift, e il linguaggio è diventato un dettaglio di implementazione. Conta la forma mentis dell'analisi: leggere un flusso di lavoro, spezzarlo in passi e scegliere per ognuno la tecnica giusta. Come riferimento ho usato paradigmi noti, quelli delle fonti qui sotto: workflow deterministici accanto agli agenti, la RAG come memoria comune, la sorveglianza umana su tutto ciò che arriva alle persone.

Lavori come questo cambiano alcuni mestieri, e il cambiamento arriva comunque, oggi o fra qualche anno. Preferisco accompagnarlo. Un'infrastruttura così è un supporto per chi fa del proprio mestiere un'arte: al titolare restano il disegno, la stampa e l'occhio sul pezzo finito, e il resto lo smistano gli agenti.

Fonti

• AI (Artificial Intelligence) (si apre in una nuova scheda), modulo Drupal
• AI Agents (si apre in una nuova scheda), modulo Drupal
• Building effective agents (si apre in una nuova scheda), Anthropic: workflow deterministici e agenti, e quando usare gli uni o gli altri
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (si apre in una nuova scheda), Lewis e altri, 2020: l'articolo che ha introdotto la RAG
• LLM06: Excessive Agency (si apre in una nuova scheda), OWASP Top 10 per le applicazioni LLM: perché un agente non decide da solo
• Articolo 14 dell'AI Act, sorveglianza umana (si apre in una nuova scheda)
• Ollama (si apre in una nuova scheda), per i modelli locali
• LiteLLM, fornitori supportati (si apre in una nuova scheda)
• Security advisory policy (si apre in una nuova scheda) di drupal.org
• WhatsApp Business Platform (si apre in una nuova scheda)