Piattaforma Converged AI

Converged AI è una piattaforma open-source per aziende manifatturiere: service di stampa 3D, officine CNC, laboratori R&D e reti di piccole officine.

Il suo compito è occuparsi di tutto ciò che accade intorno alla produzione: richieste, file, preventivi, code, stati degli ordini, comunicazione con i clienti, attrezzature, pagamenti, consegne e vendite ricorrenti. Le macchine continuano a produrre pezzi, il team continua a prendere decisioni tecniche, e Converged collega tutto in un sistema gestibile.

La piattaforma include 17 soluzioni raggruppate in quattro aree: ordini e clienti, produzione e scorte, denaro e profitto, team e responsabilità. Non sono “moduli per fare moduli”, ma scenari pronti per problemi concreti dell’officina.

Cosa fa Converged

Un’azienda manifatturiera ha due livelli di lavoro. Il primo è produrre il pezzo, assemblare il prodotto e completare l’ordine. Il secondo è tutto ciò che deve accadere prima, durante e dopo la produzione: accettare una richiesta, non perdere il file, concordare il prezzo, mettere il lavoro in coda, avvisare il cliente, capire il carico delle macchine, vedere i ritardi e incassare il pagamento.

Converged copre questo secondo livello. È un circuito digitale di controllo che collega sito web, richieste dei clienti, attività interne, attrezzature, magazzino, pagamenti, notifiche e analytics. Il proprietario non vede un insieme di strumenti scollegati, ma un’immagine viva del business: cosa è arrivato, cosa è stato accettato, cosa è in coda, cosa è pronto, dove c’è rischio di ritardo e dove si perde margine.

La piattaforma è particolarmente utile quando la produzione funziona già, ma la gestione dipende da chat, fogli di calcolo, memoria dei dipendenti e controllo manuale. Converged non impone subito un ERP o MES pesante. Parte da processi concreti e costruisce gradualmente un sistema unificato intorno a essi.

In uno scenario tipico, il cliente invia una richiesta tramite sito, form, messenger o operatore. Converged salva la richiesta, allega i file, crea un ordine, aiuta a stimare il prezzo, mette il lavoro in coda, segue l’esecuzione e tiene informato il cliente. Un operatore può chiedere lo stato nell’interfaccia o tramite chat IA, e il sistema risponde con dati reali, non con supposizioni.

Di conseguenza, l’officina dipende meno dalla coordinazione manuale. Le persone si concentrano sulla produzione e sulle decisioni che richiedono davvero esperienza, mentre la piattaforma gestisce instradamento, controllo delle scadenze, messaggi ripetitivi, raccolta degli stati e preparazione delle azioni.

Sistema di soluzioni

Converged non viene venduto come una piattaforma vuota in cui il cliente deve prima inventare l’architettura e assemblare moduli. L’unità di valore di base è una soluzione: uno scenario operativo pronto che risolve un problema aziendale chiaro.

La piattaforma prevede 17 soluzioni raggruppate in quattro aree:

• Ordini e clienti — richieste in ingresso, vetrina dei servizi, storico cliente, stati, comunicazione e vendite ricorrenti.
• Produzione e scorte — carico delle attrezzature, code, materiali, controllo qualità, guasti e spedizioni.
• Denaro e profitto — costo, margine, pagamenti, crediti, pricing e scenari di crescita.
• Team e responsabilità — zone di responsabilità, turni, standard, knowledge base e onboarding.

Una soluzione dentro Converged non è solo una schermata dell’interfaccia. Di solito include modello dati, workflow, ruoli, notifiche, azioni di agenti IA e integrazioni con attrezzature o servizi esterni. Il proprietario non sceglie una “funzione”, ma un problema: accelerare la gestione delle richieste, vedere la coda delle macchine, capire la redditività degli ordini o mettere ordine nei turni.

La descrizione dettagliata di tutte le soluzioni deve stare in una sezione separata. Nella documentazione prodotto è importante fissare il principio: Converged AI è la piattaforma, e le soluzioni sono scenari applicativi che funzionano al suo interno e chiudono gradualmente diverse aree del business manifatturiero.

Attrezzature e officina

Converged non sostituisce il firmware delle macchine e non tenta di controllare la produzione alla cieca. Si collega sopra le attrezzature, legge la telemetria, collega lo stato delle macchine agli ordini e mostra cosa sta realmente accadendo in officina.

La piattaforma è pensata per diversi tipi di attrezzature: stampanti 3D Bambu Lab, Marlin e Klipper, macchine CNC, celle robotiche e adattatori specializzati. Dove possibile, Converged riceve stati, errori, avanzamento dell’esecuzione, temperatura, code di attività e altri dati tecnici. Dove il controllo diretto è rischioso o non disponibile, il sistema resta uno strato di osservazione e coordinamento.

Per il proprietario significa una cosa semplice: le attrezzature smettono di essere un insieme di finestre separate. Si vede quali macchine sono occupate, dove c’è inattività, cosa è in ritardo, quale ordine è legato a una specifica operazione e dove deve intervenire un operatore. Quando il parco cresce, questa visibilità diventa più importante del passaggio manuale tra interfacce separate di stampanti o macchine.

Converged collega anche le attrezzature al processo aziendale. Un’attività non è semplicemente “in stampa” o “in fresatura”: si trova nel contesto di un ordine, una scadenza, un cliente, un materiale, un pagamento e un passo successivo. L’officina diventa parte del sistema comune, non un’isola separata.

Processi

Il problema principale di un’officina in crescita raramente è la mancanza di un pulsante in più. Più spesso, i processi vivono nella testa delle persone: chi deve rispondere al cliente, quando calcolare il prezzo, chi controlla il file, quando avviare la produzione, chi avvisare in caso di ritardo e cosa fare dopo la spedizione.

In Converged queste catene sono descritte come workflow. Un processo tipico può andare dalla richiesta alla stima, approvazione, messa in coda, produzione, controllo qualità, pagamento, consegna e notifiche. L’utente di solito non costruisce un grafo da zero: gli scenari pronti vengono forniti con le soluzioni, e la configurazione si riduce a regole, ruoli, scadenze, integrazioni e notifiche.

Tecnicamente, l’esecuzione è spostata nello strato Runtime. Esso esegue workflow, attività cron, passi di integrazione e logica aziendale rimanendo stateless: i dati persistenti restano nei microservizi, e Runtime risponde dell’esecuzione delle catene. Così la logica di business non viene dispersa in decine di servizi e resta un punto chiaro dove vivono le regole di processo.

Per implementazioni complesse, i workflow possono essere estesi. Uno sviluppatore descrive gli scenari come classi TypeScript tipizzate, e gli agenti IA possono lanciare azioni consentite dentro questi scenari. Ma per l’utente comune l’obiettivo è diverso: non costruire un editor, ma attivare un processo pronto e ottenere un risultato gestito.

Livello IA

L’IA in Converged non è una chat separata aggiunta per estetica. È uno strato di controllo sopra dati, interfaccia e processi. L’utente può chiedere cosa succede a un ordine, preparare una risposta al cliente, trovare un ritardo, avviare un workflow consentito o raccogliere un riepilogo del carico delle macchine.

Il modello riceve contesto dalla piattaforma: richieste, stati, file, telemetria, storico cliente, diritti di accesso e attività correnti. La risposta quindi si basa sui dati dell’azienda, non su ragionamenti generici. Se serve un’azione, l’IA non aggira direttamente il sistema: chiama funzioni, microservizi o workflow consentiti attraverso uno strato controllato.

I provider dei modelli si collegano tramite adattatori. Una singola installazione può usare GPT, Claude, DeepSeek, Mistral, Gemini o altri motori se sono adatti al compito e alla policy del cliente. Un modello può comunicare con i clienti, un altro analizzare requisiti tecnici, un terzo esaminare documenti o stati di produzione.

Il principio chiave è il controllo. L’IA ha un proprio profilo di accesso, tutte le azioni sono registrate e le operazioni critiche vengono eseguite con gli stessi diritti e policy delle azioni umane. Questo permette di affidare la routine agli agenti senza dare loro potere incontrollato sulla produzione.

Architettura

Converged è progettato come piattaforma modulare, ma non come una raccolta caotica di microservizi. La separazione è semplice: l’interfaccia mostra dati e avvia azioni, Runtime esegue processi, i microservizi possiedono dati, e gli adattatori collegano attrezzature e sistemi esterni.

I microservizi restano intenzionalmente sottili. Ogni servizio risponde della propria area dati, della validazione e di un’API tipizzata. Non deve conoscere la logica interna dei servizi vicini e non deve diventare un centro nascosto dei processi aziendali. Questo riduce l’accoppiamento e rende il sistema più semplice da mantenere.

Tutta la logica trasversale viene spostata in Runtime. Se il sistema deve accettare un ordine, interrogare diversi servizi, creare un’attività, inviare una notifica, attendere un evento e aggiornare lo stato, questo viene eseguito in un workflow. Runtime non memorizza stato persistente di per sé: scrive storico, variabili e risultati tramite i servizi che possiedono i propri storage.

Lo storage è costruito intorno all’isolamento. Invece di un database comune, ogni dominio riceve i propri confini dati: SQL, key-value, file, dati colonnari, indici vettoriali o relazioni grafo dove necessario. Questo approccio aiuta a spostare workspace, limitare l’accesso ed evitare un database condiviso in cui si mescolano dati di clienti diversi.

Anche il frontend è modulare. La shell comune carica micro-frontends indipendenti tramite import map, quindi singole aree dell’interfaccia possono evolvere senza ricompilare tutto il prodotto. Per l’utente resta un unico sistema; per lo sviluppo, un insieme di zone di responsabilità chiare.

Distribuzione

Converged supporta diversi scenari di installazione: dalla piccola officina al deployment di produzione nell’infrastruttura aziendale. La piattaforma base viene distribuita sopra k3s, una distribuzione Kubernetes leggera adatta a dispositivi edge, server locali e ambienti cloud.

I profili principali sono due:

• Mono — UI, Runtime, microservizi, storage e cache sono impacchettati in modo compatto. È la modalità per sviluppo, prototipi, demo e piccole installazioni dove conta soprattutto la semplicità di avvio.
• Multi — UI, gruppi Runtime, gruppi di microservizi per dominio, storage e cache sono separati. È il profilo standard di produzione quando servono isolamento, scalabilità e controllo più preciso del carico.

Entrambi i profili usano lo stesso codice. Cambiano solo la topologia dei container e la configurazione. Un’azienda può iniziare con un’installazione compatta e poi spostare lo stesso sistema in un’infrastruttura più seria senza riscrivere il prodotto.

Negli scenari self-hosted, il cliente controlla installazione, rete, backup, aggiornamenti e posizione fisica dei dati. Questo è adatto ad aziende con requisiti interni di sicurezza o con il desiderio di mantenere la produzione completamente dalla propria parte. La consegna cloud elimina il lavoro operativo: la piattaforma viene distribuita e aggiornata dal team del servizio, mentre il cliente riceve un ambiente pronto.

È possibile anche un’opzione ibrida: dati sensibili e attrezzature restano localmente, mentre il cloud viene usato per aggiornamenti, accesso esterno, coordinamento di team distribuiti o singole funzioni IA. Il principio importante è non vincolare il cliente a un solo modello di consegna.

Tecnologie

La parte server di Converged è costruita su Bun ed Elysia. Bun avvia rapidamente JavaScript e TypeScript, usa la memoria in modo efficiente ed è adatto a deployment edge compatti. Elysia viene usato come strato HTTP per plugin backend e microservizi.

I contratti tra servizi sono descritti con tipi. NRPC collega interfacce TypeScript alle implementazioni e genera pacchetti client, così frontend, Runtime e backend lavorano con gli stessi contratti invece che con API testuali scollegate.

Lo storage dei dati usa un insieme di store leggeri per compiti diversi: SQL, key-value, file, dati colonnari, indici vettoriali e relazioni grafo. Lo strato nativo Behemoth e gli adattatori Zig coprono i casi in cui contano basso overhead, accesso alle attrezzature, Unix socket o FFI.

Il frontend è una piattaforma React con micro-frontends. La shell comune carica moduli UI separati, e gli scenari di prodotto possono evolvere indipendentemente. Questo è importante per una piattaforma con molte soluzioni: l’interfaccia non deve trasformarsi in un monolite pesante.

Orchestrazione e consegna sono costruite intorno a k3s, Helm e profili di configurazione. Lo stesso insieme di componenti può essere assemblato in un profilo mono compatto o separato in gruppi per la produzione.

Prestazioni

Converged è progettato per siti produttivi che non sempre dispongono di un grande parco server. Per questo il sistema evita peso inutile: Bun riduce l’overhead dei processi backend, Runtime resta stateless e i microservizi possono essere raggruppati per tipo di carico invece di eseguire centinaia di container separati.

Le prestazioni derivano dall’architettura, non da un singolo trucco. I dati non attraversano strati inutili, i servizi possiedono i propri store, Runtime parallelizza workflow e attività cron, e gli adattatori nativi vengono usati dove HTTP o un normale strato JS aggiungerebbero troppo overhead.

Un’installazione compatta può funzionare su un piccolo server o single-board computer se il carico corrisponde alla scala dell’officina. Con la crescita, Runtime, microservizi e gruppi storage possono essere separati per usare più core CPU, isolare attività pesanti ed evitare che un collo di bottiglia fermi tutto il sistema.

La piattaforma non promette prestazioni infinite “out of the box”. I colli di bottiglia dipendono da attrezzature, volume dei file, numero di ordini, provider IA e integrazioni. L’architettura di Converged permette di iniziare in modo compatto e scalare solo le parti che diventano realmente calde.

Sicurezza

Converged parte dal presupposto che i dati di produzione non debbano finire in un unico spazio condiviso. Ordini, file dei clienti, parametri tecnologici, pagamenti, messaggi e telemetria delle attrezzature devono essere separati per workspace e zone di responsabilità.

Architetturalmente, questo è supportato dall’isolamento dei dati. I microservizi possiedono i propri store, e i workspace possono avere directory, chiavi, file e confini di accesso separati. Questo semplifica export, migrazione self-hosted, backup e audit.

I diritti di accesso si applicano non solo alle persone, ma anche agli agenti IA. Se un modello lancia un’azione, legge dati o chiama un workflow, deve farlo dentro il proprio profilo di permessi. Le azioni sono registrate, quindi è possibile ricostruire chi o quale agente ha avviato un passo, quali dati sono stati toccati e come si è concluso lo scenario.

I deployment self-hosted e private danno al cliente pieno controllo sull’infrastruttura: rete, segreti, API key, backup e posizione fisica dei dati. Il cloud è più semplice operativamente, ma non deve diventare vendor lock-in: i dati devono restare portabili e gli scenari riproducibili in un’altra installazione.

Licenze

Converged è distribuito sotto AGPL-3.0. È una licenza copyleft per software di rete: se modifichi la piattaforma e ne fornisci accesso tramite rete, le modifiche devono essere pubblicate secondo i termini della licenza.

Per gli utenti questo significa che la versione self-hosted può essere distribuita senza acquistare una licenza per il codice stesso. Questo percorso è adatto ad aziende che hanno bisogno di controllo, installazione locale, auditabilità o esperimenti sul proprio hardware. La responsabilità operativa resta al proprietario dell’installazione: aggiornamenti, backup, monitoraggio, sicurezza e disponibilità.

La consegna cloud non è vendita di codice chiuso, ma un servizio intorno a una piattaforma open-source. Il cliente paga per avvio rapido, supporto, aggiornamenti, backup, monitoraggio, infrastruttura e funzionamento prevedibile. Per molte officine è più economico che costruire internamente competenze DevOps.

Questo equilibrio è importante per la fiducia: il core resta aperto, la community può verificare e migliorare la piattaforma, e il modello commerciale si costruisce intorno a implementazione, supporto e consegna controllata del valore.

Comunità

Converged è pensato come piattaforma manifatturiera aperta, non come una scatola SaaS chiusa. Il core di base è disponibile con licenza open-source, e intorno possono nascere integrazioni, microservizi, micro-frontends, workflow e soluzioni applicative.

Questo conta nel mercato manifatturiero: officine diverse usano attrezzature, materiali, standard di qualità e catene di fornitura diverse. Un sistema chiuso raggiunge rapidamente i limiti di un singolo vendor. Un’architettura aperta permette di aggiungere adattatori e scenari per condizioni operative reali.

Un’estensione può essere semplice: un nuovo adattatore per attrezzature, integrazione con un servizio di pagamento, import da un vecchio sito, un modulo UI separato o un workflow per un settore specifico. Se l’estensione è utile ad altri partecipanti, può diventare parte del catalogo soluzioni o restare un’implementazione privata.

Aperto non significa senza controllo. Le estensioni devono passare una revisione tecnica, rispettare i confini architetturali e non ricevere accesso ai dati più ampio del necessario. La fiducia nell’ecosistema si costruisce su codice sorgente, riproducibilità e un modello chiaro di permessi.

Codice sorgente

Il progetto viene sviluppato apertamente. Codice sorgente, architettura attuale e materiali di lavoro sono disponibili nel repository:

https://github.com/solenopsys/converged

Il repository è utile non solo agli sviluppatori. Permette di capire come sono organizzati microservizi, Runtime, micro-frontends, generazione dei contratti, profili di distribuzione e adattatori hardware. Per le aziende che valutano self-hosted o deployment private, è una parte importante della verifica: la piattaforma non è una scatola chiusa.