Agents IA d’Anthropic : 280 lignes à supprimer sur Cloudflare

Agents IA : ce qu’ont réellement apporté les versions 0.100 à 0.102 du SDK

Trois releases en huit jours : la surface de l’Anthropic Python SDK a davantage évolué qu’au cours des six mois précédents. Les dates ont leur importance, car toute production restée sur anthropic==0.99.x a manqué l’intégralité du runtime Managed Agents en l’espace d’un seul sprint.

v0.100.0 (6 mai 2026) a ajouté au namespace beta la prise en charge du multi-agent, des outcomes et des webhooks, ainsi que la validation du vault. L’interface à retenir est la suivante : client.beta.managed_agents.sessions.create(thread=..., outcome=..., metadata=...) renvoie un session_id, puis s’exécute de façon asynchrone sur l’infrastructure d’Anthropic. La boucle d’orchestration n’est plus à votre charge.

v0.101.0 (11 mai 2026) a introduit le client AWS pour Claude Platform on AWS et fait passer tous les exemples des cookbooks à claude-sonnet-4-5-20250929. Pour Bedrock, c’est la version minimale à viser : la variable d’environnement ANTHROPIC_BEDROCK_SERVICE_TIER et ses valeurs default/flex/priority arrivent ici, pas dans la 0.100.

v0.102.0 (13 mai 2026) a ajouté les types BetaManagedAgentsSearchResultBlock, les diagnostics de cache pour la bêta du prompt cache et la validation immédiate des itérateurs Pydantic. La surface des types de blocs continue donc de bouger — c’est la principale raison pour laquelle je ne migre pas encore mon code multi-agents.

La nouveauté majeure, ce sont les outcomes. Vous rédigez une grille d’évaluation ; un agent évaluateur distinct note le résultat, puis l’agent recommence jusqu’à satisfaire cette grille. Les évaluations internes d’Anthropic annoncent jusqu’à +10 points de réussite par rapport aux boucles de prompting classiques, +8.4% pour la génération de docx et +10.1% pour les pptx. Ces chiffres rejoignent ce que j’observe avec mon propre Critic Durable Object : une seule nouvelle tentative enrichie des remarques du juge procure à peu près le gain d’un passage au palier supérieur de modèle.

L’autre moitié du dispositif repose sur les webhooks. Huit événements de session sont envoyés vers une URL enregistrée dans Claude Console : session.status_run_started, session.status_idled, session.status_rescheduled, session.status_terminated, session.thread_created, session.thread_idled, session.thread_terminated et, surtout, session.outcome_evaluation_ended. Le secret de signature commence par whsec_… et n’est affiché qu’une fois lors de la création. La vérification se fait avec client.webhooks.unwrap(payload, signature, secret).

L’orchestration multi-agents est également arrivée, mais elle reste soumise à une demande d’accès à la research preview. J’explique plus loin pourquoi je n’active pas encore cette option.

Ce que cela change pour les fondateurs non techniques

Anthropic exécute désormais l’agent à votre place. Vous définissez la grille — « l’article atteint-il 2,000 mots, cite-t-il trois sources primaires et passe-t-il la regex anti-IA ? » — puis l’agent évaluateur d’Anthropic note la sortie et relance l’agent jusqu’à validation. Votre ingénieur n’a plus à coder cette boucle.

L’impact financier est double. D’abord, moins de logique de relance artisanale dans le code, donc moins de temps d’ingénierie senior consacré à sa maintenance. Ensuite, davantage de tentatives dans la session Anthropic, facturées chacune avec un supplément de $0.08 par heure de session, en plus des tokens. Le gain net dépend entièrement de la durée des sessions.

En toute franchise, pour une équipe qui lance la v1 d’un produit agentique, Managed Agents remplace environ 40% du code d’orchestration qu’un ingénieur senior aurait autrement dû construire. Si le produit existe déjà, la part est moindre ; en revanche, les webhooks suppriment la boucle de polling qui se cache presque certainement quelque part dans la stack.

La question à poser au CTO cette semaine : « Attendons-nous toujours la fin par polling, ou sommes-nous déjà passés à session.outcome_evaluation_ended ? » Si la réponse est « polling », une demi-journée de refactorisation suffit pour réduire à la fois le coût d’infrastructure et la latence des requêtes.

La stack Cloudflare que j’utilise aujourd’hui

Pour bien comprendre ce qui peut disparaître, voici l’architecture actuelle : un unique worker Hono sur Cloudflare Workers — cible ES2021 et binding Static Assets — sert de façade à six Durable Objects, un par routine de publication. Editorial, Discovery, Writer, Distribution, Maintenance et Manager, auxquels s’ajoute un septième objet, ManualIntake, pour l’interface d’administration.

Chaque routine passe par l’un des six Cloudflare Workflows suivants : PublishWorkflow, WriteArticle, PublishArticle, EnrichIdea, DiscoverIdeas, DistributeArticle. Le plus sollicité, PublishWorkflow, compte huit étapes idempotentes : validate, ground, generate, clean, persist, index, cover, publish. Chaque étape d’I/O est encapsulée ainsi :

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

D1 conserve l’état canonique (transitions de editorial_brief.status : dispatched → drafting → published / failed). Vectorize gère les embeddings bloc par bloc (Gemini-2 768d, format de recherche asymétrique). Tous les appels payants aux modèles passent par un point de contrôle unique, callAi(env, ctx, runner). Celui-ci alimente ai_call_log avec agent_id, workflow_instance_id et idea_id pour agréger les coûts, tout en imposant un plafond quotidien de $20 et une limite de $1 par instance.

C’est l’architecture à 6 DO que j’ai détaillée précédemment. Pour migrer vers Managed Agents, l’emplacement de la logique de relance est le point décisif. Elle se trouve à deux endroits :

1. Les relances des étapes de workflow (peu coûteuses, gratuites si l’appel sous-jacent aboutit) : coupures réseau, limitations de débit et erreurs 5xx transitoires des fournisseurs en amont.
2. Une boucle « judge-and-retry » écrite à la main dans clean.ts : exécuter Writer, puis Critic ; si score < 0.75, reformuler le prompt avec les remarques de Critic, avec un maximum de 3 tentatives.

Managed Agents remplace la seconde. La première reste en place.

Agents IA sur Cloudflare : les 280 lignes que le SDK 0.100 permet de retirer

La boucle « judge-and-retry » de src/worker/workflows/publish/clean.ts correspond presque exactement aux outcomes. Aujourd’hui, elle représente environ 120 lignes d’orchestration : appeler Writer, faire évaluer sa sortie par Critic selon une grille stockée dans editorial_brief.rubric_md, parser la note, bifurquer selon le seuil, enrichir le bloc système avec les remarques, puis recommencer jusqu’à trois fois. Critic lui-même ajoute 80 lignes de Durable Object — hooks d’hibernation, SQLite par instance pour l’historique des grilles, clés d’idempotence par tentative. Enfin, l’agrégation par tentative dans ai_call_log occupe encore 40 lignes dans callAi.ts, puisque chaque essai est journalisé séparément avant consolidation dans le dashboard.

Ces trois blocs se réduisent à un seul appel Managed Agents :

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" };

C’est tout. La session s’exécute de façon asynchrone jusqu’à son terme sur l’infrastructure d’Anthropic. Le paramètre outcome reprend le travail jusque-là confié au Critic DO : un agent évaluateur indépendant note la sortie selon la grille, puis relance l’agent principal jusqu’à validation.

En contrepartie, j’ajoute une route /api/admin/webhooks/managed-agents. Elle vérifie la signature whsec_…, teste event.type === "session.outcome_evaluation_ended", puis réécrit le résultat dans 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 });
});

Quarante lignes, avec signature vérifiée et idempotence assurée par brief_id.

Diff net : 240 lignes d’orchestration en moins. Un binding Durable Object de moins dans wrangler.json. Un fichier de migration en moins. En contrepartie : 40 lignes de gestion de webhook et un secret dans Cloudflare Secrets Store.

L’endpoint de polling GET /api/admin/workflows/:id/status continue de fonctionner. Il lit désormais dans D1 l’état de la session, alimenté par le webhook, au lieu d’interroger env.PUBLISH_WORKFLOW.get(id).status(). L’interface ne change pas, et le dashboard d’administration n’y voit aucune différence.

Attention à un point : les wrappers de relance step.do restent sur toutes les autres étapes d’I/O. Génération de l’image de couverture, revalidation Vercel, purge du cache Cloudflare — les grilles d’outcome ne leur apportent rien, tandis que le cache d’étapes de Workflows, conçu pour être rejoué sans risque, reste très utile. Inutile de démonter ce qui fonctionne.

Le fichier que je conserve — et pourquoi le calcul des coûts bascule à grande échelle

callAi.ts reste. Plafond quotidien de $20, limite de $1 par instance : tout appel payant à un modèle doit passer par lui, qu’il soit direct, qu’il transite par AI Gateway ou qu’il utilise Managed Agents.

Voici pourquoi. Managed Agents facture selon trois axes : les tokens au tarif standard, auxquels s’ajoutent $0.08 par heure de session et $10 pour 1000 recherches web. À mon volume — six routines de publication, un article par déclenchement et environ 3 minutes par session — le coût horaire de session revient à environ $0.004 par article, hors tokens. Autrement dit, presque rien.

Le calcul change lorsque les sessions s’allongent. Une session Anthropic Skills de 4 heures coûte à elle seule $0.32 de runtime, avant les tokens. À raison de 50 sessions de ce type par jour, cela représente $480 par mois uniquement en heures de session. Une session de recherche multi-étapes laissée une heure en attente d’une recherche web ajoute $0.08 qui n’existaient pas auparavant. Même l’attente d’un service en aval est facturée : la documentation d’Anthropic annonce un décompte à la milliseconde, et le compteur continue de tourner.

Ce point de contrôle impose une limite stricte que le dashboard Managed Agents n’offre pas. Le dashboard n’affiche le coût qu’après coup. Avant même le lancement de la session, callAi.ts lève une NonRetryableError au milieu du workflow si l’estimation préalable risque de dépasser le plafond quotidien.

Cette estimation est volontairement prudente :

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;
}

Le calcul du coût par heure de session est le piège le plus rapide pour les configurations d’ingénieur solo. Sans plafond, un seul agent qui s’emballe — précisément le comportement que peut encourager la boucle de relance outcome lorsque la grille est trop stricte — engloutit le budget de la journée avant même d’être détecté. Je l’ai vu arriver.

Conservez ce point de contrôle. Faites-y passer sessions.create(). Journalisez l’estimation avant le démarrage de la session, puis rapprochez-la de event.session.usage.total_cost_usd reçu dans le payload du webhook lorsque la session se termine.

La migration que je diffère encore : l’orchestration multi-agents

L’orchestration multi-agents est la grande annonce d’Anthropic Dev Day. Un agent principal décompose la tâche et confie les sous-tâches à des sous-agents spécialisés, chacun avec son propre modèle, son prompt et ses outils. Ils travaillent en parallèle sur un système de fichiers partagé, puis l’agent principal agrège leurs résultats. Sur le papier, c’est exactement le rôle actuel de mon Manager DO : distribuer le travail à Writer, Discovery et Distribution en parallèle via DO RPC, chacun avec son état SQLite, tandis que R2 + D1 jouent le rôle de « système de fichiers » partagé.

Trois raisons me font patienter.

Première raison : l’API bouge encore. L’orchestration multi-agents reste en research preview et nécessite une demande d’accès distincte. BetaManagedAgentsSearchResultBlock vient tout juste d’arriver dans la 0.102. Les types de blocs associés aux résultats multi-agents ne sont pas encore stabilisés. Migrer aujourd’hui obligerait à reprendre l’intégration à chaque mise à jour du SDK pendant les deux ou trois prochaines releases. La surface webhook s’est stabilisée en 0.100 ; celle du multi-agent continue d’évoluer.

Deuxième raison : le système de fichiers partagé est limité à la session et éphémère. Dans une session Managed Agents, il disparaît à la fin de celle-ci. R2 et D1, eux, persistent entre toutes mes routines, restent interrogeables depuis n’importe quel worker et survivent au crash d’une session. Tant que le système partagé ne devient pas durable — ou que R2 ne peut pas être monté directement dans la sandbox de session — cette migration ferait régresser mon workload.

Troisième raison : la séparation lead/subagent d’Anthropic est rigide. Le rôle de l’agent principal est fixe. Or mon Editorial DO pilote certains jours, lorsqu’une routine de publication se déclenche, et agit comme pair les autres jours, lorsque l’interface d’administration envoie un brief et qu’Editorial rejoint le pipeline en cours de route. Adopter cette abstraction hébergée reviendrait à aplatir une asymétrie qui m’est utile.

Le déclic viendra lorsque le système de fichiers partagé deviendra durable et utilisable entre les sessions — ou lorsque R2 pourra être monté dans la sandbox. Pour l’instant, c’est un changement sans gain, pas une amélioration.

Checklist précise pour migrer vers les SDK 0.100 à 0.102

La migration demande un après-midi pour Discovery, puis un autre pour Writer ; le reste suit. Épinglez la 0.102.0. Enregistrez le webhook. Supprimez le Critic DO. Conservez le point de contrôle.