Nota: da quando è uscito questo articolo, l’app desktop si chiama FabricLoom e funziona su macOS, Windows e Linux.

Gran parte del dibattito attuale sull’IA locale si concentra sui modelli: quale modello eseguire, quanto è veloce, quanta VRAM serve, se è «agentic» e quanto si avvicina alle prestazioni del cloud. Sono domande che contano, ma credo che trascurino un problema più di fondo: l’IA locale è ancora difficile da usare all’interno dei normali flussi di lavoro software.

Si può scaricare un modello, avviare un’interfaccia di chat e magari puntarlo su una cartella. Ma nel momento in cui si vuole fare qualcosa di concreto con i file — convertire questo PDF, estrarre questa tabella, riassumere questi documenti, trascrivere questo audio, classificare queste immagini, trasformare qualcosa in dati strutturati e poi passare quel risultato a un altro strumento — le cose si complicano in fretta. Ogni app inventa il proprio modello di plugin. Ogni strumento di workflow inventa la propria astrazione. Ogni framework di «agenti» vuole diventare la sala di controllo.

Penso che la direzione migliore sia più noiosa e più utile: decostruire i pacchetti software in piccole utility tipizzate.

È questo che sto costruendo con MachineFabric. L’idea è trattare gli strumenti basati sull’IA più come comandi Unix, ma aggiornati per l’IA locale e per i flussi di lavoro moderni sui file. Una cartuccia è un’utility mirata: accetta un tipo noto di input, produce un tipo noto di output e può essere collegata ad altre cartucce. Una cartuccia da PDF a testo non ha bisogno di sapere nulla del report finale. Una cartuccia di embedding non ha bisogno di sapere nulla dell’interfaccia. Una cartuccia di riassunto non ha bisogno di possedere l’intero flusso di lavoro. Ciascun pezzo dovrebbe fare il suo lavoro, dichiarare cosa accetta e cosa produce e lasciare che sia il sistema a comporli.

In MachineFabric queste composizioni sono DAG tipizzati tra tipi di file su macOS. Si parte dai file, il sistema trova le trasformazioni possibili, le cartucce si collegano tra loro e il flusso di lavoro resta locale, deterministico e ispezionabile.

Alla base c’è CapDAG, un protocollo aperto per il dispatch tipizzato delle capacità. Descrive cosa può fare una cartuccia, come si abbinano le capacità e come una trasformazione può essere collegata a un’altra. L’obiettivo non è solo «plugin per un’app», ma un modo portabile di impacchettare piccole capacità e smistarle tra linguaggi e runtime.

È anche il motivo per cui sono scettico sulla parola «agentic». Molta automazione utile con l’IA non richiede di fingere che il software sia dotato di autonomia. Richiede trasformazioni affidabili, confini chiari e strumenti componibili. Anche flussi di lavoro complessi si possono spesso descrivere come un grafo di passi concreti: estrarre, trasformare, cercare, ordinare, riassumere, validare, scrivere. Non è meno potente. È solo più onesto.

La mia esperienza con gli LLM è che sono molto utili, ma hanno un limite nel ragionamento. Per questo mi interessa meno mettere un «agente» nella sala di controllo e molto di più costruire macchinari migliori per il reparto produttivo.

MachineFabric supporta oggi diversi backend LLM locali: llama.cpp (GGUF), MLX e Candle. Si può incollare l’ID di un modello Hugging Face, scaricarlo e ogni cartuccia in grado di usare quel modello lo riconosce. Un piccolo modello da 0,5B e un grande modello da 70B diventano motori diversi dietro lo stesso sistema di capacità.

L’idea per l’utente è semplice: clic destro su un file, si sceglie cosa si vuole che diventi e si lascia lavorare il grafo tipizzato. Stesso Finder, stessi file, nuove trasformazioni.

Questo è il problema che sto cercando di risolvere: l’IA locale non dovrebbe vivere solo dentro le chat o in app monolitiche. Dovrebbe essere confezionata in piccole utility concrete e tipizzate, componibili in flussi di lavoro reali. Questo è MachineFabric e, alla base, CapDAG.