Quello che avrei voluto sapere prima di costruire il mio primo AI Agent in n8n
Il mio primo AI agent mi ha richiesto circa quattro minuti per essere costruito.
Nodo Chat Trigger. Modello Gemini collegato. Premo Execute. Scrivo "Ciao" — ricevo "Ciao! Come posso aiutarti oggi?"
Ero convinto di aver finito. Ho detto alle persone che avevo costruito un AI agent.
Il giorno dopo sono tornato e ho scritto qualcosa che faceva riferimento alla nostra conversazione precedente.
L'agent non aveva la minima idea di cosa stessi parlando. Totale vuoto. Come incontrare qualcuno che ieri ti ha sorriso calorosamente e oggi ti guarda come se non ti avesse mai visto.
Paziente con amnesia. Reset completo. Zero memoria di qualsiasi cosa.
È lì che ho capito: quello che avevo costruito non era davvero un agent. Era una finestra di chat con un modello collegato.
Intelligente, certo. Ma stateless — senza stato. Nessuna memoria di ieri, nessuna consapevolezza del contesto, nessuna persistenza di alcun tipo.
Ogni messaggio che riceve è il primo messaggio che abbia mai ricevuto.
Risolvere quel singolo problema ha aperto tutta una serie di nuove domande. Cos'è esattamente il contesto? Dove risiede? Come fa l'agent a recuperarlo? Quanto se ne può passare prima che il modello vada in crisi?
Quello che segue è tutto quello che avrei voluto mi dicesse qualcuno prima di collegare quel primo nodo AI.
1. La Simple Memory non è memoria per la produzione
Quando aggiungi per la prima volta un Memory sub-node al tuo AI Agent, n8n ti offre la Simple Memory come impostazione predefinita. Funziona subito. L'agent ricorda quello che hai detto due messaggi fa, tiene il filo del contesto, sembra vera memoria.
Non lo è.
La Simple Memory memorizza la cronologia della conversazione nella RAM — nel processo in esecuzione, niente altro.
Nel momento in cui il tuo workflow si riavvia, la sessione termina, o n8n stesso si riavvia, ogni conversazione che stava tenendo svanisce. Nessun database. Nessun file. Niente scritto da nessuna parte. Evapora.
Questo conta nel momento in cui il tuo agent gestisce utenti reali.
L'utente A invia un messaggio. Il workflow gira, la Simple Memory tiene il contesto. L'utente A invia un follow-up tre minuti dopo — nuova esecuzione del workflow, la Simple Memory è vuota. L'agent si ripresenta. L'utente A chiude la scheda.
Per una vera persistenza, devi memorizzare la cronologia delle conversazioni in un database esterno e recuperarla all'inizio di ogni esecuzione del workflow. Postgres e Supabase sono le configurazioni più comuni. Il pattern è questo:
Il Workflow parte → recupera la cronologia della conversazione dell'utente dal DB → passa la cronologia all'AI Agent come contesto → l'agent risponde → aggiunge il nuovo messaggio al DB
Aggiunge nodi. Aggiunge tempo di configurazione. È la differenza tra una demo e qualcosa che funziona davvero.
2. Il tuo System Prompt fa tutto il lavoro di configurazione reale
La maggior parte delle persone scrive una riga nel campo del system prompt. Qualcosa tipo: "Sei un assistente utile."
Poi si chiede perché l'agent risponde a domande a cui non dovrebbe, va fuori tema o magari allucinato, chiama i tool nell'ordine sbagliato, o produce output in un formato che nessun nodo a valle riesce a interpretare.
Il system prompt non è un'etichetta che attacchi al modello. È l'unico posto in cui stai davvero configurando il comportamento dell'agent.
Le impostazioni del modello — temperature, top-p — aggiustano la casualità. Il system prompt definisce cosa fa l'agent, come risponde, cosa rifiuta o limita tramite guardrail, e in quale formato restituisce l'output.
Un system prompt che fa davvero il suo lavoro assomiglia più a questo:
Sei un agente di supporto clienti per [Azienda].
Il tuo compito: rispondi solo a domande su ordini, rimborsi e problemi con i prodotti.
Se qualcuno chiede qualcosa al di fuori di questi argomenti, reindirizzalo educatamente.
Rispondi sempre in questo formato JSON:
{
"message": "la tua risposta qui",
"category": "order | refund | product | other",
"escalate": true | false
}
Se non riesci a risolvere il problema, imposta escalate su true.
Non è lungo. Ma è specifico. Dice all'agent cosa fare, cosa non fare e cosa restituire. Ogni vincolo mancante è un comportamento che non hai definito — il che significa che il modello lo riempie come meglio crede.
Quando il tuo agent si comporta in modo imprevedibile, il system prompt è il primo posto in cui guardare.
3. L'agent andrà in loop se non lo limiti
Il nodo AI Agent ha un'impostazione chiamata Max Iterations. Controlla quante volte l'agent può chiamare un tool prima che n8n lo forzi a fermarsi e restituire una risposta.
Il valore predefinito è generoso. Troppo generoso per la maggior parte dei casi.
Ecco cosa succede senza un limite sensato: l'agent chiama un tool, ottiene un risultato, decide di aver bisogno di ulteriori informazioni, chiama un altro tool, si confonde, chiama di nuovo il primo tool, loop. A seconda del modello e dei tool collegati, questo può andare avanti per un po' prima che qualcosa fallisca in modo visibile.
A quel punto hai bruciato crediti API e il workflow è andato in timeout.
Imposta Max Iterations su qualcosa di ragionevole. Da cinque a dieci di solito è sufficiente per un agent ben delimitato.
Se il tuo agent ha genuinamente bisogno di più di dieci chiamate a tool per completare un singolo task, è un problema di design — non un numero da aumentare.
L'altra cosa importante da sapere: quando l'agent raggiunge il limite di iterazioni, non va in crash. Restituisce quello che ha a quel punto, che potrebbe essere incompleto. Costruisci i tuoi nodi a valle per gestirlo — non dare per scontato che l'output finale dell'agent sia sempre una risposta completa.
4. Le descrizioni dei tool sono istruzioni, non etichette
Quando aggiungi un tool al tuo AI Agent (un workflow tool, un HTTP Request, una funzione personalizzata) c'è un campo Description. La maggior parte delle persone scrive qualcosa di breve. "Recupera i dati del cliente." "Invia email."
Quella descrizione non è per te. È per il modello.
n8n passa il nome e la descrizione del tool all'LLM quando deve decidere quale tool chiamare. Il modello legge la tua descrizione e la usa per capire quando invocare quel tool, quale input inviare e se questo è il tool giusto per il passaggio corrente.
Una descrizione vaga produce una selezione dei tool inconsistente. Il modello indovina. A volte indovina giusto.
Una descrizione che funziona davvero dice al modello la condizione di attivazione e l'input atteso:
Usa questo tool quando l'utente chiede informazioni sullo stato del suo ordine o sulla spedizione.
Input: l'ID dell'ordine come stringa. Esempio: "ORD-12345".
Restituisce: stato attuale dell'ordine, data di consegna stimata e URL di tracciamento.
Tre frasi. Ora il modello sa esattamente quando chiamarlo, cosa inviare e cosa aspettarsi in risposta.
Riscrivere le descrizioni dei tuoi tool in questo modo è il modo più veloce in assoluto per rendere il comportamento dell'agent più consistente senza cambiare nient'altro.
5. Testa con input sbagliati, non con input corretti
La Chat UI di n8n è eccellente per il testing. Puoi inviare messaggi direttamente al tuo agent, osservare le chiamate ai tool, verificare l'output. Feedback veloce e reale.
Il problema: tu sai già cosa si aspetta il tuo agent. Scrivi messaggi puliti e completi.
Gli utenti reali no.
Prima di dichiarare un agent pronto, fallo girare con input per cui non è stato progettato:
- "sì fai la cosa" — nessuna intenzione chiara
- Un messaggio che fa riferimento a qualcosa di cui l'agent non ha contesto
- Un messaggio vuoto
- Una domanda completamente al di fuori del suo scope definito
Osserva cosa succede. Se chiama il tool sbagliato, va in loop, o restituisce una risposta malformata — è esattamente l'informazione di cui hai bisogno. Correggi il system prompt o le descrizioni dei tool prima che quel comportamento raggiunga qualcuno al di fuori della tua scheda del browser.
La Chat UI di n8n è una sandbox sicura. Usala per rompere le cose di proposito.
Cosa fare da qui
L'agent che costruisci il secondo giorno sarà migliore di quello che costruisci il primo giorno. Questa è la vera lezione. Nessuna di queste insidie è oscura — semplicemente non emergono finché non hai fatto girare il sistema almeno una volta e osservato come si rompe.