Am Freitagabend habe ich Claude gebeten, meine KI-Rechtsberatungs-Plattform Erst Recht durchzuleuchten – Backend, Datenbank, Bezahlflow, das Anwalts-Upgrade, die ganze Palette. Statt sich selbst Schritt für Schritt durchzuarbeiten, schrieb Claude ein kurzes Skript: sieben spezialisierte Agents, jeder für eine Domäne, alle gleichzeitig.
Fünf Minuten und elf Sekunden später lag eine nach Schweregrad sortierte Findings-Liste vor mir, an der ein einzelner Entwickler einen halben Tag gesessen hätte. Darin: mehrere kritische Funde, darunter eine sicherheitskritische Schwachstelle, die ein einzelner Durchlauf übersehen hätte – und genau an ihr zeigt sich am besten, worum es bei dieser neuen Arbeitsweise geht.
Das ist beeindruckend. Aber es ist nicht der Punkt. Der Punkt ist, was es möglich macht, dass ein Modell jetzt einen ganzen Plan in ausführbaren Code gießen und einen Schwarm von Agents parallel darauf loslassen kann. Genau dafür gibt es seit dem 28. Mai Claude Opus 4.8 und die dynamischen Workflows.
Opus 4.8 in einem Absatz
Anthropic hat Opus 4.8 nur 41 Tage nach 4.7 veröffentlicht – der schnellste Flaggschiff-Zyklus bisher. Für mich zählt davon vor allem eines: Das Modell ist als Agent ehrlicher geworden. Es übersieht Code-Fehler rund viermal seltener, flaggt Unsicherheiten von sich aus und macht weniger unbelegte Behauptungen. Dazu kommen neue „Effort-Controls" (man wählt, wie tief Claude nachdenkt) und ein günstigerer Fast-Mode. Klingt nach Detailpolitur – ist aber genau die Grundlage, auf der man einem Agenten überhaupt ein laufendes Produkt anvertraut.
Die eigentliche Verschiebung: Der Plan zieht ins Skript
Bisher war das Limit für alles, was ein KI-Agent autonom erledigen konnte, immer dasselbe: das Kontextfenster. Der Agent hielt den Plan im Kopf, und jedes Zwischenergebnis – jede gelesene Datei, jeder Tool-Aufruf – landete im selben Fenster. Irgendwann war es voll, und der Agent verlor den Faden. Mehr Helfer dazuzuholen half nicht, denn auch deren Ergebnisse flossen wieder in dieses eine Gedächtnis.
Dynamische Workflows drehen das um. Claude schreibt den Plan nicht mehr in seinen Kopf, sondern als Skript: Welche Agents laufen, in welcher Reihenfolge, was an wen weitergereicht wird. Eine Laufzeit führt dieses Skript im Hintergrund aus, während die Zwischenergebnisse in Skript-Variablen leben – nicht im Kontext des Modells. Claudes Gedächtnis hält am Ende nur noch die fertige Antwort.
Der Plan wandert aus dem Kopf in den Code. Damit fällt die Grenze, die bisher alles begrenzt hat – und ein einzelner Lauf kann Dutzende bis hunderte Agents koordinieren (bis zu 16 gleichzeitig, 1.000 insgesamt).
Das ist mehr als „dasselbe, nur schneller". Weil der Plan jetzt Code ist, kann er wiederholbare Qualitätsmuster erzwingen: Agents, die die Funde anderer Agents gezielt zu widerlegen versuchen, bevor irgendetwas berichtet wird. Genau das wurde in meinem Fall zum entscheidenden Schritt.
Mein 5-Minuten-Beweis
Der Workflow für Erst Recht hatte zwei Phasen:
Sieben Read-only-Agents, jeder mit einer Domäne: Backend-API, Datenbank, Anwalts-Upgrade, Payment, Frontend-Verdrahtung, Build/Tests/Dependencies, E-Mail. Sie lesen nur – und alle gleichzeitig.
Die sieben Roh-Audits werden zu einer einzigen, nach Schweregrad priorisierten Findings-Liste verdichtet – die Vorlage für die anschließenden Fixes.
| Agent | Tokens | Tools | Dauer |
|---|---|---|---|
| backend-api | 177,5k | 36 | 4m 32s |
| lawyer-upgrade | 157,7k | 34 | 5m 11s |
| database | 111,9k | 40 | 4m 36s |
| payment-stripe | 108,4k | 25 | 4m 34s |
| frontend-wiring | 100,8k | 39 | 4m 01s |
| build-tests-deps | 86,5k | 34 | 4m 27s |
| email-notifications | 71,7k | 25 | 3m 27s |
Hier sieht man die Magie der parallelen Orchestrierung schwarz auf weiß: Addiert man die Agents auf, sind das rund eine halbe Stunde Arbeit. Weil sie aber gleichzeitig liefen, war die ganze Phase nach 5m 11s durch – exakt der langsamste Agent, sonst nichts. Das ist der Unterschied zwischen „ein Agent arbeitet eine lange Liste ab" und „ein Schwarm erledigt sie in der Zeit seines langsamsten Mitglieds".
Wo das Modell sich selbst misstraut hat
Der spannendste Moment kam nach den Funden – und er gehört genau zu jener sicherheitskritischen Schwachstelle. Der erste Fix dafür sah sauber aus. Doch bei der Live-Gegenprüfung gegen das echte System stellte sich heraus: Der Fix lief ins Leere. Die Ursache lag eine Ebene tiefer, als der erste Blick vermuten ließ – nach dem „Fix" bestand das Problem unverändert weiter.
Verifikation schlägt Vertrauen
Ein normaler Audit hätte den ersten Fix als erledigt abgehakt. Weil der Workflow jeden kritischen Fund gegen das laufende System prüfte – mit dem ausdrücklichen Ziel, ihn zu widerlegen –, fiel der Fehlschlag auf, und das Problem wurde wirklich behoben, nicht nur scheinbar.
Das ist der Punkt, an dem die Ehrlichkeit von Opus 4.8 und die Struktur der Workflows ineinandergreifen: ein Modell, das eher zugibt „das sieht erledigt aus, ist es aber nicht", in einem Ablauf, der dieser Skepsis einen eigenen Prüfschritt gibt. Am Ende standen sechs Commits auf main, quer durch Sicherheit, Bezahlflow, das Anwalts-Upgrade und veraltete Abhängigkeiten – jeder kritische Fix vor dem Schließen noch einmal live gegengeprüft.
Was das wirklich aufschließt
Vergiss für einen Moment meinen Audit. Wenn „ein Plan plus tausend Agents" zum Normalfall wird, verschiebt sich, welche Arbeit überhaupt denkbar ist:
- Aufgaben, die heute niemand anfasst, werden machbar. Eine Migration über hunderttausende Zeilen, ein Audit jeder einzelnen API-Route, ein Aufräumen quer durch ein altes Repo – Dinge, die man bisher verschob, weil sie zu groß für eine Sitzung waren.
- Recherche, die sich selbst gegenprüft. Statt einer Antwort, die plausibel klingt, fächern Agents eine Frage aus mehreren Richtungen auf, holen Quellen, und stimmen darüber ab, welche Behauptung die Gegenprüfung überlebt. Was durchfällt, fliegt raus, bevor du es siehst.
- Entscheidungen aus mehreren Köpfen. Eine schwierige Architektur-Frage lässt sich aus drei unabhängigen Blickwinkeln entwerfen und gegeneinander abwägen, bevor man sich festlegt – statt einen einzigen ersten Entwurf endlos zu drehen.
- Verifikation als Voreinstellung. Der eingebaute Reflex, einen Fund erst zu widerlegen statt ihm zu glauben, ist genau das, was meinen No-Op-Fix gerettet hat. Das wird zum Standard, nicht zur Ausnahme.
- Prozesse statt Prompts. Ein guter Workflow lässt sich speichern und immer wieder ausführen. Aus dem einmaligen „mach mal" wird ein wiederholbarer Ablauf – das Branch-Review, der Release-Check, der Wochen-Audit, jedes Mal identisch orchestriert.
- Eine neue Rolle für den Entwickler. Man tippt weniger Prompts und dirigiert mehr Schwärme. Gerade für kleine Teams und Solo-Entwickler heißt das: Reichweite, die früher eine ganze Abteilung gebraucht hätte.
Die ehrliche Kehrseite
Dynamische Workflows sind eine Research-Preview – kein fertiges Produkt. Ein Schwarm kostet spürbar mehr Tokens als dieselbe Aufgabe im Gespräch, und mehr Agents sind nicht automatisch besser: Für eine kleine, gut umrissene Frage ist ein einzelner Agent schneller und billiger. Der Hebel zündet erst, wenn eine Aufgabe in viele unabhängige Teile zerfällt, mehr Material umfasst, als ein Kontextfenster trägt, und ein Ergebnis liefert, das eine Gegenprüfung verträgt. Genau dann – und nur dann – greife ich danach.
Verwendete Tools:
Erst Recht ist meine eigene Legal-Tech-Plattform – und gleichzeitig mein Testfeld für genau solche Workflows. Du überlegst, wie KI-gestützte Multi-Agent-Abläufe deinem Team echte Arbeit abnehmen können? Schreib mir.