Multica bündelt 26 Coding-Agenten in einem selbstgehosteten Workspace

Fünf Coding-Agenten in fünf Terminalfenstern sind schnell gestartet. Sobald mehrere davon gleichzeitig an einem Repository arbeiten, beginnt jedoch die Koordinationsarbeit: Agent A wartet auf Zugriff, Agent B übernimmt versehentlich dasselbe Issue, während ein dritter Diff bereits zur Abnahme bereitliegt. Der Zeitgewinn schrumpft.

Multica will diese Abläufe in einen gemeinsamen, selbstgehosteten Workspace verlagern. Das offene Projekt unterstützt nach eigener Angabe 26 Agenten-CLIs, darunter Claude Code, Codex, Cursor und Kimi. Ein Agent übernimmt ein Issue, meldet Fortschritt und Blocker und reicht seine Arbeit zur Prüfung ein. Auftrag, Entscheidungen und Diff bleiben dabei mit dem Lauf verbunden.

Die Idee trifft einen echten Engpass. Mehr parallele Agenten sparen wenig Zeit, wenn ein Entwickler ihren Zustand weiterhin aus einzelnen Sitzungen rekonstruieren muss.

Das Issue wird zur gemeinsamen Akte

Multica beschreibt den Workspace als Arbeitsfläche für Menschen und Coding-Agenten. Aufgaben wandern über Issues an einen Agenten; Kommentare und Laufstatus halten den Weg bis zum Ergebnis fest. Die Arbeit landet zunächst im Review und nicht unmittelbar im Hauptbranch.

Damit erhält die Abnahme eine sichtbare Grenze. Ein fehlgeschlagener Lauf bleibt nachvollziehbar, und ein fertiger Diff braucht weiterhin eine menschliche Freigabe. Fehlt diese Trennung, wächst mit der Zahl paralleler Werkzeuge auch das Risiko, dass ungeprüfte oder widersprüchliche Änderungen im Repository zusammenlaufen.

Ein Bericht von AgentConn nennt außerdem wiederverwendbare Team-Skills: Erfolgreiche Lösungen lassen sich demnach verpacken und später erneut einsetzen. Dadurch kann Wissen aus einer einzelnen Agentensitzung in den gemeinsamen Arbeitsprozess übergehen, statt mit dem geschlossenen Terminalfenster zu verschwinden.

Das funktioniert allerdings nur mit Pflege. Ein veralteter Skill verteilt überholte Annahmen schneller im Team, als eine einzelne Sitzung es könnte.

Selbsthosting bedeutet einen vollständigen Stack

Nach der Self-Hosting-Dokumentation besteht Multica aus einem Go-Backend mit REST-API und WebSocket-Server, einer Webanwendung auf Basis von Next.js 16 sowie PostgreSQL 17; zusätzlich installiert jeder Nutzer für lokale Agentenläufe die Multica-CLI und startet einen Agent-Daemon auf dem eigenen Rechner. Docker und Docker Compose gehören ebenfalls zu den Voraussetzungen.

Die eigentliche Agentenausführung bleibt laut AgentConn auf der eigenen Maschine oder in der eigenen Cloud-Infrastruktur. Das kann für Organisationen entscheidend sein, die Quellcode und Laufdaten nicht an eine fremde Agentenplattform übertragen wollen.

Die Kontrolle kostet Betrieb. Backend, Weboberfläche, Datenbank und lokale Daemons bilden gemeinsam eine zusätzliche Infrastruktur, die abgesichert, aktualisiert, überwacht und im Fehlerfall wiederhergestellt werden muss. Fällt PostgreSQL aus, steht auch der gemeinsame Arbeitsstand still.

Self-Hosting ist hier kein Häkchen. Es ist eine Architekturentscheidung.

Der dokumentierte Schnellstart richtet Server, CLI und Konfiguration in zwei Schritten ein. Eine knappe Installation senkt die Einstiegshürde, ersetzt aber kein Betriebskonzept für Backups, Zugriffsrechte und Ausfälle. Wer Multica produktiv prüft, sollte deshalb nicht nur einen Agentenlauf starten, sondern vorab klären, wer den gemeinsamen Workspace betreibt und wer bei einem Ausfall verantwortlich ist.

Der Nutzen muss sich unter Parallelität beweisen

Die breite CLI-Unterstützung erleichtert den Einstieg mit unterschiedlichen Werkzeugen. Sie sagt jedoch nichts darüber aus, wie zuverlässig diese Agenten dieselben Issues, Statusmeldungen und Review-Grenzen nutzen. Jede weitere Integration vergrößert zudem die Fläche, auf der Änderungen der angebundenen CLIs aufgefangen werden müssen.

AgentConn beschreibt Multica als Koordinationsschicht und berichtet, dass das Projekt am 4. September 2026 Platz fünf bei GitHub Trending erreichte. Damit hat Multica Aufmerksamkeit gewonnen. Belastbare Betriebserfahrung in größeren Teams folgt aus einer Trending-Platzierung noch nicht.

Der überzeugendste Teil des Konzepts ist deshalb nicht die Zahl der unterstützten Werkzeuge, sondern die Review-Grenze vor dem Hauptbranch. Sie greift dort an, wo parallele Agentenarbeit tatsächlich riskant wird: bei unklaren Zuständigkeiten, verlorenen Übergaben und Änderungen, deren Herkunft sich später nur mühsam rekonstruieren lässt.

Ob Multica diese Probleme löst oder lediglich in einen weiteren Stack verschiebt, zeigt erst ein reales Repository mit konkurrierenden Aufgaben. Ein sinnvoller Pilot braucht dafür zwei verschiedene Agenten-CLIs, mehrere unabhängige Issues und ein verbindliches Review vor jedem Merge. Die Mindestregel ist einfach: Der zusätzliche Betrieb lohnt sich erst, wenn der Workspace nachweisbar Doppelarbeit verhindert, festgefahrene Läufe sichtbar macht und die Abnahme beschleunigt.