La maggior parte delle aziende incontra gli agenti AI per la prima volta attraverso uno strumento che già usa. Zapier ha aggiunto AI Agents alla sua piattaforma. Make ha seguito con le proprie funzionalità di scenario agentivo. Entrambi sono genuinamente utili — e entrambi hanno modalità di errore che non sono evidenti finché non stai gestendo un processo che conta davvero.
Questa è una valutazione d’acquisto, non una recensione di prodotto. La domanda non è quale piattaforma abbia una UX migliore. La domanda è: dati gli obiettivi di business del processo che vuoi automatizzare, quale livello di strumento è la scelta razionale?
Perché “agenti in ogni SaaS” complica la decisione d’acquisto
Le piattaforme di automazione che retrofittano gli “agenti AI” nel loro prodotto creano un problema di nomenclatura. La parola “agente” ora copre tutto: da un semplice prompt GPT che riformatta una voce Notion, a un sistema multi-step con stato che instrada, decide e agisce su API esterne con logica di recovery.
Le piattaforme non mentono — ma l’etichetta nasconde enormi differenze in affidabilità, controllo dei dati, struttura dei costi e gestione degli errori. Un workflow che pubblica un aggiornamento LinkedIn quando un blog va online non appartiene alla stessa categoria di un agente che qualifica i lead in entrata, consulta il CRM, redige una risposta personalizzata e registra il risultato. Trattarli come equivalenti porta a scegliere lo strumento sbagliato per il lavoro sbagliato.
Le tre dimensioni che contano davvero per questa decisione:
- Economia per esecuzione — quanto costa ogni run, e come scala?
- Modalità di errore — come si comporta il sistema quando una chiamata LLM va storta, un’API di terze parti è lenta, o i dati in ingresso sono disordinati?
- Controllo dei dati e osservabilità — dove vanno i tuoi dati, e riesci a vedere cosa ha fatto davvero l’agente?
Economia per esecuzione: dove i costi di piattaforma diventano imprevedibili
Zapier e Make addebitano per operazione o consumo di task. Un semplice Zap con un trigger e due action step costa due task — i trigger sono sempre gratuiti nel modello di fatturazione di Zapier. Un run “agente” che chiama un LLM, interroga un foglio di calcolo, invia un messaggio Slack e aggiorna un record CRM potrebbe consumare da dieci a trenta operazioni a seconda di come è strutturato — e questo prima di considerare i costi dei token LLM, che le piattaforme tipicamente trasferiscono con un markup.
Per un processo a basso volume e basso rischio — diciamo, 50 run al mese con input prevedibili — i prezzi di piattaforma sono del tutto ragionevoli. Stai pagando per la velocità di deployment e zero overhead infrastrutturale. È un valore reale.
L’economia cambia quando:
- Il volume cresce oltre poche centinaia di run significativi al mese
- Ogni run prevede più chiamate LLM (retrieval, classificazione, generazione sono chiamate separate nella maggior parte dei pattern agentivi)
- Hai bisogno di logica di retry, che riesegue le operazioni e moltiplica il consumo
Un esempio concreto: un team di vendita di 10 persone che usa un agente basato su Zapier per qualificare e instradare 500 form fill in entrata al mese, con ogni run che tocca cinque operazioni e due chiamate LLM, potrebbe consumare 5.000+ task al mese più i costi LLM pass-through. A quel volume, un agente custom che gira su una cloud function costa una frazione per run — il costo variabile è solo la spesa diretta per le API LLM, tipicamente ben sotto $0,01 per run di qualifica usando i modelli mid-tier attuali (a titolo di riferimento, GPT-4o mini è prezzato a $0,15 per milione di token in input e Claude Haiku a $0,25 per milione di token in input a metà 2026).
Il punto di crossover varia per caso d’uso, ma per la maggior parte dei processi agentivi significativi, arriva prima di quanto i compratori si aspettino.
Come falliscono gli agenti di piattaforma — e perché è difficile prevederlo
Il problema più profondo non è il costo. È che Zapier e Make sono stati progettati per workflow deterministici. Quando lo step A si completa, lo step B parte. Gli agenti non sono deterministici — coinvolgono chiamate LLM che possono restituire formati inaspettati, output ambigui o errori diretti. Le piattaforme sottostanti non sono state costruite per gestire questo in modo elegante.
In pratica, questo si manifesta come:
Fallimenti parziali silenziosi. Un Zap potrebbe completarsi con successo anche se l’LLM ha restituito una risposta malformata, perché lo step successivo registra qualsiasi cosa abbia ricevuto. Il CRM viene aggiornato con dati corrotti, e lo scopri settimane dopo.
Nessuna intelligenza di retry. Se una chiamata API fallisce a metà run, la maggior parte degli agenti basati su piattaforma si ferma o innesca un errore generico. Non c’è logica per riprovare lo step specifico che ha fallito, usare un modello di fallback, o avvisare un revisore umano per quel caso specifico.
Profondità di debug. La visibilità di debug varia per piattaforma. Zapier espone la cronologia a livello di task e checkpoint di versione. Il Reasoning Panel di Make (lanciato a febbraio 2026) fornisce tracce visive step-by-step delle decisioni dell’agente e delle chiamate agli strumenti. Nessuno dei due eguaglia l’osservabilità completa di un sistema custom — non avrai la traccia completa del ragionamento LLM, i conteggi di token grezzi, o un log di audit strutturato nel formato che definisci — ma il divario si sta riducendo. Per un processo che tocca dati di clienti o registri finanziari, anche gli strumenti di piattaforma in miglioramento potrebbero non essere sufficienti.
Controllo di prompt e modello. Gli agenti di piattaforma variano nel controllo che espongono. Sia Zapier che Make ora offrono supporto multi-modello e configurazione del system-prompt; tuttavia, il controllo granulare sul versioning del modello e sui parametri di inferenza rimane più limitato rispetto a un sistema completamente custom. Quando una piattaforma aggiorna i default del modello sottostante, il comportamento del tuo agente può cambiare senza preavviso.
Per i processi dove un errore costa denaro, danneggia una relazione con un cliente, o tocca dati regolamentati, queste modalità di errore contano enormemente.
Dove gli agenti di piattaforma sono la risposta giusta
Per essere diretti: gli agenti Zapier e Make sono una buona scelta in scenari specifici.
Buona corrispondenza:
- Processi che girano meno di poche centinaia di volte al mese
- Task di contenuto a basso rischio: formattazione, sintesi, notifiche interne
- Team senza capacità di sviluppo interna e necessità reale di muoversi velocemente
- Prototipi e proof of concept dove la velocità di iterazione conta più dell’affidabilità in produzione
- Colmare i gap tra strumenti SaaS che hanno già integrazioni Zapier
Se sei una società di consulenza di cinque persone che vuole un agente per estrarre le note delle riunioni con i clienti da Notion, sintetizzarle e redigere una email di follow-up — Zapier o Make funzioneranno bene e ti ci porteranno in un pomeriggio.
Il problema è quando uno strumento scelto per la sua comodità in un contesto a basso rischio viene promosso a un processo ad alto rischio perché “funziona già”. Questo è il percorso verso i fallimenti silenziosi e le brutte sorprese.
Cosa significa davvero “custom” — e quando vale la pena
“Custom” non significa partire da zero senza dipendenze. In pratica, significa costruire su framework agentivi aperti (LangGraph, CrewAI, orchestrazione personalizzata) e infrastruttura che controlli tu, piuttosto che all’interno di una piattaforma di automazione di terze parti.
I vantaggi sono concreti:
- Osservabilità completa. Ogni chiamata LLM, invocazione di strumento e decisione viene registrata in un formato che definisci tu. Puoi tracciare esattamente perché un agente ha intrapreso un’azione specifica.
- Gestione deterministica degli errori. Scrivi tu la logica di retry, i percorsi di fallback, i trigger human-in-the-loop. L’agente si comporta secondo le tue regole, non il gestore di errori generico della piattaforma.
- I dati rimangono dove decidi. Gli agenti custom possono girare all’interno del tuo ambiente cloud o on-premise. Nessun dato cliente passa attraverso l’infrastruttura Zapier o Make.
- Il costo scala linearmente con l’utilizzo, non esponenzialmente. I costi diretti delle API LLM sono prevedibili e tipicamente molto più bassi per run rispetto ai prezzi pass-through della piattaforma ad alto volume.
- Il comportamento è bloccato. Controlli le versioni del modello, i prompt e i cicli di aggiornamento. Niente cambia nel tuo agente perché un vendor SaaS ha fatto un aggiornamento.
Il compromesso è reale: lo sviluppo custom richiede un tempo di build più lungo (settimane, non ore), una specifica, e un responsabile continuativo. Per processi genuinamente ad alto rischio — qualifica dei clienti, estrazione di dati finanziari, comunicazioni regolamentate, workflow multi-step dove i fallimenti hanno costi reali — quell’investimento tipicamente si ripaga in pochi mesi. Per semplici task interni, è eccessivo.
Vedi Build vs Buy: un framework decisionale per gli agenti AI per un approccio strutturato a quando lo sviluppo custom è davvero giustificato.
Una matrice decisionale pratica
| Agente di piattaforma (Zapier/Make) | Agente custom | |
|---|---|---|
| Velocità di deployment | Ore/giorni | Settimane |
| Sviluppo richiesto | Nessuno | Sì |
| Costo per run ad alto volume | Alto (task + markup) | Basso (API diretta) |
| Trasparenza degli errori | Limitata | Completa |
| Controllo dei dati | Ospitato sulla piattaforma | Controllo tuo |
| Blocco prompt/modello | Limitato | Completo |
| Indicato per | Basso volume, interno, basso rischio | Alto volume, rivolto ai clienti, alto rischio |
| Non indicato per | Logica complessa, dati regolamentati, alto volume | Prototipazione rapida, nessuna risorsa di sviluppo |
Questa matrice semplifica, ma la logica sottostante tiene: la scelta dovrebbe seguire le implicazioni del processo, non la comodità degli strumenti.
Per approfondire dove le piattaforme no-code incontrano limiti strutturali, Quando i builder di agenti AI no-code raggiungono il loro limite copre i pattern che vediamo più spesso.
Il quadro dei costi su 12 mesi
I compratori spesso confrontano il costo di build (il custom è più costoso inizialmente) senza modellare il quadro completo. Un agente custom costruito una volta e in esecuzione per un anno contro una soluzione di piattaforma che costa CHF X/mese ad alto volume spesso appare molto diverso al sesto mese.
Le variabili che inclinano il calcolo:
- Volume mensile di run
- Operazioni medie per run
- Se il processo crescerà (il volume raramente rimane piatto)
- Il costo di un evento di errore (un singolo run sbagliato che invia un preventivo errato a 200 clienti cambia completamente la matematica)
Per una visione operativa di come questi numeri si sommano davvero, Il costo reale degli agenti AI: TCO custom vs piattaforma approfondisce il modello di costo totale.
La domanda giusta per il tuo processo specifico
Quando un cliente viene da noi con “stiamo pensando di costruirlo in Zapier”, la prima cosa che chiediamo non riguarda lo strumento. È: qual è il costo di un run sbagliato? Qual è il volume mensile previsto tra dodici mesi, non oggi? Alcuni dei dati elaborati appartengono ai clienti?
Queste tre domande di solito risolvono la decisione più velocemente di qualsiasi confronto di funzionalità.
Se le tue risposte indicano un agente di piattaforma — usane uno. Sono buoni strumenti per ciò per cui sono progettati. Se le tue risposte indicano qualcosa con rischi e volumi reali, l’automazione di piattaforma creerà probabilmente debito tecnico e rischio operativo che supera la comodità di deployment.
Il nostro lavoro di sviluppo agenti AI parte tipicamente da questo tipo di scoping: analizziamo il processo, i dati, la tolleranza al fallimento e il modello di costi prima di raccomandare un approccio. A volte la risposta è “continua a usare Zapier per questo”. Spesso no.
Se stai valutando un’automazione che ha superato la fase di “proof of concept” e vuoi una visione onesta su se il livello dello strumento corrisponde alle implicazioni, prenota una chiamata di 30 minuti con noi. Analizzeremo il processo specifico, il modello di costi, e ti diremo chiaramente quale approccio ha senso — anche se significa rimanere con quello che hai. Niente pitch, solo l’analisi.