superglue: Integrationen aus natürlicher Sprache, mit FSL statt MIT

Welche Integrationsarbeit superglue übernehmen soll

Das Projekt richtet sich an Teams, die Systeme verbinden müssen, für die es keinen fertigen Connector gibt oder deren Connector gepflegt werden müsste. Das README nennt als Zielgruppe ausdrücklich ERP- und Accounting-Einführungen (NetSuite, Sage Intacct, SAP, Business Central, Acumatica), die Anbindung interner Systeme an AI-Plattformen wie Claude und das Onboarding von Kundensystemen. Der Beschreibungstext auf GitHub fasst das kürzer: Integrationen und Werkzeuge aus natürlicher Sprache, für Long-Tail- und Enterprise-Systeme. Der behauptete Unterschied zu klassischen iPaaS-Produkten liegt nicht in der Zahl fertiger Konnektoren, sondern darin, dass die Verbindung selbst beschrieben statt programmiert wird. Die README-Tabelle stellt das als Vorher-Nachher-Vergleich dar, etwa 140 Stunden manuelle Excel-Transformationen gegen eine in Klartext beschriebene Zuordnung. Solche Zahlen stammen aus der Projektdokumentation und sind nicht unabhängig überprüfbar; sie sollten als Marketingmaterial gelesen werden, nicht als Messergebnis.

Was im Repository tatsächlich liegt und was nicht

Die Hauptsprache ist TypeScript, der Default-Branch heißt main. Ein Client-SDK wird als npm-Paket @superglue/client ausgeliefert, daneben existiert ein Docker-Image unter superglueai/superglue. Der letzte Push datiert auf den 19. August 2026. Für das Repository sind keine Releases abrufbar, es gibt also keinen versionierten Stand, an dem man sich orientieren könnte. Ebenso fehlt eine LICENSE-Datei im ausgelieferten Material: Die Lizenzangabe lautet NOASSERTION, das README spricht von FSL für das Hauptprojekt und MIT für die Client-SDKs und verweist auf LICENSE im Repository. Wer die Bedingungen prüfen will, muss diese Datei selbst öffnen. Eine Besonderheit ist die Architektur der Wissensbasis: Laut README lernt superglue, wie die Systeme eines Unternehmens funktionieren, aus dem unternehmenseigenen Wissen. Das ist der Kern des Ansatzes und gleichzeitig die Stelle, an der Daten das eigene Netz verlassen, sofern nicht self-hosted betrieben wird.

Der Ablauf: Beschreibung, Mapping, laufende Synchronisation

Aus dem Material lässt sich ein dreistufiger Ablauf ableiten. Erstens die Beschreibung: Ein Mapping wird in natürlicher Sprache formuliert, nicht als Code. Zweitens die Umsetzung: Agenten übersetzen diese Beschreibung in eine Integration, die gegen die Zielschnittstelle arbeitet. Das README nennt als Beispiel eine Sage-Intacct-Migration, bei der 185 Konten in unter einer Stunde übertragen wurden, nachdem die Zuordnung in Klartext beschrieben war. Drittens der Betrieb nach dem Go-live: Die Dokumentation spricht davon, Daten nach der Inbetriebnahme synchron zu halten. Genau dieser dritte Punkt ist der architektonisch interessanteste, denn er bedeutet, dass die erzeugte Integration nicht einmalig ausgeführt, sondern dauerhaft betrieben wird. Welche Laufzeitumgebung das übernimmt, wie Fehlerbehandlung aussieht und wie ein fehlgeschlagener Lauf erneut angestoßen wird, geht aus dem vorliegenden Material nicht hervor. Diese Lücke ist relevant, weil Integrationsfehler selten beim ersten Lauf auftreten, sondern Wochen später, wenn sich ein Feld in der Quellanwendung ändert.

Unterstützte Systeme: breit, aber ohne Tiefenangabe

Die Liste im README ist lang und deckt REST, GraphQL, SOAP, dateibasierte Systeme und Datenbanken ab, ergänzt um einen Satz, der praktisch alles mit API, Datenbank oder Dateizugang einschließt. Die Aufzählung reicht von ERP und CRM über Projektmanagement, Kommunikation, Zahlungsverkehr, E-Commerce, HR, DevOps, Analytics, Marketing, Dateiprotokolle wie FTP, SFTP und SMB, Ticketing, CMS, Identity und schließlich AI-Anbieter. Für einen Leser, der eine Entscheidung treffen will, ist diese Liste nur begrenzt hilfreich: Sie sagt nichts darüber, wie tief die Unterstützung je System geht. Ob eine Salesforce-Anbindung Bulk-API, Änderungsereignisse und Sandbox-übergreifende Deployments abdeckt oder nur einfache Objekt-CRUD-Aufrufe, ist aus dem Material nicht erkennbar. Bei SOAP-Systemen, die im ERP-Umfeld häufig vorkommen, ist die Frage nach WSDL- und Session-Handling offen. Wer ein konkretes System anbinden will, sollte die Tiefe an genau diesem System prüfen, bevor die Breite der Liste als Argument dient.

Inbetriebnahme: zwei Wege, wenig Detail im Repository

Das README bietet zwei Optionen. Die erste ist die Anmeldung unter app.superglue.cloud, also der gehostete Betrieb. Die zweite ist Self-Hosting, verlinkt auf docs.superglue.cloud/getting-started/setup#self-hosted. Für den lokalen Start nennt das Repository nur das Docker-Image superglueai/superglue; konkrete Kommandos wie ein docker run mit Portmapping oder eine Compose-Datei stehen im ausgelieferten Material nicht. Auch Umgebungsvariablen oder Konfigurationsschlüssel werden nicht aufgeführt. Wer den Self-Hosted-Weg plant, muss die Setup-Seite der Dokumentation lesen, bevor er den Aufwand einschätzt. Auf der Client-Seite ist das npm-Paket @superglue/client der Einstiegspunkt für eigene Anwendungen, die die erzeugten Integrationen aufrufen sollen. Das ist ein klarer Vorteil gegenüber reinen UI-Produkten: Die Integrationen sind programmatisch nutzbar. Wer allerdings erwartet, aus dem Repository allein eine lauffähige Instanz aufzusetzen, wird die Dokumentationsseite brauchen.

Wo der Ansatz an Grenzen stößt

Die erste Einschränkung ist struktureller Natur. Ein System, das aus Unternehmenswissen lernt, braucht dieses Wissen in einer Form, die maschinell verwertbar ist. Wer keine dokumentierten Feldbedeutungen, keine Beispielsexporte und keine klaren Zuständigkeiten für Datenqualität hat, wird die Beschreibung in natürlicher Sprache nicht präziser machen können als das vorhandene Wissen. Die zweite Einschränkung betrifft regulierte Umgebungen. Für Migrationen in Finanz- und ERP-Systemen gilt üblicherweise eine Nachvollziehbarkeitsanforderung: Wer hat wann welches Feld wohin abgebildet, und wie lässt sich das reproduzieren. Ob superglue die Ableitung von der Beschreibung zur ausgeführten Transformation protokolliert und ob diese Protokolle für eine Prüfung ausreichen, lässt sich aus dem Material nicht beantworten. Die dritte Einschränkung ist die Lizenz. FSL ist keine permissive Open-Source-Lizenz im Sinne der OSI, sondern eine Source-Available-Lizenz mit Nutzungseinschränkungen, die typischerweise nach einer festgelegten Frist in eine offene Lizenz übergeht. Wer superglue in ein eigenes Produkt einbetten oder als Dienst weiterverkaufen will, muss die LICENSE-Datei lesen. Das ist keine Rechtsberatung, sondern der Hinweis auf die Stelle, an der die Antwort steht.

Alternative: Airbyte, Meltano oder ein eigener Connector

Der naheliegende Vergleich ist ein Connector-Framework wie Airbyte oder Meltano. Der Unterschied liegt nicht in der Funktionsliste, sondern im Erstellungsweg. Dort wird ein Connector als Code geschrieben oder aus einem Katalog ausgewählt; die Anpassung an ein Feld, das anders heißt oder anders formatiert ist, erfordert einen Entwickler und einen neuen Build. Bei superglue wird diese Anpassung als Beschreibung formuliert, und der Agent erzeugt daraus die Umsetzung. Das verschiebt die Arbeit von der Entwicklungsabteilung zu der Person, die das Mapping fachlich kennt, und genau das ist die Behauptung im README, wenn dort von Business-Usern die Rede ist, die Implementierungen selbst verantworten. Der Preis dafür ist Kontrolle: Ein handgeschriebener Connector ist deterministisch, versionierbar und im Fehlerfall bis zur Zeile nachvollziehbar. Eine aus Sprache erzeugte Integration ist es nur in dem Maß, in dem das System seine Ableitung offenlegt. Für hochfrequente, schema-stabile Pipelines mit klaren Anforderungen bleibt der klassische Connector die robustere Wahl. Für die lange Liste ungewöhnlicher Systeme, bei denen sich der Bau eines Connectors nie amortisiert, ist der sprachbasierte Weg die interessantere Option.

Wartung, Aktualisierung und Lizenzpflichten

Zum Wartungsaufwand lässt sich aus dem Material nur wenig Belastbares sagen. Es gibt keine Releases, also keine Versionsnummern, an denen man Upgrades festmachen könnte. Der letzte Push liegt im August 2026, das Projekt ist nicht archiviert. Wer selbst hostet, übernimmt die Aktualisierung des Docker-Images superglueai/superglue und muss dabei beachten, dass ohne veröffentlichte Releases kein Changelog zwischen zwei Ständen existiert. Das Client-SDK unter @superglue/client ist MIT-lizenziert und damit für die eigene Anwendung unproblematisch. Das Hauptprojekt steht unter FSL, was bedeutet, dass die Nutzungsrechte nicht identisch mit denen einer MIT- oder Apache-Lizenz sind. Für die meisten internen Integrationen dürfte das unkritisch sein, für den Weiterverkauf als gehosteter Dienst oder die Einbettung in ein kommerzielles Produkt ist die LICENSE-Datei die maßgebliche Quelle. Wer den gehosteten Weg unter app.superglue.cloud wählt, umgeht die Lizenzfrage teilweise, gibt aber die Kontrolle über die Datenwege ab. Diese Abwägung ist die eigentliche Entscheidung, nicht die Länge der Systemliste.

Redaktionelles Fazit

superglue passt zu Teams, die viele Systeme mit API, Datenbank oder Dateizugang verbinden müssen und dafür nicht pro Zielsystem einen eigenen Connector pflegen wollen. Wer eine permissive Open-Source-Lizenz braucht oder jede Datenbewegung ausschließlich in eigener Infrastruktur ohne Agentenbeteiligung abwickeln muss, sollte zuerst die LICENSE-Datei im Repository lesen und prüfen, ob die FSL-Bedingungen zum eigenen Vertriebsmodell passen. Vor dem Produktiveinsatz ist zu klären, ob die eigene Umgebung im Self-Hosted-Setup vollständig abgebildet werden kann, denn das README verweist dafür nur auf docs.superglue.cloud/getting-started/setup#self-hosted und nennt im Repository selbst keine Konfigurationsschlüssel.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. superglue-ai/superglue on GitHub