Der Orchestrator: Warum die Absicht den Prozess überdauern sollte

Aktuelle Agent-Stacks sind invertiert. Die Oberfläche (Terminal, Editor) besitzt das Modell, die Tools und den Verlauf, während die Identität ephemer ist – öffne ein neues Terminal und der Agent verschwindet. Der Autor schlägt eine Orchestrator-Schicht vor, die die Absicht von einem einzelnen Prozess entkoppelt. Wesentliche Eigenschaften:

• Identität oberhalb von Sitzungen: Ein logischer Agent besteht über Prozesse hinweg. Sitzungen kommen und gehen; der Agent bleibt.
• Routing über Oberflächen hinweg: Der Agent verteilt Arbeit an verschiedene Maschinen (z. B. Repo-Box, GPU-Box, Telefon), ohne sie als nicht zusammenhängend zu behandeln.
• Echte Übergabe-Primitive: Ein typisiertes Objekt, das enthält, was erledigt wurde, was unerledigt ist, blockierte Entscheidungen – kein verlustbehafteter Chat-Verlauf.
• Peer-Agenten, keine Sub-Agenten: Zwei Agenten in unterschiedlichen Kontexten koordinieren sich über eine Steuerungsebene, die keiner von beiden besitzt.
• Treiberübergreifende Aufrufe: „Günstiges Modell fasst zusammen, teures Modell handelt“ ist eine primitive, kein Prompt-Engineering. Der Orchestrator wählt die Laufzeit pro Schritt nach Kosten, Latenz und Fähigkeit.
• Freigabeoberflächen, die überleben: Wenn der Agent auf Freigabe pausiert und du drei Zeitzonen entfernt bist, reist die Freigabe zu dir, ohne den Agenten am Leben zu erhalten.

Konkretes Beispiel: Triage eines flaky Tests

Heute öffnest du drei Terminals und kopierst Stacktraces zwischen Claude, Gemini und Grok. Der gewünschte Ablauf des Autors unter einer Orchestrator-Absicht: „Triage diesen Flake, schlage eine Lösung vor, lass sie prüfen.“

• Ollama (lokal): Erfasse das Testprotokoll, entferne Rauschen, erstelle eine strukturierte Fehlerzusammenfassung. Kostenlos, verlässt nie die Maschine.
• Gemini CLI: Nimm die Zusammenfassung plus das Repo, identifiziere die verdächtige Änderung, erstelle einen Patch. Großer Kontext, stark im Lesen von Code, schreibgeschützter Repo-Zugriff.
• Grok Build: Nimm den Patch und den ursprünglichen Fehler, gib ein Urteil ab (ausliefern/überarbeiten/eskalieren). Eine weitere Modellfamilie als Zweitmeinung. Kein Schreibzugriff.

Drei Laufzeiten, drei Berechtigungsumfänge, drei Kostenstufen, eine Absicht. Der Orchestrator trägt das Übergabeobjekt zwischen den Schritten und präsentiert eine einzige Freigabe anstelle von drei getrennten Unterhaltungen. Wenn Grok „eskalieren“ sagt, pausiert die Absicht und wartet auf eine menschliche Entscheidung – ohne Ollama oder Gemini am Leben zu erhalten.

Seit letzter Woche laufen mindestens drei terminalnative Coding-Agenten lokal: Ollama-Laufzeit, Googles Gemini CLI und xAIs Grok Build mit Planmodus und parallelen Sub-Agenten. Das Modell ist der günstige, austauschbare Teil. Der Orchestrator sollte der langweilige, beständige Teil sein.