Qu'est-ce que Claude Managed Agents ? Le cloud entièrement managé d'Anthropic

Faire tourner un agent en production, cela veut dire mettre en place la boucle de l'agent, l'exécution des outils, un sandbox et la persistance de l'état — le tout par vous-même. Claude Managed Agents vous retire toute cette charge : Anthropic s'en occupe pour vous. Lancé en bêta publique le 8 avril 2026, c'est une suite d'API composables pour construire et déployer des agents hébergés dans le cloud à grande échelle.

Cet article présente, sur la base d'informations officielles, ce qu'est Managed Agents, en quoi il se distingue de l'Agent SDK auto-hébergé, la mémoire persistante et le « dreaming », la notation fondée sur les résultats et le multi-agent, ainsi que la tarification. Les points clés d'emblée. ① Au lieu de « construire votre propre boucle d'agent », vous obtenez un environnement entièrement managé où Claude peut lire des fichiers, exécuter des commandes, naviguer sur le web et exécuter du code en toute sécurité. ② Il dispose d'une mémoire persistante limitée à l'espace de travail (montée sur /mnt/memory), qu'un « dream » peut réorganiser et consolider. ③ La tarification est tokens + $0.08 par heure de session.

1. Qu'est-ce que Managed Agents ?

Selon les mots d'Anthropic, Managed Agents est « une suite d'API composables pour construire et déployer des agents hébergés dans le cloud à grande échelle », et la documentation le décrit comme un « harnais d'agent préconstruit et configurable qui s'exécute sur une infrastructure managée ». L'essentiel : « Au lieu de construire votre propre boucle d'agent, votre exécution d'outils et votre runtime, vous obtenez un environnement entièrement managé où Claude peut lire des fichiers, exécuter des commandes, naviguer sur le web et exécuter du code en toute sécurité. » La mise en cache des prompts, la compaction du contexte, le sandboxing et la persistance de l'état sont intégrés dès le départ.

Il s'organise autour de quatre concepts — Agent (la définition) / Environment (où il s'exécute) / Session / Events. L'Environment peut être un sandbox cloud managé par Anthropic ou un sandbox auto-hébergé sur votre propre infrastructure.

Un Agent peut recevoir les skills d'Anthropic (pptx, xlsx, docx, pdf) ainsi que des skills que vous créez et téléversez vous-même (jusqu'à 500 par session). Côté outils, en plus de l'ensemble intégré et des serveurs MCP, vous pouvez définir des « outils personnalisés » exécutés par votre propre code.

Ici, le « harnais » (harness) désigne tout ce qui, dans un agent, n'est pas le modèle : la boucle, les outils, la mémoire, les garde-fous, etc. L'idée elle-même est expliquée dans Qu'est-ce que le harness engineering ?

2. Comparaison avec l'Agent SDK (auto-hébergé vs managé)

Ce qu'on a facilement tendance à confondre, c'est la différence avec le Claude Agent SDK. Les deux forment une paire selon l'axe « vous l'exécutez » vs « Anthropic l'exécute ».

En bref : « vous voulez construire votre propre moteur ? Agent SDK. Vous voulez louer le moteur et vous concentrer sur le contenu ? Managed Agents. » Ce ne sont pas des concurrents — c'est un choix sur la part de l'exploitation que vous gardez vous-même. Pour le concept d'agents, voir qu'est-ce que le multi-agent ; pour en construire un, comment construire un système multi-agent.

3. Mémoire persistante et « dreaming »

Une fonctionnalité emblématique de Managed Agents est la mémoire persistante (un memory store). C'est « une collection de documents texte limitée à l'espace de travail », montée comme un répertoire (/mnt/memory/) à l'intérieur du sandbox de la session. L'agent la lit et l'écrit avec des opérations de fichiers normales, et son contenu persiste d'une session à l'autre. Chaque modification crée une version de mémoire immuable à des fins d'audit. Les versions passées sont conservées 30 jours après leur écriture, mais les versions récentes d'une mémoire active sont toujours gardées, quel que soit leur âge (une mémoire qui change peu peut donc conserver un historique de plus de 30 jours). Pour garder l'historique plus longtemps, exportez-le via l'API. Limites : 100 kB par mémoire, 10 000 mémoires par store, 8 stores par session.

Point d'attention pour les développeurs : l'API qui gère les memory stores utilise un en-tête bêta dédié, agent-memory-2026-07-22. L'envoyer avec managed-agents-2026-04-01 provoque une erreur 400 (l'opération qui attache un memory store à une session garde l'en-tête habituel). Avec un sandbox auto-hébergé, la mémoire n'est pas un montage connecté en permanence : le processus de travail en garde une copie et la synchronise (documentation de la mémoire).

Plus inhabituel : le « dreaming ». D'après la description officielle : « Un dream lit un memory store existant en même temps que les transcriptions des sessions passées, puis produit un nouveau memory store réorganisé : doublons fusionnés, entrées obsolètes ou contredites remplacées par la dernière valeur, et nouvelles informations mises en avant. » C'est un job asynchrone (1 à 100 sessions en entrée, avec des instructions facultatives) qui nécessite son propre en-tête bêta, dreaming-2026-04-21 (managed-agents-2026-04-01 seul ne donne pas accès aux endpoints de dream).

Le modèle qui exécute le dream se choisit à la création. La documentation des dreams cite neuf modèles pris en charge pendant l'aperçu de recherche : Claude Opus 5.5, Claude Fable 5.1, Claude Opus 5, Claude Fable 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5.5, Claude Sonnet 5, Claude Sonnet 4.6 (vérifié le 12 octobre 2026). Les modèles Haiku, absents de la liste, ne peuvent pas exécuter de dream. Un dream est facturé aux tarifs standard des tokens du modèle choisi.

4. Notation par résultats et multi-agent

Une fonctionnalité plus récente est la notation fondée sur les résultats. D'après Anthropic : « Vous rédigez un barème décrivant à quoi ressemble le succès et l'agent travaille à l'atteindre. Un évaluateur distinct juge la sortie par rapport à vos critères dans sa propre fenêtre de contexte. » Anthropic indique qu'elle « a amélioré le taux de réussite des tâches jusqu'à 10 points par rapport à une boucle de prompting standard » (+8,4 % pour docx, +10,1 % pour pptx). Ce sont des mesures d'Anthropic elle-même — l'annonce parle de « our internal benchmarks » —, et non des résultats de tiers. Bêta publique.

L'orchestration multi-agent est également intégrée : « Un agent principal découpe le travail en plusieurs parties et délègue chacune à un spécialiste doté de son propre modèle, prompt et outils », s'exécutant en parallèle sur un système de fichiers partagé. La philosophie de conception consistant à orchestrer des agents fait écho à comment construire un système multi-agent.

Il existe aujourd'hui trois façons de confier du travail (documentation multi-agent). ① La délégation à des sous-agents (un seul niveau de délégation, jusqu'à 25 fils enfants simultanés). ② Les dynamic workflows : l'agent écrit lui-même un programme qui lance plusieurs agents et rassemble leurs résultats, et le serveur l'exécute (jusqu'à 1 000 agents par exécution, et par défaut 10 exécutions ouvertes simultanément par session). ③ L'advisor : l'agent poursuit le travail lui-même et, au moment de planifier ou de vérifier la finition, demande conseil à un modèle plus puissant (les conseils sont facturés au tarif de ce modèle). Dans tous les cas, les tokens de tous les agents lancés sont facturés ; la documentation officielle recommande donc de fixer un plafond de dépense pour la session.

5. Ce qui a été ajouté depuis le lancement

Depuis son lancement le 8 avril 2026, Managed Agents s'enrichit toutes les quelques semaines. Les dates proviennent des annonces d'Anthropic (celles d'octobre 2026, des notes de version de Claude Platform).

• 23 avril 2026 — Mémoire : les memory stores sont lancés en bêta publique.
• 19 mai 2026 — Outcomes, orchestration multi-agents, webhooks, dreaming : les trois premiers en bêta publique, le dreaming en research preview. Un webhook peut vous prévenir quand le travail est terminé.
• 19 mai 2026 — Sandboxes auto-hébergées et tunnels MCP : seule l'exécution des outils peut passer sur votre propre infrastructure (ou chez un fournisseur de sandboxes comme Cloudflare, Daytona, Modal ou Vercel), tandis que la boucle, la gestion du contexte et la reprise sur erreur restent chez Anthropic. Les tunnels MCP relient des serveurs MCP de votre réseau privé sans les exposer, en research preview.
• 9 juin 2026 — Déploiements planifiés et vaults : un agent peut démarrer selon une expression cron et un fuseau horaire (à la minute près). Pour les clés d'API stockées dans un vault, la sandbox ne contient qu'une valeur de substitution ; la vraie clé est ajoutée à la frontière du réseau, uniquement pour les requêtes vers les domaines autorisés, si bien que l'agent ne la voit jamais.
• 7 octobre 2026 — Les limites réseau s'appliquent aussi à la recherche et à la récupération web : lorsqu'un environnement cloud utilise le réseau limited, ses hôtes autorisés (allowed_hosts) s'appliquent désormais aussi aux outils web_search et web_fetch. Un appel web_fetch vers une URL d'un hôte non autorisé renvoie une erreur, et web_search omet les résultats de ces hôtes. Si allowed_hosts est vide, aucun des deux outils ne renvoie de page ni de résultat. allow_package_managers et allow_mcp_servers n'ajoutent aucun hôte pour ces deux outils. Le réseau unrestricted et les sandboxes auto-hébergées ne sont pas concernés. En outre, la création d'une session échoue avec une erreur 400 lorsque le allowed_domains d'un outil web activé contient un hôte hors de allowed_hosts (de même pour une mise à jour de session qui ajoute une telle entrée). Une entrée de allowed_hosts ne correspond qu'à un hôte exact, sauf si elle commence par *. : docs.example.com n'est donc pas couvert par ["example.com"].
• 7 octobre 2026 — La récupération web se limite aux URL déjà vues dans la session : web_fetch ne récupère désormais que les URL déjà apparues dans la session, par exemple dans le texte d'un message de l'utilisateur, dans un résultat de web_search ou dans une page récupérée plus tôt avec web_fetch. Le but est de réduire le risque d'exfiltration de données. Une URL qui n'apparaît que dans la sortie de Claude lui-même, le prompt système, un document joint ou la sortie de bash ou d'un outil MCP ne compte pas, et sa récupération renvoie l'erreur url_not_in_prior_context. Pour que l'agent récupère une URL, envoyez-la dans le texte d'un événement user.message.
• 9 octobre 2026 — Dynamic workflows (bêta) : les dynamic workflows de l'option ② de la section 4 sont devenus disponibles. L'agent écrit un programme qui lance de nombreux agents par phases et rassemble leurs résultats, et le serveur l'exécute en arrière-plan sous forme de workflow run. On les active en donnant au champ multiagent de l'agent le type multiagent_20261001 avec les workflows activés, et on indique dans le prompt système quand lancer une exécution. La progression se suit via les événements workflow_run.* du flux d'événements.
• 14 octobre 2026 — Les déploiements planifiés fonctionnent aussi sur Claude Platform on AWS : lancés en juin, les déploiements planifiés sont désormais disponibles aussi sur Claude Platform on AWS (vérifié le 18 octobre 2026). Sur AWS, chaque exécution crée une session sous la forme d'un rôle IAM de votre propre compte AWS. Il faut au préalable régler le champ execution_identity de l'agent sur aws_role ; créer un déploiement sans cela renvoie une erreur 400. La documentation des déploiements planifiés indique toujours la fonctionnalité en bêta.
• 14 octobre 2026 — Export OpenTelemetry (bêta) : les requêtes de la Messages API et les sessions de Managed Agents peuvent désormais être suivies via OpenTelemetry dans votre outil de supervision existant (vérifié le 18 octobre 2026). Le SDK de Claude émet des spans en Python, TypeScript, C#, Go, Java, PHP et Ruby ; pour obtenir les spans côté API, ajoutez une destination d'export dans la Claude Console (documentation officielle).

On peut aussi fixer un plafond de dépense par session (session budget) : la consommation est valorisée au prix public et les nouveaux appels au modèle s'arrêtent une fois le plafond atteint.

6. Tarification et disponibilité

La tarification comporte deux dimensions : ① les tokens (tarifs standard des modèles, avec mise en cache des prompts appliquée) + ② le temps d'exécution de la session à $0.08 par heure de session. Le temps d'exécution est facturé à la milliseconde et uniquement tant que le statut est running (l'inactivité ou la replanification sont gratuites). Exemple chiffré d'Anthropic : une session de code d'une heure consommant 50 000 tokens en entrée et 15 000 en sortie coûte environ $0.705 Cet exemple utilise les tarifs de Claude Opus 5 ($5 en entrée / $25 en sortie par million de tokens, selon la page de tarifs en septembre 2026).

Voici le même cas recalculé par modèle avec les tarifs de la page au 12 octobre 2026. La colonne de droite reprend le second exemple d'Anthropic, où 40 000 des tokens d'entrée sont des lectures de cache (la lecture de cache coûte normalement 0,1× le tarif d'entrée ; 0,05× sur Opus 5.5 et Sonnet 5.5).

Les $0.08 d'exécution sont identiques sur chaque ligne ; l'écart vient des tokens. Plus le modèle est bon marché, plus le temps d'exécution pèse dans la facture (environ 40 % sur Haiku 4.5, environ 90 % sur Haiku 5.5). Notez que Haiku 5.5 passe à un tarif plus élevé (entrée $0.50, sortie $2.50) dès que l'entrée d'une requête dépasse 100 000 tokens. Dans une session d'agent où le contexte s'accumule, ce seuil est facile à franchir.

Le temps d'exécution seul par mois se calcule ainsi : heures par jour × 30 jours × $0.08. Seul le temps au statut running compte ; le temps idle passé à attendre votre prochain message n'est pas facturé. Laisser une session ouverte toute la journée ne facture que le temps où elle travaille vraiment.

Les deux colonnes de droite supposent que chaque heure consomme les mêmes tokens que l'exemple ci-dessus (50 000 en entrée, 15 000 en sortie, sans cache). La consommation réelle varie de plusieurs ordres de grandeur selon la tâche : lisez la colonne d'exécution comme un plancher et plafonnez la dépense en tokens avec un budget de session.

7. Pour commencer

Le quickstart officiel compte quatre étapes. Chaque requête doit porter l'en-tête bêta managed-agents-2026-04-01 (le SDK l'ajoute pour vous).

1. Créer un agent : définir le modèle, le prompt système, les outils, les serveurs MCP et les skills. L'ensemble d'outils intégrés (bash, opérations sur fichiers, recherche web, etc.) s'active avec agent_toolset_20260401. On le crée une fois et on le réutilise par son ID.
2. Créer un environnement : choisir où il s'exécute. Pour une sandbox cloud, préciser les paquets préinstallés et si le trafic sortant est libre (unrestricted) ou limité aux hôtes autorisés (limited). Si on ne le précise pas dans l'API, c'est unrestricted ; l'écran de création de la Console part de limited. La documentation officielle demande de le préciser explicitement. Depuis le 7 octobre 2026, les hôtes autorisés de limited s'appliquent aussi aux outils de recherche et de récupération web : ajoutez à allowed_hosts les sites dont ils ont besoin (un hôte ajouté est aussi ouvert à la sandbox).
3. Démarrer une session : la lancer avec l'agent et l'environnement. C'est aussi là qu'on peut fixer un plafond de dépense (budget).
4. Envoyer des événements et recevoir les résultats : envoyer le message de l'utilisateur sous forme d'événement ; Claude utilise les outils de lui-même et renvoie les résultats en server-sent events (SSE). On peut envoyer d'autres instructions en cours de route ou l'interrompre.

On peut aussi décrire l'agent et l'environnement dans des fichiers et les créer avec ant apply depuis la CLI. Pour démarrer depuis Claude Code, lancez /claude-api managed-agents-onboard dans la dernière version : un guide interactif vous accompagne dans la configuration (quickstart officiel).

8. Quand l'utiliser, quand l'éviter

D'après la section « quand l'utiliser » de la documentation officielle et les conditions de la page des tarifs :

Résumé

Claude Managed Agents est un environnement entièrement managé où Anthropic exploite pour vous la boucle de l'agent, l'exécution des outils, le sandbox et la persistance de l'état. Là où l'Agent SDK auto-hébergé signifie « vous faites tourner le moteur », Managed Agents signifie « Anthropic l'exécute, et vous vous concentrez sur la définition » — un choix apparié qui diffère sur l'endroit où se situe la responsabilité d'exploitation.

Ses marques de fabrique sont la mémoire persistante limitée à l'espace de travail (montée sur /mnt/memory, persistant d'une session à l'autre) et le « dreaming » (préversion de recherche) pour la réorganiser et la consolider, auxquels s'ajoutent la notation fondée sur les résultats et l'orchestration multi-agent. La tarification est tokens + $0.08 par heure de session, disponible pour tous les comptes API en tant que bêta publique d'avril 2026 (stateful, donc non éligible au ZDR / HIPAA BAA). À lire aussi : guide de l'Agent SDK, qu'est-ce que le multi-agent, comment construire un système multi-agent.

FAQ

Q. Qu'est-ce que Managed Agents ?
A. La suite d'API d'Anthropic pour construire et déployer des agents hébergés dans le cloud. Au lieu de construire votre propre boucle d'agent, exécution d'outils et runtime, vous obtenez un environnement entièrement managé où Claude peut lire des fichiers, exécuter des commandes, naviguer sur le web et exécuter du code en toute sécurité. La mise en cache des prompts, la compaction, le sandboxing et la persistance de l'état sont intégrés. Il a été lancé en bêta publique le 8 avril 2026.

Q. En quoi diffère-t-il de l'Agent SDK ?
A. Sur qui détient l'exploitation. L'Agent SDK est un harnais auto-hébergé que vous exécutez en Python / TypeScript, où vous gérez la boucle, les outils et l'infrastructure. Avec Managed Agents, Anthropic fournit la boucle, le sandbox, l'état et la mémoire sur une infrastructure managée, et vous vous concentrez sur la définition de l'agent. Ce ne sont pas des concurrents — c'est un choix sur la part de l'exploitation que vous conservez.

Q. Qu'est-ce que la mémoire persistante et le « dreaming » ?
A. La mémoire persistante (un memory store) est une collection de documents texte limitée à l'espace de travail, montée dans le sandbox sous /mnt/memory/ ; l'agent la lit et l'écrit avec des opérations de fichiers normales et elle persiste d'une session à l'autre. Le « dreaming » est un job asynchrone qui lit la mémoire existante et les transcriptions des sessions passées pour produire un memory store réorganisé — en fusionnant les doublons, en mettant à jour les valeurs obsolètes et en faisant émerger de nouvelles informations. Le dreaming est actuellement une préversion de recherche (demande d'accès requise).

Q. Combien ça coûte ?
A. Deux dimensions : frais de tokens + temps d'exécution de la session à $0.08 par heure de session. Le temps d'exécution est facturé à la milliseconde et uniquement tant que le statut est running (inactivité / replanification gratuites). L'estimation d'Anthropic est d'environ $0.705 pour une session d'une heure consommant 50 000 tokens en entrée et 15 000 en sortie (aux tarifs de Claude Opus 5 : $0.625 de tokens plus $0.08 de temps d'exécution). Aux tarifs du 12 octobre 2026, le même cas coûte $0.58 sur Opus 5.5, $0.33 sur Sonnet 5.5, $0.205 sur Haiku 4.5 et environ $0.09 sur Haiku 5.5. Le temps d'exécution seul, à 8 heures de running par jour, revient à $19.20 par mois (8 × 30 × $0.08). Les tokens utilisent les tarifs standard des modèles avec mise en cache des prompts.

Q. Tout le monde peut-il l'utiliser ?
A. C'est une bêta publique depuis le 8 avril 2026, activée par défaut pour tous les comptes API, accessible via Claude Console / Platform CLI / Claude Code. Mais comme elle est stateful par conception, elle est non éligible au Zero Data Retention (ZDR) ni à un HIPAA BAA. Notez aussi que les fonctionnalités varient selon leur stade — le dreaming est une préversion de recherche nécessitant une demande d'accès (consultez la documentation officielle pour les informations les plus récentes).