Sieben Agents, eine echte Legal-Tech-Plattform, fünf Minuten. Aber das ist nicht die Story. Die Story ist, was es bedeutet, dass das jetzt geht.
Am Freitagabend habe ich Claude gebeten, meine KI-Plattform für rechtliche Ersteinschätzungen Erst Recht durchzuleuchten – von vorne bis hinten, die ganze Codebasis. 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 ein priorisierter Bericht mit konkreten Verbesserungen über alle Bereiche vor mir, an dem ein einzelner Entwickler einen halben Tag gesessen hätte. Das Spannendste kam aber erst danach, bei der Gegenprüfung – und genau dort 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 einem eigenen Bereich der Codebasis. Sie lesen nur – und alle gleichzeitig.
Die sieben Roh-Audits werden zu einem einzigen, priorisierten Bericht mit konkreten Verbesserungen verdichtet – die Vorlage für die anschließende Umsetzung.
| Agent | Tokens | Tools | Dauer |
|---|---|---|---|
| agent-1 | 177,5k | 36 | 4m 32s |
| agent-2 | 157,7k | 34 | 5m 11s |
| agent-3 | 111,9k | 40 | 4m 36s |
| agent-4 | 108,4k | 25 | 4m 34s |
| agent-5 | 100,8k | 39 | 4m 01s |
| agent-6 | 86,5k | 34 | 4m 27s |
| agent-7 | 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 dem Bericht – bei der Umsetzung. Eine erste Änderung sah fertig aus, hielt der Gegenprüfung aber nicht stand – erst im zweiten Anlauf war sie wirklich erledigt.
Verifikation schlägt Vertrauen
Ein normaler Audit hätte die erste Änderung als erledigt abgehakt. Weil der Workflow die wichtigsten Änderungen gezielt gegenprüfte – mit dem ausdrücklichen Ziel, sie zu widerlegen –, fiel das auf, und am Ende zählte, was wirklich wirkt, nicht was nur so aussieht.
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, über mehrere Bereiche hinweg – jede wichtige Änderung vor dem Abschluss noch einmal 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 in meinem Lauf eine nur scheinbar fertige Änderung abgefangen 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.