Nei vari esperimenti personali con gli LLM non avevo ancora dedicato un po’ di tempo a sperimentare un sistema agentico di base, ovvero un’architettura in cui un orchestratore organizza e regola l’attività di sub agenti dedicati a task specifici. Per farlo, ho deciso di ideare quello che poi è diventato Pipeline, un web magazine dedicato all’impatto dell’AI nel mondo del digital product design, ovvero il perimetro ampio nel quale mi muovo professionalmente, gestito interamente da un team di agenti AI che si occupano di tutte le attività editoriali: ricerca e selezione del tema, scrittura dell’articolo, creazione della cover grafica, fact checking e verifica del testo, pubblicazione.
Primo step: l’ambiente
Ho scelto di utilizzare Claude , con cui ho attiva una subscription Pro, e il framework Hugo, che uso con soddisfazione per tutti i miei siti (compreso questo, qui alcune info sul setup di Hugo).
La prima cosa che ho fatto è stata installare Claude Code CLI (avrei potuto installare l’app per Mac ma ho preferito e preferisco lavorare con il terminale):
curl -fsSL https://claude.ai/install.sh | bash
Poi ho creato una cartella per il progetto, mi sono posizionato in quella cartella, e ho lanciato Claude:
cd ~/Documents/personali/HUGO/pipeline-magazine
claude
Ed ecco l’interfaccia di Claude CLI in tutto il suo splendore vintage dal sapore MS-DOS d’antan:

Da quel momento in poi, ogni iterazione è avvenuta in linguaggio naturale, demandando a Claude ogni attività pratica (codice, comandi da terminale, ecc). Dopo aver inizializzato git e settato l’origin al repo Github nel frattempo creato, ho iniziato il lavoro vero e proprio:
- Ho creato il sito di base con Hugo, con alcune semplici indicazioni di base per un MVP decente
- Ho lanciato il comando
hugo serverper vedere su localhost le modifiche in tempo reale (se hugo è in esecuzione, fa un reload automatico a ogni modifica dei file) - Ho iterato su stile, colori, layout dei contenuti in home
- Ho lasciato Claude propormi il nome (accogliendo la prima proposta 😀)
A quel punto avevo un ambiente funzionante, con una navigazione di base (homepage e pagina articolo). Era arrivato il momento di creare il team editoriale.
Il team agentico
Gli agenti, il vero team editoriale del progetto, sono stati creati definendo prima i ruoli principali (ricerca, scrittura, verifica, pubblicazione), fino alla modellazione completa tramite iterazioni successive sempre più complesse. Nel momento in cui scrivo il team è composto da 7 agenti qui riportati in ordine di “ingaggio” da parte dell’orchestratore:
1. News researcher
Cerca notizie reali e aggiornate su AI applicata a product design e sviluppo software. Partendo dalle 5 categorie definite nel piano editoriale (ovvero Product Design, Development, Design Engineering, Prototyping, Creative Tooling), analizza le fonti e propone un angolo (in italiano diciamo “punto di vista” o “prospettiva”) specifico e non duplicato per un nuovo articolo, verifica che il tema non sia già stato trattato consultando l’indice degli angoli (che viene aggiornato alla creazione di ogni nuovo articolo) e restituisce il brief (tema, taglio, fonti citate) da passare allo stadio di scrittura.
2. Article writer
Scrive l’articolo editoriale in inglese (700-800 parole) nel tone-of-voice (ben descritto) del magazine. Parte dal brief di tema, angolo e fonti prodotto dal ricercatore, crea il file Hugo content/posts/*.md con il front matter corretto, e produce il corpo definitivo del pezzo, pronto per gli stadi successivi.
3. Chart Builder
Valuta se il testo dell’articolo contiene dati reali e confrontabili che possano giovarsi dell’aiuto di un grafico, e in caso positivo inserisce un grafico Chart.js tramite lo shortcode chart del sito. Costruisce il grafico solo con i numeri già presenti nel testo, rigorosamente senza inventarne, e interviene dopo la scrittura del corpo e prima della scelta della cover. Ovviamente in tinta con lo stile del sito.
4. Cover Image Picker
Qui mi sono proprio divertito. Inizialmente sono partito con il modello Flux tramite le API di Fal.ai. Poi ho capito che questo iperrealismo (impressionante eh) c’entrava davvero poco e nulla. Allora ho provato ad andare in una dimensione più astratta: prima ho generato un’immagine geometrica di riferimento con ChatGPT, che poi ho fornito a Claude per dargli un’indicazione del risultato. Poi ho definito la palette e i vincoli, spiegando la necessità di avere un elemento prevalente concettualmente collegato al contenuto dell’articolo, e a forza di prova e revisione è venuto un agente davvero brillante, che sfrutta Nano Banana con Gemini 2.5 Flash Image (con chiamata tramite API) che adotta uno stile illustrativo mid-century / vintage screen-print, piatto e geometrico con un elemento focale specifico dell’articolo e fino a tre colori armonici con blend-lock. L’agente genera l’immagine, fa una prima verifica che sia ok, poi la salva in locale e aggiorna il campo image nel front matter del post.
Basta vedere i risultati su 11 articoli per valutare la resa qualitativa, ma soprattutto la coerenza di stile (nessuna di queste immagini ha richiesto revisione post generazione).
5. Metadata Enricher
Questo agente nasce a seguito di una mia fissazione recente (di cui tornerò a parlare): il tagging dei contenuti web tramite i metadati strutturati di schema.org, che dovrebbe aiutare i motori di ricerca (e in teoria anche gli LLM, ma su questo c’è dibattito) a comprendere meglio il contesto dei contenuti, evitando quindi allucinazioni date da scarsa chiarezza semantica. L’agente inietta i dati strutturati schema.org nel frontmatter, e con la build, questi tag vengono inseriti in formato JSON-LD nell’head dell’HTML.
6. Github Publisher
Committa (eh, I know…) il nuovo articolo - comprensivo di cover e eventuali grafici - su un branch dedicato, e poi effettua il push sul remoto GitHub (origin) aprendo una PR, lasciando (e questo è fondamentale) la revisione finale e il merge allo stadio successivo.
7. PR Reviewer
Usando lo stesso meccanismo della code review, il PR Reviewer si occupa di fare una vera e propria revisione del testo: esegue il fact-checking e la revisione di qualità finale della PR dell’articolo (mi è già capitato che abbia corretto quote non verificate e non attribuibili), controlla il blocco dei dati strutturati, “guarda” (incredibile eh) immagini e grafici per verificare che siano ben fatti, e alla fine esegue il merge, ma solo se la revisione viene superata.

nuovo-articolo e sorveglia tutto il processo, e qui a fianco è visibile la struttura finale dei file. Per far partire tutta l’orchestra è sufficiente usare in Claude Code il comando /nuovo-articolo [categoria opzionale]. Notare il file settings-local in cui vengono definiti in formato JSON tutta una serie di abilitazioni, blocchi di sicurezza e altre impostazioni che guidano l’orchestrazione.
Automatizzare o sorvegliare il processo?
Mi intrigava molto l’idea di lasciar fare gli agenti da soli, e ho provato a impostare una routine attivata da un comando /schedule in Claude Code, che funziona anche a computer spento perché si scarica un clone dal repo remoto, con l’idea di generare un nuovo articolo automaticamente ogni due giorni. La prima cosa che ho dovuto fare è stata garantire nei settings tutta una serie di autorizzazioni per procedere con comandi e operazioni sui file direttamente sul computer, perché ovviamente non si dà per scontato di default che qualunque intervento sul file system sia gradito. Poi ho dovuto ricostruire nell’ambiente remoto tutte le variabili d’ambiente settate in locale (API key soprattutto). Alla fine funziona, e anche bene, ma spesso e volentieri si inceppa per un bug noto per cui Claude Code blocca l’accesso a domini esterni nonostante l’impostazione “All domains” nell’allow-list.
C’è poi da dire un’altra cosa: il processo non deve essere frequentissimo, non dura più di 10/15 minuti ed è comunque gradevole seguirlo mentre ti bevi un caffè. Mo’ va bene l’automazione ma insomma, val la pena almeno stare lì a godersi lo spettacolo e intervenire con un paio di pigre pressioni del tasto Enter quando Claude ci fa una domanda.
Piuttosto, sto pensando a delle routine di link checking e di verifica delle fonti da schedulare indipendentemente dalla creazione degli articoli. Ma vedremo!
