In Ivy Tendril wird aus einem GitHub-Issue über eine feste Abfolge von Phasen ein fertiger Pull Request: Das Issue trifft per Webhook in der Inbox ein, ein Agent entwirft einen Plan, ein Entwickler prüft und genehmigt den Plan, ein Agent führt ihn in einem isolierten Git-Worktree aus, die Verifikation läuft durch, der Entwickler prüft das Diff und ein Agent eröffnet den Pull Request. Menschen greifen an exakt zwei Punkten ein: beim Plan und beim Diff. Alles andere wird autonom von Agenten erledigt – und viele Tickets durchlaufen diese Kette zur selben Zeit. Dieser Artikel begleitet ein Ticket durch alle Phasen.
Der Lebenszyklus im Überblick
Ivy bezeichnet diesen Ablauf als Software-Fabrik: eine definierte Sequenz von Phasen, in denen Agenten die Arbeit ausführen und Menschen an festgelegten Prüfpunkten die Ergebnisse abnehmen. Die Phasen, die jeweiligen Akteure und die Abschlussbedingungen sind nachfolgend aufgeführt. Die vollständige Referenz finden Sie in der Lebenszyklus-Dokumentation.
| Phase | Akteur | Abschlussbedingung |
|---|---|---|
| Inbox | Agent (Webhook) | Das Issue ist mit Titel, Beschreibung, Labels und Link gespeichert |
| Draft plan | Agent (CreatePlan) | Ein Entwurf mit Ziel, Umfang, betroffenen Dateien und Verifikationsschritten existiert |
| Plan review, Checkpoint 1 | Mensch | Der Entwickler gibt den Plan frei (ggf. nach Annotationen und Überarbeitungen) |
| Execute | Agent (ExecutePlan) | Der Agent meldet den Plan in seinem Worktree als abgeschlossen |
| Verify | Agent | Tests und Linter sind durchgelaufen und das Diff liegt zur Prüfung bereit (Verifikations-Gates) |
| Diff review, Checkpoint 2 | Mensch | Der Entwickler gibt das Diff frei |
| Pull request | Agent (CreatePr) | Für den Branch des Plans existiert ein Pull Request auf GitHub, erstellt über die Pull Requests REST API |
| Merge und Bereinigung | Mensch merged, Agent bereinigt | Der Worktree wird gelöscht und Erkenntnisse werden im Speicher (Memory) abgelegt |
Vom Issue zum genehmigten Plan
Das Issue trifft ein
Ein Benutzer erstellt Issue #418 im Repository: „Export to CSV drops rows with commas in the description field.“ Die GitHub-Integration liefert es per Webhook an die Inbox von Tendril. Zu diesem Zeitpunkt wird noch nichts ausgeführt. Die Inbox ist eine Übersicht eingehender Aufgaben, und ein Entwickler entscheidet, welche davon in Pläne umgewandelt werden. Fehlerberichte aus jam.dev treffen auf demselben Weg ein.
CreatePlan entwirft den Plan
Der Entwickler wählt das Issue aus und klickt auf Create plan. Die CreatePlan-Promptware liest das Issue, ihr eigenes Repository-Memory sowie den relevanten Quellcode und erstellt einen Entwurf. Ein typischer Entwurf nennt das Ziel, die voraussichtlich betroffenen Dateien (src/export/csv.ts nebst Testdatei), den Lösungsansatz (Felder mit Trennzeichen gemäß RFC 4180 in Anführungszeichen setzen) und die Verifikationsschritte (Testfall mit Komma in der Beschreibung ergänzen, bestehende Export-Tests ausführen). Der Entwurf erscheint in Drafts.
Checkpoint 1: Der Entwickler prüft den Plan
Dies ist der erste der beiden menschlichen Prüfpunkte. Der Entwickler liest den Entwurf und bemerkt ein Problem: Der Plan schlägt vor, ausschließlich das Beschreibungsfeld in Anführungszeichen zu setzen, doch derselbe Fehler betrifft sämtliche Freitextspalten. Anstatt den Plan manuell umzuschreiben, markiert der Entwickler den entsprechenden Absatz und fügt eine Annotation hinzu: „Apply the quoting to all string columns, not just description.“ Die UpdatePlan-Promptware schreibt den Plan unter Berücksichtigung des Kommentars neu, und der überarbeitete Entwurf wird erneut vorgelegt.
Fehlt dem Entwurf Detailtiefe, kann der Entwickler ExpandPlan ausführen. Zeigen die Kommentare, dass das Ticket eigentlich aus zwei getrennten Aufgaben besteht – beispielsweise dem Bugfix und einer separaten Migration des Exportmoduls auf eine geteilte CSV-Bibliothek –, teilt SplitPlan die Aufgabe in zwei unabhängig voneinander weiterlaufende Pläne auf. Sobald der Entwickler zufrieden ist, erteilt er die Freigabe. Der Plan bildet nun die verbindliche Spezifikation für den Lauf, und der Agent muss das ursprüngliche Issue nicht mehr neu interpretieren.
Ausführung und Verifikation
ExecutePlan läuft in einem isolierten Worktree
Nach der Freigabe erstellt Tendril für den Plan einen eigenen Git-Worktree auf einem eigenen Branch und startet den ausgewählten Agenten darin. Der Entwickler wählt den Agenten pro Plan: Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode oder einen anderen CLI-Agenten. Der Arbeitsablauf bleibt unabhängig von der Agentenwahl exakt gleich.
Der Worktree ist entscheidend, da andere Pläne parallel ausgeführt werden. Jeder Plan besitzt sein eigenes Arbeitsverzeichnis und seinen eigenen Branch; unfertige Änderungen eines Plans können andere Pläne daher nicht beeinträchtigen, und der Haupt-Branch bleibt bis zum Review unberührt. Die Hintergründe dieses Konzepts werden in Git-Worktrees für parallele KI-Agenten ausführlich erläutert.
Während der Agent arbeitet, streamt die Jobs-Ansicht seine Ausgaben und Toolaufrufe in Echtzeit: gelesene Dateien, ausgeführte Befehle, gestartete Tests sowie die bisher verbrauchten Tokens und Kosten. Der Entwickler kann zusehen oder zwischenzeitlich einen anderen Plan prüfen. Ist ein Cloudflare Quick Tunnel aktiviert, steht derselbe Stream auch auf dem Smartphone zur Verfügung.
Die Verifikation läuft
Sobald der Agent die Fertigstellung des Plans meldet, startet die Verifikation im Worktree: Testsuite und Linter laufen durch, und das resultierende Diff wird zur Überprüfung aufbereitet. Die Ergebnisse werden in der Review-Ansicht auf drei Reitern dargestellt: Tests, Lint und Diff. Ein fehlschlagender Test oder ein Linter-Fehler ist sofort sichtbar, noch bevor ein Mensch Zeit darauf verwendet, den Code zu lesen. Pro- und Enterprise-Pläne können Verifikationsergebnisse zudem aus der CI-Pipeline importieren. Warum Verifikation als harte Schranke statt als unverbindliche Empfehlung behandelt werden sollte, beschreibt der Artikel Verifikations-Gates für KI-generierten Code.
Review, Pull Request und Bereinigung
Checkpoint 2: Der Entwickler prüft das Diff
Dies ist der zweite menschliche Prüfpunkt. In der Review-Ansicht analysiert der Entwickler das Diff gemeinsam mit dem Plan und den Verifikationsergebnissen. Bei Issue #418 ändert das Diff src/export/csv.ts, fügt eine Hilfsfunktion für Anführungszeichen hinzu und erweitert die Testdatei um drei Fälle: ein Komma, ein Anführungszeichen und einen Zeilenumbruch innerhalb eines Feldes. Alle Tests bestehen und der Linter meldet keine Fehler. Der Entwickler gibt das Diff frei.
Entspricht das Diff nicht den Erwartungen, verweigert der Entwickler die Freigabe, ergänzt den Plan um die fehlenden Anforderungen und stößt die Ausführung erneut an. Ohne diese Freigabe gelangt kein Code zu GitHub.
CreatePr öffnet den Pull Request
Die CreatePr-Promptware eröffnet den Pull Request auf Basis des Plan-Branches. Ab hier greift der gewohnte Review- und Merge-Prozess des Teams auf GitHub. Die Pull-Requests-Ansicht in Tendril überwacht dabei kontinuierlich den Status aller so erstellten offenen PRs.
Nach dem Merge
Wird der PR gemergt, entfernt Tendril den Worktree. Die ExecutePlan-Promptware schreibt anschließend ihre Erkenntnisse in den Speicher. Bei diesem Ticket wird beispielsweise notiert: „The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export“. Der nächste Plan, der das Exportmodul betrifft, liest diesen Hinweis vor Beginn der Arbeiten.
Der gesamte Ablauf benötigt bei einem Ticket dieser Größenordnung nur wenige Minuten Agentenzeit und zwei kurze Momente menschlicher Aufmerksamkeit. Ivy berichtet, dass das eigene Entwicklungsteam nach Einführung dieses Workflows von rund 10 auf über 100 Pull Requests pro Tag skalieren konnte – bei unverändert strikter Einhaltung der beiden Kontrollpunkte.
Erste Schritte
Installieren Sie Tendril, binden Sie die GitHub-Integration an, damit Issues in der Inbox eingehen, und führen Sie zunächst ein einzelnes Ticket mit einem Agenten durch die Kette, bevor Sie Pläne parallel laufen lassen.
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Unter Windows nutzen Sie irm https://cdn.ivy.app/install-tendril.ps1 | iex. Die kostenlose Edition, quelloffen unter der Functional Source License verfügbar, enthält den kompletten Lebenszyklus. Pro und Enterprise bieten darüber hinaus Team-Features, Verifikationsimporte aus der CI und On-Premises-Hosting.
Häufig gestellte Fragen
Kann der Agent einen Prüfpunkt überspringen, wenn die Änderung klein ist?
Nein. Die beiden Kontrollpunkte gelten ausnahmslos für jeden Plan. Eine einzeilige Korrektur durchläuft die Plan- und Diff-Genehmigung genauso wie jeder andere Plan. Kleine Pläne erfordern lediglich weniger Zeit beim Review.
Was geschieht, wenn zwei parallele Pläne dieselbe Datei ändern?
Da jeder Plan in einem eigenen Worktree und auf einem eigenen Branch arbeitet, tritt während der Ausführung kein Konflikt auf. Der Konflikt wird erst sichtbar, wenn der zweite Pull Request gerebased oder gemergt wird, und wird wie gewohnt über Git gelöst. Das modulare Aufteilen von Plänen reduziert solche Überschneidungen deutlich.
Muss das Issue zwingend aus GitHub stammen?
Nein. Pläne können auch aus einer manuell eingegebenen Idee, einem Fehlerbericht aus jam.dev, der CLI, der REST-API oder dem MCP-Server entstehen. Der GitHub-Webhook ist lediglich ein möglicher Einstiegspunkt in die Inbox.
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.