Eine KI-Agenten-Orchestrierung ist produktionsreif, wenn acht Kriterien erfüllt sind: Agenten arbeiten in isolierten Arbeitsbereichen, jede Änderung durchläuft eine automatisierte Verifikation, Menschen entscheiden an klar definierten Kontrollpunkten, Kosten werden pro gemergter Arbeitseinheit erfasst, Agenten-Instruktionen liegen als versionierte Dateien vor, der Orchestrator ist an keinen einzelnen Modellanbieter gebunden, die Datenresidenz ist lückenlos geklärt und bei fehlgeschlagenen Durchläufen greift ein definierter Wiederherstellungspfad. Ein Pilotprojekt benötigt keinen einzigen dieser Punkte und wirkt dennoch beeindruckend. Der Produktivbetrieb verlangt alle acht, da jeder Punkt für eine Fehlerursache steht, die erst unter realer Last zum Tragen kommt. Dieser Artikel liefert die Checkliste, zeigt typische unzureichende Antworten auf und erklärt, wie Sie jedes Kriterium an Ihrem bestehenden System prüfen.
Die Checkliste
| # | Anforderung | Zu stellende Frage | Unzureichende Antwort |
|---|---|---|---|
| 1 | Workspace-Isolation | Wohin schreibt jeder Agent? | „Direkt in den Repository-Checkout“ |
| 2 | Automatisierte Verifikation | Was muss bestanden sein, bevor ein Mensch prüft? | „Der Reviewer führt die Tests aus“ |
| 3 | Menschliche Kontrollpunkte | Wo genau entscheidet ein Mensch? | „Reviewer prüfen die PRs“ |
| 4 | Kostenzuordnung | Was hat die letzte gemergte Änderung gekostet? | „Wir sehen die monatliche API-Rechnung“ |
| 5 | Versionierte Instruktionen | Wo liegen die Anweisungen des Agenten? | „In einem Prompt, den jemand reinkopiert hat“ |
| 6 | Anbieter-Portabilität | Was bricht weg, wenn das Modell eingestellt wird? | „Wir würden die Prompts umschreiben“ |
| 7 | Datenresidenz | Welche Parteien besitzen eine Kopie des Codes? | „Das regelt der Anbieter“ |
| 8 | Wiederherstellung | Was passiert, wenn ein Lauf mittendrin abbricht? | „Irgendwer bemerkt es und räumt auf“ |
Die Reihenfolge ist entscheidend. Punkte 1 bis 3 betreffen die Korrektheit: Ohne sie erzeugt der Durchsatz schneller Fehler, als das Review hinterherkommt. Punkte 4 bis 6 sichern die Nachhaltigkeit: Ohne sie läuft das System zwar, lässt sich aber weder fundiert bewerten noch migrieren. Punkte 7 und 8 sind jene Themen, die ein Sicherheits-Audit bzw. der Bereitschaftsdienst ansprechen werden – meist erst nach dem Rollout.
1. Workspace-Isolation
Wenn zwei Agenten denselben Checkout bearbeiten, überschreiben sie sich gegenseitig – das resultierende Diff gehört zu keinem der beiden Pläne. Die grundlegende Isolationseinheit sollte ein Git-Worktree sein: ein separates Arbeitsverzeichnis mit eigenem Branch und Index, das sich den Objektspeicher mit dem Haupt-Checkout teilt. Das Erstellen ist ein Checkout, kein Klonen, und dauert nur den Bruchteil einer Sekunde, statt die gesamte Historie erneut herunterzuladen.
# Ein Verzeichnis und ein Branch pro Plan.
git worktree add ../work/plan-4812 -b plan/4812
git -C ../work/plan-4812 status --short
git worktree remove ../work/plan-4812
Container bieten eine stärkere Abgrenzung, wenn der Agent nicht vertrauenswürdigen Code ausführt, und Dockers Sicherheitsmodell legt fest, was diese Abgrenzung garantiert. Für vertrauenswürdige Agenten im eigenen Repository sind Worktrees meist der optimale Kompromiss: planbezogene Isolation ohne zeitraubenden Containerstart im kritischen Pfad. Git-Worktrees für parallele KI-Agenten behandelt die Fehlerquellen, einschließlich geteilter Git-Hooks und Submodule, die Teams häufig übersehen.
So testen Sie es: Starten Sie zwei Pläne, die dieselbe Datei berühren, und vergewissern Sie sich, dass beide saubere, voneinander getrennte Diffs erzeugen.
2. Automatisierte Verifikation vor dem menschlichen Review
Ein Reviewer, der ein nicht kompilierendes Diff liest, verschwendet wertvolle Zeit. Tests, Linter, Typüberprüfungen, Builds und ein Scope-Check gegen den Plan sollten im Worktree des Agenten laufen und ihre Ausgaben an die Änderung anhängen. Das ist Continuous Integration, angewandt pro Plan statt nur pro Branch.
Zwei Gates sind spezifisch für Agenten-Code: Ein Scope-Check vergleicht die geänderten Dateien mit den im Plan genannten Dateien – denn ein Agent, der einen Null-Check beheben soll, neigt bisweilen dazu, nebenbei die Datei neu zu formatieren und Variablen umzubenennen. Ein Sicherheits-Scan prüft Kategorien der OWASP Top 10 for LLM Applications: unsichere Ausgabebehandlung, Supply-Chain-Einschleusungen, geleakte Zugangsdaten. Verifikations-Gates für KI-generierten Code erläutert, welche Gates blockieren und welche lediglich informieren sollten.
So testen Sie es: Fragen Sie, welcher Prozentsatz der Agenten-Änderungen den Menschen mit fehlschlagenden Tests erreicht. Wenn das niemand weiß, existiert das Gate nur auf dem Papier.
3. Menschliche Kontrollpunkte an exakt zwei Stellen
Null Kontrollpunkte bedeutet, dass ein Agent direkt auf Main mergt und Fehler von Kollegen entdeckt werden. Zehn Kontrollpunkte bedeuten, jeden einzelnen Tool-Aufruf freizugeben – das macht den Menschen zur langsamsten Komponente und verleitet Reviewer zu rein reflexartigem Durchwinken.
Zwei Kontrollpunkte platzieren das menschliche Urteilsvermögen genau dort, wo es das Ergebnis beeinflusst. Das Plan-Gate ist der Punkt, an dem Korrekturen am günstigsten sind: Es existiert noch kein Code und der Plan ist eine Textseite. Das Diff-Gate ist der Punkt, an dem die Korrektheit anhand der Verifikationsergebnisse bestätigt wird. Was ist eine Software-Fabrik beschreibt diesen Ablauf im Detail.
So testen Sie es: Nennen Sie die beiden Zeitpunkte, an denen ein Mensch entscheidet. Wenn die Antwort eine diffuse Reihe von Aktivitäten statt zweier klarer Punkte ist, haben Sie keine Kontrollpunkte, sondern lediglich manuelle Aufsicht.
4. Kostenzuordnung pro gemergter Änderung
Die monatliche API-Rechnung liefert keine handlungsrelevanten Erkenntnisse. Die entscheidende Kennzahl sind die Kosten pro gemergter Pull Request: Gesamtausgaben im Zeitraum – einschließlich abgelehnter oder abgebrochener Pläne – geteilt durch die Anzahl gemergter Pull Requests. Abgelehnte Arbeit gehört zu den Kosten akzeptierter Arbeit.
Betrachten Sie dies stets zusammen mit der Ablehnungsquote (Denial Rate), dem Anteil geschlossener, ungemergter Pull Requests. Jede Kennzahl für sich lässt sich manipulieren, indem man die andere verschlechtert – weshalb die DORA-Metriken seit jeher als Kennzahlenpaare ausgewiesen werden. Messung des Durchsatzes von KI-Coding-Agenten definiert jede Metrik und erklärt, was schlechte Werte bedeuten.
So testen Sie es: Fragen Sie nach den Kosten pro gemergter PR des Vormonats. Wenn sich diese Zahl nur mühsam per Hand aus einer Monatsabrechnung schätzen lässt, wird sie nicht aktiv gesteuert.
5. Instruktionen als versionierte Dateien
Agentenverhalten, das in Prompts lebt, die jemand in ein Chat-Fenster kopiert hat, lässt sich weder reviewen noch diffen oder zurückrollen. Instruktionen gehören ins Repository – aus demselben Grund wie Konfigurationen in The Twelve-Factor App: Jede Änderung wird zum Diff in einer Pull Request, die ein Senior Engineer ablehnen kann.
// Instruktionen und Speicher sind Dateien, die der Orchestrator liest,
// keine im Binary fest verdrahteten Strings. Eine am Montag gelernte
// Konvention wenden am Dienstag alle Agenten und alle Entwickler an.
interface Promptware {
program: string; // Program.md - Anweisungen für diese Phase
memory: string[]; // Memory/ - Erkenntnisse über diese Codebasis
tools: string[]; // Tools/ - definierte Berechtigungen
logs: string[]; // Logs/ - Append-Only-Ausführungshistorie
}
Das Risiko heißt Prompt-Drift: Ein Agent, der seine eigenen Instruktionen ändern darf, kann sie auch verschlechtern – etwa indem er nach einem unzuverlässigen Testdurchlauf die Regel „Fehlschlagende Tests bis zu dreimal wiederholen“ ergänzt. Versionierung ist die Gegenmaßnahme, da die Änderung als Diff sichtbar wird. Promptware: Agenten, die ihre eigenen Instruktionen verbessern behandelt sowohl dieses Risiko als auch das Aufblähen des Speichers.
So testen Sie es: Führen Sie git log auf dem Verzeichnis aus, das Ihre Agenten-Instruktionen enthält. Ein leeres Ergebnis bedeutet, dass Ihre Prompts unversioniert sind.
6. Portabilität über Modelle und Agenten hinweg
Modelle werden nach dem Zeitplan des Anbieters abgekündigt, nicht nach Ihrem. Ein Orchestrator, der fest auf einen Anbieter setzt, verwandelt jede Deprecation-Notice in ein Migrationsprojekt. Die Schicht, die Ihnen gehören sollte, ist der Workflow: Phasen, Gates, Kontrollpunkte und Speicher. Die darunterliegende Ausführungseinheit sollte pro Plan austauschbar sein, und der Zugriff auf Tools sollte über offene Schnittstellen wie das Model Context Protocol statt über maßgeschneiderte Einzelintegrationen erfolgen.
Portabilität erlaubt auch kostenoptimiertes Routing: Für eine Triage genügt oft ein leichtgewichtiges Modell; ein Architekturplan verlangt ein Spitzenmodell. Diese Abwägung funktioniert nur, wenn der Modellwechsel eine Konfigurationseinstellung und kein Refactoring ist.
So testen Sie es: Wechseln Sie das Modell für einen einzelnen Plan und führen Sie ihn aus. Erfordert das eine Codeänderung, haben Sie eine harte Abhängigkeit statt einer Konfiguration.
7. Geklärte Datenresidenz
Jede Kopie Ihres Repositorys außerhalb Ihrer Kontrolle muss inventarisiert, vertraglich abgesichert und am Ende gelöscht werden. Ein gehosteter Agent klont das Repository in die Umgebung des Anbieters. Damit verarbeiten mindestens zwei externe Stellen Ihren Quellcode: der Agenten-Anbieter und der Modell-Provider. Ein Local-First-Orchestrator hat nur eine Stelle – und das ausschließlich für die Codefragmente, die tatsächlich in Prompts einfließen.
Das ist weniger ein Sicherheits- als ein Geltungsbereichsargument: Es bestimmt, wie viele Auftragsverarbeitungsverträge ein DSGVO-Audit umfassen muss und ob EU-Datenresidenz eine simple Anbietereinstellung oder eine langwierige Vertragsverhandlung ist. Local-First AI Development beantwortet die Fragen, die Sicherheitsteams stellen werden.
So testen Sie es: Listen Sie alle Parteien auf, die während eines einzigen Agenten-Laufs eine Kopie Ihres Codes halten. Wenn die Liste länger ist als gedacht, wird das Sicherheits-Audit zum selben Ergebnis kommen.
8. Ein definierter Wiederherstellungspfad
Unter Last schlagen Durchläufe fehl: Netzwerk-Timeouts mitten im Lauf, ein Agent, der sich im Kreis dreht, ein Verifikationsschritt, der nicht zurückkehrt. Der Orchestrator braucht für jedes Szenario eine Antwort, und die darf nicht lauten: „Irgendjemand bemerkt es schon.“
- Fehlgeschlagene Verifikation: Die Aufgabe geht mit der vollständigen Fehler-Ausgabe – nicht nur einer Zusammenfassung – zurück an den Agenten und wird im selben Worktree bis zum Erreichen eines Retry-Limits wiederholt.
- Abgebrochener Lauf: Worktree und Branch werden bereinigt, damit ein blockierter Plan kein Verzeichnis hinterlässt, über das spätere Läufe stolpern.
- Kostenexplosion oder Endlosschleife: Ein Token- und Zeitbudget pro Plan, das die Ausführung aktiv stoppt, statt erst im Nachhinein zu berichten.
- Partieller Zustand: Da jeder Plan seinen eigenen Worktree und Branch besitzt, wird ein fehlgeschlagener Lauf durch Löschen eines einzigen Ordners verworfen. Im geteilten Repository wurde nichts verändert.
So testen Sie es: Brechen Sie einen Agentenprozess mitten im Plan abrupt ab. Was bleibt auf der Festplatte zurück und wird der nächste Plan dadurch beeinträchtigt?
Wie Ivy Tendril die acht Punkte umsetzt
Ivy Tendril ist eine Local-First-Desktop-Anwendung für macOS, Windows und Linux, die Coding-Agenten vom Plan bis zum geprüften Pull Request ausführt. Worktree-pro-Plan (1), Tests, Linting und Diff-Inspektion bei jeder Änderung mit CI-Import in Pro (2), die zwei menschlichen Kontrollpunkte (3), Kosten pro Plan und pro Job (4), Promptware-Einheiten als versionierte Dateien (5), freie Wahl von CLI-Agent und Modell pro Plan (6), Code und Logs, die Ihren Rechner nie verlassen (7), sowie automatische Wiederholungsversuche mit Fehler-Ausgabe und anschließender Worktree-Bereinigung (8).
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Unter Windows verwenden Sie irm https://cdn.ivy.app/install-tendril.ps1 | iex. Tendril ist kostenlos und quelloffen unter der Functional Source License verfügbar; Team-Funktionen, On-Premises-Hosting, SSO und CI-Verifikationsimporte sind in den Pro- und Enterprise-Plänen enthalten.
Häufig gestellte Fragen
Welchen der acht Punkte sollte ein Team zuerst angehen?
Zuerst Isolation, dann Verifikation, dann Kontrollpunkte. Kosten- und Speicherprobleme sind ärgerlich; zwei Agenten, die in denselben Checkout schreiben, erzeugen jedoch nicht zuordenbare Defekte – das ist schwerwiegender und ungleich schwieriger zu debuggen.
Gilt diese Checkliste nur für Coding-Agenten?
Die konkreten Fehlermodi ja. Isolation, Scope-Checks und Diff-Reviews existieren, weil das Ergebnis eine Änderung an einer gemeinsamen Codebasis ist. Ein Agent, der nur Daten liest oder in eine eigene Datenbank schreibt, erfordert andere Kriterien.
Wie viele Agenten können parallel laufen, bevor diese Punkte wichtig werden?
Genau zwei. Ein einzelner Agent in einem Checkout kommt ohne all das aus. Sobald ein zweiter zeitgleich arbeitet, werden Isolation und Kostenzuordnung unverzichtbar – und die Review-Kapazität wird zum Engpass für den Gesamtdurchsatz, nicht die Ausführungsgeschwindigkeit.
Steigert mehr Parallelität den Durchsatz endlos?
Nein. Reviews sind ein serieller Prozess. Nach Amdahls Gesetz setzt der serielle Anteil die Obergrenze: Werden Agenten über den Sättigungspunkt der Reviewer hinaus skaliert, steigen lediglich Kosten und Ablehnungsquoten, nicht aber die Anzahl gemergter Änderungen.
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.