AgentConnect: Open-Source-Plattform für Multi-Agenten-Teams, in der Claude Code, Codex und Menschen im selben Thread arbeiten

Das Problem

AgentConnect ist eine Open-Source-Plattform unter der Apache-2.0-Lizenz. Sie soll es Menschen und mehreren KI-Agenten ermöglichen, in den Gesprächen und Arbeitsabläufen zusammenzuarbeiten, die ein Team bereits nutzt. Das README beginnt mit dem Satz „die Open-Source-Multi-Agenten-Alternative zu Claude Tag“ und dem Motto „@ any agent“. Gemeint ist: Wo immer Arbeit entsteht, arbeiten die Agenten neben dem Team und miteinander und lernen dabei weiter.

Der Hintergrund ist leicht wiederzuerkennen. Die meisten Coding-Agenten sind noch immer persönliche Werkzeuge im Terminal einer einzelnen Person. Kolleginnen und Kollegen sehen nicht, was der Agent tut. Sie können seine Sitzung nicht übernehmen und seine Ergebnisse nicht prüfen. Der Kontext, den er aufbaut, bleibt auf einem Laptop. So schreibt jedes Team denselben Klebecode neu: Nachrichtenkanäle, Cron-Jobs, Umgang mit Zugangsdaten, Zusammenführung von Kontext. AgentConnect will diesen Klebecode zur Plattform machen.

Kernarchitektur: drei Komponenten, zwei Ebenen

Das README beschreibt drei Komponenten. Die erste ist der Daemon. Er führt zugewiesene Agenten über eine ihm gehörende ACP-Verbindung (Agent Client Protocol) aus. Er verwaltet Arbeitsbereiche und Sitzungszustand, hält direkte Verbindungen zu den Chat-Plattformen, führt Zeitpläne aus und sendet den Datenverkehr zu Modellanbietern selbst. Die zweite ist das Relay, das optional ist. Es nimmt Callback-basierte Zugriffe und Web-Chat an, leitet zentral verwaltete MCP- und OpenConnector-Zugriffe weiter und reicht Nachrichten direkt an den zuständigen Daemon durch. Es speichert nichts dauerhaft. Die dritte ist die Control Plane mit Web-Oberfläche. Sie verwaltet Authentifizierung, Konfiguration, Platzierung, Berechtigungen, Metadaten und Beobachtbarkeit. Ausdrücklich freigegebenes Organisationswissen und Skill-Revisionen speichert sie selbst. In allen anderen Fällen leitet sie begrenzte Lesezugriffe bei Bedarf an den Daemon weiter.

Die wichtigste Entwurfsentscheidung ist die Trennung von Datenebene und Steuerungsebene. Live-Nachrichten und ACP-Update-Ströme bleiben auf dem Weg über Daemon und Relay. Abgesehen von freigegebenem Organisationswissen und begrenzten Skill-Paketen speichert die Control Plane nur Koordinations-Metadaten: keine Nachrichtentexte, keine Anhänge, keine ausstehenden Dream-Vorschläge und keine ACP-Sitzungsströme. Das README beschreibt auch das Ausfallverhalten: Ist die Control Plane kurz nicht erreichbar, laufen bestehende Sitzungen und lokale Zeitpläne des Daemons weiter. Nur neue Zuweisungen und Konfigurationsänderungen warten, bis sich der Daemon wieder verbunden hat. Das ist eine pragmatische Antwort auf die erste Frage jedes Plattformteams: Was geht kaputt, wenn der Steuerdienst ausfällt?

Technische Idee eins: Laufzeit-Neutralität durch ACP

AgentConnect bindet sich an keine bestimmte Agenten-Laufzeit. Claude Code, Codex, Grok Build, DeepSeek, Pi und jede andere ACP-kompatible Laufzeit laufen nebeneinander. Jeder Agent hat eigene Laufzeit, eigenes Modell, eigenen Arbeitsbereich, eigene Werkzeuge und eigene Maschine, die getrennt konfiguriert werden. Laut README zwingt der Austausch einer Laufzeit nicht dazu, den Arbeitsablauf drumherum neu aufzubauen.

ACP wirkt wie eine gemeinsame Steckdose. Weil der Daemon mit allen Agenten über dasselbe Protokoll spricht, brauchen die darüberliegenden Schichten für Routing, Berechtigungen und Speicher keine Sonderversion je Werkzeug. Für Teams, die schon mehrere Coding-Agenten mischen, ist das leichter zu pflegen, als für jeden einen eigenen Chat-Bot anzubinden.

Technische Idee zwei: Decisions und Jev-Routing

Der zweite bemerkenswerte Mechanismus sind wiederverwendbare Decisions, angetrieben von Jev (TypeSafe). Eine Decision beantwortet drei Fragen: Wann soll ein Agent antworten, welcher Spezialist bekommt ein neues Gespräch, und welche Laufzeit und welches Modell gelten für eine neue Sitzung.

Das README nennt zwei Szenarien. Beim Support-Triage leitet Jev ein neues Gespräch an die passenden Spezialisten, Menschen und Agenten untersuchen es im selben Thread, und Fehlerbehebung samt Prüfung bleiben von Anfang bis Ende sichtbar. Bei individuellen Code-Reviews wählt Jev für jeden neuen GitHub-Pull-Request die Reviewer sowie Laufzeit und Modell jeder Review-Sitzung. Allgemeine, Architektur- oder Sicherheits-Reviewer können eigene Anweisungen, Repository-Zugriffe, Werkzeuge und Sandbox-Richtlinien haben.

Damit entsteht eine konfigurierbare Richtlinienschicht zwischen „wer arbeitet“ und „womit“, statt dass diese Regeln in einem Bot-Skript vergraben liegen.

Speicher, Wissen und Grenzen

Jeder Agent hat eigenen Speicher und eigene Skills. Teams können geprüftes Knowledge veröffentlichen, das alle Agenten bei Bedarf finden, und der Bereitstellungsleitfaden erwähnt eine optionale Mem0-Konfiguration.

Auf der Kontrollseite nennt das README ausdrückliche Grenzen: wer jeden Agenten und jede Sitzung sehen darf, welche Repositories und Werkzeuge ein Agent nutzen darf und welche anderen Agenten er aufrufen darf. Arbeit kann mit einer Nachricht, einem Issue, einem Pull-Request, einem Webhook oder einem Zeitplan beginnen.

Bereitstellung

Es gibt zwei Wege zum Selbsthosting. Der schnellste führt über Docker: Repository klonen und docker compose up -d --pull always ausführen, dann starten Web-Konsole, Control Plane, Relay und PostgreSQL. Danach öffnet man localhost:3000, fügt in der Konsole einen Daemon hinzu, führt den erzeugten Befehl aus und legt den ersten Agenten an. Der Standard-Stack lauscht nur auf 127.0.0.1 und nutzt einen lokalen Modus ohne Authentifizierung, gedacht für die Evaluierung.

Für Cluster erscheint mit jedem Release ein offizielles Helm-Chart unter derselben Versionsnummer, erreichbar unter oci://ghcr.io/agentconnect-md/charts/agentconnect. Ein getrennter Setup Server läuft auf Loopback an Port 8091 und konfiguriert die Browser-Authentifizierung über Logto, die Apps für GitHub, Slack, Google und Lark beziehungsweise Feishu sowie das Verhalten voreingestellter Agenten. Das Repository enthält außerdem einen Setup-Skill, mit dem Claude Code oder Codex die Installation als interaktives Tutorial begleiten. Die Entwicklung braucht Node 24.12.0 oder neuer und pnpm 11.

Folgen für das Ökosystem

Für Entwickler liegt der Hauptnutzen darin, Agenten aus dem persönlichen Terminal in einen gemeinsamen Teamraum zu holen. Im selben Slack-Thread kann ein Mensch die Arbeit eines Agenten übernehmen, prüfen oder korrigieren.

Für Unternehmen bedeutet Apache-2.0 plus Selbsthosting, dass Agentenausführung und Arbeitsbereiche in einer selbst betriebenen Umgebung bleiben können, was für Compliance-sensible Teams wichtig ist. Der Parallelbetrieb mehrerer Laufzeiten senkt zudem die Abhängigkeit von einem einzelnen Modellanbieter.

Grenzen und offene Fragen

Ein Punkt muss klar benannt werden: Das README veröffentlicht keine Benchmarks, keine Latenzwerte und keine Kosten. Dieser Artikel macht daher keine Leistungsaussagen. Bei einer Bewertung lohnen sich folgende Punkte.

Erstens ist der Standard-Stack ein Evaluierungsmodus ohne Authentifizierung; für den Produktivbetrieb braucht es echte Authentifizierung, öffentliche URLs und die Linux-Sandbox-Voraussetzungen. Zweitens können Agenten, die andere Agenten aufrufen, Kosten vervielfachen und den Schaden von Fehlern vergrößern, daher müssen Berechtigungsgrenzen und Aufrufgraph sorgfältig entworfen werden. Drittens hängen Decisions an Jev, einer externen Komponente, deren Reife und Austauschbarkeit gesondert zu prüfen sind. Viertens erklärt das README Claude Tag selbst nicht, der Vergleich sollte also in der offiziellen Dokumentation geprüft werden.

Ausblick

Wird Multi-Agenten-Arbeit alltäglich, verschiebt sich der Engpass von der Fähigkeit eines einzelnen Agenten zu Organisationsfragen: Routing, Berechtigungen, Speicher und Beobachtbarkeit. AgentConnect setzt auf diese Schicht, als Open Source, selbst hostbar und neutral gegenüber Laufzeiten.

Ob es ein Standard wird, hängt vom Wachstum des ACP-Ökosystems ab und davon, ob die Community reife Praktiken für Sicherheit und Kostenkontrolle entwickelt. Derzeit ist es eine glaubwürdige Referenzimplementierung, die ein Team ausprobieren und anhand eigener Messungen beurteilen kann.