Funktionserklärungen 01: Orchestration Engine

Vom ersten Auftrag zum geprüften Patch

Agent Argo besteht nicht aus einem einzelnen Modell, das möglichst lange an einer Aufgabe arbeitet. Es ist ein System, das Softwarearbeit in nachvollziehbare Schritte übersetzt: planen, aufteilen, bearbeiten, prüfen, korrigieren und erst dann zur Übernahme vorlegen.

Mit diesem Beitrag beginnt die Reihe „Funktionserklärungen“. Sie macht die zentralen Mechanismen von Agent Argo verständlich – nicht als Marketingversprechen, sondern entlang ihres tatsächlichen Einsatzes. Den Auftakt bildet die Orchestration Engine: der Ablauf, der aus einer Anforderung einen kontrollierten Arbeitsprozess macht.

1. Vor dem Start: Qualität, Kosten und Autonomie festlegen

Bevor Argo eine Aufgabe bearbeitet, sind zwei Entscheidungen wichtig. Sie sind absichtlich voneinander getrennt:

1. Wie soll Argo zwischen Kosten und Ergebnisqualität abwägen?
2. Wie selbstständig darf Argo im Projekt handeln?

Das verhindert einen typischen Zielkonflikt: Ein gründlicher Lauf muss nicht automatisch mehr Schreibrechte erhalten. Und ein autonomer Lauf muss nicht automatisch teure Modelle wählen.

Die drei Stufen für Kosten und Qualität

Der Modell-Router kennt drei verständliche Modi. Sie verändern, wie stark Preis und Modellstufe in die Auswahl einfließen; der benötigte Skill bleibt immer zentral.

Stufe	Router-Modus	Geeignet für
Sparsam	economy	Routineaufgaben, Extraktion, klar abgegrenzte Änderungen. Kosten wiegen stark.
Ausgewogen	balanced	Der Standard für die meisten Läufe: Skill-Fit, Kosten und Qualitätsstufe bleiben im Gleichgewicht.
Anspruchsvoll	expert	Architektur, Recherche, komplexe Analysen und anspruchsvolle Reviews. Modellstufe wiegt deutlich stärker, Kosten weniger.

Die Betriebsprofile Schnell & günstig, Ausgewogen und Gründlich bündeln diesen Router-Modus mit weiteren Entscheidungen: etwa, ob gemeinsames Denken nur beobachtet oder aktiv ausgeführt wird, ob Verifikation verbindlich ist und ob Argo bei einem Fehlversuch stärker eskalieren darf.

Die drei Stufen der Autonomie

Die Autonomie regelt nicht, was Argo für richtig hält, sondern wann es dafür einen Menschen braucht.

Stufe	Verhalten
Sicher	Argo analysiert und plant. Änderungen bleiben zur Prüfung; vor schreibenden oder risikoreichen Aktionen wird gefragt.
Ausgewogen	Normale Änderungen können in einem isolierten Arbeitsstand entstehen. Bei Löschen, Befehlen, Downloads, Netzwerkzugriff oder geschützten Pfaden fragt Argo weiter nach.
Voll autonom	Der Lauf arbeitet ohne gewöhnliche Rückfragen durch. Harte Sicherheits-, Policy- und Budgetgrenzen gelten weiterhin.

Im Code sind diese Regeln genauer als readonly, confirm_write, auto_write und bypass umgesetzt. Die drei Stufen machen sie bedienbar; die Projekt-Policy bleibt aber immer die letzte Instanz. Sie kann etwa Cloud-Provider ausschließen, nur lokale Modelle erlauben, Netzwerkzugriffe sperren, Commands begrenzen, Secrets schützen oder ein Kostenlimit setzen.

2. Die CEO-Ebene macht aus dem Auftrag einen Plan

Der Nutzer beschreibt zunächst das Ziel in normaler Sprache. Die CEO-Ebene von Argo erhält dazu einen begrenzten Projektüberblick, den verfügbaren Modellkatalog und relevante Projektinformationen. Sie kann bei offenen Fragen zuerst nachfragen oder einen Plan erzeugen.

Ein Plan enthält nicht nur eine To-do-Liste. Jede Aufgabe bekommt eine Rolle, eine Beschreibung, Abhängigkeiten und benötigte Fähigkeiten – zum Beispiel coding, planning, qa_review oder context_comprehension. Für schwierige Aufgaben kann auch eine höhere Schwierigkeit vermerkt werden. Die CEO-Ebene nennt dabei nicht starr ein Modell: Sie beschreibt die Arbeit, der Router entscheidet später pro Aufgabe über das passende Modell.

Der Plan bleibt damit die menschlich lesbare Vereinbarung über das Vorhaben, während die Ausführung adaptiv bleiben darf.

3. Aus dem Plan wird ein Task-Graph

Nach der Planfreigabe verwandelt Argo die Aufgaben in einen Task-Graphen. Ein Knoten darf erst laufen, wenn seine Abhängigkeiten erfolgreich abgeschlossen sind. Unabhängige Aufgaben können parallel laufen.

Der Scheduler sortiert bereite Knoten nach einer nachvollziehbaren Nutzenheuristik: erwartete Qualität minus Kosten-, Zeit- und Risikostrafe. Befindet sich ein Knoten auf dem kritischen Pfad, erhält er bei Gleichstand Vorrang, weil er die Gesamtdauer des Laufs bestimmt.

Bei hoher Unsicherheit oder hohem Risiko kann Argo vor der Bearbeitung einen gemeinsamen Denkmodus auswählen: mehrere Perspektiven entwickeln Ansätze, kritisieren sich gegenseitig und liefern einen begründeten Arbeitsansatz für den Worker. Ob das nur protokolliert oder wirklich ausgeführt wird, entscheidet das vor dem Lauf gewählte Betriebsprofil.

4. Vor jedem Task: passender Kontext, passende Fähigkeiten, passendes Modell

Bevor ein Worker startet, baut Argo einen auf Rolle und Aufgabe zugeschnittenen Kontext. Dazu gehören relevante Dateien, Abhängigkeitsergebnisse und – sofern aktiviert – ein kompaktes Memory-Paket sowie geeignete Skill-Anleitungen. Argo übernimmt dabei nicht blind das gesamte Projektwissen in den Prompt. Memory und Skills werden nach Relevanz, Herkunft, Aktualität, Kosten und Sicherheitsstatus ausgewählt.

Dann wählt der Modell-Router ein Modell. Zuerst werden Kandidaten ausgeschlossen, die nicht erreichbar sind, kein ausreichendes Kontextfenster haben, deren Kontingent aufgebraucht ist oder die gegen die aktive Policy verstoßen. Von den verbleibenden Modellen bewertet Argo vier Faktoren:

• Fähigkeits-Fit: Wie gut ist ein Modell für die benötigten Skills bewertet? Bei mehreren Skills wird der Mittelwert betrachtet.
• Kosten: Wie teuer ist die Anfrage – oder bei aktivem Kosten-Routing das voraussichtlich erfolgreiche Ergebnis?
• Modellstufe: Schwierige, sicherheitskritische, Architektur- und Review-Aufgaben dürfen eine Flagship-Stufe bevorzugen.
• Erfahrungswerte: Nach ausreichend vielen echten Ergebnissen fließen die jüngste Erfolgs- und Wiederholungsrate einer Modell-/Skill-Kombination ein.

Für die Kostenrechnung kann Argo die Expected Cost of Success nutzen: direkter Preis, erwartete Wiederholungen, Verifikationsaufwand, mögliche Nacharbeit und eine kleine Latenzstrafe. Ein billiger einzelner Aufruf ist also nicht automatisch die günstigste Lösung, wenn er häufiger scheitert oder Nacharbeit auslöst.

Eine explizite Modellempfehlung wird nur akzeptiert, wenn sie verfügbar, durch die Policy erlaubt und groß genug für den Kontext ist. Planung, Delegation und Kontextverständnis der CEO-Ebene verwenden wiederum ein starkes Modell, das speziell für diese drei Fähigkeiten ausgewählt wird.

5. Der Worker bearbeitet den Task in kleinen, überprüfbaren Schritten

Ein Worker arbeitet nicht mit einer einzigen Antwort. Er durchläuft eine begrenzte ReAct-Schleife:

1. Das Modell schlägt strukturierte Aktionen vor – etwa Dateien lesen, durchsuchen, Tests ausführen oder Änderungen schreiben.
2. Der Executor prüft Berechtigung, Pfad, Command-Risiko und aktive Policy.
3. Argo führt nur erlaubte Aktionen aus.
4. Ergebnisse, Diffs und Fehlermeldungen fließen als Beobachtung zurück an das Modell.
5. Auf dieser Grundlage korrigiert der Worker seinen nächsten Schritt oder schließt die Aufgabe ab.

Damit kann ein Agent beispielsweise erst den betroffenen Code lesen, dann eine Änderung vornehmen, einen Test ausführen und ein Testergebnis in die nächste Entscheidung einbeziehen. Der vollständige Ablauf bleibt im Laufprotokoll sichtbar.

Auch die Ausgabe selbst wird geprüft. Falls ein Modell ungültiges Aktions-JSON liefert, kann Argo eine begrenzte Reparaturschleife anfordern. Im strengen Modus wird eine dauerhaft fehlerhafte Ausgabe kontrolliert abgelehnt, statt unklaren Text als Aktion zu interpretieren.

6. Bei Fehlern: gezielt korrigieren statt blind wiederholen

Nicht jeder fehlgeschlagene Task bedeutet, dass der gesamte Lauf gescheitert ist. Die Orchestration Engine unterscheidet Fehlerursachen und reagiert kontrolliert:

• Ein temporärer Fehler kann innerhalb fester Grenzen erneut versucht werden.
• Ein harter Verifikationsbefund liefert seine konkrete Beanstandung als Auftrag für den nächsten Versuch.
• Bei aktivierter Kaskadierung übernimmt der nächste Versuch die Erkenntnisse des vorherigen, statt bei null zu beginnen.
• Nach einem Fehlversuch darf Argo ein stärkeres Modell bevorzugen.
• Ist ein Budget erschöpft, wird kein teurer Blindversuch gestartet: Der Knoten endet mit einem dokumentierten Teilergebnis oder wird sichtbar eskaliert.

Die Knotenstrategie entscheidet schließlich, ob eine Aufgabe übersprungen werden kann, kontrolliert fehlschlägt oder eine Nutzerentscheidung benötigt. Abhängige Aufgaben erhalten ausschließlich bestätigte Teilergebnisse. Dadurch wird aus einem lokalen Fehler kein stiller Fehler, der sich durch den restlichen Plan fortsetzt.

7. Nach der Umsetzung: Review, Verifikation und ein möglicher weiterer Zyklus

Sind die geplanten Tasks bearbeitet, prüft Argo den integrierten Stand aus mehreren Blickwinkeln:

• Der QA-Agent darf Dateien lesen und Test-Kommandos ausführen.
• Der Architektur-Agent prüft die Struktur lesend und bleibt bewusst ohne Schreibrechte.
• Deterministische Verifier können Tests, Typprüfung oder Linting als objektive Orakel ausführen.
• Modellbasierte und deterministische Befunde werden zu einem Gesamturteil zusammengeführt.

Falls QA, Architektur oder ein verbindlicher Verifier Probleme finden, ordnet Argo die Befunde den betroffenen Aufgaben zu. Nur diese Aufgaben werden mit dem konkreten Feedback erneut bearbeitet. Danach folgt wieder Review und Verifikation. Ohne Konsensmodus ist diese Schleife begrenzt; in einem ausdrücklich gewählten Konsensmodus läuft sie weiter, bis der Nutzer stoppt oder die Prüfer zustimmen.

Ein Verifier im Beobachtungsmodus dokumentiert Befunde, blockiert aber nicht. Im verbindlichen Modus kann ein harter Befund verhindern, dass das Ergebnis als erfolgreich gilt. So lässt sich die Strenge pro Betriebsprofil wählen, ohne die Nachvollziehbarkeit aufzugeben.

8. Erst wenn der Stand geprüft ist: Dokumentation und CEO-Zusammenfassung

Nach einem abgeschlossenen Arbeits- und Prüfzyklus kann ein Dokumentationsagent die Änderungen festhalten. Anschließend erstellt die CEO-Ebene die Zusammenfassung für den Nutzer: Was wurde erledigt? Was blieb offen? Welche Prüfungen liefen? Welche Dateien oder Entscheidungen sind betroffen?

Das Ergebnis ist mehr als ein Chat-Text. Der Lauf führt eine gemeinsame Kennung für Plan, Modellwahl, Kosten, Aktionen, Verifikationsurteile, Nutzerunterbrechungen und spätere Patch-Entscheidungen. Dadurch lässt sich nachvollziehen, wie Argo zu einem Ergebnis gelangt ist.

9. Zum Schluss entscheidet der Mensch über den echten Workspace

Standardmäßig arbeitet Argo in einem isolierten Worktree. Die Änderungen liegen dort als Patch, nicht still im echten Projekt. Je nach Autonomiestufe passiert anschließend eines von drei Dingen:

• Der Patch bleibt zur Annahme, teilweisen Übernahme, Bearbeitung oder Verwerfung bereit.
• Ein erfolgreicher Patch wird automatisch übernommen.
• Bei Konflikten mit zwischenzeitlich geänderten Dateien stoppt Argo sichtbar; es überschreibt keine fremden Änderungen.

Ein fehlgeschlagener Lauf wird nicht automatisch angewandt. Auch eine sehr autonome Konfiguration hebt die Policy nicht auf: Secret-Schutz, Befehlsregeln, Providergrenzen, Budgetlimits und notwendige Human Gates bleiben wirksam.

Was die Orchestration Engine leistet

Die Orchestration Engine entscheidet nicht nur, welches Modell als Nächstes antwortet. Sie verbindet Nutzerabsicht, Einstellungen, Planung, Parallelisierung, Modellwahl, Werkzeugnutzung, Fehlerkorrektur, Qualitätssicherung und sichere Übernahme zu einem zusammenhängenden Ablauf.

Der Maßstab ist nicht „möglichst viele Agenten“. Zusätzliche Arbeit entsteht nur dort, wo sie begründet ist: ein stärkeres Modell für eine schwierige Architekturentscheidung, ein zweiter Denkansatz bei Unsicherheit, ein gezielter Retry nach einer Verifier-Beanstandung oder eine menschliche Freigabe vor einer riskanten Wirkung.

Der Kurs ist damit gesetzt.