Magic von dtyq: eine Agentenplattform, die Daten, Budgets und Freigaben zentralisiert

Warum das Projekt existiert: Kontrolle statt Bastellösung

Das README beginnt mit einem Vergleich zu OpenClaw, das als persönlicher Assistent beschrieben wird: alle wichtigen IM als Gesprächskanäle, beliebige LLMs, autonomer Betrieb rund um die Uhr. Genau dieser Zuschnitt erzeugt im Unternehmen vier Probleme, die das Projekt benennt: Daten liegen in einzelnen Konten und verschwinden mit dem Mitarbeiter, es gibt keine Budgetgrenzen, Ausgaben enden als reiner Text, und riskante Aktionen laufen ohne Freigabe durch. Magic positioniert sich als Antwort auf diese vier Punkte, nicht als besserer Assistent. Zielgruppe sind laut README ausdrücklich zwei sehr unterschiedliche Lager: Ein-Personen-Unternehmen und kleine Teams, die Rollen abdecken wollen, für die niemand eingestellt wurde, und größere Organisationen, die KI zentral verwalten und Abteilungsbudgets zuordnen müssen. Diese Doppeladressierung ist auffällig. Ein Solo-Gründer braucht keine Mandantentrennung, ein Konzern keine Vorlage für Vertragsentwürfe.

Was im Repository sichtbar ist und was nicht

Der Code liegt überwiegend in TypeScript, Standardbranch ist master, der letzte Push datiert auf den 12. August 2026. Releases wurden für diese Auswertung nicht abgerufen, belastbare Versionsnummern fehlen daher. Die Lizenz ist als NOASSERTION ausgewiesen, das heißt, die automatische Erkennung konnte keine eindeutige Standardlizenz zuordnen. Wer Magic produktiv einsetzen will, muss die Lizenzdatei im Repository selbst lesen und klären, ob Weitergabe, Änderung und kommerzieller Betrieb erlaubt sind. Aus der Ferne lässt sich dazu nichts sagen, und ein Testlauf ersetzt diese Prüfung nicht. Die Themenliste des Repositories nennt unter anderem agent, workflow, low-code, no-code, mcp und sandbox, was grob zur Selbstbeschreibung passt, aber keine Architektur belegt.

Der Aufbau: Agenten in Containern, Traffic über einen Sidecar

Die einzige Stelle im Material, die technisch konkret wird, ist der Abschnitt zur Sicherheit. Dort heißt es, jeder Agent laufe in einem eigenen Sandbox-Container, getrennt vom Hauptsystem in einem separaten VPC und über private Endpunkte angebunden. Ein Sidecar-Netzwerkproxy verwalte den Verkehr unabhängig pro Nutzer, mit vollständiger Ressourcen- und Datentrennung zwischen Mandanten. Das ist eine Aussage über die Betriebsform, nicht über den Code: Die Plattform geht davon aus, dass Agenten beliebigen, auch fehlerhaften oder bösartigen Code ausführen, und zieht daraus die Konsequenz, sie wegzusperren statt ihnen zu vertrauen. Der zweite Mechanismus ist die Freigabe: Bei als riskant eingestuften Operationen, im README genannt werden Datenlöschung und E-Mail-Versand, wird ein Genehmigungsworkflow ausgelöst, routinemäßige Aktionen laufen autonom. Wer das selbst nachbauen will, braucht genau diese zwei Dinge, eine Isolation und einen Haltepunkt vor der Aktion. Ob die Klassifizierung riskanter Aktionen konfigurierbar ist oder fest im Code steht, geht aus dem Material nicht hervor.

Installation: was das README zeigt und was es schuldig bleibt

Das README verlinkt einen Abschnitt mit dem Anker self-hosted-deployment und setzt einen Deploy-now-Hinweis direkt in die Badge-Zeile. Konkrete Befehle, Compose-Dateien oder Umgebungsvariablen enthält der vorliegende Textauszug nicht, er bricht zudem im Abschnitt zum offenen Ökosystem ab. Wer die Installation plant, muss den Deployment-Abschnitt im Repository selbst aufrufen und dort nachsehen, welche Dienste gestartet werden, welche Ports belegt sind und wie der Sidecar-Proxy pro Nutzer konfiguriert wird. Das ist keine Kleinigkeit: Eine Plattform, die Agenten in separaten Containern und getrennten Netzen betreibt, hat mehr bewegliche Teile als eine einzelne Anwendung mit einer Datenbank. Rechnen Sie mit mehreren Komponenten, nicht mit einem Binary. Die im README erwähnten Budgetgrenzen pro Abteilung, pro Nutzer und pro Agent sind ebenfalls Konfigurationsarbeit, deren Schlüsselnamen im Auszug fehlen.

Die Ausgabeschicht: Ergebnisse statt Chatverlauf

Ein wiederkehrender Punkt im README ist, dass Ausgaben nicht als Text enden sollen. Ein eingebautes Rendering-Framework soll Ergebnisse direkt in fertige Artefakte überführen: Präsentationen, Daten-Dashboards, Meeting-Zusammenfassungen, Berichte, Excel-Dateien und eine als infinite canvas bezeichnete Fläche für Bilder. Das ist der Teil, der Magic von reinen Workflow-Engines unterscheidet, denn dort endet der Lauf typischerweise in einem JSON-Objekt oder einer Benachrichtigung, und die Formatierung bleibt Handarbeit. Der Preis dafür ist Bindung: Wer Ausgaben als PPTX oder XLSX braucht, akzeptiert, dass die Plattform das Format bestimmt. Wie viel Kontrolle über Layout und Vorlagen bleibt, lässt sich aus den Screenshot-Verweisen im README nicht ableiten.

Grenzen: wo Magic das falsche Werkzeug ist

Der Betrieb in einem separaten VPC mit privaten Endpunkten und Sidecar-Proxy ist eine Architekturentscheidung mit Folgen. Sie setzt voraus, dass die ausführende Umgebung überhaupt in mehrere Netze aufgeteilt werden kann. Wer Magic auf einem einzelnen gemieteten Server ohne Netzsegmentierung betreibt, verliert genau die Eigenschaft, mit der das Projekt wirbt, und behält den Aufwand. Zweitens: Die Freigabepflicht für riskante Aktionen ist ein Sicherheitsgewinn und eine Verfügbarkeitsbremse. Ein Agent, der nachts Daten bereinigen soll, wartet dann auf einen Menschen. Drittens: Die Dokumentation im vorliegenden Auszug ist überwiegend Nutzenargumentation. Zu Fehlerbehandlung, Wiederholungsversuchen, Datenbankmigrationen oder dem Verhalten bei Ausfall einzelner Dienste steht dort nichts. Für ein System, das Unternehmensdaten hält, ist das eine Lücke, die man vor der Entscheidung selbst schließen muss.

Alternative: n8n und der Unterschied im Ansatz

Der naheliegende Vergleich ist n8n, eine quelloffene Workflow-Automatisierung, die ebenfalls selbst gehostet werden kann und deren Knoten HTTP-Aufrufe, Datenbanken und LLM-Endpunkte verbinden. Der Unterschied liegt nicht im Funktionsumfang, sondern im Zentrum des Modells. n8n hat einen Workflow als oberste Einheit, der deterministisch abläuft: Sie definieren Schritte, Verzweigungen und Fehlerpfade, und das Ergebnis ist reproduzierbar. Magic setzt den Agenten an diese Stelle, also eine Instanz, die selbst entscheidet, welche Werkzeuge sie wann aufruft. Daraus folgen die Kontrollschichten, die Magic zusätzlich mitbringt: Budgets, Freigaben, Sandbox. Wer einen festen, prüfbaren Ablauf braucht, etwa eine nächtliche Rechnungsexport-Kette, ist mit n8n besser bedient und spart sich die Agenteninfrastruktur. Wer Aufgaben hat, deren Schritte sich vorher nicht vollständig angeben lassen, zahlt bei n8n mit manueller Nacharbeit und bei Magic mit Betriebsaufwand.

Wartung, Upgrades und die Lizenzfrage

Zum Wartungsaufwand lässt sich aus dem Material nur begrenzt etwas sagen. Releases wurden nicht abgerufen, ein Änderungsprotokoll liegt nicht vor. Sichtbar ist ein aktiver Branch mit einem Push im August 2026, was auf laufende Entwicklung hindeutet, aber nichts über Stabilität zwischen Versionen aussagt. Wer die Plattform einführt, sollte deshalb vorab klären, wie Upgrades ablaufen, ob Datenbankschemata migriert werden und ob die Sandbox-Container eigene Images verwenden, die separat aktualisiert werden müssen. Letzteres ist wahrscheinlich, denn ein Container, der fremden Code ausführt, braucht eigene Pflege. Die Lizenz ist als NOASSERTION ausgewiesen, das ist der wichtigste offene Punkt. Ohne eindeutige Lizenzkennung lässt sich nicht beurteilen, ob eine kommerzielle Nutzung oder eine Weitergabe der angepassten Plattform zulässig ist. Das ist keine Rechtsberatung, sondern eine Aufforderung, die LICENSE-Datei im Repository zu lesen, bevor Code in eine Produktionsumgebung wandert.

Redaktionelles Fazit

Wer mehrere Abteilungen mit Agenten versorgen will und dafür zentrale Budgets, Freigabeschritte und eine eigene Sandbox braucht, findet in Magic einen sinnvollen Ausgangspunkt. Wer heute einen einzelnen Assistenten für sich selbst betreiben will, trägt mit dieser Plattform deutlich mehr Betriebsaufwand als nötig. Vor dem Rollout sollte geprüft werden, wie der Sidecar-Proxy pro Nutzer konfiguriert wird, ob die Instanz tatsächlich in einem separaten VPC mit privaten Endpunkten läuft, und was die als NOASSERTION ausgewiesene Lizenz für die geplante Nutzung erlaubt. Ohne geklärte Lizenzfrage bleibt die Installation ein Testsystem.

Offizielle Quellen

1. dtyq/magic on GitHub
2. Issues
3. Project website
4. README