Ho costruito 21 automazioni Claude in sei settimane: quante ne funzionavano davvero, e quante ne restano

Il sistema è andato in produzione a metà febbraio 2026. Sono ventuno automazioni, girano tutte sulla stessa macchina, e all'inizio di aprile ho fatto il primo bilancio serio.

Il bilancio non è andato come mi aspettavo. Di quelle ventuno, un gruppo intero non aveva mai prodotto un singolo output utile. Un altro produceva output che nessuno leggeva. Ventuno è il conto delle automazioni attive: ce n'erano altre tre, spente entro marzo, che nel conteggio non entrano.

Il punto è che un ecosistema di automazioni non si misura da quante ne hai. Si misura da quante ne puoi spegnere senza che cambi niente.

Quello che segue è il resoconto di quelle sei settimane, scritto oggi: l'architettura com'era, i fallimenti come li ho misurati allora, i numeri con il contesto attaccato. In coda c'è il seguito, cioè cosa è successo a quelle ventuno nei mesi dopo. È la parte che allora non potevo scrivere.

Il punto di partenza: il collo di bottiglia non era la competenza

A metà febbraio la situazione era questa. Lavoro da solo, senza dipendenti. Il lavoro con i clienti B2B occupa le ore centrali della giornata. Il blog e la presenza LinkedIn sono canali che devono esistere, perché la lead generation passa da lì, ma sono esattamente il tipo di lavoro che salta per primo quando la settimana si riempie.

Il collo di bottiglia non era sapere cosa fare. Le ore erano finite e non erano comprimibili.

Il discorso è che quando sei solo hai due strade. Una è ridurre il perimetro, cioè fare meno cose e farle bene. L'altra è spostare il lavoro ripetitivo su un sistema che gira quando tu non ci sei. Ho scelto la seconda, con una condizione: ogni automazione doveva produrre un artefatto che qualcuno o qualcosa a valle avrebbe letto. Se l'output finiva in un file che nessuno apriva, l'automazione era inutile anche se tecnicamente funzionava.

Questa condizione l'ho scritta prima di iniziare. L'ho poi violata sei volte. Ci torno dopo.

L'architettura: orchestratore, sub-agenti, task schedulati

Il sistema si reggeva su tre livelli, e conviene guardarli separatamente perché sbagliano in modi diversi.

Livello 1: l'orchestratore. Claude fa da coordinatore. Riceve un compito grosso, lo spezza, e delega a sub-agenti che girano in parallelo. La divisione dei ruoli è per modello: un modello più capace fa la pianificazione e le scelte, modelli più veloci ed economici fanno l'esecuzione meccanica. Sembra un dettaglio di ottimizzazione dei costi, e in parte lo è. L'effetto che conta davvero però è un altro: separare chi decide da chi esegue rende gli errori leggibili. Se l'output è sbagliato, sai subito se hai un problema di piano o di esecuzione. Ho scritto in modo più esteso su come si costruiscono i sub-agenti in Claude Agent SDK e sub-agenti Python per i report B2B.

Livello 2: i task schedulati. Ogni automazione è un task con un orario, un prompt lungo e versionato, e un file di istruzioni che definisce il comportamento. Non sono script che chiamano un modello. Sono procedure scritte in linguaggio naturale, con vincoli espliciti, che il modello esegue leggendo lo stato reale del repository.

Livello 3: lo stato su disco. Tutto quello che il sistema sa vive in file markdown dentro un repository. Le istruzioni di progetto, le regole di scrittura, lo storico delle decisioni, i report. Nessun database. La ragione è banale: un file markdown lo posso leggere io e lo può leggere il modello, e il diff di git mi dice quando è cambiato.

Lo stack sotto è ordinario: Next.js e Sanity per il sito, Vercel per l'hosting, Python per gli script che parlano con le API esterne, Google Cloud per il resto. La documentazione ufficiale di Claude Code copre bene la parte di runtime, quindi non la ripeto qui.

La limitazione che conta davvero

C'era un vincolo strutturale che a metà febbraio non avevo valutato abbastanza: tutto girava in locale. I task schedulati vivevano sulla mia macchina. Nessun fallback in cloud, nessuna coda che recuperasse le esecuzioni saltate. Se la macchina era spenta, il sistema non girava.

Il sabato in cui non accendevo il computer, qualche automazione non partiva e nessuno se ne accorgeva fino al lunedì. Al momento della costruzione quella scelta sembrava un risparmio. Si è rivelata il limite principale dell'intero impianto, e più avanti in questo pezzo si vede quanto è costato smontarla.

Le famiglie di automazioni

Le ventuno non erano ventuno cose diverse. Erano cinque famiglie, e raggrupparle così rende molto più evidente dove stava il valore e dove stava il rumore.

Contenuto e blog. Generazione degli articoli con vincoli editoriali forti, pubblicazione verso il CMS, audit di qualità sui post già online. È la famiglia che produce l'artefatto più visibile e anche quella che ha causato il problema più grosso.

SEO e monitoraggio. Lettura periodica dei dati di Search Console, controllo dello stato di indicizzazione, health check del sistema. Output: report che leggevo io, settimanalmente.

Outreach. Sequenze email per link building e guest post, monitoraggio delle risposte in casella, follow-up a scadenza. È la famiglia con il ciclo più lungo tra azione e risultato misurabile.

LinkedIn. Scansione delle notizie di settore, preparazione dei contenuti, diario settimanale, dashboard di engagement. Era la famiglia più giovane: l'automazione della pubblicazione vera e propria è partita a inizio aprile, quindi al momento del bilancio era la meno matura di tutte.

Instagram. Pipeline video, analytics, planner dei contenuti, analisi dei pattern.

Quest'ultima famiglia merita una riga a parte, perché è il fallimento più netto del sistema e ne parlo nella sezione dedicata.

Il dettaglio che rompe tutto: i nomi dei campi

Una nota tecnica che vale più di molta teoria. Il CMS ha un campo per il titolo SEO che sta dentro un oggetto annidato, e un campo per la data di pubblicazione con un nome preciso. Nelle prime settimane più di un task scriveva sui nomi sbagliati, quelli che uno si aspetterebbe per convenzione invece di quelli reali dello schema.

Risultato: i task giravano e riportavano successo, ma non scrivevano niente di utile. Nessun errore e nessun alert. I campi vuoti li ho scoperti a mano, guardando il CMS.

Questa è la classe di guasto più pericolosa in un sistema di automazioni: il fallimento silenzioso che restituisce successo. Da lì è nata la regola che i nomi canonici dei campi stanno scritti nelle istruzioni di progetto, in una tabella con la colonna "non usare" accanto a quella corretta.

I numeri, con il contesto attaccato

Qui provo a essere preciso su cosa è misurato e cosa no, perché i case study di automazione sono pieni di numeri senza denominatore.

Tempo risparmiato: 40+ ore/mese [misurato su N=1, periodo: 6 settimane]. Il metodo è la stima del tempo che impiegavo prima a fare la stessa cosa a mano, moltiplicata per la frequenza. Non c'è gruppo di controllo, non c'è tracking automatico delle ore, e il soggetto misurato sono io. Prendetelo come un ordine di grandezza dichiarato.

Costo dello stack: non lo pubblico, e vi dico perché. Le voci sono quattro: l'abbonamento al modello, l'hosting del sito, il dominio, il servizio di invio email. La voce che pesa è la prima, con distacco. Le altre stanno nel rumore. Il totale però non ho una contabilità separata che me lo dia: il numero che potrei scrivere sarebbe una ricostruzione a memoria, e in un pezzo che sta chiedendo al lettore di fidarsi dei numeri sarebbe la cosa peggiore da fare. Quando vedete "il mio stack costa X al mese" in un case study, chiedetevi se dietro c'è una somma di fatture o una stima arrotondata verso il basso.

Pagine pubblicate: 45 nel sitemap, 39 indicizzate alla misura di fine marzo. Il grosso era stato pubblicato nelle settimane immediatamente precedenti, con una frequenza che si è rivelata un errore.

Traffico organico: 510 impressioni e 10 click negli ultimi 28 giorni misurati (fine marzo 2026, dato diretto da Search Console). Un solo articolo pillar generava intorno al 70% delle impressioni. Il sito era giovane e questi numeri sono piccoli in assoluto: li riporto perché il rapporto tra loro è la cosa interessante, non il valore.

Il numero che manca, e lo dico perché la sua assenza è informativa: non avevo una misura del ritorno economico diretto delle automazioni. Sapevo quanto tempo mi restituivano. La conversione di quel tempo in fatturato è una catena troppo lunga per attribuirla con onestà dopo un mese e mezzo di sistema in piedi. Sul come si costruisce una misura di ritorno che regga ho scritto separatamente in ROI dell'AI per le PMI italiane.

Cosa non ha funzionato

Questa è la sezione utile. Le altre le trovate in qualsiasi case study.

1) Automazioni che girano e non producono niente. La pipeline Instagram era composta da quattro task attivi. Video, analytics, planner, analisi dei pattern. Al bilancio di aprile aveva prodotto zero video pubblicati, con tre blocchi tecnici mai risolti a monte. I quattro task partivano regolarmente, consumavano tempo di esecuzione, scrivevano log, e non c'era un solo artefatto pubblicato all'altro capo.

Il sintomo era "la pipeline non pubblica". La causa è che avevo automatizzato un processo che non avevo mai eseguito a mano fino in fondo. Non sapevo dove si rompeva perché non ci ero mai arrivato.

2) Automazioni senza consumatore a valle. Un task generava un diario settimanale. Nessuno lo leggeva, nessun altro task lo usava come input. Un file che si aggiornava nel vuoto. Un secondo task doveva produrre una dashboard di engagement, ma i dati che gli servivano non erano disponibili nella forma che assume: girava, e produceva una dashboard vuota.

Questa è esattamente la condizione che mi ero scritto prima di iniziare, violata due volte.

3) Automazioni senza dati. L'analizzatore di pattern per Instagram doveva trovare regolarità nei contenuti pubblicati. I contenuti pubblicati erano zero. Il task ha una logica di skip automatico che si attiva quando il campione è vuoto, quindi ogni esecuzione terminava immediatamente senza fare nulla. Funzionava perfettamente e non serviva a niente.

4) Duplicazione tra task nati in momenti diversi. Avevo due automazioni che scansionavano le notizie di settore, costruite in momenti diversi per due canali diversi. Facevano sostanzialmente lo stesso lavoro sulle stesse fonti e producevano due output sovrapposti. Andavano consolidate in una sola.

5) Task spenti senza una diagnosi scritta. Tre automazioni di supporto interno, tutte con notifica su Slack, sono state disattivate prima della fine di marzo. Sono andato a rileggere il registro dei task disabilitati per capire perché, e alla voce "motivo" ho trovato quattro parole: "non più in uso". Non c'è una diagnosi, non c'è una misura, non c'è niente che mi permetta oggi di ricostruire cosa mi avesse convinto a spegnerle. È un problema che a prima vista sembra minore e non lo è: se non registri perché hai spento qualcosa, il mese dopo qualcuno (tu) ricostruisce lo stesso task da capo, con un nome diverso e le stesse ragioni per cui il primo non serviva.

6) Volume di pubblicazione sul blog. Ho pubblicato con cadenza quasi giornaliera su un dominio nuovo. ipotesi: questa è la scelta che mi costerà di più. Un sito senza storia ha un budget di scansione limitato, e riversarci decine di URL nuovi in poche settimane porta il motore a scoprire pagine che poi non indicizza. La documentazione di Google sulla gestione del crawl budget descrive il meccanismo. All'epoca non avevo ancora la misura precisa di quante pagine fossero ferme in "scoperta ma non indicizzata", e la stavo raccogliendo. Se l'ipotesi regge, la correzione è ridurre la frequenza e lavorare sulla profondità.

Segno per il lettore che questa ipotesi ha avuto una verifica, e la trovate più giù.

Le tre automazioni che tengo senza discutere

Per bilanciare. Tre avevano un rapporto valore/manutenzione fuori scala rispetto alle altre.

Il generatore di articoli con vincoli editoriali. Non conta che scriva. Conta che scriva rispettando una checklist non negoziabile: lunghezza minima, link interni obbligatori, campi del CMS corretti, immagine di copertina presente. Il valore non sta nella generazione, sta nel gate. Un articolo che non passa i controlli resta in bozza e non viene pubblicato.

L'audit sui post già online. Rilegge quello che è già pubblicato e segnala cosa non rispetta le regole. È l'unica automazione che lavora contro il lavoro delle altre, e per questo è la più utile: è l'unico punto del sistema dove qualcosa controlla qualcos'altro.

Il monitoraggio SEO settimanale. Un report, una volta a settimana, con i dati veri. Sostituisce un'ora di clic dentro le dashboard, e soprattutto rende visibile un andamento che a occhio non vedrei.

Il pattern comune è che nessuna delle tre è la più sofisticata del gruppo. Sono le tre che producono un artefatto che qualcuno legge e su cui poi si decide qualcosa.

Quattro mesi dopo: cosa è successo davvero a quelle ventuno

Qui finisce la fotografia di aprile. Questa sezione la scrivo a fine luglio 2026, con il vantaggio scomodo di sapere come è andata.

Le otto da spegnere sono state chiuse in due settimane. Il 7 aprile i due scanner di notizie duplicati sono stati fusi in uno solo. Il 15 aprile ne sono state disattivate sei in un colpo: le quattro della pipeline Instagram, il diario settimanale senza lettori, la dashboard di engagement senza dati. Nessuna di queste chiusure ha richiesto una decisione difficile, il che è esattamente il punto: erano già morte, mancava solo l'atto formale.

L'ipotesi sul crawl budget ha retto, e la correzione è stata immediata. Il 9 aprile la frequenza di pubblicazione del blog è scesa da quotidiana a tre volte a settimana, con un vincolo scritto nelle istruzioni di progetto invece che nelle mie intenzioni. Da lì il traffico organico ha una traiettoria che a inizio aprile non avrei scommesso: alla misura del 27 luglio 2026 la property registra 98.026 impressioni e 1.050 click negli ultimi 28 giorni, posizione media 5,52. Confrontato con le 510 impressioni e i 10 click dei 28 giorni di fine marzo, il salto è di due ordini di grandezza. Il driver non è la quantità: è un cluster di query commerciali su un tema preciso, dove un pugno di pagine profonde ha scalato posizioni. Pubblicare meno e più a fondo ha funzionato meglio di pubblicare tutti i giorni.

Il limite architetturale, quello vero, è costato una migrazione. Il 15 aprile cinque automazioni sono state spostate dalla mia macchina a un layer cloud che gira sull'infrastruttura del modello, senza dipendere dal fatto che il laptop sia acceso. Non erano cinque task tra i tanti: erano quelli che dovevano girare ogni giorno, sorveglianza del sistema compresa. Su come si progetta un sistema ibrido locale più cloud, e su cosa si rompe nel passaggio, ho scritto il seguito tecnico di questo pezzo in architettura ibrida Cowork e Routines cloud.

La lezione più cara è arrivata a luglio, quando ho spento il monitor di salute del sistema. Girava sulla stessa macchina che doveva sorvegliare, quindi quando la macchina non partiva, il guardiano non partiva con lei. Per trentasei ore nessuno se n'è accorto. Un guardiano che dipende dalla stessa macchina che sorveglia non è un guardiano, è una decorazione.

Delle ventuno, quante ne sono rimaste? La risposta onesta è che non è ricostruibile una a una. Otto sono state spente entro aprile e cinque sono state migrate altrove. Le altre nel frattempo sono state fuse, riscritte, spostate su un runtime diverso o sostituite da un'erede con un altro nome. Un mapping uno a uno lo potrei fabbricare, ma sarebbe una narrazione, non un conteggio.

Quello che posso contare è lo stato di oggi. Un audit interno del 18 luglio 2026 ha censito circa 62-65 automazioni attive su cinque runtime diversi: la mia macchina, il layer cloud, i job containerizzati, un piccolo server sempre acceso, l'app desktop. Il numero suona come un successo. Il dato interessante è un altro, ed è il motivo per cui l'audit è stato fatto: il rapporto tra le automazioni che sorvegliano il sistema e quelle che producono valore diretto è circa 1 a 1. Metà del sistema esiste per tenere in piedi l'altra metà. L'audit ha classificato cinque processi come candidati alla cancellazione, e da lì è nata una regola che ora sta scritta nelle istruzioni: prima di costruire una nuova automazione, va verificato che il processo che serve abbia una metrica scritta e che non sia meta-lavoro travestito da lavoro.

La pipeline Instagram, il fallimento più netto del pezzo, oggi pubblica. Non perché sia stata riparata: perché è stata ributtata via e riscritta come pipeline containerizzata che gira in cloud, con gate di qualità che possono bloccare la pubblicazione. Ha richiesto mesi e un ripensamento completo del formato. La diagnosi di aprile era corretta e insufficiente allo stesso tempo: il problema non era dove si rompeva il codice, era che non sapevo che cosa volevo pubblicare.

Una nota su cosa vuol dire "spento". I tre task di supporto disattivati a marzo, quelli senza diagnosi scritta, hanno ricevuto l'approvazione formale alla cancellazione il 15 luglio. A oggi sono ancora lì come record disabilitati, perché la cancellazione fisica si fa solo da un'interfaccia grafica e nessuno l'ha aperta. Quattro mesi tra "questa cosa non serve" e "questa cosa non c'è più", su un'automazione già spenta. Vale la pena tenerlo a mente quando si stima quanto costa disfare quello che si costruisce.

Come lo rifarei, in quattro passi

Non partite da ventuno. È il consiglio meno interessante e il più corretto.

1. Eseguite il processo a mano, fino in fondo, almeno tre volte. Se non lo avete mai portato a termine manualmente, non sapete dove si rompe, e automatizzerete un percorso che non arriva in fondo. La pipeline Instagram è morta esattamente qui.
2. Scrivete chi legge l'output prima di scrivere l'automazione. Un nome: una persona, un altro task, una pagina pubblica. Se non riuscite a scriverlo, quello che avete in mano è un file che si aggiorna da solo.
3. Automatizzatene una sola, e tenetela in osservazione per due settimane. Il tempo di manutenzione emerge solo dopo qualche ciclo. Un task che sembra gratuito il primo giorno può costare mezz'ora a settimana di correzioni.
4. Mettete un controllo che possa dire di no. Il gate che blocca la pubblicazione vale più della generazione. Senza un punto in cui il sistema si ferma, l'automazione amplifica gli errori alla stessa velocità con cui amplifica il lavoro buono.

C'è un passo zero, e me lo ha insegnato l'audit di luglio più di quanto me lo avesse insegnato la costruzione: prima di automatizzare un processo, chiedetevi se potete cancellarlo. Il lavoro che sparisce costa meno di quello che gira da solo. Su come questa logica si applica alla gestione di più clienti in parallelo ho scritto in Claude per consulenti B2B, e sul metodo di mappatura dei processi in automazione dei processi aziendali.

FAQ

Quanto tempo serve per costruire un ecosistema simile?

Le prime tre o quattro automazioni si costruiscono in due o tre settimane, lavorandoci nei ritagli. Quello che avevo in piedi al bilancio di aprile è il risultato di circa sei settimane. Il numero però è ingannevole, perché il tempo di costruzione è la parte piccola. La parte grande è il tempo di correzione: da lì è uscita una lista di sei problemi strutturali. Cinque sono stati chiusi entro due settimane dal bilancio, spegnendo o fondendo quello che li causava. Il sesto, cioè l'abitudine di scrivere perché si spegne qualcosa, è ancora aperto mentre pubblico questo pezzo.

Serve saper programmare?

Serve saper descrivere un processo con precisione. La parte di codice vero in questo sistema è minima e sta negli script che parlano con le API esterne. Il grosso sono istruzioni scritte in italiano, con vincoli espliciti e criteri di accettazione. La competenza che conta è quella di chi scrive procedure.

Quanto costa mantenerlo?

Le voci di spesa sono l'abbonamento al modello (la voce dominante), l'hosting, il dominio, l'invio email. Un totale preciso non lo pubblico: non tengo una contabilità separata di questo sistema, e preferisco dirvelo invece di darvi una cifra ricostruita a memoria. Il costo che sottovalutano tutti, me compreso, non è comunque quello: è il tempo di manutenzione. Il rapporto 1 a 1 tra automazioni di sorveglianza e automazioni di valore, misurato a luglio, è la forma che quel costo prende quando lo lasci crescere senza guardarlo.

Perché non usare uno strumento no-code?

È una scelta legittima e per molti processi è la scelta giusta. La ragione per cui non l'ho fatta è che il mio stato vive in file di testo dentro un repository con lo storico completo. Voglio poter leggere un diff e capire cosa è cambiato nel comportamento del sistema tre settimane fa. Con un editor visuale quella tracciabilità la perdo.

Le automazioni scrivono i contenuti al posto tuo?

Producono le bozze dentro vincoli che ho scritto io, e non pubblicano niente che non passi i controlli. Le regole di voce, gli anti-pattern linguistici e i criteri di qualità sono file che mantengo a mano. Quando la voce sbanda, il problema non è il modello: è che quel file non era abbastanza preciso.

Il sistema di allora esiste ancora?

Nella sua forma di aprile, no. Gira su cinque runtime invece che su uno, una parte importante non dipende più dal mio laptop, e diversi task di allora sono stati sostituiti da eredi con un altro nome. Quello che è sopravvissuto intatto è il livello che sembrava il meno tecnologico: le istruzioni scritte, i gate che possono dire di no, e l'abitudine di tenere il conto di cosa non serve.

La cosa che porto a casa

Su ventuno automazioni, quelle che cambiavano davvero la mia settimana erano tre. Otto erano da spegnere o da fondere, e infatti sono state chiuse tutte entro due settimane dal bilancio. Le restanti stavano in mezzo, facevano il loro lavoro, e non le avrei notate se fossero sparite.

Non è un fallimento del sistema. È il rapporto normale tra quello che costruisci e quello che serve, quando costruisci in fretta e misuri dopo. Il problema è che quel rapporto lo si scopre solo tenendo il conto, e il conto quasi nessuno lo tiene, perché contare le automazioni che non servono è meno soddisfacente che aggiungerne una nuova.

Quattro mesi dopo il conto dice sessanta e passa automazioni, metà delle quali servono a sorvegliare l'altra metà. Il numero da guardare, allora come adesso, è quante ne puoi togliere domani senza che cambi niente.

Se volete la versione operativa di questo metodo, il percorso con cui costruisco e soprattutto con cui decido cosa non costruire sta in Claude Mastery: è il corso in cui ho messo i vincoli, i gate e le checklist che qui ho solo raccontato.