Il tuo flusso di lavoro AI è in esecuzione in questo momento.
Solo che non sai che ha smesso di funzionare tre giorni fa.
Continua a girare. Continua a bruciare crediti API. Continua a inviare output che nessuno legge. L'agente che hai passato due weekend a costruire sta producendo spazzatura a $0,40 per mucchio di spazzatura — e non lo scoprirai finché un cliente non ne farà uno screenshot e te lo invierà un martedì.
Questa non è sfortuna. È il risultato predefinito.
Salva questo articolo. Lo leggerai due volte.
Il Cimitero dei 30 Giorni
Ogni settimana, centinaia di fondatori costruiscono flussi di lavoro AI e li postano su Twitter.
La demo sembra pulita. Il thread riceve like. I commenti dicono "questo è il futuro."
Trenta giorni dopo, il flusso di lavoro è morto.
Non cancellato. Non sostituito. Morto e ancora in esecuzione. Che addebita la carta. Che non produce nulla di utile. Il fondatore è andato avanti. L'agente non ha ricevuto il messaggio.
Il 90% dei flussi di lavoro AI costruiti oggi non sopravviverà al primo mese in produzione. Non perché i modelli siano scadenti. Non perché le idee siano sbagliate. Perché i costruttori hanno commesso tre errori che garantiscono il fallimento — e nessuno ha detto loro quali fossero quegli errori prima del lancio.
Questo è quell'articolo.
Perché Muoiono
Ecco l'anatomia della morte di un flusso di lavoro. È sempre la stessa sequenza.
Giorno 1: Lo costruisci. Funziona perfettamente nella demo. Ti sembra di aver sbloccato qualcosa.
Giorno 3: Funziona ancora. Smetterai di controllarlo così attentamente.
Giorno 9: Qualcosa cambia. Il formato di una risposta API si sposta leggermente. Una fonte che stava leggendo finisce dietro un login. Il modello interpreta un caso limite diversamente rispetto al primo giorno. L'output degrada silenziosamente. Nessuno se ne accorge.
Giorno 14: Il flusso di lavoro ora produce output che tecnicamente è una risposta, ma sostanzialmente è inutile. È ancora in esecuzione. Stai ancora pagando.
Giorno 23: Un cliente o un collega menziona che qualcosa non va. Indaghi. Trovi 12 giorni di output difettoso che pensavi venisse gestito.
Giorno 30: Lo uccidi. Ti dici che l'AI non è pronta. Vai avanti.
Il modello non ti ha deluso. La build ha deluso il modello.
Le 3 Regole Che Separano il 10% da Tutti Gli Altri
I fondatori i cui flussi di lavoro sopravvivono 30 giorni, 90 giorni, un anno — non sono più intelligenti. Non hanno prompt migliori. Costruiscono con tre regole che tutti gli altri ignorano.
Regola 1 — Nessuna Descrizione del Lavoro, Nessun Agente
La maggior parte delle persone costruisce agenti con una sensazione.
"Aiutami con i contenuti." "Monitora i concorrenti." "Gestisci le email dei clienti."
Questa non è una descrizione del lavoro. È un desiderio. E i desideri non sopravvivono al weekend.
Una descrizione del lavoro ha cinque parti:
Cosa osserva. Il trigger specifico o la pianificazione. "Ogni lunedì alle 7:00" o "ogni volta che viene aperta una nuova issue su GitHub con l'etichetta 'bug'" o "ogni volta che arriva un'email da un dominio non nella mia rubrica." Non "a volte" o "quando pertinente."
Cosa legge. Le fonti esatte. Non "controlla Internet." "Preleva da questi tre feed RSS, questa base Airtable e gli ultimi 7 giorni di questo canale Slack." Specifico. Delimitato. Nessuna ambiguità.
Cosa produce. Il formato esatto dell'output. Non "un riassunto." "Un brief in tre sezioni: risultato principale in una frase, tre punti di supporto con una fonte ciascuno, un'azione consigliata. Sotto le 300 parole. In questo Google Doc."
Cosa non fa. I guardrail. "Non inviare mai un'email esterna senza approvazione umana." "Non modificare mai il database di produzione." "Non pubblicare mai direttamente. Salva sempre nelle bozze." Le cose che dai per scontate sono quelle che ti bruceranno.
Come sai che ha funzionato. La condizione di successo. "Se il brief è vuoto, inviami un messaggio Slack dicendo che non sono stati trovati aggiornamenti pertinenti. Non inviare un brief vuoto."
Le sensazioni non sopravvivono al weekend. Le descrizioni del lavoro sì.
Ogni flusso di lavoro che costruirai d'ora in poi inizia con una descrizione del lavoro. Non un prompt. Una descrizione del lavoro.
Regola 2 — Il Fallimento Silenzioso È l'Unico Fallimento Che Ti Uccide
I fallimenti rumorosi vanno bene. I fallimenti rumorosi inviano un errore. Fermano il flusso di lavoro. Ti svegliano. Li sistemi.
I fallimenti silenziosi sono quelli che uccidono le aziende.
Un fallimento silenzioso sembra un successo. Il flusso di lavoro gira. L'output arriva. Il formato è corretto. Il contenuto è sbagliato — leggermente, poi di più, poi completamente — e poiché sembra giusto, nessuno lo controlla.
Ecco come si verifica un fallimento silenzioso nella pratica:
Il tuo agente dei contenuti scrive 30 post. Lo imposti per pianificare automaticamente quelli che ottengono un punteggio superiore a 80 nella tua rubrica interna. La rubrica è stata calibrata sui tuoi primi 20 post. Al giorno 15, il modello inizia a interpretare la tua rubrica in modo diverso. I post che ottengono 82 sono ora mediocri secondo il tuo standard reale. Vengono pubblicati comunque. Il tuo engagement cala. Dai la colpa all'algoritmo.
Il tuo agente di ricerca invia un brief settimanale. Al giorno 11, una delle fonti che stava leggendo cambia la propria struttura URL. L'agente non riesce a recuperarla silenziosamente. Colma il vuoto con dati cache più vecchi e non segnala il buco. Leggi un brief basato su informazioni obsolete e prendi una decisione su di esso.
Il tuo agente di triage della posta in arrivo abbozza risposte. Al giorno 8, inizia a categorizzare un certo tipo di email come a bassa priorità perché il nome del mittente corrisponde a un pattern nel suo addestramento. Perdi tre email importanti da un nuovo cliente che per caso condivide il cognome con una newsletter che non leggi mai.
In ogni caso: il flusso di lavoro è girato. Nessun errore è stato lanciato. Hai perso comunque.
La soluzione è la verifica obbligatoria dell'output. Ogni agente necessita di tre cose:
Un output canarino. Un campo in ogni output che sia facile da verificare e difficile da falsificare. Un timestamp della fonte più recente letta. Un conteggio degli elementi elaborati. Un punteggio di confidenza. Qualcosa che puoi vedere in due secondi e sapere che l'agente ha effettivamente svolto il lavoro.
Un avviso di fallimento silenzioso. Se l'agente non produce nulla, o produce qualcosa al di sotto di una soglia, non invia un output vuoto. Invia un avviso. "Nessun risultato trovato in questo ciclo — ecco cosa ho controllato e perché potrei non aver trovato nulla." Niente è sempre più utile di un risultato vuoto convincente.
Un controllo a campione settimanale. Scegli un output per agente a settimana. Leggilo completamente. Confrontalo con ciò che avresti scritto tu stesso. Richiede quattro minuti. Cattura la deriva prima che diventi fallimento.
Gli agenti non falliscono rumorosamente. Costruisci per le rotture silenziose.
Regola 3 — Il Tuo Portatile Non È Infrastruttura
Qui è dove muore il 90% dei costruttori.
Costruiscono localmente. La demo funziona. Pubblicano il thread su Twitter. Qualcuno chiede se è in esecuzione in produzione. Dicono di sì. Quello che intendono è: è in esecuzione sul loro MacBook, che in questo momento è aperto, sulla loro scrivania, nel loro appartamento, connesso al loro WiFi di casa, e smetterà di funzionare quando chiuderanno il coperchio per andare all'aeroporto giovedì.
Il tuo portatile non è infrastruttura. È un ambiente di sviluppo che casualmente sta eseguendo qualcosa di importante in questo momento.
Ecco cosa succede agli agenti ospitati su portatile:
macOS invia un aggiornamento alle 4 del mattino. La macchina si riavvia. L'agente si ferma. Nessuno lo sa fino a lunedì.
Chiudi il coperchio su un volo. Sei ore di flussi di lavoro persi. L'agente di triage della posta non ha fatto triage. Il cacciatore di bug non ha cacciato. L'agente del daily standup non ha inviato nulla.
Il tuo WiFi di casa cade per venti minuti. L'agente riprova. Fallisce. Va avanti. Non registra nulla. La finestra che doveva catturare è persa.
Vai in vacanza. Il portatile resta a casa. Tutto resta a casa con lui.
La vera infrastruttura funziona quando non stai guardando. Funziona quando dormi, su un aereo, a cena, irraggiungibile per un weekend. Non ha bisogno che tu tenga il coperchio aperto.
La regola è semplice: se il flusso di lavoro deve essere eseguito più di una volta e non puoi permetterti che salti un ciclo, non vive sul tuo portatile.
Le tre opzioni di infrastruttura che funzionano davvero:
Un VPS con un process manager. Un server da $12 al mese con PM2 o Supervisor. Il tuo agente viene eseguito come processo gestito. Se si blocca, PM2 lo riavvia automaticamente. Se il server si riavvia, PM2 lo avvia all'avvio. Economico. Affidabile. Non glamour. Funziona.
Una piattaforma gestita per agenti. Progettata appositamente per questo. Gestisce riavvii, monitoraggio, avvisi. Costa più di un VPS. Ti fa risparmiare i weekend che passeresti a debugare perché il processo è morto. Ne vale la pena una volta che i tuoi agenti generano valore reale.
Serverless con un programmatore. AWS Lambda o Google Cloud Functions attivati da EventBridge o Cloud Scheduler. Zero infrastruttura da gestire. Paghi per esecuzione. Scalano a zero quando non sono in esecuzione. Opzione migliore per agenti che girano su un programma fisso piuttosto che in continuazione.
Nessuna di queste è complicata. Tutte richiedono quindici minuti di configurazione. Ognuna di esse ti salverà dall'aggiornamento di macOS delle 4 del mattino che uccide i tuoi agenti e il tuo lunedì mattina.
Chiudi il portatile. Gli agenti dovrebbero continuare a funzionare.
Il Flusso di Lavoro Che Sopravvive
Ecco come appare un flusso di lavoro di 90 giorni quando vengono applicate tutte e tre le regole.
La descrizione del lavoro: Ogni lunedì alle 7:00, leggi gli ultimi 7 giorni di post da questi 5 account concorrenti e queste 3 newsletter di settore. Estrai qualsiasi annuncio di prodotto, cambiamento di prezzo o contenuto che abbia ottenuto più di 500 interazioni. Confronta con il brief della settimana precedente. Segnala qualsiasi novità. Output di un brief in tre sezioni: cosa è cambiato, cosa sta guadagnando trazione, quale lacuna hanno lasciato aperta. Se non vengono trovati cambiamenti, invia un avviso: "settimana tranquilla — ecco cosa è stato controllato." Consegnare a questa pagina Notion e inviare una notifica Slack.
L'output canarino: Ogni brief include: "Fonti controllate: 8. Elementi elaborati: [N]. Timestamp dell'elemento più recente: [timestamp]." Se N è zero o il timestamp è più vecchio di 8 giorni, invia un avviso invece di un brief.
L'infrastruttura: In esecuzione su un VPS da $12 al mese. PM2 gestisce il processo. Se si blocca, si riavvia in 30 secondi. Una revisione settimanale dei log richiede 3 minuti ogni venerdì.
Il controllo a campione: Ogni venerdì, un brief viene letto completamente. Richiede 4 minuti. Ha catturato la deriva due volte in sei mesi.
Quel flusso di lavoro è in esecuzione da sei mesi. Ha saltato due cicli — entrambe le volte ha inviato un avviso spiegando perché. Non ha mai fallito silenziosamente.
Questa è la differenza tra un flusso di lavoro che sopravvive e uno che muore al nono giorno.
La Verità Scomoda
La maggior parte delle persone leggerà questo, annuirà e costruirà il prossimo agente allo stesso modo dell'ultimo.
Un prompt. Una demo. Un thread su Twitter. Trenta giorni di silenzio. Un flusso di lavoro morto che nessuno ha ufficialmente ucciso.
Le tre regole non sono complicate. Una descrizione del lavoro richiede venti minuti per essere scritta. La verifica dell'output richiede un campo e una condizione. L'infrastruttura richiede quindici minuti di configurazione.
Il divario non è la conoscenza. Il divario è se lo fai prima del lancio o dopo che il flusso di lavoro fallisce.
Ogni agente che costruisci senza una descrizione del lavoro è un agente che ricostruirai. Ogni agente senza verifica dell'output è un agente che fallirà silenziosamente. Ogni agente sul tuo portatile è un agente che morirà la prossima volta che chiuderai il coperchio.
Costruiscili bene una volta. Funzionano per sempre.
Segui @sairahul1 per altri manuali completi su come costruire flussi di lavoro AI che sopravvivono al contatto con il mondo reale.
TL;DR
Il 90% dei flussi di lavoro AI muore in 30 giorni. Sempre per gli stessi tre motivi.
Regola 1 — Nessuna descrizione del lavoro, nessun agente. Le sensazioni non sopravvivono al weekend. Definisci cosa osserva, legge, produce, evita e come sai che ha funzionato. Prima di scrivere un singolo prompt.
Regola 2 — Il fallimento silenzioso è l'unico fallimento che ti uccide. I fallimenti rumorosi vanno bene. I fallimenti silenziosi sembrano successi finché un cliente non li trova. Costruisci un output canarino, un avviso di fallimento silenzioso e un controllo a campione settimanale in ogni agente.
Regola 3 — Il tuo portatile non è infrastruttura. Funziona quando il coperchio è aperto. I veri agenti funzionano quando dormi, su un aereo, irraggiungibile per un weekend. VPS, piattaforma gestita o serverless. Scegline uno. Configuralo prima del lancio.
Gli agenti che sopravvivono non sono più intelligenti. Sono costruiti bene.
