Um Coding-Agenten parallel zu betreiben, geben Sie jedem Agenten seinen eigenen Git-Worktree und Branch, speisen die Agenten aus einer Warteschlange vorab von Menschen geprüfter Pläne, führen Tests und Linter innerhalb jedes Worktrees aus, bevor jemand das Diff liest, und erfassen die Kosten jedes Plans. Die meisten Teams gelangen zu diesem Setup, indem sie drei frühere Muster durchlaufen: ein einzelner Agent im Chat-Fenster, ein Agent pro Branch von Hand gestartet und eine Warteschlange mit Worker-Agenten. Jedes Muster löst ein Problem und bringt das nächste zum Vorschein. Dieser Leitfaden beschreibt die vier Muster, was auf jeder Stufe bricht und welche sechs Kernaufgaben ein Orchestrator zwingend übernehmen muss.

Die vier Muster

Steve Yegges „8 Stufen der KI-gestützten Entwicklung“ (2025) bietet hierfür einen nützlichen Orientierungsrahmen. Die zugrunde liegende Schleife – über einen Schritt nachdenken, handeln, das Ergebnis beobachten, wiederholen – entspricht dem in Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models formalisierten Prinzip. Jedes der folgenden Muster ist eine andere Antwort darauf, wer diese Schleife überwacht. Die meisten Teams befinden sich derzeit auf Stufe 2 bis 3: Ein Entwickler promptet einen Agenten, prüft das Ergebnis und committet. Die Orchestrierung mit parallelen Agenten, persistentem Speicher und Review-Gates entspricht Stufe 8.

Muster 1: Ein einzelner Agent im Chat-Fenster

Ein Entwickler öffnet ein Terminal oder ein IDE-Panel, beschreibt eine Aufgabe und beobachtet, wie der Agent Dateien im Arbeitsverzeichnis editiert. Der Durchsatz beträgt exakt eine Aufgabe pro Entwickler gleichzeitig, da sich Agent und Mensch denselben Checkout teilen. Wird eine zweite Aufgabe gestartet, bevor die erste abgeschlossen ist, landen beide Änderungen im selben Baum – und das resultierende Diff verliert jede Aussagekraft.

Muster 2: Ein Agent pro Branch, manuell gestartet

Der nächste logische Schritt besteht darin, jeder Aufgabe ihren eigenen Branch und ihren eigenen Checkout zuzuweisen. Git-Worktrees machen dies extrem leichtgewichtig: ein gemeinsamer Objektspeicher, mehrere unabhängige Arbeitsverzeichnisse.

# Aus dem Haupt-Checkout heraus:
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "Add a search button to the sidebar. Run the tests when done."

Ein Entwickler kann nun zwei oder drei Agenten gleichzeitig ausführen, jeden in seinem eigenen Ordner. Was hierbei bricht, ist die Übersicht: Niemand dokumentiert, welcher Worktree zu welcher Aufgabe gehört, und Prompts verschwinden im Scrollback des Terminals. Wenn zwei Agenten auf dieselben Dateien angesetzt werden, entstehen Merge-Konflikte, die erst beim Mergen auffallen.

Muster 3: Warteschlange mit Worker-Agenten in isolierten Worktrees

Sobald ein Team mehr als eine Handvoll Agenten betreibt, wird das manuelle Starten zum größten Engpass. Die Lösung ist eine Warteschlange: Aufgaben werden eingereiht, Worker-Prozesse greifen sie ab, erstellen einen Worktree, führen den Agenten aus, pushen den Branch und öffnen einen Pull Request. Multi-Agenten-Forschungs-Frameworks wie AutoGen formalisieren exakt diese Worker-Warteschlangen-Architektur.

Doch wenn der Mensch beim Aufgabenstart komplett außen vor bleibt, offenbart sich die nächste Schwachstelle: Niemand prüft die Aufgabenstellung vor dem Start des Agenten. Schlecht spezifizierte Aufgaben verbrennen teure Token für Pull Requests, die niemand haben will. Zudem prüft niemand das Ergebnis vor dem Erstellen des PRs, wodurch menschliche Reviewer zum Flaschenhals werden. Und da die Warteschlange unbeaufsichtigt läuft, steigen die Kosten unbemerkt an.

Muster 4: Plan-Lebenszyklus mit menschlichen Kontrollpunkten

Das vierte Muster ergänzt zwei menschliche Kontrollpunkte und einen automatisierten Verifikationsschritt: Aus einer Aufgabe wird ein schriftlicher Plan. Ein Mensch liest den Plan, bevor eine einzige Zeile Code geschrieben wird. Agenten führen den Plan in isolierten Worktrees aus. Tests, Linter und eine Diff-Zusammenfassung laufen direkt im Worktree – nach demselben Prinzip der Continuous Integration, angewendet pro Agent statt pro Entwickler. Ein Mensch prüft das Diff. Erst danach wird der Pull Request eröffnet.

Ivy bezeichnet dieses Muster als Software-Fabrik: ein wiederholbarer Workflow, bei dem jede Änderung dieselben Phasen und dieselben zwei Freigaben durchläuft. Eine ausführliche Definition finden Sie im Leitfaden Was ist eine Software-Fabrik.

Was auf jeder Stufe bricht

Muster	Was es löst	Was als Nächstes bricht
Einzelner Agent im Chat	Noch nichts; dies ist die Ausgangsbasis	Nur eine Aufgabe pro Entwickler; geteiltes Arbeitsverzeichnis
Ein Agent pro Branch, manuell	Parallele Aufgaben ohne Verzeichniskollisionen	Kontextverlust, ungesicherte Prompts, Konflikte erst beim Merge
Warteschlange mit Workern	Manueller Startschritt entfällt	Ungeprüfte Ein- und Ausgaben, unkontrollierte Kostenexplosion
Plan-Lebenszyklus mit Kontrollpunkten	Verhindert Fehlversuche und ungeprüfte Diffs	Erfordert Tooling für Queue, Isolation, Verifikation, Kosten und Speicher

Was ein Orchestrator leisten muss

Ein Orchestrator ist die Software, die Muster 4 verlässlich steuert. Er hat sechs Kernaufgaben – fehlt auch nur eine davon, muss sie manuell erledigt werden und wird sofort wieder zum Flaschenhals:

Warteschlange (Queue): Pläne warten in definierter Reihenfolge mit klarem Status: Entwurf (Draft), Genehmigt (Approved), Wird ausgeführt (Executing), Verifiziert (Verifying), Im Review (In Review), Gemergt (Merged). Der Status muss ohne Terminal ersichtlich sein.
Isolation: Jeder aktive Plan erhält seinen eigenen Worktree und Branch. Der Main-Branch empfängt niemals direkte Schreibzugriffe eines Agenten. Git-Worktrees für parallele KI-Agenten erklärt, warum Worktrees geteilten Checkouts und Containern überlegen sind.
Verifikation: Tests, Linter, Typüberprüfungen und Diff-Zusammenfassungen laufen isoliert im Worktree, nachdem der Agent fertig ist und bevor ein Mensch den Code sieht. Bei Fehlern geht die Aufgabe samt Fehlerausgabe zurück an den Agenten.
Review: Exakt zwei Kontrollpunkte (Plan und Diff) mit eindeutiger Freigabe- oder Ablehnungsfunktion. Eine Ablehnung auf Planebene kostet null Token für die Codeerstellung. Eine Ablehnung auf Diff-Ebene kostet genau einen Durchlauf.
Kostenabrechnung: Token und Budget werden pro Plan und pro Job präzise erfasst, sodass das Team jederzeit sieht, was ein gemergter PR gekostet hat und wie viel für abgebrochene Pläne aufgewendet wurde.
Speicher (Memory): Was ein Agent in einem Plan gelernt hat, muss im nächsten Plan verfügbar sein. Andernfalls startet jeder Agent bei null und wiederholt dieselben Fehler.

Wie Ivy Tendril dies umsetzt

Ivy Tendril ist eine Local-First-Desktop-Anwendung für macOS, Windows und Linux, die Muster 4 für beliebige CLI-Coding-Agenten abbildet. Über den Befehl tendril --web läuft Tendril auch vollständig headless.

Queue: Die Ansicht Plans verwaltet alle Pläne samt Lebenszyklusstatus. Drafts, Icebox und Empfehlungen halten noch nicht freigegebene Arbeiten fest. Pläne können über Webhooks aus GitHub Issues und jam.dev-Fehlerberichten oder über MCP-Server, REST-API und CLI erstellt werden.
Isolation: Beim Start der Ausführung legt Tendril automatisch einen Git-Worktree und einen Branch für diesen Plan an. Viele Pläne laufen zeitgleich nebeneinander. Nach dem Merge entfernt Tendril den Worktree wieder. Siehe Git-Worktrees für parallele KI-Agenten.
Verifikation: Die Review-App zeigt Tests, Linting und Diffs in separaten Tabs für jeden Plan. In Pro-Plänen können Verifikationsergebnisse direkt aus der CI importiert werden.
Review: Am Plan-Kontrollpunkt kann der Reviewer einen Entwurf per Expand, Split oder Update verfeinern oder direkt Inline-Kommentare hinterlassen, woraufhin der Plan neu generiert wird. Der Diff-Kontrollpunkt folgt nach der Verifikation. Ohne beide Freigaben öffnet sich kein Pull Request.
Kostenabrechnung: Token-Verbrauch und Kosten werden pro Plan und Job gemessen. Das Dashboard bietet klare Kosten-KPIs und Trendanalysen.
Speicher (Memory): Jede Phase wird von einer Promptware-Einheit gesteuert, bestehend aus einer versionierten Program.md mit Instruktionen, einem Memory/-Verzeichnis für dauerhafte Erkenntnisse, abgegrenzten Tools/ und Logs/. Zu den Standardeinheiten gehören CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr und CreateIssue. Siehe Promptware.

Tendril ist vollkommen agentenunabhängig. Es unterstützt Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode sowie jedes andere CLI-Tool. Modell und Agent können pro Plan frei gewählt werden. Der Code bleibt stets lokal auf Ihrem Rechner; externe Aufrufe erfolgen ausschließlich zur konfigurierten LLM-API und zu GitHub.

Ivy berichtet, dass das eigene Entwicklungsteam die Anzahl täglicher Pull Requests nach Einführung dieses Workflows von etwa 10 auf über 100 steigern konnte.

Erste Schritte

Installieren Sie Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh unter macOS oder Linux, bzw. irm https://cdn.ivy.app/install-tendril.ps1 | iex unter Windows. Details finden Sie unter Installation.
Öffnen Sie ein Repository in Tendril und hinterlegen Sie den API-Key Ihres bevorzugten Modellanbieters.
Erstellen Sie einen Plan aus einem bestehenden Issue, prüfen Sie den Entwurf, starten Sie die Ausführung und begutachten Sie das Diff in der Review-App.
Sobald der erste Plan gemergt ist, erstellen Sie drei Pläne gleichzeitig und beobachten Sie die parallele Ausführung.

Tendril ist kostenlos und quelloffen unter der Functional Source License verfügbar. Erweiterte Team-Funktionen, SSO, On-Premises-Hosting und CI-Verifikationsimporte sind in den Pro- ($59 pro Nutzer/Monat) und Enterprise-Plänen enthalten.

Häufig gestellte Fragen

Benötige ich Container, um Agenten parallel auszuführen?

Nein. Git-Worktrees bieten jedem Agenten ein eigenes Arbeitsverzeichnis und einen eigenen Branch bei geteiltem Objektspeicher. Container bringen zusätzliche Laufzeit-Isolation, die sinnvoll ist, wenn Agenten Systempakete installieren oder Ports binden müssen. Die meisten Software-Entwicklungsaufgaben benötigen dies nicht.

Wie viele Agenten können gleichzeitig laufen?

Das Limit wird in der Praxis durch die Rate-Limits des Modellanbieters und die Rechenkapazität der lokalen Maschine für Tests bestimmt, nicht durch den Orchestrator. Beginnen Sie mit drei bis fünf parallelen Plänen und steigern Sie die Anzahl, solange die Verifikationsschritte zügig abschließen.

Was geschieht, wenn zwei Pläne dieselbe Datei bearbeiten?

Der zweite Plan, der gemergt werden soll, wird auf seinem Branch einen Konflikt erzeugen. Die Lösung liegt bereits in der Planungsphase: Pläne, die dieselben Module berühren, sollten vor der Ausführung aufgeteilt oder sequenziert werden. Genau dafür steht die Split-Aktion in Tendril zur Verfügung.

Erste Schritte mit Ivy Tendril

Sind Sie bereit für parallele Agenten-Orchestrierung auf Entwickler-Niveau?

Code erkunden: Untersuchen Sie Ivy Tendril auf GitHub (Open Source).
Dokumentation lesen: Finden Sie Integrationsanleitungen unter tendril.ivy.app.
Architektur-Sitzung vereinbaren: Kontaktieren Sie renco@ivy.app für eine 30-minütige technische Beratung.

Agenten-Orchestrierungsmuster: Parallele Coding-Agenten effizient betreiben