Du bittest deinen KI-Assistenten, das Produkt eines Wettbewerbers zu recherchieren, die Ergebnisse zusammenzufassen, ein Vergleichsdokument zu erstellen und es per E-Mail an dein Team zu schicken. Ein einzelner Agent kann jeden dieser Schritte ausführen — aber sie alle gut, nacheinander und unter Beibehaltung des Kontexts über alle vier Aufgaben hinweg zu erledigen, strapaziert die Grenzen dessen, was eine einzelne Agent-Sitzung elegant bewältigt. Das Context-Window füllt sich. Der Agent verliert den Überblick über frühere Schritte. Die Qualität des Endergebnisses leidet, weil das Modell zu viele Anliegen gleichzeitig jongliert.
Das ist das Problem, das Agent-Schwärme lösen. Statt dass ein Agent alles macht, zerlegt ein Koordinator-Agent die Aufgabe in Teilaufgaben und delegiert jede an einen Spezialisten-Agent. Der Recherche-Agent durchsucht das Web und liefert strukturierte Ergebnisse. Der Schreib-Agent nimmt diese Ergebnisse und erstellt das Dokument. Der E-Mail-Agent versendet das Ergebnis. Jeder Agent arbeitet in seinem eigenen Container, mit seinem eigenen Context-Window, fokussiert auf eine Sache.
Die Idee ist nicht neu — CrewAI und AutoGen erforschen Multi-Agent-Muster seit über einem Jahr. Was an NanoClaws Ansatz anders ist: Jeder Agent im Schwarm läuft in seinem eigenen isolierten Container, was bedeutet, dass die Sicherheits- und Isolationsgarantien, die für Einzelagent-Konversationen gelten, automatisch auf Multi-Agent-Workflows ausgedehnt werden.
Wie Schwärme in NanoClaw funktionieren
NanoClaws Schwarm-Architektur basiert auf einem einfachen Primitiv: Ein Agent kann andere Agents starten. Wenn Claude Code in einem Container läuft, ist eines der verfügbaren Tools die Agent-Delegation — die Fähigkeit, eine Teilaufgabe zu beschreiben und NanoClaw einen neuen Container dafür starten zu lassen. Der Eltern-Agent erhält das Ergebnis zurück, wenn der Kind-Agent fertig ist.
Die Orchestrierung geschieht natürlich durch Claudes eigenes Reasoning. Man definiert keinen Workflow-Graphen und konfiguriert keine Agent-Rollen in einer YAML-Datei. Man beschreibt, was man will, und Claude entscheidet, ob es direkt erledigt oder Teile an Sub-Agents delegiert wird. Die Entscheidung basiert auf demselben Reasoning, das Claude gut darin macht, komplexe Probleme zu zerlegen — es erkennt, wenn eine Aufgabe unabhängige Komponenten hat, die von fokussierter Aufmerksamkeit profitieren würden.
In der Praxis sieht das wie ein Baum von Containern aus. Der Root-Container empfängt die Nachricht, entscheidet, dass Web-Recherche und Dokumentenerstellung nötig sind, startet zwei Kind-Container, wartet auf deren Ergebnisse und synthetisiert eine finale Antwort. Jeder Kind-Container hat seinen eigenen CLAUDE.md-Kontext, seinen eigenen gemounteten Arbeitsbereich und seinen eigenen Satz von Tools. Der Recherche-Agent hat Web-Browsing aktiviert; der Schreib-Agent hat Schreibzugriff auf den gemeinsamen Arbeitsbereich. Keiner kann auf den Kontext oder die Tools des anderen zugreifen.
Warum Container-Isolation für Schwärme wichtig ist
Die meisten Multi-Agent-Frameworks lassen alle Agents im selben Prozess laufen. CrewAIs Agents teilen sich eine Python-Runtime. AutoGens Agents teilen sich einen Konversations-Thread. Das funktioniert für Demos, erzeugt aber im Produktivbetrieb Probleme, die sich im Nachhinein schwer beheben lassen.
Das erste Problem ist der Schadensradius. Wenn ein Agent in einem Schwarm auf eine Prompt-Injection trifft — eine bösartige Website, die versucht, das Verhalten des Agents zu kapern — ist die Injection auf diesen einzelnen Container beschränkt. Sie kann den Eltern-Agent nicht beeinflussen, nicht auf die Kontexte anderer Kind-Agents zugreifen und nicht die Konversationshistorie des ursprünglichen Nutzers lesen. Der kompromittierte Container wird abgebaut, wenn er fertig ist, und der Eltern-Agent erhält die produzierte Ausgabe (die er auf Qualität prüfen kann, bevor er sie verwendet).
Das zweite Problem ist Ressourcenkonflikte. Agents in einem gemeinsamen Prozess konkurrieren um dasselbe Context-Window, denselben Speicher und dieselbe CPU. In NanoClaw hat jeder Container seine eigenen Ressourcen. Ein Recherche-Agent, der schwere Webseiten browst, bremst keinen Schreib-Agent aus, der ein Dokument erstellt. Die Container laufen parallel auf separaten Threads, und das Ressourcenmanagement des Hosts übernimmt die Planung.
Das dritte Problem ist Credential-Scoping. Ein Recherche-Agent braucht Webzugriff, sollte aber keine Dateischreibrechte haben. Ein Dateiverwaltungs-Agent braucht Festplattenzugriff, sollte aber keinen Webzugriff haben. In einem Shared-Process-Framework erfordert die Durchsetzung dieser Grenzen Berechtigungsprüfungen auf Anwendungsebene, die umgangen werden können. In NanoClaw sind die Grenzen Container-Mounts — der Recherche-Agent kann buchstäblich nicht auf die Festplatte schreiben, weil kein beschreibbarer Pfad in seinen Container gemountet ist.
Praktische Schwarm-Muster
Die Muster, die sich aus der realen Nutzung ergeben, sind interessanter als die theoretische Architektur. Das häufigste ist das Recherche-und-Synthese-Muster: Ein Eltern-Agent startet 3–5 Recherche-Agents, die verschiedene Aspekte einer Frage parallel untersuchen, sammelt ihre Ergebnisse und produziert eine synthetisierte Antwort, die gründlicher ist als ein einzelner Agent in einem Durchgang liefern könnte.
Das zweithäufigste Muster ist Entwurf-und-Review. Ein Agent schreibt einen ersten Entwurf, dann startet er einen Reviewer-Agent mit der Anweisung, ihn zu kritisieren. Das Feedback des Reviewers geht zurück an den ursprünglichen Agent (oder einen neuen Entwurfs-Agent) zur Überarbeitung. Das produziert merklich bessere Ergebnisse als Single-Pass-Generierung, weil der Reviewer-Agent ein frisches Context-Window hat und den Entwurf ohne die kognitive Last bewerten kann, ihn selbst geschrieben zu haben.
Das dritte Muster ist Tool-Spezialisierung. Manche Aufgaben erfordern Tools, die teuer oder riskant sind — Web-Browsing, Shell-Befehlsausführung, Dateisystem-Änderungen. Ein Eltern-Agent kann diese Operationen an Kind-Agents mit spezifischem Tool-Zugriff delegieren und dabei seinen eigenen Kontext sauber und seine eigenen Berechtigungen minimal halten. Der Eltern-Agent berührt nie direkt das Dateisystem oder das Netzwerk; er verarbeitet nur die Ergebnisse, die Kind-Agents zurückliefern.
Die Grenzen von Schwärmen
Schwärme sind nicht kostenlos. Jeder Kind-Agent ist ein separater Claude API-Aufruf, was separate Token-Kosten bedeutet. Ein Schwarm, der fünf Recherche-Agents startet, kostet ungefähr fünfmal so viel wie ein einzelner Agent, der die gesamte Recherche durchführt. Für einfache Fragen — „Wie ist das Wetter?" oder „Übersetze diesen Satz" — sind Schwärme reiner Overhead.
Die Latenz summiert sich ebenfalls. Selbst bei paralleler Ausführung muss der Eltern-Agent auf den langsamsten Kind-Agent warten, bevor er Ergebnisse synthetisieren kann. Ein Schwarm von fünf Agents, bei dem einer 30 Sekunden braucht, um eine langsame Website zu browsen, bedeutet, dass der Nutzer 30 Sekunden plus Synthesezeit wartet, unabhängig davon, wie schnell die anderen vier waren.
NanoClaw geht damit pragmatisch um. Claude entscheidet basierend auf der Aufgabenkomplexität, wann Schwärme eingesetzt werden — einfache Fragen bekommen direkte Antworten, komplexe mehrteilige Anfragen werden delegiert. Der Nutzer konfiguriert kein Schwarm-Verhalten; er stellt einfach Fragen, und das System skaliert seinen Ansatz passend zur Komplexität. Das Ziel ist nicht, Schwärme überall einzusetzen — sondern dort, wo sie tatsächlich bessere Ergebnisse liefern als ein einzelner Agent.
Die Multi-Agent-Zukunft besteht nicht darin, einzelne Agents zu ersetzen. Es geht darum, einzelnen Agents die Fähigkeit zu geben, um Hilfe zu bitten, wenn sie sie brauchen, auf eine Weise, die sicher, isoliert und transparent ist. NanoClaws Container-pro-Agent-Modell macht das möglich, ohne die Sicherheitskompromisse, die mit dem Betrieb mehrerer Agents in einer gemeinsamen Umgebung einhergehen.