Sub-Agents sind einfach falsch

Polylanes Autofix-Agent war ursprünglich als Workflow aus mehreren Sub-Agents aufgebaut, jeder zuständig für eine einzelne Aufgabe:

• eine Triage, um Tausende von Alerts und Signalen zu sichten
• ein Coordinator, der die Sub-Agents steuert
• bis zu fünfzehn Sub-Agents, um alle möglichen Hypothesen zum Problem zu untersuchen
• und ein Coding-Agent, der schließlich einen Pull Request einreicht

Ein bestätigtes Issue konnte bis zu 18 Agents und Sub-Agents für die Untersuchung und den Fix nach sich ziehen. Heute erledigt dieselbe Arbeit ein einziger Agent.

Der Workflow war ein sinnvolles Design auf Basis dessen, was wir zu der Zeit wussten: kleine Prompts, kleine Tool-Sets, ein Orchestrator, der Ergebnisse zwischen Spezialisten trägt. Er war jedoch extrem teuer und schwer zu betreiben und nachzuvollziehen.

Was ist ein Issue?

Polylane scannt Logs, Metriken und Traces von jeder Cloud-Ressource (Lambda-Funktion, Cloudflare Worker, Vercel-Projekt usw.) bei jedem verbundenen Provider. Für jede Ressource speichern wir Baselines über mehrere Zeithorizonte, sodass wir Saisonalität in den Daten erfassen können. Anschließend bewerten wir den aktuellen Zustand der Cloud-Ressource und vergleichen ihn mit historischen Daten. Werte, die die Baseline durchbrechen, werden als Issues erfasst.

Issues können auch durch Alerts entstehen, die wir von Observability- und Error-Tracking-Lösungen erhalten.

Wie lösen wir Issues?

Um ein Issue zu lösen, müssen wir:

1. Triage: Daten sammeln, um das Issue zu bestätigen oder zu verwerfen.
2. Untersuchen: Mehrere Hypothesen bewerten und den Root Cause bestimmen.
3. Einen Pull Request öffnen oder eskalieren. Entweder einen Pull Request schreiben, der das Issue löst, an einen Engineer eskalieren, wenn der Fix keine Codeänderung ist, oder einen Bericht mit den Erkenntnissen schreiben und stoppen.

Die überwiegende Mehrheit der Runs endet vor einem Pull Request oder einer Eskalation, wenn Polylane zu dem Schluss kommt, dass das Issue entweder ein False Positive oder harmlos ist.

Sub-Agents-Architektur

Unsere ursprüngliche Architektur basierte auf mehreren Sub-Agents.

Wir nutzten einen Orchestrator-Agent, um die Arbeit zwischen mehreren Sub-Agents zu koordinieren. Sub-Agents wurden instanziiert, um Hypothesen zu untersuchen und sie mit unterschiedlichen Ausgangspunkten zu beweisen oder zu widerlegen (zum Beispiel beginnend mit den Logs oder beginnend mit der Codebase usw.).

Die Erkenntnisse der Sub-Agents wurden mit einfacher Arithmetik abgestimmt und von einem weiteren Agent zusammengefasst, bevor sie an den Coordinator-Agent weitergereicht wurden.

Das Urteil jeder Hypothese war eine konfidenzgewichtete Abstimmung über ihre Durchläufe.

const CONFIDENCE_RANK = { definitive: 4, strong: 3, moderate: 2, weak: 1, speculative: 0 };

function aggregatePassVerdicts(passes: PassResult[]): Verdict {
  const weights: Record<string, number> = {};
  const counts: Record<string, number> = {};
  for (const p of passes) {
    weights[p.verdict] = (weights[p.verdict] ?? 0) + CONFIDENCE_RANK[p.confidence];
    counts[p.verdict] = (counts[p.verdict] ?? 0) + 1;
  }
  const totalWeight = Object.values(weights).reduce((a, b) => a + b, 0);
  const [winner, winnerWeight] = Object.entries(weights).sort((a, b) => b[1] - a[1])[0];

  const countMajority = counts[winner] > passes.length / 2;
  const weightMajority = winnerWeight > totalWeight / 2;
  if (!countMajority && !weightMajority) {
    return { verdict: "inconclusive", confidence: "weak", summary: `No consensus across ${passes.length} passes.` };
  }

  const majority = passes.filter((p) => p.verdict === winner);
  const confidence = majority.reduce((min, p) => (CONFIDENCE_RANK[p.confidence] < CONFIDENCE_RANK[min] ? p.confidence : min), majority[0].confidence);
  const lead = majority.reduce((best, p) => (CONFIDENCE_RANK[p.confidence] > CONFIDENCE_RANK[best.confidence] ? p : best));
  return { verdict: winner, confidence, summary: lead.summary };
}

Sobald alle Hypothesen untersucht waren, hat der Coordinator, falls ein Root Cause identifiziert wurde, entweder an einen Engineer eskaliert oder einen Plan für den Fix geschrieben. Dieser Plan wurde an einen Coding-Sub-Agent übergeben, um den Fix umzusetzen und den Pull Request einzureichen.

Das Hauptproblem dieser Architektur ist der Kontextverlust zwischen den Sub-Agents. Jeder Agent gab nur Bruchteile seines Kontexts nach oben oder unten weiter, durch Zusammenfassung, und sowohl vor- als auch nachgelagerte Agents mussten regelmäßig dieselbe Arbeit wiederholen.

Zudem hatte der Agent, der den Fix schrieb, nur den Plan zur Verfügung, ohne Kontext zum ursprünglichen Issue oder den in der Untersuchung gesammelten Beweisen. Das führte zu mittelmäßigen Pull Requests, die sich häufig auf Symptome statt auf den Root Cause konzentrierten.

Wir haben uns für diese Architektur vor allem deshalb entschieden, weil die führenden Modelle, als wir sie im März 2026 entworfen haben, nicht immer in der Lage waren, eine Untersuchung von Anfang bis Ende durchzuführen, einschließlich des Schreibens des Fixes, und ganz einfach gesagt, unser Harness war auch noch nicht so gut.

Es wurde zunehmend schwerer, auf dieser Grundlage weiterzubauen, weil:

• Debugging viele Traces erforderte. Um eine End-to-End-Untersuchung nachzuvollziehen, mussten mehrere, teils Dutzende von Traces durchgesehen werden.
• Evaluation pro Stufe erfolgte. Jeder Sub-Agent konnte einzeln evaluiert werden und bestehen, während das Endergebnis schlecht war, weil die Fehler in den Übergaben lagen.

Wir haben diese Architektur monatelang iteriert, jeden Agent einzeln verbessert und an Prompts und Übergaben gefeilt, aber die Ergebnisse haben den Aufwand nie gerechtfertigt. Es war teuer, schwer zu debuggen, und die Pull Requests waren nicht gut genug.

Ein einzelner Agent

Am 3. September haben wir den Sub-Agents-Workflow durch einen einzigen Agent ersetzt, der alles von der Triage bis zum Pull Request übernimmt. Derselbe Agent sammelt die Beweise, untersucht alle Hypothesen und reicht den Pull Request ein.

Wir haben den Triage-Agent, den Coordinator, die Hypothesen-Agents und den Autofix-Agent gelöscht, zusammen mit den Workflows, die Ergebnisse zwischen ihnen transportierten, und den Gates, die vor dem Pull Request standen. Die betrieblichen Vorteile zeigten sich sofort: ein Trace zum Auswerten, keine Zusammenfassungen zwischen Sub-Agents mehr.

Wichtiger noch: Die Qualität der Pull Requests hat sich verbessert, und die Zeit zwischen der Erkennung eines Issues und der Eröffnung des Pull Requests, der es behebt, ist deutlich gesunken. Im Monat rund um den Wechsel sank der Median von 2,2 Stunden auf 35 Minuten und das p90 von neun Tagen auf unter zwei Stunden. Unter der Pipeline blieb ein Finding typischerweise mehrere Stunden lang in einer Kette von Workflows liegen, jeder wartend auf den vorherigen. Beim einzelnen Agent öffnet sich der Pull Request nur Minuten nach der Erkennung des Issues.

Wir eröffnen jetzt auch deutlich mehr Pull Requests. Als wir Sub-Agents einsetzten, endeten 0,6 % der erkannten Issues in einem Pull Request. Beim einzelnen Agent sind es 4,2 %, Tendenz steigend. Der Unterschied liegt in den Fehlermodi. Eine Pipeline mit mehreren Sub-Agents muss jede Übergabe überstehen: Die Triage muss das Finding weiterreichen, der Coordinator muss Hypothesen erzeugen, der Fan-out muss zu einem Urteil kommen usw. Jede Übergabe ist ein potenzieller Fehlermodus.

Auch die Kosten pro Pull Request sind gesunken. Jeder Run startet jetzt mit dem stärkeren Modell, sodass ein verworfenes Finding mehr kostet als unter der Pipeline. Aber die durchschnittlichen Kosten pro Pull Request sind in den ersten neun Tagen des einzelnen Agents von $111 auf etwa $18 gefallen. Dieser Rückgang ist nicht ausschließlich das Ergebnis der Architekturänderung, da wir aktiv an jedem Aspekt von Polylane iterieren. Ein Teil davon ist die gewöhnliche Drift eines Systems unter ständiger Iteration.

Baue keine Sub-Agents

• Übergaben verlieren mehr, als sie sparen. Jede Zusammenfassung, die zwischen Agents weitergegeben wird, ist Kontext, den der nächste Agent nie haben wird. Der Agent, der die Beweise sammelt, sollte der Agent sein, der danach handelt.
• Bewerte den Run, nicht die Agents. Evaluationen pro Agent bestehen, während das System versagt, weil die Fehler zwischen den Agents liegen.
• Behalte einen Trace pro Run. Eine falsche Entscheidung, verteilt über ein Dutzend Traces, braucht einen Nachmittag, um erklärt zu werden. In einem Trace reicht ein Scrollen.