n8n 2.47: gli Agent hanno lo storico delle versioni
Con n8n 2.47.0, uscita il 3 novembre 2026 sul canale beta, gli Agent guadagnano lo storico delle versioni e una timeline di pubblicazione. In pratica puoi tenere in produzione una versione stabile mentre continui a modificare la bozza. Per chi mette in azienda un assistente che risponde su Slack o Telegram, questa è la differenza tra aggiornare a caso e aggiornare con controllo.
Cosa arriva con n8n 2.47
Prima il contesto sulle versioni. Secondo il changelog ufficiale di n8n, oggi la stable è la 2.46.6 e la beta è la 2.47.2. La 2.47.0 del 3 novembre introduce le novità di sostanza. La 2.47.2 del 4 novembre corregge l’installazione npm su tutte le piattaforme. Chi aggiorna solo alle stabili resta sulla 2.46.6, dove troverà già le credenziali personali nei progetti di team di cui ho scritto a fine ottobre.
Gli Agent di cui parlo qui non sono il nodo AI Agent dentro un workflow. Sono gli assistenti standalone del progetto (scheda Agents), ancora in Preview: hanno modello, istruzioni, tool, knowledge base e canali. Con la 2.47.0 n8n aggiunge lo storage delle versioni, la history di pubblicazione e la possibilità di pubblicare una versione salvata in modo indipendente dalla bozza. Lo dice il changelog GitHub, e la documentazione ufficiale lo spiega così: la bozza è dove lavori, la versione pubblicata è quella che risponde in chat, sui canali e sugli schedule. Ogni publish crea uno snapshot. Puoi ripristinare una versione precedente senza buttare il lavoro in corso.
Nella stessa release arrivano altre cose utili. Gli amministratori possono accendere o spegnere n8n Assistant (l’assistente che costruisce flussi e Agent da un prompt) con un interruttore in Settings e con la variabile d’ambiente N8N_INSTANCE_AI_ENABLED. Se non imposti nulla, su Enterprise l’Assistant resta spento, sugli altri piani acceso. La credenziale Postgres accetta certificati SSL propri (CA, chiave e certificato client). Il limite di upload per i file di knowledge degli Agent sale a 25 MB. Arrivano anche tool MCP per leggere i log di sessione degli Agent.
Un esempio dal magazzino
Immagina un’azienda di distribuzione con un Agent “Stato spedizioni” collegato a Telegram. L’Agent legge lo stato dal gestionale tramite un workflow tool, risponde ai magazzinieri e, se serve, apre un ticket. Oggi è in produzione la versione pubblicata lunedì. Martedì il responsabile logistica vuole aggiungere una regola: se il collo è in giacenza da più di 48 ore, l’Agent propone di richiamare il cliente.
Senza versionamento serio, ogni modifica alla bozza rischia di diventare produzione al prossimo publish frettoloso. Con lo storico e la pubblicazione indipendente puoi lavorare sulla bozza, provarla in Preview, pubblicare solo quando il comportamento è stabile, e in caso di risposte sbagliate tornare alla versione di lunedì. È lo stesso schema che già usiamo sui workflow (draft e published), portato sugli Agent. Per un team operativo che non può permettersi un assistente che “inventa” la procedura di reso, conta più di qualsiasi modello nuovo.
Il mio punto di vista
La direzione è quella giusta. Gli Agent senza history sono pericolosi in produzione: una modifica alle istruzioni o a un tool cambia il comportamento per tutti i canali collegati, e nessuno sa cosa c’era prima. Avere snapshot e timeline rende gli Agent gestibili come un pezzo di software, non come un prompt lasciato in un file.
I limiti restano chiari. Primo, gli Agent sono ancora in Preview: possono sbagliare e il comportamento può cambiare. Secondo, la 2.47 è beta. In produzione oggi io resterei sulla 2.46.6 e proverei la 2.47 su un’istanza di test, soprattutto se usi gli Agent o Postgres con SSL client. Terzo, il versionamento non sostituisce le policy: tool che scrivono sul gestionale o mandano email vanno comunque protetti con approval umana, come già consente n8n.
Cosa fare questa settimana
Se stai già costruendo Agent su n8n, monta una copia di test sulla 2.47.2, crea un Agent semplice, pubblica, modifica le istruzioni e ripubblica. Controlla che la timeline mostri entrambe le versioni e che tu possa tornare indietro. Se gestisci un’istanza self hosted, valuta anche se n8n Assistant deve stare acceso o spento per policy, e documenta la scelta in Settings o via N8N_INSTANCE_AI_ENABLED. Infine, prima di promuovere un Agent in produzione, chiediti quale versione è live e chi è autorizzato a pubblicarne una nuova.
Se il tuo team vuole costruire Agent n8n con bozza, pubblicazione e controllo delle versioni (senza lasciare tutto a un unico “esperto” interno), scrivimi. Dai un’occhiata ai percorsi di formazione e progettiamo insieme un modulo su automazione e agenti adatto al vostro contesto.