Sto costruendo INAZUMA da zero. La parte difficile non è il codice.
Sono partito chiedendomi quale tool imparare. Poi ho capito che la domanda interessante era un’altra: quale problema vale davvero la pena trasformare in un sistema?
Non sono partito con una vocazione mistica per la programmazione. Sono partito cercando una direzione. Volevo capire cosa potevo costruire con l’AI che avesse valore fuori da una demo, e per un po’ ho fatto quello che fanno in tanti: ho guardato tool, automazioni, agenti, video, workflow. Ogni cosa sembrava la prossima cosa da imparare.
Il problema è che imparare un altro tool non ti dice cosa costruire. A un certo punto ho smesso di chiedermi “come faccio questa automazione?” e ho iniziato a chiedermi “che sistema dovrebbe esistere qui?”. È una differenza piccola nella frase e gigantesca nel lavoro.
Il pattern che continuava a ripetersi
Partivo da un pezzo singolo e finivo sempre per allargare il perimetro. Un AI receptionist diventava: chiamata, intent, calendario, CRM, follow-up, eccezioni, handoff umano. Un sistema per riattivare lead diventava: segmentazione, contesto, messaggio, risposta, qualificazione, booking, aggiornamento dati. Non riuscivo più a vedere il nodo singolo senza vedere tutto quello che c’era intorno.
Costruire mi ha fatto cambiare idea più delle ricerche
La parte utile dei prototipi non è stata poter dire “guarda, funziona”. È stata scoprire dove non funzionavano. La latenza in una chiamata vocale. Un dato sporco che rompe un workflow. Un caso limite che non avevo previsto. Una knowledge base che sulla carta sembra perfetta e nella pratica contiene tre versioni della stessa informazione.
Ogni volta il problema interessante era un livello sotto rispetto a quello che avevo immaginato. E ogni volta il prodotto diventava meno “AI” da copertina e più architettura, dati, controllo e integrazione.
Il rischio vero: cambiare direzione troppo velocemente
Ho tante idee. È utile, ma è anche pericoloso. Ogni nuova idea sembra più pulita di quella che stai già costruendo, semplicemente perché non hai ancora incontrato i suoi problemi. Sto imparando che la disciplina non è trovare l’idea perfetta: è restare abbastanza a lungo su una direzione da ottenere una risposta reale dal mercato.
Da automazioni isolate a sistemi
INAZUMA oggi nasce da qui: non vendere “un chatbot”, “un workflow” o “un agente” come se fossero prodotti autosufficienti. Prima capire il processo, poi progettare il sistema che lo prende in carico. Contesto, intelligenza, azione. Il tool viene dopo.
Non so ancora dove arriverà. Preferisco dirlo così invece di riscrivere la storia tra due anni facendo sembrare tutto inevitabile. La parte interessante, per me, è proprio questa: costruire mentre sto ancora capendo cosa merita davvero di essere costruito.
Non serve sapere già dove arriverà. Serve capire abbastanza bene cosa vale la pena continuare a costruire.
Se INAZUMA cambia direzione, questo pezzo dovrebbe invecchiare insieme al progetto. È più interessante così che fingere, tra due anni, che il percorso fosse ovvio fin dall’inizio.
Dal Journal
Ho costruito un AI receptionist. Il problema non era la voce.
Cosa costa davvero un AI receptionist e cosa si scopre costruendone uno: latenza, integrazioni, casi limite, ROI e differenza tra una demo e un sistema.
Quanto costa una sedia vuota? Il no-show è un problema più interessante di quanto sembri.
No-show negli studi odontoiatrici: costo operativo, recall, validazione e cosa imparare quando un problema adiacente sembra più forte del progetto principale.
Tre nodi n8n e un LLM non fanno un AI System.
La differenza tra workflow con AI e AI system: contesto, intelligenza, azione, feedback e gestione delle eccezioni.