KI-Agenten auf Cloudflare: Was Anthropic SDK 0.100–0.102 ersetzt

KI-Agenten im Anthropic SDK: Was 0.100 bis 0.102 wirklich liefern

Drei Releases in acht Tagen – und die Oberfläche des Python SDK hat sich stärker verändert als in den sechs Monaten davor. Der Zeitraum ist relevant: Wer in der Produktion auf anthropic==0.99.x festgelegt war, hat die komplette Managed-Agents-Laufzeitumgebung innerhalb eines einzigen Sprints verpasst.

v0.100.0 (6. Mai 2026) brachte Unterstützung für Multi-Agenten, Outcomes, Webhooks und Vault-Validierung in den beta-Namensraum. Entscheidend ist diese Form: client.beta.managed_agents.sessions.create(thread=..., outcome=..., metadata=...) liefert eine session_id zurück und läuft asynchron auf der Infrastruktur von Anthropic. Die Orchestrierungsschleife liegt damit nicht mehr im eigenen Verantwortungsbereich.

v0.101.0 (11. Mai 2026) ergänzte den AWS-Client für Claude Platform on AWS und stellte sämtliche Cookbook-Beispiele auf claude-sonnet-4-5-20250929 um. Für Bedrock ist das die maßgebliche Version: Die Unterstützung der Umgebungsvariable ANTHROPIC_BEDROCK_SERVICE_TIER (default/flex/priority) kam erst hier hinzu, nicht schon mit 0.100.

v0.102.0 (13. Mai 2026) ergänzte BetaManagedAgentsSearchResultBlock-Typen, Cache-Diagnosen für die Prompt-Cache-Beta und eine sofortige Pydantic-Validierung von Iteratoren. Die Blocktypen sind weiterhin in Bewegung. Genau deshalb migriere ich meinen Multi-Agenten-Code noch nicht.

Das wichtigste Feature sind Outcomes. Eine Rubrik definiert die Anforderungen, ein separater Evaluator-Agent bewertet das Ergebnis danach, und der Agent wiederholt seine Arbeit, bis sie besteht. Anthropic beziffert den Zugewinn in der internen Evaluation gegenüber üblichen Prompting-Schleifen auf bis zu +10 Punkte beim Aufgabenerfolg, auf +8.4% bei der DOCX-Erstellung und auf +10.1% bei PPTX. Das deckt sich mit meiner Erfahrung aus dem eigenen Critic Durable Object: Ein einziges erneutes Prompting mit den Hinweisen des Judges bringt ungefähr so viel wie der Wechsel in die nächsthöhere Modell-Qualitätsstufe.

Die zweite Hälfte sind Webhooks. Acht Session-Ereignisse werden an eine in der Claude Console hinterlegte URL gesendet: session.status_run_started, session.status_idled, session.status_rescheduled, session.status_terminated, session.thread_created, session.thread_idled, session.thread_terminated und – am wichtigsten – session.outcome_evaluation_ended. Das Signaturgeheimnis beginnt mit whsec_… und wird beim Anlegen genau einmal angezeigt. Geprüft wird es mit client.webhooks.unwrap(payload, signature, secret).

Auch die Multi-Agenten-Orchestrierung ist erschienen, allerdings nur nach einem gesonderten Antrag auf Zugang zur Research Preview. Warum ich diesen Schalter noch nicht umlege, folgt weiter unten.

Was Managed Agents für nicht technische Gründer bedeutet

Anthropic betreibt den Agenten nun als Dienst. Sie formulieren die Rubrik („Hat der Artikel 2,000 Wörter, nennt er drei Primärquellen und besteht er den De-AI-Regex?“). Ein Evaluator-Agent von Anthropic bewertet die Ausgabe und lässt den Agenten so lange erneut laufen, bis das Ergebnis besteht. Die Retry-Schleife muss nicht länger vom eigenen Engineering-Team entwickelt werden.

Bei den Kosten wirken zwei Effekte. Erstens verschwinden individuell gebaute Retry-Schleifen aus der Codebasis – und damit Wartungsarbeit für erfahrene Entwickler. Zweitens entstehen innerhalb einer Anthropic-Session zusätzliche Versuche, die jeweils neben den Tokens mit $0.08 pro Session-Stunde abgerechnet werden. Ob sich das insgesamt lohnt, hängt vollständig von der Laufzeit der Sessions ab.

Realistisch betrachtet ersetzt Managed Agents bei einem v1-Agentenprodukt etwa 40% des Orchestrierungscodes, den ein Senior Engineer sonst selbst schreiben müsste. Bei einem bereits ausgelieferten Produkt ist der Anteil kleiner. Die Webhook-Seite beseitigt jedoch die Polling-Schleife, die dort mit hoher Wahrscheinlichkeit noch irgendwo läuft.

Die Frage an den CTO für diese Woche lautet: „Fragen wir den Abschluss weiterhin per Polling ab, oder sind wir bereits auf session.outcome_evaluation_ended umgestiegen?“ Lautet die Antwort „Polling“, reicht ein halber Tag für ein Refactoring, das Infrastrukturkosten und Request-Latenz zugleich senkt.

Mein aktueller Cloudflare-Stack

Damit klar wird, welcher Code entfallen kann, zunächst die Architektur: Ein einzelner Hono Worker auf Cloudflare Workers (ES2021-Target, Static-Assets-Binding) sitzt vor sechs Durable Objects – je eines pro Publisher-Routine. Editorial, Discovery, Writer, Distribution, Maintenance und Manager; hinzu kommt als siebtes Objekt ManualIntake für die Admin-Oberfläche.

Jede Routine startet über einen von sechs Cloudflare Workflows: PublishWorkflow, WriteArticle, PublishArticle, EnrichIdea, DiscoverIdeas und DistributeArticle. Die meiste Arbeit erledigt PublishWorkflow mit acht idempotenten Schritten: validieren, fundieren, generieren, bereinigen, persistieren, indexieren, Cover erstellen und veröffentlichen. Jeder I/O-Schritt ist wie folgt gekapselt:

const result = await step.do(
  "generate-article",
  { retries: { limit: 3, backoff: "exponential" } },
  async () => env.WRITER.generate(brief)
);

D1 hält den kanonischen Zustand (Statuswechsel in editorial_brief.status: dispatched → drafting → published / failed). Vectorize verwaltet Embeddings auf Blockebene (Gemini-2 768d, asymmetrisches Retrieval-Format). Jeder kostenpflichtige Modellaufruf läuft durch den zentralen Engpass callAi(env, ctx, runner). Dort wird er für die Kostenaggregation in ai_call_log mit agent_id, workflow_instance_id und idea_id protokolliert; zugleich gelten ein Tageslimit von $20 und ein Limit von $1 je Instanz.

Das ist der bereits dokumentierte Aufbau mit 6 Durable Objects. Für die Migration zu Managed Agents zählt vor allem, wo die Retry-Logik sitzt. Es sind zwei Stellen:

1. Wiederholungen einzelner Workflow-Schritte (günstig und kostenlos, wenn der zugrunde liegende Aufruf erfolgreich ist): Netzwerkabbrüche, Rate Limits und vorübergehende 5xx-Fehler vorgeschalteter Anbieter.
2. Eine von Hand geschriebene „Judge-and-Retry“-Schleife in clean.ts: Writer ausführen, Critic ausführen und bei score < 0.75 mit den Critic-Hinweisen erneut prompten – maximal 3 Versuche.

Managed Agents ersetzt die zweite Variante. Die erste bleibt.

Diese 280 Zeilen macht SDK 0.100 überflüssig

Die Judge-and-Retry-Schleife in src/worker/workflows/publish/clean.ts lässt sich am direktesten auf Outcomes abbilden. Aktuell umfasst die Orchestrierung rund 120 Zeilen: Writer aufrufen, das Ergebnis durch den Critic anhand einer in editorial_brief.rubric_md gespeicherten Rubrik bewerten lassen, Score parsen, je nach Schwellenwert verzweigen, die Hinweise als Systemblock an einen neuen Prompt hängen und das Ganze bis zu drei Mal wiederholen. Weitere 80 Zeilen entfallen auf das Critic Durable Object selbst – Hibernation Hooks, SQLite pro Instanz für den Rubrikverlauf und Idempotenzschlüssel pro Versuch. Hinzu kommen 40 Zeilen für die Aggregation der einzelnen Versuche in ai_call_log innerhalb von callAi.ts, weil jeder Versuch getrennt protokolliert und anschließend im Dashboard zusammengeführt wird.

Alle drei Blöcke schrumpfen auf einen einzigen Managed-Agents-Aufruf:

const session = await anthropic.beta.managedAgents.sessions.create({
  thread: { messages: [{ role: "user", content: brief.body_md }] },
  outcome: {
    rubric: brief.rubric_md,
    evaluator: "claude-sonnet-4-5-20250929"
  },
  metadata: { brief_id: brief.id, workflow_instance: ctx.instanceId }
});
return { session_id: session.id, status: "pending" };

Mehr ist nicht nötig. Die Session läuft asynchron auf der Seite von Anthropic bis zum Abschluss. Der Parameter outcome übernimmt die Aufgabe des Critic DO: Ein separater Evaluator-Agent prüft die Ausgabe anhand der Rubrik und startet den primären Agenten erneut, bis er besteht.

Neu hinzu kommt eine Route unter /api/admin/webhooks/managed-agents. Sie prüft die Signatur whsec_…, reagiert auf event.type === "session.outcome_evaluation_ended" und schreibt das Resultat zurück nach D1.

app.post("/api/admin/webhooks/managed-agents", async (c) => {
  const raw = await c.req.text();
  const event = await anthropic.webhooks.unwrap(
    raw, c.req.header("anthropic-signature")!, c.env.WEBHOOK_SECRET
  );

  if (event.type !== "session.outcome_evaluation_ended") {
    return c.json({ ok: true });
  }

  await c.env.DB.update(editorial_brief).set({
    status: event.outcome.passed ? "published" : "failed",
    body_md: event.result.body,
    session_cost_usd: event.session.usage.total_cost_usd
  }).where(eq(editorial_brief.id, event.session.metadata.brief_id));

  return c.json({ ok: true });
});

Das sind vierzig Zeilen, mit geprüfter Signatur und dank brief_id idempotent.

Nettodifferenz: 240 Zeilen Orchestrierung weniger. Ein Durable-Object-Binding weniger in wrangler.json. Eine Migrationsdatei weniger. Dafür 40 Zeilen Webhook-Verarbeitung und ein zusätzliches Geheimnis im Cloudflare Secrets Store.

Der Polling-Endpunkt unter GET /api/admin/workflows/:id/status funktioniert weiterhin. Er liest den Session-Status nun aus D1, das vom Webhook befüllt wird, statt env.PUBLISH_WORKFLOW.get(id).status() aufzurufen. Die Benutzeroberfläche bleibt unverändert. Das Admin-Dashboard bemerkt den Wechsel nicht.

Wichtig ist: Die step.do-Retry-Wrapper bleiben um alle anderen I/O-Schritte erhalten. Weder Cover-Bilderzeugung noch Vercel-Revalidierung oder Cloudflare-Cache-Purge profitieren von Outcome-Rubriken. Alle drei profitieren weiterhin vom wiederholungssicheren Step-Caching der Workflows. Funktionierenden Code sollte man hier nicht herausreißen.

Warum eine Datei bleibt – und die Kostenrechnung mit der Größe kippt

callAi.ts bleibt erhalten: Tageslimit $20, Limit pro Instanz $1. Jeder kostenpflichtige Modellaufruf läuft darüber, ob direkt, über AI Gateway oder über Managed Agents.

Der Grund liegt im Abrechnungsmodell. Managed Agents berechnet auf drei Achsen: Tokens zu den üblichen Preisen, dazu $0.08 pro Session-Stunde sowie $10 je 1000 Websuchen. Bei meinem Volumen – sechs Publisher-Routinen, ein Artikel pro Ausführung und rund 3 Minuten je Session – kommen pro Artikel ungefähr $0.004 an Session-Stunden-Kosten zusätzlich zu den Tokens hinzu. Das ist vernachlässigbar.

Bei langen Sessions kippt die Rechnung. Eine 4-stündige Anthropic-Skills-Session verursacht allein $0.32 Laufzeitkosten zusätzlich zu den Tokenkosten. Bei 50 solcher Sessions am Tag sind das $480 im Monat nur für Session-Stunden, noch vor den Tokens. Wartet eine mehrstufige Recherche-Session eine Stunde in einer Websuch-Warteschlange, entstehen $0.08, die zuvor nicht angefallen wären. Auch die Leerlaufzeit einer Session, die auf einen nachgelagerten Dienst wartet, wird berechnet. Laut Anthropic-Dokumentation erfolgt die Abrechnung millisekundengenau, der Zähler läuft jedoch weiter.

Der zentrale Engpass erzwingt eine harte Obergrenze, die das Managed-Agents-Dashboard nicht bietet. Dort werden die Session-Kosten erst im Nachhinein sichtbar. callAi.ts löst dagegen noch vor dem Session-Start mitten im Workflow einen NonRetryableError aus, wenn die Vorabschätzung das Tageslimit überschreiten würde.

Die Vorabschätzung ist bewusst konservativ:

async function estimateSessionCost(brief: Brief): Promise<number> {
  const tokenEstimate = brief.body_md.length / 3.5;
  const inputCost = (tokenEstimate / 1_000_000) * 3.0;
  const outputCost = (tokenEstimate * 1.5 / 1_000_000) * 15.0;
  const sessionHourEstimate = (brief.expected_minutes / 60) * 0.08;
  const safetyMargin = 1.4;
  return (inputCost + outputCost + sessionHourEstimate) * safetyMargin;
}

Bei der Kostenrechnung pro Session-Stunde geraten Setups von Solo-Entwicklern am schnellsten aus dem Ruder. Ohne Obergrenze verbraucht ein einziger außer Kontrolle geratener Agent das Tagesbudget, bevor es auffällt – genau dieses Verhalten kann die outcome-Retry-Schleife bei einer zu strengen Rubrik begünstigen. Ich habe es erlebt.

Deshalb bleibt der Engpass. sessions.create() läuft weiterhin darüber. Die Vorabschätzung wird vor dem Start der Session protokolliert und nach deren Ende mit event.session.usage.total_cost_usd aus dem Webhook-Payload abgeglichen.

Warum ich die Multi-Agenten-Orchestrierung noch nicht migriere

Die Multi-Agenten-Orchestrierung ist das zentrale Feature des Anthropic Dev Day. Ein Lead-Agent zerlegt die Aufgabe und verteilt Teilaufgaben an spezialisierte Subagenten, die jeweils eigene Modelle, Prompts und Tools nutzen. Die Subagenten arbeiten parallel auf einem gemeinsamen Dateisystem; der Lead führt ihre Ergebnisse zusammen. Auf dem Papier entspricht das genau meinem heutigen Manager DO: Es beauftragt Writer, Discovery und Distribution parallel per DO RPC. Jedes verfügt über einen eigenen SQLite-Zustand, R2 und D1 dienen als gemeinsames „Dateisystem“.

Drei Gründe sprechen für das Abwarten.

Erstens: API-Änderungen. Die Multi-Agenten-Orchestrierung befindet sich in einer Research Preview, für die ein eigener Zugang beantragt werden muss. BetaManagedAgentsSearchResultBlock ist gerade erst mit 0.102 hinzugekommen. Die Blocktypen für Multi-Agenten-Ergebnisse verändern sich weiterhin. Eine sofortige Migration würde bedeuten, die Integration bei jedem SDK-Update der nächsten zwei oder drei Releases neu zu schreiben. Die Webhook-Oberfläche ist seit 0.100 stabil; Multi-Agenten sind noch in Bewegung.

Zweitens: Das gemeinsame Dateisystem gilt nur für eine Session und ist flüchtig. Das gemeinsame Dateisystem innerhalb einer Managed-Agents-Session verschwindet mit deren Ende. R2 und D1 bleiben dagegen über alle Routinen hinweg erhalten, lassen sich von jedem Worker abfragen und überleben einen Session-Absturz. Solange das gemeinsame Dateisystem nicht dauerhaft wird oder R2 nicht direkt in die Session-Sandbox eingebunden werden kann, wäre die Umstellung für meine Workload ein Funktionsverlust.

Drittens: Die Aufteilung in Lead und Subagenten ist bei Anthropic fest vorgegeben. Der Lead-Agent hat eine feste Rolle. Mein Editorial DO übernimmt diese Führung an manchen Tagen, wenn eine Publisher-Routine startet. An anderen ist es ein gleichrangiger Teilnehmer, etwa wenn die Admin-Oberfläche einen Brief verteilt und Editorial erst mitten in der Pipeline hinzukommt. Für eine gehostete Abstraktion müsste ich eine nützliche Asymmetrie einebnen.

Attraktiv wird die Migration, sobald das gemeinsame Dateisystem dauerhaft und Session-übergreifend ist oder R2 direkt in die Sandbox eingebunden werden kann. Heute wäre sie ein Seitwärtsschritt, kein Fortschritt.

Migrationscheckliste für Anthropic SDK 0.100 bis 0.102

Die Migration dauert für Discovery einen Nachmittag, für Writer einen weiteren; der Rest folgt. 0.102.0 festschreiben. Webhook registrieren. Critic DO löschen. Den Kostenengpass behalten.