Agenti AI che collaborano su n8n: cosa funziona e cosa no
Più agenti che si passano il lavoro sembrano magia nelle demo e diventano un incubo in produzione. Le regole che uso per farli funzionare davvero.
Indice
- 01Perché n8n e non uno script
- 02Un agente, un compito, dei limiti
- 03L'umano va messo nel punto giusto
- 04Costi e fallback
01Perché n8n e non uno script
n8n dà tre cose che uno script perde subito: un'esecuzione visibile passo per passo, i tentativi di ripetizione gestiti dalla piattaforma e la cronologia di ogni run. Quando un flusso con LLM sbaglia, la domanda non è «cosa ha risposto il modello» ma «in quale nodo si è rotto e con quale input».
Uso n8n come orchestratore e non come luogo dove scrivere logica di business complessa: le parti pesanti restano in servizi interrogabili via API, versionati come tutto il resto.
02Un agente, un compito, dei limiti
L'errore più comune è un unico agente onnisciente con un prompt di tremila parole. Funziona finché non devi capire perché ha sbagliato. Preferisco più agenti con un compito ciascuno: uno estrae, uno classifica, uno riscrive nel tono richiesto, uno verifica il risultato contro criteri espliciti.
Ogni agente riceve solo il contesto che gli serve e restituisce una struttura dati, non prosa libera. Se l'output non rispetta lo schema, il nodo fallisce: meglio un errore chiaro di un testo plausibile e sbagliato.
ingest → extract (agent A) → classify (agent B)
→ rewrite (agent C) → validate (agent D, schema + regole)
→ [ok] publish → notify
→ [ko] human-in-the-loop03L'umano va messo nel punto giusto
Un umano che approva tutto è un collo di bottiglia; un umano che non approva niente è un rischio. Il punto giusto è l'azione irreversibile o visibile all'esterno: pubblicare, inviare, addebitare. Prima di quella soglia gli agenti possono lavorare da soli.
La conseguenza pratica è che il flusso deve poter restare in attesa senza perdere stato. Se un'approvazione che arriva dopo due giorni rompe l'esecuzione, non hai un flusso: hai una demo.
04Costi e fallback
Ogni nodo con un modello è una chiamata a pagamento: conviene misurare token e latenza per nodo, non per flusso, e usare il modello grande solo dove serve davvero. Spesso la classificazione regge con un modello piccolo e il costo scende di un ordine di grandezza.
Infine il fallback: se il provider è irraggiungibile il flusso non deve morire, deve degradare — mettere in coda, avvisare, o passare all'umano. È la stessa disciplina delle integrazioni verso sistemi esterni, applicata all'AI.
Hai un problema simile sul tuo sistema?
Parliamone