Claude schreibt jetzt sein eigenes Orchestrierungs-Skript.

Vorab in eigener Sache

Diese Reihe war zwei Monate still. Der Grund war keine Schreibblockade, sondern ein Konstruktionsfehler in meiner eigenen Redaktions-Pipeline: Der wöchentliche Recherche-Agent hat brav jeden Donnerstag einen Entwurf erzeugt — aber es waren leere Gerüste, die noch jemand hätte ausschreiben müssen. Und er hat zehn Wochen lang dasselbe Thema vorgeschlagen, weil ein Dedup-Fehler dafür sorgte, dass nie freigegebene Entwürfe nicht als „schon behandelt" zählten.

Beides ist repariert. Ich erzähle das, weil es exakt die Klasse von Fehler ist, um die es heute geht: Ein Automatismus, der zuverlässig läuft und trotzdem nichts produziert. Zur Wiedergutmachung liegen vier Ausgaben bereit statt einer.

Der Denkfehler: Es geht nicht um Parallelität

Fast jeder Artikel über Dynamic Workflows führt mit derselben Zahl: hunderte Subagenten gleichzeitig. Beeindruckend — aber Parallelität konntest du vorher auch schon haben. Subagenten gibt es seit über einem Jahr.

Der Unterschied steht in der offiziellen Doku, und er lässt sich auf eine Frage eindampfen: Wer hält den Plan?

Bei normalen Subagenten hält Claude den Plan — im Context-Fenster. Jedes Zwischenergebnis, jede Schleife, jede Verzweigung frisst Kontext. Bei langen Aufgaben passiert dann das Bekannte: Claude verliert den Faden, wiederholt sich, vergisst, was in Schritt 3 herauskam.

Bei einem Dynamic Workflow schreibt Claude ein JavaScript-Skript, und eine separate Runtime führt es aus. Schleifen, Zähler, Zwischenergebnisse liegen dann in Skript-Variablen — nicht im Context-Fenster. In Claudes Kontext landet nur das Endergebnis.

Die Abgrenzung, die alle verwechseln

Du kennst aus Band 1 und 2 bereits Subagenten und Skills. Dazu kamen Agent Teams und /goal. Fünf Dinge, die sich ähnlich anfühlen. Diese Tabelle stammt aus der offiziellen Doku und sortiert sie:

So löst du es aus

ultracode: prüfe jeden API-Endpunkt unter src/routes/
auf fehlende Auth-Checks

/effort ultracode          # Claude entscheidet selbst, wann ein Workflow passt
claude --effort ultracode  # oder direkt beim Start

/workflows        # Live-Ansicht aller Runs
/deep-research    # mitgelieferter Workflow für Recherche

Für Pro-Abos wichtig: Dynamic Workflows sind bei Max, Team, Enterprise und API standardmäßig an — im Pro-Plan musst du sie erst in /config einschalten.

Wie ein Skript aussieht

Das hier steht so in der offiziellen Doku. Es ist kürzer, als man erwartet:

export const meta = {
  name: 'audit-routes',
  description: 'Audit every route handler for missing auth checks',
}

const found = await agent('List every .ts file under src/routes/.', {
  schema: { type: 'object', required: ['files'], properties: { files: { type: 'array', items: { type: 'string' } } } },
})

const audits = await pipeline(found.files, file =>
  agent(`Audit ${file} for missing authentication checks.`, { label: file }),
)

return audits.filter(Boolean)

Zwei Funktionen musst du kennen, mehr nicht:

• agent(prompt, {schema}) startet einen Subagenten. Mit schema ist die Antwort erzwungenes JSON — du kannst also direkt damit weiterrechnen.
• pipeline(liste, fn) startet einen Agenten pro Listenelement. Das ist das Fan-out.

Was das Skript nicht kann: selbst auf Dateien oder die Shell zugreifen. Es koordiniert nur — lesen, schreiben und ausführen tun ausschließlich die Agenten. Jeder Run legt sein Skript als Datei unter ~/.claude/projects/<session>/ ab. Du kannst es lesen, ändern und neu starten lassen.

Die zwei Fallen

Wann es sich lohnt — und wann nicht