Converged-AI-Plattform

Converged AI ist eine Open-Source-Plattform für Fertigungsunternehmen: 3D-Druck-Dienstleister, CNC-Werkstätten, F&E-Labore und Netzwerke kleiner Werkstätten.

Ihre Aufgabe ist es, alles zu übernehmen, was rund um die Produktion passiert: Anfragen, Dateien, Kalkulationen, Warteschlangen, Auftragsstatus, Kundenkommunikation, Ausrüstung, Zahlungen, Lieferung und Wiederverkäufe. Die Maschinen fertigen weiterhin Teile, das Team trifft weiterhin technische Entscheidungen, und Converged verbindet alles zu einem steuerbaren System.

Die Plattform enthält 17 Lösungen, gruppiert in vier Bereiche: Aufträge und Kunden, Produktion und Bestand, Geld und Gewinn, Team und Verantwortung. Das sind keine „Module um der Module willen“, sondern fertige Szenarien für konkrete Werkstattprobleme.

Was Converged leistet

Ein Fertigungsunternehmen hat zwei Arbeitsebenen. Die erste ist, ein Teil zu fertigen, ein Produkt zu montieren und den Auftrag abzuschließen. Die zweite ist alles, was davor, währenddessen und danach passieren muss: eine Anfrage annehmen, die Datei nicht verlieren, den Preis abstimmen, die Arbeit in eine Warteschlange stellen, den Kunden informieren, Maschinenauslastung verstehen, Verzögerungen sehen und die Zahlung erhalten.

Converged deckt diese zweite Ebene ab. Es ist eine digitale Steuerungsschicht, die Website, Kundenanfragen, interne Aufgaben, Ausrüstung, Bestand, Zahlungen, Benachrichtigungen und Analytik verbindet. Der Inhaber sieht nicht eine Sammlung getrennter Werkzeuge, sondern ein lebendiges Bild des Geschäfts: was eingegangen ist, was angenommen wurde, was in der Warteschlange steht, was fertig ist, wo Verzögerungen drohen und wo Marge verloren geht.

Die Plattform ist besonders nützlich, wenn die Produktion bereits funktioniert, die Steuerung aber von Chats, Tabellen, Mitarbeitergedächtnis und manueller Kontrolle abhängt. Converged zwingt nicht sofort zur Einführung eines schweren ERP oder MES. Es beginnt mit konkreten Prozessen und baut schrittweise ein einheitliches System darum herum.

In einem typischen Szenario stellt ein Kunde eine Anfrage über Website, Formular, Messenger oder Operator. Converged speichert die Anfrage, hängt Dateien an, erstellt einen Auftrag, hilft bei der Preiskalkulation, stellt die Arbeit in die Warteschlange, verfolgt die Ausführung und hält den Kunden informiert. Ein Operator kann den Status in der Oberfläche oder über den KI-Chat abfragen, und das System antwortet mit echten Daten statt Vermutungen.

Dadurch hängt die Werkstatt weniger von manueller Koordination ab. Menschen konzentrieren sich auf Produktion und Entscheidungen, die wirklich Erfahrung erfordern, während die Plattform Routing, Terminkontrolle, wiederkehrende Nachrichten, Statuserfassung und Aktionsvorbereitung übernimmt.

Lösungssystem

Converged wird nicht als leere Plattform verkauft, bei der der Kunde zuerst selbst Architektur erfinden und Module zusammenbauen muss. Die grundlegende Werteinheit ist eine Lösung: ein fertiges Arbeitsszenario, das ein klares Geschäftsproblem löst.

Die Plattform umfasst 17 Lösungen, gruppiert in vier Bereiche:

• Aufträge und Kunden — eingehende Anfragen, Leistungspräsentation, Kundenhistorie, Status, Kommunikation und Wiederverkäufe.
• Produktion und Bestand — Auslastung der Ausrüstung, Warteschlangen, Materialien, Qualitätskontrolle, Störungen und Versand.
• Geld und Gewinn — Kosten, Marge, Zahlungen, Forderungen, Preisbildung und Wachstumsszenarien.
• Team und Verantwortung — Verantwortungsbereiche, Schichten, Standards, Wissensbasis und Onboarding.

Eine Lösung in Converged ist nicht nur ein Bildschirm in der Oberfläche. Sie enthält in der Regel Datenmodell, Workflow, Rollen, Benachrichtigungen, KI-Agentenaktionen und Integrationen mit Ausrüstung oder externen Diensten. Der Inhaber wählt keine „Funktion“, sondern ein Problem: Anfragen schneller bearbeiten, die Maschinenwarteschlange sehen, Auftragsrentabilität verstehen oder Schichten ordnen.

Die detaillierte Beschreibung aller Lösungen gehört in einen separaten Abschnitt. In der Produktdokumentation ist der Grundsatz wichtig: Converged AI ist die Plattform, und Lösungen sind Anwendungsszenarien, die in ihr laufen und nach und nach verschiedene Bereiche eines Fertigungsunternehmens schließen.

Ausrüstung und Werkstatt

Converged ersetzt keine Maschinenfirmware und versucht nicht, Produktion blind zu steuern. Es verbindet sich oberhalb der Ausrüstung, liest Telemetrie, verknüpft den Maschinenzustand mit Aufträgen und zeigt, was in der Werkstatt tatsächlich passiert.

Die Plattform ist für unterschiedliche Ausrüstung gedacht: 3D-Drucker von Bambu Lab, Marlin und Klipper, CNC-Maschinen, Roboterzellen und spezialisierte Adapter. Wo möglich, erhält Converged Status, Fehler, Ausführungsfortschritt, Temperatur, Aufgabenwarteschlangen und andere technische Daten. Wo direkte Steuerung riskant oder nicht verfügbar ist, bleibt das System eine Beobachtungs- und Koordinationsschicht.

Für den Inhaber bedeutet das eine einfache Sache: Ausrüstung ist nicht mehr eine Sammlung getrennter Fenster. Man sieht, welche Maschinen beschäftigt sind, wo Leerlauf entsteht, was verspätet ist, welcher Auftrag mit einer konkreten Operation verbunden ist und wo ein Operator eingreifen muss. Wenn der Maschinenpark wächst, wird diese Sichtbarkeit wichtiger als das manuelle Wechseln zwischen einzelnen Drucker- oder Maschinenoberflächen.

Converged verbindet Ausrüstung auch mit dem Geschäftsprozess. Eine Aufgabe ist nicht nur „im Druck“ oder „beim Fräsen“: Sie steht im Kontext von Auftrag, Termin, Kunde, Material, Zahlung und nächstem Schritt. Die Werkstatt wird Teil des gemeinsamen Systems und keine separate Insel.

Prozesse

Das Hauptproblem einer wachsenden Werkstatt ist selten, dass noch ein Button fehlt. Häufiger leben Prozesse in den Köpfen der Mitarbeitenden: wer dem Kunden antwortet, wann der Preis berechnet wird, wer die Datei prüft, wann Produktion startet, wer bei Verzögerung informiert wird und was nach dem Versand passiert.

In Converged werden solche Ketten als Workflows beschrieben. Ein typischer Prozess kann von Anfrage über Kalkulation, Freigabe, Warteschlange, Produktion, Qualitätskontrolle, Zahlung, Lieferung und Benachrichtigungen laufen. Der Nutzer baut normalerweise keinen Graphen von Grund auf: fertige Szenarien kommen mit den Lösungen, und die Konfiguration reduziert sich auf Regeln, Rollen, Fristen, Integrationen und Benachrichtigungen.

Technisch wird die Ausführung in die Runtime-Schicht verlagert. Sie führt Workflows, Cron-Aufgaben, Integrationsschritte und Geschäftslogik aus und bleibt dabei stateless: persistente Daten liegen in den Microservices, Runtime ist für die Ausführung der Ketten zuständig. So wird Geschäftslogik nicht über Dutzende Services verstreut, sondern hat einen klaren Ort.

Für komplexe Implementierungen können Workflows erweitert werden. Ein Entwickler beschreibt Szenarien als typisierte TypeScript-Klassen, und KI-Agenten können erlaubte Aktionen innerhalb dieser Szenarien starten. Für normale Nutzer ist das Ziel aber ein anderes: keinen Editor bauen, sondern einen fertigen Prozess aktivieren und ein kontrolliertes Ergebnis erhalten.

KI-Schicht

KI in Converged ist kein separater Chat, der nur für den Eindruck hinzugefügt wurde. Sie ist eine Steuerungsschicht über Daten, Oberfläche und Prozesse. Ein Nutzer kann fragen, was mit einem Auftrag passiert, eine Kundenantwort vorbereiten lassen, eine Verzögerung finden, einen erlaubten Workflow starten oder eine Zusammenfassung der Maschinenauslastung erhalten.

Das Modell erhält Kontext aus der Plattform: Anfragen, Status, Dateien, Telemetrie, Kundenhistorie, Zugriffsrechte und aktuelle Aufgaben. Die Antwort basiert daher auf Unternehmensdaten, nicht auf allgemeinen Vermutungen. Wenn eine Aktion nötig ist, umgeht die KI das System nicht direkt: Sie ruft erlaubte Funktionen, Microservices oder Workflows über eine kontrollierte Schicht auf.

Modellanbieter werden über Adapter angeschlossen. Eine Installation kann GPT, Claude, DeepSeek, Mistral, Gemini oder andere Engines nutzen, wenn sie zur Aufgabe und zur Richtlinie des Kunden passen. Ein Modell kann mit Kunden kommunizieren, ein anderes technische Anforderungen analysieren, ein drittes Dokumente oder Produktionsstatus auswerten.

Der zentrale Grundsatz ist Kontrolle. KI hat ein eigenes Zugriffsprofil, alle Aktionen werden protokolliert, und kritische Operationen laufen unter denselben Rechten und Richtlinien wie menschliche Aktionen. So kann man Agenten Routine anvertrauen, ohne ihnen unkontrollierte Macht über die Produktion zu geben.

Architektur

Converged ist als modulare Plattform entworfen, aber nicht als chaotische Sammlung von Microservices. Die Trennung ist einfach: Die Oberfläche zeigt Daten und startet Aktionen, Runtime führt Prozesse aus, Microservices besitzen Daten, und Adapter verbinden Ausrüstung und externe Systeme.

Microservices bleiben bewusst schlank. Jeder Service ist für seinen Datenbereich, Validierung und eine typisierte API verantwortlich. Er soll die interne Logik benachbarter Services nicht kennen und nicht zum versteckten Zentrum von Geschäftsprozessen werden. Das senkt Kopplung und macht das System leichter wartbar.

Die gesamte bereichsübergreifende Logik wird in Runtime verschoben. Wenn das System einen Auftrag annehmen, mehrere Services abfragen, eine Aufgabe erstellen, eine Benachrichtigung senden, auf ein Ereignis warten und den Status aktualisieren muss, geschieht das in einem Workflow. Runtime speichert selbst keinen persistenten Zustand: Historie, Variablen und Ergebnisse werden über die Services geschrieben, denen ihre Speicher gehören.

Storage ist um Isolation herum aufgebaut. Statt einer gemeinsamen Datenbank erhält jeder Bereich eigene Datengrenzen: SQL, Key-Value, Dateien, Spaltendaten, Vektorindizes oder Graphbeziehungen, wo sie nötig sind. Dieser Ansatz hilft, Workspaces zu verschieben, Zugriff zu begrenzen und eine gemeinsame Datenbank zu vermeiden, in der Daten verschiedener Kunden vermischt werden.

Auch das Frontend ist modular. Die gemeinsame Shell lädt unabhängige Micro-Frontends über eine Import Map, sodass einzelne Bereiche der Oberfläche sich weiterentwickeln können, ohne das gesamte Produkt neu zu bauen. Für den Nutzer bleibt es ein System; für die Entwicklung entstehen klare Verantwortungsbereiche.

Bereitstellung

Converged unterstützt mehrere Installationsszenarien: von einer kleinen Werkstatt bis zum Production-Deployment in der Infrastruktur eines Unternehmens. Die Basisplattform läuft auf k3s, einer leichtgewichtigen Kubernetes-Distribution für Edge-Geräte, lokale Server und Cloud-Umgebungen.

Es gibt zwei Hauptprofile:

• Mono — UI, Runtime, Microservices, Storage und Cache sind kompakt gepackt. Dieser Modus ist für Entwicklung, Prototypen, Demos und kleine Installationen gedacht, bei denen einfacher Start wichtiger ist.
• Multi — UI, Runtime-Gruppen, domänenbezogene Microservice-Gruppen, Storage und Cache sind getrennt. Das ist das Standard-Production-Profil, wenn Isolation, Skalierung und präzisere Lastkontrolle nötig sind.

Beide Profile verwenden denselben Code. Nur Container-Topologie und Konfiguration unterscheiden sich. Ein Unternehmen kann mit einer kompakten Installation beginnen und dasselbe System später in ernsthaftere Infrastruktur verschieben, ohne das Produkt neu zu schreiben.

Bei Self-hosted-Szenarien kontrolliert der Kunde Installation, Netzwerk, Backups, Updates und den physischen Speicherort der Daten. Das passt zu Unternehmen mit internen Sicherheitsanforderungen oder dem Wunsch, die Produktion vollständig auf der eigenen Seite zu halten. Die Cloud-Lieferung nimmt operative Aufgaben ab: Die Plattform wird vom Serviceteam bereitgestellt und aktualisiert, während der Kunde eine fertige Arbeitsumgebung erhält.

Eine hybride Variante ist ebenfalls möglich: sensible Daten und Ausrüstung bleiben lokal, während die Cloud für Updates, externen Zugriff, Koordination verteilter Teams oder einzelne KI-Funktionen genutzt wird. Der wichtige Grundsatz ist, den Kunden nicht auf ein einziges Liefermodell festzulegen.

Technologien

Die Serverseite von Converged basiert auf Bun und Elysia. Bun startet JavaScript und TypeScript schnell, nutzt Speicher effizient und passt gut zu kompakten Edge-Deployments. Elysia dient als HTTP-Schicht für Backend-Plugins und Microservices.

Serviceverträge werden typisiert beschrieben. NRPC verbindet TypeScript-Interfaces mit Implementierungen und generiert Client-Pakete, damit Frontend, Runtime und Backend mit denselben Verträgen arbeiten statt mit verstreuten String-APIs.

Für Daten werden mehrere leichte Stores je nach Aufgabe genutzt: SQL, Key-Value, Dateien, Spaltendaten, Vektorindizes und Graphbeziehungen. Die native Behemoth-Schicht und Zig-Adapter decken Fälle ab, in denen geringer Overhead, Zugriff auf Ausrüstung, Unix-Sockets oder FFI wichtig sind.

Das Frontend ist eine React-Plattform mit Micro-Frontends. Die gemeinsame Shell lädt getrennte UI-Module, und Produktszenarien können unabhängig wachsen. Das ist wichtig für eine Plattform mit vielen Lösungen: Die Oberfläche darf nicht zu einem schweren Monolithen werden.

Orchestrierung und Lieferung basieren auf k3s, Helm und Konfigurationsprofilen. Derselbe Komponentensatz kann als kompaktes Mono-Profil oder in getrennten Gruppen für Production zusammengesetzt werden.

Leistung

Converged ist für Produktionsstandorte entworfen, die nicht immer über eine große Serverflotte verfügen. Deshalb vermeidet das System unnötiges Gewicht: Bun senkt den Overhead von Backend-Prozessen, Runtime bleibt stateless, und Microservices können nach Lasttyp gruppiert werden, statt Hunderte separate Container zu starten.

Leistung entsteht hier durch Architektur, nicht durch einen einzelnen Trick. Daten laufen nicht durch unnötige Schichten, Services besitzen ihre Stores, Runtime parallelisiert Workflows und Cron-Aufgaben, und native Adapter werden dort eingesetzt, wo HTTP oder eine normale JS-Schicht zu viel Overhead hinzufügen würden.

Eine kompakte Installation kann auf einem kleinen Server oder Single-Board-Computer laufen, wenn die Last zur Größe der Werkstatt passt. Beim Wachstum können Runtime, Microservices und Storage-Gruppen getrennt werden, um mehr CPU-Kerne zu nutzen, schwere Aufgaben zu isolieren und zu verhindern, dass ein Engpass das ganze System stoppt.

Die Plattform verspricht keine unendliche Leistung „out of the box“. Engpässe hängen von Ausrüstung, Dateivolumen, Auftragszahl, KI-Anbietern und Integrationen ab. Die Architektur von Converged erlaubt es, kompakt zu starten und nur die Teile zu skalieren, die wirklich heiß werden.

Sicherheit

Converged geht davon aus, dass Produktionsdaten nicht in einen gemeinsamen Haufen geworfen werden dürfen. Aufträge, Kundendateien, technische Parameter, Zahlungen, Nachrichten und Maschinentelemetrie müssen nach Workspaces und Verantwortungsbereichen getrennt werden.

Architektonisch wird das durch Datenisolation unterstützt. Microservices besitzen ihre Stores, und Workspaces können getrennte Verzeichnisse, Schlüssel, Dateien und Zugriffsgrenzen haben. Das vereinfacht Export, Self-hosted-Migration, Backups und Audit.

Zugriffsrechte gelten nicht nur für Menschen, sondern auch für KI-Agenten. Wenn ein Modell eine Aktion startet, Daten liest oder einen Workflow aufruft, muss das innerhalb seines Berechtigungsprofils passieren. Aktionen werden protokolliert, sodass nachvollziehbar ist, wer oder welcher Agent einen Schritt ausgelöst hat, welche Daten betroffen waren und wie das Szenario endete.

Self-hosted- und Private-Deployments geben dem Kunden volle Kontrolle über Infrastruktur: Netzwerk, Secrets, API-Keys, Backups und physischen Datenstandort. Der Cloud-Modus ist operativ einfacher, darf aber nicht zum Vendor-Lock-in werden: Daten müssen portabel bleiben, und Szenarien müssen in einer anderen Installation reproduzierbar sein.

Lizenzierung

Converged wird unter AGPL-3.0 veröffentlicht. Das ist eine Copyleft-Lizenz für Netzwerksoftware: Wenn Sie die Plattform verändern und über ein Netzwerk zugänglich machen, müssen die Änderungen gemäß den Lizenzbedingungen offengelegt werden.

Für Nutzer bedeutet das, dass die Self-hosted-Version ohne Kauf einer Lizenz für den Code selbst bereitgestellt werden kann. Dieser Weg passt zu Unternehmen, die Kontrolle, lokale Installation, Auditierbarkeit oder Experimente auf eigener Hardware brauchen. Die operative Verantwortung bleibt beim Betreiber der Installation: Updates, Backups, Monitoring, Sicherheit und Verfügbarkeit.

Cloud-Lieferung ist kein Verkauf geschlossenen Codes, sondern ein Service rund um eine Open-Source-Plattform. Der Kunde bezahlt für schnellen Start, Support, Updates, Backups, Monitoring, Infrastruktur und vorhersehbaren Betrieb. Für viele Werkstätten ist das günstiger, als intern DevOps-Kompetenz aufzubauen.

Dieses Gleichgewicht ist wichtig für Vertrauen: Der Kern bleibt offen, die Community kann die Plattform prüfen und verbessern, und das Geschäftsmodell basiert auf Implementierung, Betreuung und kontrollierter Wertlieferung.

Community

Converged ist als offene Fertigungsplattform gedacht, nicht als geschlossene SaaS-Box. Der Basiskern ist unter einer Open-Source-Lizenz verfügbar, und darum herum können Integrationen, Microservices, Micro-Frontends, Workflows und Anwendungslösungen entstehen.

Das ist im Fertigungsmarkt wichtig: Verschiedene Werkstätten nutzen unterschiedliche Ausrüstung, Materialien, Qualitätsstandards und Lieferketten. Ein geschlossenes System stößt schnell an die Grenzen eines einzelnen Anbieters. Eine offene Architektur erlaubt Adapter und Szenarien für reale Betriebsbedingungen.

Eine Erweiterung kann einfach sein: ein neuer Ausrüstungsadapter, Integration mit einem Zahlungsdienst, Import von einer alten Website, ein getrenntes UI-Modul oder ein Workflow für eine bestimmte Branche. Wenn eine Erweiterung für andere Teilnehmer nützlich ist, kann sie Teil des Lösungskatalogs werden oder als private Implementierung bleiben.

Offen heißt nicht unkontrolliert. Erweiterungen müssen technische Prüfung bestehen, architektonische Grenzen respektieren und dürfen keinen breiteren Datenzugriff erhalten als nötig. Vertrauen in das Ökosystem entsteht durch Quellcode, Reproduzierbarkeit und ein klares Berechtigungsmodell.

Quellcode

Das Projekt wird offen entwickelt. Quellcode, aktuelle Architektur und Arbeitsmaterialien sind im Repository verfügbar:

https://github.com/solenopsys/converged

Das Repository ist nicht nur für Entwickler nützlich. Es zeigt, wie Microservices, Runtime, Micro-Frontends, Vertragsgenerierung, Bereitstellungsprofile und Hardware-Adapter organisiert sind. Für Unternehmen, die Self-hosted oder Private-Deployment prüfen, ist das ein wichtiger Teil der Bewertung: Die Plattform ist keine geschlossene Box.