Dai prompt agli agenti: come costruire sistemi AI davvero utili in agenzia
Skill, connettori, micro-app, knowledge base e automazioni: un metodo operativo per trasformare ChatGPT, Claude e Gemini da chatbot a strumenti di lavoro.
Una giornata di otto ore con un’agenzia di comunicazione specializzata in e-commerce è un ottimo stress test per capire dove siamo arrivati con l’intelligenza artificiale.
Non perché servano otto ore per imparare a scrivere un prompt.
Il problema interessante viene dopo.
Come trasformiamo un prompt che funziona in una procedura ripetibile?
Quando quella procedura merita di diventare una skill?
Quando ha senso collegarla ai software che utilizziamo già?
Quando può diventare una piccola applicazione?
E soprattutto: quando vale realmente la pena automatizzarla?
In aula avevo davanti circa venti professionisti della stessa azienda, ma con lavori diversi: account, sales, social, performance, e-commerce, management.
Quindi non avrebbe avuto alcun senso cercare «il miglior utilizzo dell’AI».
Un account ha problemi diversi da chi gestisce campagne.
Chi lavora sui feed di Google Shopping ha esigenze diverse dal social media manager.
Il titolare vede ancora un altro livello: costi, processi, sicurezza, continuità operativa.
La giornata è servita soprattutto a costruire una forma mentis comune.
Ed è questa che rimane utile anche quando cambiano i modelli, i pulsanti e i nomi dei prodotti.
Il vero salto: dal prompt al sistema
Possiamo rappresentare l’evoluzione in questo modo:
PROMPT
↓
PROCEDURA
↓
SKILL
↓
PROGETTO
↓
CONNETTORI
↓
MICRO-APP
↓
AUTOMAZIONE
↓
AGENTE
Non sono necessariamente passaggi obbligatori.
Non dobbiamo trasformare ogni prompt in un agente.
Anzi.
Il punto è capire che esistono livelli diversi di delega.
Un prompt risolve un problema.
Una procedura stabilisce come risolverlo.
Una skill rende quella procedura richiamabile.
Un progetto aggiunge contesto stabile.
Un connettore permette al sistema di interagire con gli strumenti nei quali lavoriamo.
Una micro-app costruisce un’interfaccia intorno al processo.
Un’automazione elimina alcune azioni manuali.
Un agente può arrivare a eseguire autonomamente una sequenza di operazioni.
La tecnologia cambia.
Questa logica molto meno.
Prima regola: non dare un task complesso tutto in una volta
Uno degli errori più comuni rimane questo:
Prendi tutto questo materiale, analizzalo, fai le ricerche, trova i problemi, proponi le soluzioni, crea il report e dammi il risultato definitivo.
Premiamo Invio.
Aspettiamo.
E speriamo.
Può funzionare.
Ma per un’attività professionale importante preferisco un approccio diverso.
Divido il lavoro.
STEP 1
Comprendi input, obiettivo e vincoli.
↓
STEP 2
Proponi il piano operativo.
↓
QUALITY GATE
Io verifico che la direzione sia corretta.
↓
STEP 3
Esegui.
↓
STEP 4
Controlla il risultato rispetto ai requisiti.
↓
STEP 5
Consegna il deliverable.
Non mi interessa vedere il ragionamento interno del modello.
Mi interessa vedere il piano operativo che intende seguire.
È diverso.
Se devo confrontare due dataset, voglio sapere prima se intende normalizzare le colonne, come gestirà i valori mancanti e quali KPI confronterà.
Se deve produrre una ricerca, voglio sapere quali fonti intende cercare e quali criteri utilizzerà.
Se deve analizzare un report, voglio sapere che cosa controllerà.
Correggere il processo prima dell’esecuzione costa molto meno che correggere un deliverable sbagliato alla fine.
Questo è il principio dei quality gate: dopo uno snodo importante, inserisco un controllo.
Il modello continua soltanto quando la direzione è plausibile.
La lezione da ricordare è:
Più aumenta il costo dell’errore, meno conviene utilizzare l’AI come una black box.
Il transcript della mattina insisteva proprio sulla trasformazione dei task complessi in sequenze controllabili, con verifiche intermedie e un controllo finale prima della consegna.
Prompt chaining: quando il prompt diventa una procedura
Quando una richiesta comincia ad avere diversi passaggi, non la considero più semplicemente un prompt.
È una procedura.
Supponiamo di dover generare ogni mese un report performance.
Potremmo scrivere:
Analizza questi dati e fammi il report mensile.
Oppure trasformare l’attività:
STEP 1
Leggi integralmente i dataset.
STEP 2
Identifica KPI disponibili e dati mancanti.
STEP 3
Confronta il periodo con quello precedente.
STEP 4
Individua variazioni significative e anomalie.
STEP 5
Separa fatti, possibili interpretazioni e raccomandazioni.
STEP 6
Controlla nuovamente i valori numerici.
STEP 7
Genera il report per il cliente.
Il secondo sistema possiede una caratteristica fondamentale:
posso controllarlo.
Posso modificare lo Step 3 senza riscrivere tutto.
Posso aggiungere un controllo allo Step 6.
Posso cambiare il formato dello Step 7.
Posso testare la procedura su dieci clienti e capire dove fallisce.
A quel punto non sto più cercando il prompt perfetto.
Sto progettando un processo.
Dove devono vivere le istruzioni?
Non tutte le regole devono essere inserite nello stesso posto.
Durante la lezione abbiamo distinto tre livelli.
1. Regole generali
Sono comportamenti che vogliamo quasi sempre.
Per esempio:
non inventare dati;
distinguere informazioni verificate e ipotesi;
dichiarare quando manca un dato necessario;
utilizzare fonti quando la richiesta richiede verifica.
2. Regole del progetto
Sono specifiche di un cliente, reparto o attività.
Per esempio:
brand voice del cliente;
KPI utilizzate nel report;
documentazione di riferimento;
struttura della reportistica;
glossario;
prodotti;
storico;
vincoli commerciali.
Un progetto può funzionare come uno spazio di lavoro con una propria base di conoscenza e istruzioni specifiche. È esattamente l’uso per cui, per esempio, Anthropic descrive i Projects di Claude: chat, documenti, contesto e istruzioni raccolti intorno allo stesso ambito operativo.
3. Istruzioni della singola operazione
Sono quelle che servono soltanto adesso.
Confronta settembre con agosto.
Analizza soltanto il traffico organico.
Genera la versione executive per il cliente.
La regola pratica è abbastanza semplice:
Più un’istruzione è stabile e ricorrente, meno ha senso riscriverla ogni volta.
Quando una procedura funziona, trasformala in una skill
Qui abbiamo fatto uno dei passaggi più pratici della giornata.
Abbiamo preso una procedura e l’abbiamo trasformata in una skill richiamabile.
L’esempio costruito in diretta era un Excel Auditor.
Il problema:
Prima di inviare un Excel a un cliente o a un altro reparto voglio un controllo tecnico.
Il compito della skill:
analizzare il file;
controllare formule problematiche;
cercare riferimenti errati;
individuare vuoti incoerenti;
trovare duplicati;
segnalare valori sospetti;
verificare struttura e consistenza;
produrre prima un report;
modificare il file soltanto dopo approvazione.
La cosa importante non era Excel.
Era la logica.
Una skill è utile quando prende un’attività che continuiamo a ripetere e la trasforma in una competenza richiamabile.
Le Agent Skills di Anthropic sono effettivamente progettate come pacchetti riutilizzabili di istruzioni e possono includere file e logiche di supporto; Anthropic ha inoltre pubblicato il formato come standard aperto.
La regola più importante
Una skill dovrebbe fare una cosa.
Non creerei:
Super Skill Marketing.
Che:
analizza competitor;
genera il piano editoriale;
controlla Analytics;
crea immagini;
scrive newsletter;
prepara il preventivo;
chiama tua madre.
Meglio:
Skill 01 → Audit Excel
Skill 02 → Analisi report mensile
Skill 03 → Controllo tracking UTM
Skill 04 → Brand Voice Rewriter
Skill 05 → SEO Performance Check
Skill 06 → Quality Check finale
Una competenza delimitata è più semplice da:
comprendere;
testare;
correggere;
aggiornare;
riutilizzare.
Le skill create direttamente dai partecipanti
Qui la teoria ha cominciato a diventare interessante.
Perché ognuno ha smesso di lavorare sul mio esempio e ha iniziato a costruire qualcosa per il proprio ruolo.
Un partecipante ha creato una skill che prendeva i file esportati dalle piattaforme advertising, analizzava le KPI, utilizzava come riferimento un esempio precedente e produceva un documento coerente con la reportistica abituale.
Un’altra skill prendeva un report PDF e produceva due livelli di lettura:
analisi tecnica per chi lavora sul cliente;
commento sintetico e comprensibile da inserire nel report destinato al cliente.
Alla fine preparava anche una bozza della mail di accompagnamento.
Un’altra ancora analizzava un CSV di Google Analytics concentrandosi sul canale organico:
CSV Analytics
↓
confronto periodi
↓
valutazione crescita / stabilità / calo
↓
segnali critici
↓
azioni consigliate
Durante il test il sistema aveva persino proposto di allargare la finestra temporale perché il volume dei dati era troppo basso per trarre conclusioni robuste.
Questo è esattamente il tipo di automazione che mi interessa.
Non «fammi il marketing».
Una cosa piccola.
Ripetitiva.
Misurabile.
Verificabile.
E soprattutto utile a qualcuno che quel lavoro lo fa davvero. Gli esercizi hanno prodotto skill dedicate alla reportistica, all’interpretazione dei dati per il cliente e al confronto delle performance SEO, con controlli e output diversi a seconda del ruolo.
La domanda che cambia prospettiva: «Che cosa posso creare da questo file?»
Nel pomeriggio abbiamo ribaltato il problema.
Di solito partiamo da quello che vogliamo ottenere.
Questa volta siamo partiti da quello che abbiamo già.
Un Excel.
Un report PDF.
Un CSV.
Una presentazione.
Un documento di analisi.
E abbiamo fatto una domanda molto semplice:
Che cosa posso creare partendo da questo file che sia utile per il mio lavoro?
È una domanda molto più potente di quanto sembri.
Perché spesso non sappiamo quali trasformazioni siano possibili.
Un prompt di partenza può essere:
Lavoro come [RUOLO]
in un'azienda che si occupa di [ATTIVITÀ].
Analizza integralmente il file allegato.
Individua massimo 7 cose realmente utili
che potrei creare partendo dalle informazioni contenute nel file.
Per ciascuna indica:
- cosa creare;
- formato di output;
- problema che risolve;
- utilità per il mio ruolo;
- difficoltà di realizzazione.
Non limitarti a report, riassunti o presentazioni.
Considera anche dashboard, simulatori, strumenti interattivi,
automazioni e micro-app.
Non proporre utilizzi che richiedano dati assenti dal file
senza segnalarlo chiaramente.
Con un report di competitive pricing sono emerse idee come:
dashboard di competitive intelligence;
simulatore di scenario;
battle card commerciale;
report di posizionamento;
generatore di offerte;
osservatorio competitivo;
sistema di alert.
Con dati Amazon sono emerse:
matrice di prioritizzazione degli ASIN;
alert sui prodotti a rischio;
brief per il team content;
executive summary per il cliente;
calendario stagionale;
talking point per la call.
Con un report performance:
alert sulle anomalie;
one-pager executive;
slide per la review;
ipotesi di riallocazione budget;
dashboard sintetica.
Non significa che siano tutte buone idee.
Anzi.
Il valore dell’esercizio non è accettare tutto ciò che propone l’AI.
È utilizzarla come sparring partner per esplorare possibilità che non avevamo considerato. L’esercizio ha prodotto proprio questo tipo di esplorazione partendo da file realmente utilizzati in agenzia.
Da un Excel a una dashboard interattiva
Il passo successivo è stato ancora più concreto.
Abbiamo preso file Excel e chiesto ai modelli non semplicemente di analizzarli, ma di trasformarli in qualcosa.
Per esempio:
Crea una dashboard HTML interattiva da questo dataset. Includi KPI, filtri, grafici e tabella di dettaglio.
Qui cambia completamente l’output.
Non otteniamo più una spiegazione.
Otteniamo un artefatto utilizzabile.
Claude definisce Artifacts proprio contenuti autonomi come documenti, siti HTML, visualizzazioni, diagrammi e componenti interattivi che possono essere modificati e riutilizzati.
Durante l’esercitazione sono nate dashboard da:
performance Amazon;
campagne advertising;
dati analitici;
competitività dei prezzi;
cluster prodotto.
Uno dei casi migliori riguardava un e-commerce nel quale i prodotti venivano classificati in base alla competitività del prezzo.
I report esistevano già.
Il problema era vedere rapidamente:
quanti prodotti erano competitivi;
quanti non competitivi;
come cambiavano i cluster nel tempo;
quali gruppi stavano crescendo o diminuendo.
La dashboard non sostituiva il sistema operativo sottostante.
Lo rendeva leggibile.
Ed è importante distinguere le due cose.
Analizzare automaticamente i prezzi è molto diverso dal permettere all’AI di modificarli automaticamente.
Sul primo scenario posso essere aggressivo nella sperimentazione.
Sul secondo voglio un umano che approvi.
Prezzi, budget pubblicitari, campagne e inventario sono esempi perfetti di processi nei quali il human in the loop continua ad avere molto senso. Il confronto emerso in aula ha sottolineato proprio la differenza tra utilizzare l’AI per leggere e rappresentare i dati e concederle direttamente il potere di modificare prezzi o investimenti.
Connettori: l’AI diventa interessante quando entra negli strumenti che usiamo già
Finché lavoriamo copiando e incollando, l’AI rimane in parte separata dal processo.
Il salto avviene quando può dialogare con:
Drive;
Gmail;
Calendar;
Notion;
Slack;
strumenti di publishing;
database;
documenti;
piattaforme operative.
I connettori servono proprio a ridurre la distanza tra conversazione e lavoro reale. Anthropic, per esempio, descrive i propri Connectors come integrazioni che permettono a Claude di utilizzare conoscenza e strumenti collegati e, dove consentito, compiere azioni su di essi.
Un mio caso personale mostrato durante la lezione era piuttosto semplice.
Negli anni avevo lavorato con moltissimi clienti.
Il punto comune tra quasi tutti era Gmail.
Contratti.
Conversazioni.
Date.
Richieste.
Progetti.
Ho quindi utilizzato quelle fonti per ricostruire progressivamente uno storico:
CLIENTE
↓
PROGETTI
↓
PERIODO
↓
TIPO DI INCARICO
↓
ORE
↓
INFORMAZIONI UTILI
È stato un lavoro pesante anche per il modello e l’ho suddiviso cliente per cliente.
Ma alla fine ho trasformato anni di materiale disperso in documentazione interrogabile.
Questo ci porta a un tema molto più importante dei connettori stessi.
La conoscenza aziendale è un asset
Che cosa succede quando una persona lascia l’azienda?
Rimangono i file.
Forse.
Rimangono i deliverable.
Sicuramente.
Ma dove rimangono:
le procedure che aveva imparato;
le eccezioni;
gli errori già commessi;
le soluzioni trovate;
le convenzioni;
il modo in cui gestiva un determinato cliente;
le informazioni che «sapeva soltanto lei»?
Spesso da nessuna parte.
Parte il passaggio di consegne.
Qualcuno crea un documento in fretta.
Qualcun altro cerca cartelle.
Cominciano i:
«Dove teneva quel file?»
«Chi sa come faceva questo report?»
«Questa cosa la seguiva Luca.»
L’intelligenza artificiale rende evidente un problema che esisteva già:
molte aziende non possiedono realmente la propria conoscenza.
La ospitano temporaneamente nella testa dei dipendenti.
Mail, Drive, procedure, documenti, progetti, call e note possono invece contribuire — con le dovute policy e selezioni — a costruire una base di conoscenza aziendale.
Non serve immaginare una fantascientifica «AI che sa tutto».
Basta iniziare con qualcosa di meno spettacolare:
documentare bene ciò che oggi sappiamo fare.
Durante la lezione ho mostrato anche una knowledge base costruita in Obsidian come esempio visivo di una rete di documenti collegati.
Il concetto non era lo strumento.
Era questo:
la conoscenza che riusciamo a strutturare oggi potrà alimentare i sistemi AI aziendali di domani.
Il tema è emerso esplicitamente discutendo passaggi di consegne, procedure e conservazione del know-how maturato negli anni.
Google Apps Script: prima del super-agente, spesso basta un piccolo software
Un altro passaggio molto utile è stato distinguere due cose.
Automazione e intelligenza artificiale non sono sinonimi.
Supponiamo che io abbia un Google Sheet.
Voglio che, quando seleziono una casella:
vengano controllati alcuni dati;
venga prodotta una dashboard;
parta una mail;
venga creato eventualmente un promemoria in Calendar.
Non necessariamente serve un agente AI.
Google Apps Script può bastare.
Un partecipante aveva già costruito esattamente un sistema di questo genere.
La logica era:
COMPILAZIONE DATI
↓
CONTROLLO
↓
APPROVAZIONE UMANA
↓
FLAG
↓
GENERAZIONE DASHBOARD
↓
INVIO EMAIL
La parte che mi piace di più è il flag.
Il sistema non invia autonomamente mentre qualcuno sta ancora lavorando.
Serve un gesto umano che dice:
Adesso è pronto.
È un quality gate trasformato in interfaccia.
Un altro team utilizzava invece Apps Script insieme all’API di un modello AI per ottimizzare attributi di catalogo destinati a Google Merchant Center.
Qui entra l’intelligenza artificiale:
CATALOGO GREZZO
↓
GOOGLE SHEET
↓
SCRIPT
↓
API LLM
↓
OTTIMIZZAZIONE ATTRIBUTI
↓
NUOVO SHEET
↓
MERCHANT CENTER
Ed è qui che compare un’altra variabile.
Il costo.
Gli esempi concreti mostrati dai partecipanti comprendevano sia workflow puramente deterministici sia workflow nei quali Apps Script chiamava un modello tramite API per trasformare i dati.
L’AI non è gratis: prima di automatizzare, fate i conti
Un abbonamento mensile ci abitua a pensare all’intelligenza artificiale come a un costo fisso.
L’automazione cambia il modello.
Quando iniziamo a utilizzare API, agenti, generazione di contenuti su larga scala, video o workflow che si attivano continuamente, il consumo diventa una variabile progettuale.
Non significa che sia troppo costoso.
Significa semplicemente:
va misurato.
Una procedura che utilizziamo due volte al mese può costare pochissimo.
Un agente che ogni ora:
cerca;
legge;
ragiona;
genera;
controlla;
modifica;
richiama altre API;
è completamente diverso.
Per questo non partirei mai da:
Automatizziamo tutto.
Partirei da:
Quanto costa oggi il processo umano?
Quanto tempo richiede?
Quanto costa l'esecuzione AI?
Quante volte viene eseguita?
Quanto costa un errore?
Quanta supervisione resta necessaria?
Il processo deve davvero essere autonomo?
E quando colleghiamo un metodo di pagamento a un’API, la gestione dei limiti di spesa, delle credenziali e dei secret deve diventare parte del progetto, non un dettaglio aggiunto alla fine.
Google AI Studio, per esempio, oggi gestisce le API key lato server nei propri progetti e avverte esplicitamente che le chiamate effettuate dalle app condivise incidono sui limiti di utilizzo e possono produrre costi con modelli a pagamento.
Un principio poco sexy: non perdete la capacità di fare il lavoro
C’è un altro rischio.
Delegare talmente tanto da non sapere più come funziona il processo.
Se il report mensile esiste soltanto perché «lo fa l’agente», abbiamo un problema.
Cosa succede se:
il servizio non è disponibile;
cambia l’API;
il costo aumenta;
l’integrazione si rompe;
il modello comincia a produrre anomalie?
Per un processo critico voglio ancora qualcuno che capisca:
cosa entra;
cosa dovrebbe succedere;
cosa deve uscire;
come verificare il risultato.
Non significa fare manualmente per sempre tutto il lavoro.
Significa non trasformare l’automazione in una dipendenza incomprensibile.
La posizione che ho sostenuto in aula era volutamente prudente: utilizzare l’AI prima di tutto come amplificatore e supporto, non come sostituzione indiscriminata di processi che l’azienda non sarebbe più in grado di governare.
Pomelli: non serve soltanto chiedersi se è abbastanza bello
La parte pomeridiana si è spostata verso strumenti più creativi.
Uno dei test riguardava Pomelli, esperimento di Google Labs pensato per comprendere l’identità di un business e generare contenuti coerenti con essa.
Google lo descrive come uno strumento capace di costruire il Business DNA di un’azienda partendo dal sito — voce, font, colori e identità — e utilizzarlo per generare contenuti e campagne. Nel 2026 Google ha aggiunto anche brand book e funzionalità di creazione di siti.
Per un’agenzia e-commerce, però, la domanda interessante non era:
Possiamo sostituire il reparto creativo con Pomelli?
No.
La domanda interessante era:
Che cosa significa per il mercato quando un piccolo e-commerce può produrre in pochi minuti mockup, ambientazioni prodotto e semplici asset social?
Abbiamo testato:
estrazione del brand;
catalogo prodotti;
ambientazioni;
immagini indossate;
semplici campagne;
animazioni.
Sono emersi anche i limiti.
Font mancanti.
Proporzioni sbagliate.
Modelli ripetuti.
Prodotti interpretati male.
Packaging modificato.
Parti del prodotto «immaginate» perché mancava una reference.
Ed è qui che è emersa una regola applicabile a moltissimi strumenti generativi:
Se l’AI non sa com’è fatto qualcosa, lo inventerà.
Se mi serve mostrare un prodotto aperto, è molto meglio darle anche la reference del prodotto aperto.
Se mi serve mantenere una fibbia precisa, devo darle materiale sufficiente e controllare.
Se il prodotto deve essere commercialmente fedele, «sembra bello» non è un criterio sufficiente.
I test dei partecipanti hanno mostrato proprio questi limiti: font non recuperati, proporzioni discutibili, prodotti interpretati in modo errato e problemi quando mancava una reference visiva adeguata.
Fotografo o AI? La domanda è sbagliata
Durante questa parte è nata una discussione interessante.
Quanto viene ancora fotografato realmente per un e-commerce?
Quanto viene generato?
La risposta più sensata emersa è stata:
dipende dal livello e dal momento del processo.
Per molti prodotti può avere senso mantenere uno scatto reale e utilizzare l’AI per:
ambientazioni;
varianti;
mockup;
contenuti social;
esplorazione creativa;
previsualizzazione.
Per una campagna importante, un prodotto complesso o un brand per cui ogni dettaglio deve essere perfetto, il livello di controllo richiesto cambia completamente.
E c’è un altro errore commerciale da evitare:
«Se lo facciamo con l’AI allora costa zero.»
No.
Cambiano i costi.
Servono strumenti.
Servono competenze.
Servono iterazioni.
Serve controllo.
Serve qualcuno che sappia distinguere un risultato utilizzabile da una schifezza prodotta in trenta secondi.
L’AI abbassa il costo di alcune fasi.
Non rende automaticamente professionale ciò che genera.
Stitch: dal brief al prototipo in pochi minuti
Un altro esperimento molto interessante è stato Stitch.
Google lo sta sviluppando come ambiente AI-native per creare e iterare interfacce partendo dal linguaggio naturale, arrivando a prototipi interattivi ed esportazioni verso altri strumenti di sviluppo.
In aula lo abbiamo utilizzato per generare:
homepage;
schede prodotto;
landing page;
piccoli flussi;
interfacce di applicazioni.
Un partecipante ha creato rapidamente homepage e scheda prodotto per un e-commerce di occhiali.
Un’altra prova riguardava contenuti Amazon A+.
Un'altra landing page ha invece mostrato perfettamente un limite del sistema: partendo da una reference che conteneva elementi di più brand, Stitch aveva mescolato i linguaggi visivi.
Non era un bug misterioso.
Era un problema di input.
Reference ambigua → design ambiguo.
La velocità resta impressionante.
Ma velocità e qualità non sono sinonimi.
La lezione che mi interessa è questa:
Utilizzate il vibe design per comprimere la fase di esplorazione, non per abolire il design.
Prototipo non significa prodotto
Da Stitch siamo arrivati naturalmente a Google AI Studio.
Oggi AI Studio permette effettivamente di costruire applicazioni web full-stack e app Android a partire da prompt, mostrando codice e anteprima e permettendo di continuare poi lo sviluppo.
È impressionante.
Ed è proprio per questo che bisogna evitare una conclusione sbagliata:
Se posso creare un’app in dieci minuti, posso metterla in produzione in dieci minuti.
No.
C’è una distanza enorme tra:
IDEA
→
PROTOTIPO
e:
PROTOTIPO
→
PRODOTTO SICURO
→
UTENTI REALI
→
DATI REALI
→
PAGAMENTI
→
MANUTENZIONE
Un tool interno che legge un foglio e mi aiuta a classificare dei contenuti è una cosa.
Un e-commerce che raccoglie carte di credito è un’altra.
Un prototipo può essere costruito quasi interamente in linguaggio naturale.
Un prodotto pubblico deve affrontare:
autenticazione;
autorizzazioni;
sicurezza;
privacy;
error handling;
gestione dei secret;
database;
performance;
manutenzione;
aggiornamenti.
Il vibe coding è un enorme acceleratore.
Non sospende l’ingegneria.
Flow: l’AI come strumento di previsualizzazione
L’ultimo grande esperimento creativo della giornata è stato Google Flow.
Google lo definisce uno strumento di filmmaking AI costruito intorno a Veo, Imagen e Gemini per creare clip e scene cinematografiche.
Siamo partiti da una fotografia di prodotto.
Poi da un’idea molto sommaria per uno spot.
Il sistema ha aiutato a espanderla:
IDEA
↓
STORYBOARD
↓
PERSONAGGIO
↓
AMBIENTAZIONE
↓
INQUADRATURE
↓
APPROVAZIONE
↓
CLIP
↓
SEQUENZA
La parte interessante non era soltanto il risultato.
Era il dialogo.
La protagonista non mi convince.
Cambio.
Voglio un taglio di capelli diverso.
Cambio.
Fammi prima vedere lo storyboard.
Approvazione.
Adesso genera la scena.
È ancora una volta lo stesso schema visto al mattino.
Step. Verifica. Esecuzione.
Abbiamo iniziato parlando di prompt chaining per un report.
Siamo finiti a utilizzarlo per costruire uno spot.
La metodologia non cambia.
Cambiano gli output.
La domanda che torna sempre: qual è l’AI migliore?
A un certo punto è arrivata inevitabilmente:
Claude, ChatGPT o Gemini? Qual è migliore?
La mia risposta rimane poco spettacolare.
Per moltissime attività quotidiane generaliste, il modello migliore è spesso quello con cui riusciamo realmente a lavorare bene.
Poi emergono differenze.
Un modello può risultare migliore per una determinata attività.
Un ecosistema può integrarsi meglio con i software che utilizziamo.
Un prodotto può offrire una funzione che un altro non possiede.
Uno strumento verticale può battere tranquillamente tutti i generalisti nel proprio campo.
Ma non costruirei un metodo di lavoro aziendale intorno alla convinzione che il modello che oggi vince un benchmark rimarrà il migliore per sempre.
Costruirei invece procedure abbastanza chiare da poter essere spostate e adattate.
È una delle ragioni per cui mi interessa molto di più insegnare:
input
↓
procedura
↓
controllo
↓
output
che insegnare dove si trova oggi un particolare pulsante.
La domanda sui diversi modelli è emersa direttamente durante l’esercitazione sugli artefatti e la risposta in aula era già orientata alla scelta in funzione del lavoro e dell’ecosistema, non alla ricerca di un vincitore assoluto.
La forma mentis agentica viene prima dell’agente
Arriviamo così al punto più importante dell’intera giornata.
Un agente non nasce quando apriamo n8n, Zapier o un altro software.
Nasce molto prima.
Nasce quando guardiamo un lavoro e riusciamo a descriverlo così:
TRIGGER
Quando arriva X
↓
ACQUISISCI
Prendi questi dati
↓
ANALIZZA
Esegui questi controlli
↓
DECIDI
Applica questi criteri
↓
QUALITY GATE
Se accade Y, chiedi approvazione
↓
AZIONE
Genera / aggiorna / salva / invia
↓
LOG
Registra ciò che hai fatto
Questo è già pensiero agentico.
Poi possiamo farlo manualmente.
Poi trasformarlo in una skill.
Poi collegare una sorgente.
Poi automatizzare il trigger.
Poi, eventualmente, lasciare che una parte del processo avvenga in autonomia.
Ma se non sappiamo descrivere il processo, l’agente non risolve il problema.
Lo nasconde.
Non iniziate dall’agente
La tentazione è fortissima.
Facciamo un agente che gestisce il new business.
No.
Prima:
Come gestiamo oggi il new business?
Quali fonti utilizziamo?
Come scegliamo un prospect?
Quali escludiamo?
Che informazioni raccogliamo?
Come valutiamo se vale la pena contattarlo?
Che cosa deve contenere il primo messaggio?
Quando serve un controllo umano?
Dove registriamo il risultato?
Soltanto dopo possiamo immaginare:
ricerca
↓
qualificazione
↓
audit
↓
documento
↓
CRM
↓
bozza email
A quel punto l’automazione diventa comprensibile.
La stessa regola vale per reportistica, SEO, social, advertising, amministrazione ed e-commerce.
Partirei sempre così
Scegli una task piccola.
Deve essere ripetitiva.
Deve avere un risultato verificabile.
Descrivi come la fai oggi.
Dividila in step.
Inserisci i controlli.
Provala manualmente con l’AI.
Trasformala eventualmente in skill.
Collegala agli strumenti solo quando funziona.
Automatizzala soltanto quando sai misurarne errori, costi e benefici.
È molto meno sexy di:
Abbiamo 14 agenti autonomi.
Però probabilmente funziona meglio.
Il messaggio dato in aula era esattamente questo: iniziare gli esperimenti agentici da task piccoli, non critici, misurabili e verificabili, mantenendo un periodo di controllo umano prima di concedere maggiore autonomia.
I concetti che devono rimanere
Dopo otto ore di strumenti, prove, errori, dashboard, skill, prototipi, immagini, video e API, non vorrei che rimanesse un catalogo di software.
Vorrei rimanessero questi principi.
1. Un buon output nasce prima dell’output
Se il compito è ambiguo, anche un modello potentissimo dovrà prendere troppe decisioni al posto nostro.
2. Le attività complesse vanno spezzate
Comprensione → esecuzione → verifica → consegna.
3. Le procedure ripetibili devono smettere di vivere soltanto nella nostra testa
Scriviamole.
Testiamole.
Miglioriamole.
4. Una skill deve avere un lavoro riconoscibile
Più è chiara la responsabilità, più è semplice verificarla.
5. I connettori hanno valore quando eliminano passaggi inutili
Non colleghiamo strumenti perché possiamo.
Colleghiamoli perché risolvono un attrito reale.
6. Non tutto ciò che può essere automatizzato deve essere automatizzato
Prezzi, investimenti, invii esterni e dati critici meritano quality gate.
7. Automazione non significa necessariamente AI
A volte basta Apps Script.
Ed è meglio così.
8. Un prototipo generato in cinque minuti non è un prodotto finito
Vibe coding e vibe design comprimono enormemente il tempo di esplorazione.
La produzione rimane un altro mestiere.
9. I costi fanno parte dell’architettura
Token, API, generazioni e supervisione non possono essere ignorati quando un esperimento diventa processo.
10. La conoscenza aziendale va raccolta prima di poter essere interrogata
L’AI non crea magicamente il know-how che non abbiamo documentato.
11. L’agente viene alla fine
Prima dobbiamo sapere che cosa deve fare.
Dal chatbot all’infrastruttura di lavoro
Il punto d’arrivo non è avere un chatbot più intelligente.
È molto più interessante.
Immagino un’azienda nella quale ogni reparto possiede progressivamente:
CONTESTO AZIENDALE
│
├── knowledge base
├── clienti
├── procedure
└── policy
COMPETENZE
│
├── audit dati
├── reportistica
├── SEO analysis
├── brand voice
├── quality control
└── competitive intelligence
STRUMENTI
│
├── Gmail
├── Drive
├── Analytics
├── Sheets
├── Calendar
└── piattaforme operative
AUTOMAZIONI
│
├── trigger
├── controlli
├── approvazioni
└── output
A quel punto l’AI non è più il sito che apro quando mi serve una frase.
Diventa uno strato operativo dell’azienda.
Ma arrivarci saltando direttamente all’agente è probabilmente il modo peggiore.
La sequenza corretta è molto più noiosa.
E molto più solida.
Capisci il lavoro.
Descrivi il lavoro.
Dividilo in step.
Controllalo.
Rendilo ripetibile.
Collegalo.
Misuralo.
E soltanto dopo, se ne vale davvero la pena, automatizzalo.
Perché alla fine un agente AI sofisticatissimo rimane costruito sulla stessa domanda con cui abbiamo iniziato:
Sai spiegargli esattamente che cosa deve fare?
Se la risposta è no, il problema non è ancora l’intelligenza artificiale.
Il problema è il processo.