La risposta diretta
Per creare agenti AI che reggono in produzione servono quattro componenti: strumenti (le azioni che l’agente può eseguire), modello (il cervello che decide), memoria (il contesto che persiste) e guardie (i controlli che bloccano gli errori silenziosi). L’ordine giusto è questo, non quello inverso. Chi parte dal modello costruisce un agente che ragiona bene ma non fa niente di utile.
Perché l’ordine di costruzione conta quanto le parti stesse
La maggior parte di chi comincia a creare agenti AI apre il playground, sceglie GPT-4o o Claude, scrive un prompt elaborato e poi si chiede perché l’agente non combina nulla. Il problema non è il modello. Il problema è che il modello non ha niente da fare.
Un agente AI è un loop: riceve un input, decide un’azione, esegue l’azione, osserva il risultato, decide il passo successivo. Se le azioni non esistono — cioè se gli strumenti non sono collegati — il loop si chiude su se stesso e l’agente produce solo testo. Testo che descrive cosa farebbe, se potesse fare qualcosa.
Questo articolo copre le quattro parti nell’ordine in cui ha senso costruirle, con l’errore tipico di ciascuna. Alla fine sai esattamente dove mettere le mani quando vuoi creare agenti AI che girano da soli senza sorvegliarli a ogni ciclo.
Prima parte: gli strumenti — il motivo per cui l’agente esiste
Gli strumenti sono le azioni che l’agente può eseguire nel mondo reale. Leggere righe da un foglio Google, creare un contatto in GoHighLevel, mandare un messaggio su Slack, fare una chiamata HTTP a un’API esterna. Senza strumenti l’agente è un modello linguistico con un prompt lungo: risponde, non agisce.
L’errore tipico qui è costruire gli strumenti troppo generici. Un tool che si chiama «gestisci CRM» non esiste: esiste un tool che crea un contatto, uno che aggiorna un campo, uno che legge le note. Più il tool è atomico, più l’agente sa quando usarlo e meno si inceppa nel decidere cosa fare.
Il metodo che funziona è partire dalla lista delle azioni umane che vuoi sostituire. Scrivi ogni azione come un verbo più un oggetto: «crea contatto», «invia email», «legge riga». Quella lista è la mappa degli strumenti da costruire prima ancora di toccare un modello.
Come si collegano gli strumenti in pratica
In n8n ogni tool è un nodo che l’agente può chiamare durante il loop. In Make, gli strumenti sono i moduli che il layer AI orchestra. La logica è la stessa: definisci l’azione, definisci gli input che riceve, definisci cosa restituisce. Il modello poi decide quando e come chiamarli — ma solo se esistono già.
Se stai costruendo il tuo primo agente e vuoi capire da dove partire senza scrivere codice, questo articolo sulle opzioni no-code copre i tool più accessibili con i loro limiti reali.
Seconda parte: il modello — il cervello che sceglie quale strumento usare
Solo dopo aver definito gli strumenti ha senso scegliere il modello. Non perché il modello non conti — conta moltissimo — ma perché la scelta giusta dipende da cosa deve fare. Un agente che legge email e classifica ticket ha bisogni diversi da uno che fa ricerca multi-step e sintetizza fonti.
I due parametri che guidano la scelta sono la capacità di seguire istruzioni complesse e il costo per token. Un modello più potente sbaglia meno nel selezionare lo strumento corretto, ma costa di più a ogni ciclo. Se l’agente gira centinaia di volte al giorno, la differenza di costo è reale.
L’errore tipico è scegliere sempre il modello più recente e più costoso perché «tanto è il migliore». Un agente di classificazione che deve rispondere «supporto / vendite / altro» non ha bisogno di reasoning avanzato. Ne ha bisogno uno che deve pianificare una sequenza di azioni su dati ambigui.
Reasoning effort e quando serve davvero
Alcune piattaforme — OpenAI agent builder inclusa — permettono di regolare il «reasoning effort», cioè quanto il modello si ferma a ragionare prima di rispondere. Su task semplici e ripetitivi, abbassarlo riduce la latenza e il costo senza perdere qualità. Su task che richiedono pianificazione multi-step, abbassarlo produce errori che non capisci subito da dove vengono.
La regola pratica: testa con effort basso, misura l’errore, alza solo se serve. Non partire dall’alto per sicurezza.
Terza parte: la memoria — il contesto che sopravvive al ciclo
Un agente senza memoria ricomincia da zero a ogni invocazione. Per un task isolato va bene. Per qualsiasi flusso che si estende su più sessioni, più utenti o più giorni, è un problema strutturale.
Ci sono tre tipi di memoria che un agente può usare. La memoria di sessione (chat history) conserva i messaggi dello scambio corrente: utile per un agente conversazionale, inutile tra run separati. La memoria esterna — un database, un foglio, un vector store — persiste tra sessioni e permette all’agente di recuperare informazioni su utenti o contesti precedenti. La memoria contestuale del prompt è il sistema prompt stesso: le istruzioni fisse che l’agente porta sempre con sé.
L’errore tipico è usare solo la chat history e chiamarla «memoria». L’agente ricorda la conversazione corrente, ma non sa niente del cliente che aveva risposto ieri, né del dato che aveva scritto sul CRM tre ore prima.
Quando la memoria diventa un problema di privacy
Ogni dato che persisti fuori dal modello è un dato che devi gestire. Se l’agente scrive informazioni su utenti in un database esterno, quelle informazioni vanno trattate con le stesse regole di qualsiasi dato personale. Non è un dettaglio tecnico: è il punto dove molti agenti in produzione creano debiti legali silenziosi. Prima di collegare un vector store con dati utente, chiediti chi può leggere quel database e per quanto tempo i dati restano lì.
Per capire come la memoria si integra con protocolli come MCP, questo articolo sul Model Context Protocol in n8n mostra la meccanica concreta.
Quello che nessuno dice
Un agente senza guardie esegue sbagliato con la stessa sicurezza con cui esegue giusto
Non rallenta, non dubita, non ti chiama. Produce. E se il loop è rotto, produce errori alla stessa velocità con cui produrrebbe risultati corretti.
- Silenzio del sistema — non è salute, è il sintomo che qualcosa si rompe senza segnalarlo
- Guardie di output — valida il formato e il valore prima di passarlo allo step successivo
- Fallback espliciti — decidi tu cosa succede quando lo strumento non risponde, non lasciarlo all’improvvisazione del modello
Quarta parte: le guardie — il motivo per cui l’agente regge in produzione
Le guardie sono i controlli che rendono l’agente affidabile quando qualcosa va storto. E qualcosa va sempre storto: l’API esterna risponde 200 ma restituisce un corpo vuoto, il modello produce un JSON malformato, lo strumento scrive sul campo sbagliato del CRM perché il nome del campo è cambiato.
Senza guardie l’agente continua. Esegue il passo successivo con un dato corrotto, scrive sul record sbagliato, manda l’email con il nome del placeholder al posto del nome reale. Nessun errore in console. Nessun alert. Il sistema risponde 200 e butta il problema a valle, dove lo trovi giorni dopo — o non lo trovi mai.
Le guardie si costruiscono in tre punti: sull’output del modello (il formato è quello atteso?), sull’output degli strumenti (lo strumento ha davvero scritto quello che doveva?) e sul loop (l’agente non sta girando all’infinito senza uscire?).
L’errore tipico: le guardie come ultimo pensiero
Il pattern più comune è questo: costruisci l’agente, lo testi su casi felici, funziona, lo metti in produzione. Le guardie le aggiungerai dopo. Poi non le aggiungi mai, perché l’agente «sembra funzionare».
Il silenzio dei sistemi non è salute. È il sintomo. Le guardie vanno progettate insieme agli strumenti, non attaccate sopra quando arriva il primo bug inspiegabile.
Un’automazione senza guardie non è finita. È una macchina che aspetta il momento sbagliato per rompersi in silenzio.
Il confronto tra i quattro approcci di costruzione
| Ordine di costruzione | Punto di partenza | Problema tipico | Quando usarlo |
|---|---|---|---|
| Strumenti → Modello → Memoria → Guardie | Lista delle azioni umane da sostituire | Nessuno strutturale, è l’ordine corretto | Sempre |
| Modello → Strumenti → Memoria → Guardie | Scelta del LLM | Agente che ragiona ma non esegue | Mai in produzione |
| Prompt → tutto il resto | System prompt elaborato | Prompt che compensa mancanze strutturali | Solo per prototipi usa e getta |
| Strumenti → Modello → Guardie (senza memoria) | Task isolati, nessuna persistenza | Agente che dimentica tra sessioni | Task one-shot senza contesto utente |
Make come layer di esecuzione
Make dà le braccia all’agente: è il pezzo che esegue davvero le azioni che il modello decide
Nei primi giorni l’uso più produttivo è collegare un trigger, un’azione AI e uno strumento reale — un foglio, un CRM, una notifica — per vedere il loop completo girare su dati veri.
- Fase 1 — crea uno scenario con trigger webhook e un modulo AI: vedi subito cosa decide il modello
- Fase 2 — aggiungi uno strumento reale come output: scrivi su un foglio o crea un contatto
- Fase 3 — inserisci un filtro che blocca l’output se il formato non è quello atteso: è la tua prima guardia
Apri il piano gratuito di Make →
Link di affiliazione: se ti iscrivi da qui io prendo una commissione, tu paghi uguale. Lo linko perché ci lavoro dentro ogni giorno.
Come creare agenti AI che reggono: l’ordine in sintesi
L’ordine non è una preferenza stilistica. È una questione di dipendenze logiche. Non puoi scegliere il modello giusto se non sai quali strumenti deve orchestrare. Non puoi progettare la memoria se non sai quali dati gli strumenti producono. Non puoi costruire guardie efficaci se non conosci i punti di rottura di strumenti e modello.
Chi parte dal modello costruisce un agente che impressiona in demo e si rompe in produzione. Chi parte dagli strumenti costruisce qualcosa che fa una cosa concreta, poi la fa meglio, poi regge il volume.
Per approfondire cosa sono gli agenti AI prima di costruirne uno, questo articolo parte dalla definizione senza hype. Se invece stai valutando quali agenti AI esistono già pronti all’uso, questa pagina sugli agenti AI gratis mostra dove arrivi prima di incontrare i limiti reali.
I migliori agenti AI che vedo girare non sono i più sofisticati. Sono quelli costruiti nell’ordine giusto, con guardie vere e strumenti atomici. Il modello fa il resto.
Domande frequenti
Qual è la differenza tra uno strumento e un’azione in un agente AI?
Sono la stessa cosa con nomi diversi a seconda della piattaforma. Uno strumento è una funzione che l’agente può invocare durante il suo loop: fa una cosa specifica, riceve input definiti, restituisce un output. In n8n si chiama tool, in OpenAI function calling si chiama function. Il concetto è identico.
Si può creare agenti AI gratis?
Sì, con limiti precisi. n8n self-hosted è gratuito ma richiede un server. Make ha un piano gratuito da 1.000 operazioni al mese. I modelli AI hanno costi per token che crescono con il volume. Questo articolo spiega dove si fermano le opzioni gratuite.
Quante guardie servono a un agente AI?
Almeno tre: una sull’output del modello (il formato è valido?), una sull’output degli strumenti (l’azione è andata a buon fine?), una sul loop (l’agente non sta girando all’infinito?). Oltre queste tre, dipende da quanto è critico il task e da quali API chiami.
La memoria è indispensabile per creare agenti AI funzionanti?
Dipende dal task. Per un agente che classifica email in arrivo una per una, no. Per un agente che gestisce la relazione con un cliente nel tempo, sì. La regola pratica: se l’agente deve sapere cosa è successo in una sessione precedente, serve memoria esterna. Altrimenti basta la chat history della sessione corrente.
Trasparenza: in questo articolo c’è un link di affiliazione. Se ti iscrivi da lì io ricevo una commissione, per te non cambia niente. Linko solo strumenti che uso in produzione.
