Quando NON costruire un agente IA (fai questo invece)

Indice

Pubblicato ad agosto 2026.

TL;DR: La maggior parte delle idee per agenti IA è lo strumento sbagliato per il compito. Prima di scrivere codice per un agente controllo cinque segnali che squalificano l’idea — un processo instabile, bassa frequenza, nessun test pass/fail, uno strumento più semplice che già funziona, oppure una modalità di fallimento irreversibile che non ho tempo di gestire correttamente. Se anche uno solo di questi è vero, non costruisco. Scendo invece lungo una scala di alternative più economiche, e torno a un agente personalizzato solo se nulla su quella scala regge.

[Prospettiva dell’operatore] Gestisco più di 30 agenti in produzione tra un brand di consulenza e Pickleland, una struttura di pickleball a Pflugerville, TX. Ho scartato almeno tante idee di agenti quante ne ho realizzate, e quasi nessuna è morta perché l’idea era cattiva — sono morte perché un agente era lo strumento sbagliato per quel particolare compito. Questo post è il filtro che applico prima che “dovrei costruirlo” diventi “come lo costruisco.”

La risposta di default è no

Il framework ROI che uso ti dice se un’automazione ripaga il suo costo di costruzione e manutenzione. Quella è la domanda giusta, ma è la seconda. La prima è più semplice e viene saltata di continuo: questo deve davvero essere un agente?

“Agente” è diventata l’etichetta di default per qualsiasi cosa coinvolga un LLM, allo stesso modo in cui “app” è diventata l’etichetta di default per qualsiasi cosa coinvolgesse uno schermo quindici anni fa. Non tutto ciò che tocca un modello ha bisogno di un sistema stabile, autonomo, capace di chiamare strumenti, che sorveglia trigger e agisce da solo. Molto di quello che le persone chiamano “costruire un agente” è in realtà “scrivere un prompt davvero buono ed eseguirlo a mano,” e questa non è una modalità di fallimento — è spesso lo stato finale corretto.

Tratto “costruire un agente personalizzato” come l’opzione più costosa su una scala di opzioni, non come il primo gradino. Prima di arrivarci, controllo se il compito si squalifica da solo.

Cinque segnali che indicano lo strumento sbagliato

Anche uno solo di questi, da solo, di solito basta per fermarmi.

1. Il processo non è ancora stabile. Se il flusso di lavoro è cambiato due volte nell’ultimo mese perché l’azienda stessa sta ancora capendo cosa vuole, un agente blocca la versione odierna di un processo che sta per cambiare di nuovo. Riscriverai il prompt, lo schema degli strumenti e il set di eval ogni volta che il processo cambia — il che significa che stai mantenendo un agente invece di gestire un’azienda. Eseguilo manualmente finché non si stabilizza per un trimestre, poi automatizza la versione consolidata.

2. Gira troppo raramente per ripagarsi. Un compito che accade due volte l’anno non accumula abbastanza esecuzioni da giustificare tempo di costruzione, tempo di test e un set di eval, per quanto bene funzionerebbe una volta costruito. Bassa frequenza e alto sforzo di costruzione è vicino al peggior quadrante possibile per l’automazione — paghi l’intero costo di costruzione e raccogli quasi nessuno dei risparmi.

3. Non riesci a scrivere un test pass/fail. Se non riesci a descrivere in anticipo, abbastanza bene da verificarlo programmaticamente, come appare un output corretto, non puoi costruire un’impalcatura di eval per quel compito — e un agente che non puoi valutare è un agente su cui voli alla cieca. I compiti che sono puro gusto (“suona come me”) o puro giudizio senza una rubrica coerente dietro restano manuali, o restano soggetti a revisione umana ogni volta, il che vanifica lo scopo di automatizzarli.

4. Uno strumento più semplice fa già il lavoro. Prima di definire l’ambito di un agente, chiediti cosa otterresti da una formula di foglio di calcolo, un workflow Zapier/Make/n8n con un singolo step LLM, o un prompt salvato. Se la risposta onesta è “il 90% della strada,” l’ultimo 10% raramente giustifica l’allestimento di un agente con la sua infrastruttura, il suo monitoraggio e la sua tassa di manutenzione. Ho definito l’ambito di agenti per compiti che una vista filtrata e un promemoria ricorrente sul calendario avrebbero risolto altrettanto bene.

5. La modalità di fallimento è irreversibile e non hai tempo per costruire correttamente il gate. Alcune azioni — un invio massivo di email, un rimborso, un post pubblico — non si possono annullare. I gate con revisione umana esistono esattamente per questo, ma un gate frettoloso che nessuno controlla davvero è peggio di nessuna automazione: crea l’apparenza di supervisione senza la sostanza. Se non hai il tempo di costruire e presidiare il gate correttamente, questo è un segnale per rallentare, non un motivo per saltare il gate.

Se nessuno dei cinque si applica — il processo è stabile, gira abbastanza spesso, puoi definire cosa è corretto, nessuno strumento più semplice lo copre, e la modalità di fallimento è reversibile oppure adeguatamente gestita da un gate — allora vale la pena fare i conti del ROI.

La scala che percorro prima di costruire

Quando un compito fallisce uno dei cinque controlli — o prima ancora di arrivare a quel punto — scendo lungo questa lista in ordine, e mi fermo al primo gradino che risolve davvero il problema.

1. Chiedi direttamente al modello. Nessun wrapper, nessuna chiamata a strumenti, nessuna infrastruttura stabile. Apri Claude, incolla il contesto, fai la domanda, usa la risposta. Questo gestisce più compiti occasionali e una tantum di quanto ci si aspetti, perché l’istinto “agente” scatta anche per cose che devono succedere una sola volta.

2. Un prompt salvato o istruzioni di progetto. Se lo stesso tipo di richiesta si ripresenta più volte ma ogni istanza richiede comunque che una persona raccolga gli input e riveda l’output, salva il prompt come template — istruzioni di progetto, un set di istruzioni personalizzate, uno snippet — invece di automatizzare il trigger. Ottieni il beneficio della coerenza di un agente senza l’infrastruttura.

3. Uno strumento di automazione no-code con un singolo step LLM. Per compiti che hanno davvero bisogno di un trigger (una nuova risposta a un modulo, una nuova riga in un foglio) ma la logica in sé è semplice, uno strumento di workflow con una chiamata al modello nel mezzo è drasticamente più economico da costruire e mantenere del codice personalizzato. Ci ricorro prima dell’infrastruttura personalizzata ogni volta che il trigger è standard e il volume è basso o moderato.

4. Un template eseguito manualmente. Alcuni processi beneficiano più di una checklist che di un’automazione, perché il valore sta in una persona che ragiona su ogni passaggio, non nella velocità. Non automatizzare via il ragionamento in compiti dove il ragionamento è il punto.

5. Esternalizzazione. Per tutto ciò che ha reale ambiguità o richiede giudizio e per cui non hai tempo di costruire e mantenere un set di eval, una persona — una VA, uno specialista, un fornitore di servizi produttizzati — è spesso più veloce da mettere in funzione e più facile da correggere in corsa rispetto a un agente che stai ancora mettendo a punto.

6. Solo a questo punto: un agente personalizzato. Se sei sceso lungo la scala e nulla ha retto — il trigger richiede vero giudizio sotto carico, il volume è troppo alto per la gestione manuale o esternalizzata, e supera i conti del ROI — è a quel punto che un agente costruito su misura, con il suo stack di affidabilità, guadagna il suo costo di costruzione.

Il test ombra di due settimane

Per qualsiasi cosa che stia sul filo — supera i cinque controlli ma non sono ancora sicuro — eseguo un test ombra di due settimane prima di impegnarmi in una build. Faccio il compito io stesso, usando il modello come copilota anziché come sistema autonomo: stesso prompt che darei infine all’agente, stessi input, ma leggo ogni output prima che vada da qualche parte.

Da quel test escono due cose. Primo, se il modello è davvero bravo nel compito, al livello di qualità che mi serve — se sto riscrivendo a mano metà del suo output, il compito non è pronto per essere automatizzato, indipendentemente da tutto il resto. Secondo, un vero set di eval: due settimane di input e gli output che ho giudicato corretti sono esattamente ciò di cui ha bisogno un’impalcatura di eval, e di solito l’ho raccolto gratis entro il momento in cui decido di costruire.

Il test ombra fa anche emergere i casi limite prima che siano in produzione. È molto più economico scoprire durante una prova manuale che il 15% degli input richiede una gestione speciale che scoprirlo da un reclamo di un cliente dopo che l’agente è stato lanciato.

Una regola che applico dopo aver scartato un’idea

Scartare un’idea di agente non è lo stesso che scartare il problema di fondo. Se un compito si squalifica per ora — il processo è ancora in movimento, il volume è troppo basso — scrivo perché e fisso un punto approssimativo di rivalutazione (di solito legato a un trigger specifico: “rivaluta quando le prenotazioni superano 50 a settimana,” non solo una data). Le idee di agenti scartate una volta e mai più riviste si trasformano silenziosamente in lavoro manuale permanente che nessuno ricorda di aver valutato due volte.

La disciplina inversa conta altrettanto: un’idea che supera i cinque controlli e i conti del ROI non viene automaticamente costruita oggi. Entra nella stessa coda di tutto il resto, classificata rispetto alle automazioni già dimostrate che si ripagano. Superare il filtro guadagna a un compito un posto in fila, non un’esenzione dalla definizione delle priorità.

FAQ

Questo non è solo un argomento contro l’automazione?

No — è un argomento contro il default sulla forma più costosa di automazione. La maggior parte delle alternative sulla scala qui sopra sono comunque automazione; sono solo più leggere. Gestisco decine di agenti in produzione. Il punto non è evitare di costruire; è smettere di saltare direttamente a “costruisci un agente personalizzato” quando un prompt salvato o un workflow no-code ottengono lo stesso risultato per una frazione del costo di costruzione e manutenzione.

E se il compito crescerà chiaramente di volume in futuro?

È una ragione legittima per costruire in anticipo rispetto ai numeri attuali — copro questa eccezione nel framework ROI. Tuttavia non prevale sui cinque segnali sopra. Se il processo è ancora instabile o non riesci ancora a definire un output corretto, un volume crescente significa solo che manterrai un agente rotto su scala più grande. Prima risolvi instabilità e testabilità; la scala è una ragione per costruire prima una volta risolti quei problemi, non una ragione per saltarli.

Come faccio a sapere se uno step no-code è “abbastanza buono” rispetto al bisogno di codice personalizzato?

Provalo prima e misuralo rispetto al tuo set di eval, anche uno informale. Gli step LLM no-code gestiscono bene compiti a scopo singolo e input singolo. Iniziano a soffrire quando serve un uso di strumenti multi-step, uno stato persistente tra le esecuzioni, o logica condizionale che il builder dello strumento non riesce a esprimere in modo pulito. Se colpisci quel muro, è un segnale reale per passare a infrastruttura personalizzata — non una ragione per partire da lì.

Questo vale in modo diverso per gli strumenti interni rispetto a quelli rivolti ai clienti?

I cinque segnali si applicano nello stesso modo, ma la posta in gioco è diversa. Uno strumento interno con un processo instabile spreca solo il tempo del tuo team quando si rompe. Uno rivolto ai clienti con un processo instabile erode la fiducia di persone che non si sono iscritte per essere il tuo set di eval. Applico in particolare una versione più rigida del segnale cinque alle automazioni rivolte ai clienti — la soglia per “adeguatamente gestito da un gate” è più alta quando dall’altra parte di un errore c’è uno sconosciuto, non un collega.

Qual è la ragione più comune per cui scarti un’idea di agente?

Il segnale tre — nessun test pass/fail pulito. È il più facile da perdere durante la definizione dell’ambito perché il compito sembra ben definito finché non provi a scrivere, in anticipo, come appare davvero un output corretto. Se non riesco a farlo in una frase o due, so che l’agente sarà non valutabile, il che significa non migliorabile, il che significa che non lo costruisco ancora.