Claude Managed Agents : guide complet (2026)

Claude Managed Agents est le service d’infrastructure lancé par Anthropic le 8 avril 2026 pour exécuter des agents IA autonomes en production. Au lieu de construire votre propre boucle d’agent, sandbox et couche d’exécution, vous obtenez un environnement cloud managé où Claude peut lire des fichiers, exécuter des commandes, naviguer sur le web et produire du code de manière sécurisée.

J’ai testé le service dès la première semaine de la bêta. Ce guide couvre l’architecture, le pricing, les outils disponibles et les étapes concrètes pour créer votre premier agent via l’API. Il intègre les quatre fonctionnalités passées en bêta publique entre avril et mai 2026 — mémoire persistante inter-sessions, webhooks lifecycle, orchestration multiagent et self-hosted sandboxes — ainsi que Dreaming et Outcomes, la couche d’auto-amélioration ouverte en research preview le 6 mai 2026.

Ce que Managed Agents change pour les développeurs

Managed Agents résout un problème récurrent : le décalage entre un prototype d’agent fonctionnel et un déploiement fiable en production. Anthropic prend en charge le sandboxing, la gestion d’état, l’orchestration des outils et la récupération après erreur.

En tests internes, Anthropic rapporte une amélioration de 10 points du taux de réussite des tâches sur la génération de fichiers structurés, avec les gains les plus nets sur les problèmes complexes. Les retours de la communauté confirment un onboarding en 45 minutes contre 3 jours pour une solution auto-hébergée équivalente. L’annonce a généré plus de 2 millions de vues et 39 000 likes en moins de deux heures.

Le service est en concurrence directe avec AWS Bedrock Agents et Google Vertex AI Agents. Anthropic revendique un avantage sur la qualité du modèle et l’expérience développeur.

Architecture brain/hands : le TTFT baisse de 60 % au p50 et de 90 % au p95.

Architecture : la séparation brain/hands

L’architecture de Managed Agents repose sur un principe central documenté par l’équipe engineering d’Anthropic : découpler le cerveau (raisonnement) des mains (exécution).

Le Brain correspond à Claude et son harness d’orchestration. Il décide quel outil appeler, dans quel ordre, et interprète les résultats. Le harness est stateless : il démarre sans attendre le provisionnement d’un conteneur.

Les Hands désignent les environnements d’exécution sandboxés. Chaque sandbox est un conteneur provisionné à la demande via des appels d’outils. L’interface unifiée execute(name, input) -> string permet au brain d’interagir avec n’importe quel type d’environnement : conteneur cloud, téléphone ou même un émulateur.

La Session fonctionne comme un journal d’événements durable et append-only, externe à la fenêtre de contexte de Claude. Trois opérations la définissent : getEvents() pour récupérer le contexte, emitEvent() pour enregistrer les événements, et wake() pour restaurer l’état après une panne.

En pratique, cette séparation a un impact direct sur les performances : le temps d’obtention du premier token (TTFT) a baissé d’environ 60 % au p50 et de plus de 90 % au p95, car l’inférence n’attend plus la mise en place du conteneur.

Les quatre concepts fondamentaux

Managed Agents s’articule autour de quatre abstractions que vous manipulez via l’API.

Vous créez un Agent et un Environment une seule fois, puis vous les référencez par ID pour chaque nouvelle Session. Les Events transitent en temps réel via Server-Sent Events (SSE).

Outils intégrés et outils custom

Le toolset agent_toolset_20260401 donne accès à 8 outils activés par défaut.

Vous pouvez désactiver des outils individuellement via le champ configs, ou activer uniquement ceux dont vous avez besoin en définissant default_config.enabled: false. Si vous avez besoin de fonctionnalités non couvertes par ces outils, les outils custom permettent de définir votre propre schéma d’entrée/sortie : Claude émet une requête structurée, votre code exécute l’opération côté client, et le résultat revient dans la conversation.

La connexion à des serveurs MCP (Model Context Protocol) est aussi supportée, ce qui ouvre l’intégration avec des outils tiers comme Slack, GitHub ou des bases de données internes. J’ai déjà décrit le fonctionnement de MCP dans mon guide Claude Code.

Pricing : 0,08 $ par heure de session

Le modèle tarifaire de Managed Agents combine deux composantes.

Quelques repères concrets pour estimer vos coûts :

• Tâche ponctuelle de 30 minutes avec Sonnet 4.6 : environ 0,04 $ de runtime + coût tokens
• Agent actif 24h/24, 7j/7 : environ 58 $/mois en runtime seul, avant tokens
• Usage typique en production : la plupart des agents sont dormants entre les déclenchements et coûtent bien moins que le scénario 24/7

Ce pricing reste compétitif face aux solutions auto-hébergées qui nécessitent la gestion de conteneurs, de Redis pour l’état persistant et de WebSockets pour le streaming. Ces coûts d’infrastructure et de maintenance sont souvent sous-estimés.

Les 4 étapes pour lancer un agent : Agent et Environment sont réutilisables entre les sessions.

Premiers pas : créer un agent en 4 étapes

Toutes les requêtes Managed Agents nécessitent le header anthropic-beta: managed-agents-2026-04-01. Les SDK officiels (Python, TypeScript, Go, Java, C#, Ruby, PHP) ajoutent ce header automatiquement via le namespace client.beta.

Étape 1 - Créer un Agent

Définissez le modèle, le system prompt et les outils disponibles.

from anthropic import Anthropic

client = Anthropic()

agent = client.beta.agents.create(
    name="Coding Assistant",
    model="claude-sonnet-4-6",
    system="You are a helpful coding assistant.",
    tools=[
        {"type": "agent_toolset_20260401"},
    ],
)

Le type agent_toolset_20260401 active les 8 outils intégrés. Conservez l’agent.id retourné : il sera référencé dans chaque session.

Étape 2 - Créer un Environment

L’environnement définit le conteneur cloud où l’agent s’exécute.

environment = client.beta.environments.create(
    name="production-env",
    config={
        "type": "cloud",
        "networking": {"type": "unrestricted"},
    },
)

Vous pouvez configurer les packages préinstallés (Python, Node.js, Go), les règles d’accès réseau et les fichiers montés. Conservez l’environment.id.

Étape 3 - Démarrer une Session

Lancez une session en référençant votre Agent et votre Environment.

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    title="Ma première session",
)

Étape 4 - Envoyer un message et streamer la réponse

Ouvrez un stream SSE, envoyez un événement utilisateur, puis traitez les événements au fil de l’eau.

with client.beta.sessions.events.stream(session.id) as stream:
    client.beta.sessions.events.send(
        session.id,
        events=[{
            "type": "user.message",
            "content": [{
                "type": "text",
                "text": "Crée un script Python qui génère les 20 premiers nombres de Fibonacci.",
            }],
        }],
    )

    for event in stream:
        match event.type:
            case "agent.message":
                for block in event.content:
                    print(block.text, end="")
            case "agent.tool_use":
                print(f"\n[Outil : {event.name}]")
            case "session.status_idle":
                print("\nAgent terminé.")
                break

L’agent provisionne le conteneur, exécute les outils nécessaires et streame les résultats en temps réel. L’événement session.status_idle signale la fin du traitement.

Sécurité et isolation des credentials

La séparation brain/hands n’est pas qu’une optimisation de performance : c’est le socle du modèle de sécurité.

Tokens Git : les credentials d’accès aux dépôts sont injectés lors de l’initialisation du sandbox via les remotes locaux. L’agent n’y a jamais accès directement.

Tokens OAuth : ils sont stockés dans un vault chiffré externe au sandbox. Un proxy dédié, avec des tokens scopés à la session, récupère les credentials avant chaque appel API externe.

Outils MCP : l’accès passe par un proxy dédié qui gère l’authentification de manière transparente pour l’agent.

Cette isolation structurelle signifie qu’une attaque par injection de prompt ne peut pas extraire les credentials d’authentification, même si elle parvient à manipuler le comportement de l’agent dans le sandbox.

Managed Agents : déploiement en 30 minutes contre 1 à 2 semaines en auto-hébergé, à 0,08 $/h.

Managed Agents vs solution auto-hébergée

Le choix entre Managed Agents et une infrastructure agent personnalisée dépend de vos contraintes.

Les cloud sandboxes conviennent aux équipes qui veulent passer du prototype à la production rapidement, sans expertise DevOps dédiée. Les self-hosted sandboxes sont le bon compromis pour les organisations qui ont des exigences de conformité sur l’exécution mais veulent garder l’orchestration et la qualité du modèle Anthropic. L’auto-hébergement complet reste pertinent pour les architectures multi-modèle ou les contraintes réglementaires les plus strictes.

Cas d’usage en production

Les premiers adopteurs confirmés au lancement montrent que les cas d’usage sont variés.

Notion utilise Managed Agents pour déléguer des tâches de codage, de création de slides et de tableurs à Claude, avec des dizaines de tâches parallèles exécutées simultanément dans le workspace.

Rakuten déploie des agents spécialisés par département (produit, ventes, marketing, finance, RH) avec intégration Slack et Teams.

Asana construit des AI Teammates qui prennent en charge les tâches assignées directement dans les projets, aux côtés des collaborateurs humains.

Sentry automatise le cycle complet de la détection de bug jusqu’au patch sous forme de pull request, dans un seul workflow agent.

Vibecode utilise le service pour passer du prompt à l’application déployée, un déploiement 10 fois plus rapide qu’avec une infrastructure classique.

Mémoire persistante inter-sessions

La mémoire persistante est passée en bêta publique le 23 avril 2026. Elle permet à un agent de retenir des préférences, des conventions de projet ou du contexte métier entre différentes sessions.

Le mécanisme repose sur les memory stores : des collections de documents texte scopées à un workspace. Chaque store est monté comme un répertoire sous /mnt/memory/ dans le sandbox. L’agent y lit et écrit avec les outils standard du toolset, comme n’importe quel fichier. Un résumé de chaque mount (chemin, mode d’accès, description du store) est automatiquement ajouté au system prompt.

# Créer un memory store
store = client.beta.memory_stores.create(
    name="User Preferences",
    description="Per-user preferences and project context.",
)

# Attacher le store à une session
session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    resources=[
        {
            "type": "memory_store",
            "memory_store_id": store.id,
            "access": "read_write",
            "instructions": "Check before starting any task.",
        }
    ],
)

Quelques repères pour calibrer votre usage :

• Limite par session : 8 memory stores maximum
• Limite par store : 2 000 mémoires, chacune plafonnée à 100 ko (~25 000 tokens)
• Audit trail : chaque écriture crée une memory version immuable, conservée 30 jours, avec possibilité de redact pour les données sensibles
• Accès : read_write par défaut — passez read_only pour les données de référence partagées, surtout si l’agent traite des entrées utilisateur non filtrées

C’est un mécanisme complémentaire à la mémoire conversationnelle de Claude que j’ai détaillé dans un article dédié : les memory stores persistent les connaissances structurées entre sessions, là où la mémoire conversationnelle gère le fil d’une discussion.

Dreaming : des agents qui apprennent de leurs sessions passées

Dreaming est ouvert en research preview depuis le 6 mai 2026. C’est la couche d’auto-amélioration qui complète la mémoire passive décrite plus haut : là où les memory stores accumulent des écritures locales et incrémentales, Dreaming relit les sessions terminées et restructure cette mémoire entre les runs.

Le problème est concret. Au fil des sessions, un memory store accumule des doublons, des entrées contradictoires et des informations périmées. La mémoire passive n’a pas de mécanisme pour se nettoyer elle-même. C’est exactement ce que Dreaming corrige.

Comment fonctionne un dream

Un dream est un job asynchrone qui prend deux types d’entrées : un memory store pré-existant que Claude vérifie et réorganise, et 1 à 100 sessions passées dont il extrait les patterns. Le résultat n’écrase jamais l’entrée : Claude produit un nouveau memory store séparé, dans lequel les doublons sont fusionnés, les entrées périmées remplacées par la dernière valeur connue, et de nouveaux enseignements ajoutés.

Concrètement, Dreaming fait remonter trois types de signal : les erreurs récurrentes, les workflows qui convergent vers une même méthode, et les préférences d’équipe. Pour un agent de codage, cela peut être un contournement spécifique à un format de fichier ou un pattern propre à un outil — des apprentissages qui survivent désormais d’une session à l’autre.

dream = client.beta.dreams.create(
    inputs=[
        {"type": "memory_store", "memory_store_id": store_id},
        {"type": "sessions", "session_ids": [session_a, session_b]},
    ],
    model="claude-opus-4-8",
    instructions="Focus on coding-style preferences; ignore one-off debugging notes.",
)

Le champ instructions (4 096 caractères max) sert à orienter la synthèse : sur quoi se concentrer, quoi préserver, quelles conventions de sortie appliquer. C’est de la consigne haut niveau, pas un éditeur ligne par ligne — pour des corrections ciblées, passez par l’API Memory Stores directement sur le store de sortie.

Mode automatique ou revue manuelle

Comme l’input store n’est jamais modifié, deux usages cohabitent. Vous pouvez revoir le résultat avant de l’appliquer : inspectez le store de sortie via la Console ou l’API Memory Stores, puis attachez-le aux sessions suivantes si la curation vous convient, ou supprimez-le sinon. Ou vous pouvez automatiser la boucle : planifier un dream récurrent et brancher le store de sortie sur les prochaines sessions sans intervention humaine, ce qui rapproche cette mécanique des routines programmées de Claude Code.

Quelques repères pour cadrer l’usage :

• Sessions par dream : 1 à 100
• Modèles supportés en research preview : claude-opus-4-8, claude-opus-4-7, claude-sonnet-4-6
• Durée : de quelques minutes à quelques dizaines de minutes selon la taille des entrées
• Header bêta : dreaming-2026-04-21 en plus du header Managed Agents standard (les SDK l’ajoutent automatiquement)
• Facturation : tarifs tokens API standard du modèle choisi, coût croissant linéairement avec le nombre et la longueur des sessions

La preuve la plus parlante vient de Harvey : en tests, l’éditeur a multiplié par environ 6 ses taux de complétion après avoir activé Dreaming, ses agents retenant entre les sessions les contournements de format et les patterns spécifiques aux outils.

Outcomes : valider la qualité en temps réel

Dreaming a un pendant logique : Outcomes, ouvert lui aussi en research preview le 6 mai 2026. Vous définissez une rubrique de succès, l’agent travaille pour la satisfaire, et un grader séparé évalue la qualité de la sortie. En tests, Outcomes améliore le taux de réussite des tâches jusqu’à 10 points par rapport au prompting standard, avec des gains nets sur la génération de fichiers : +8,4 % sur les fichiers docx et +10,1 % sur les pptx.

Les deux mécanismes forment un système d’amélioration cohérent : la mémoire capture les apprentissages pendant le travail, Dreaming les raffine entre les sessions, et Outcomes garantit que l’agent se corrige face à un standard défini. C’est particulièrement utile pour les workflows longue durée et les systèmes multiagent, où la dérive de la mémoire coûte cher.

Webhooks : notifications de lifecycle

Les webhooks sont disponibles en bêta publique depuis le 6 mai 2026. Ils permettent de recevoir des notifications sur les changements d’état majeurs sans maintenir un polling SSE actif.

Événements supportés

Deux catégories d’événements sont disponibles.

Événements Session :

Événements Vault : vault.created, vault.archived, vault.deleted, vault_credential.created, vault_credential.archived, vault_credential.deleted, vault_credential.refresh_failed.

Configuration et vérification de signature

Les endpoints se configurent dans la Console sous Manage > Webhooks. Chaque endpoint reçoit une clé de signature préfixée whsec_, à stocker dans la variable d’environnement ANTHROPIC_WEBHOOK_SIGNING_KEY.

from flask import Flask, request
import anthropic

client = anthropic.Anthropic()
app = Flask(__name__)

@app.route("/webhook", methods=["POST"])
def webhook():
    try:
        # unwrap() lève une exception si la signature est invalide
        # ou si le payload a plus de 5 minutes
        event = client.beta.webhooks.unwrap(
            request.get_data(as_text=True),
            headers=dict(request.headers),
        )
    except Exception:
        return "invalid signature", 400

    if event.data.type == "session.status_idled":
        session = client.beta.sessions.retrieve(event.data.id)
        # traiter la session...

    return "", 200

Note importante : le payload webhook ne contient que le type et l’identifiant de l’objet, pas l’objet complet. Après réception, faites un appel GET pour récupérer l’état frais. Un endpoint est désactivé automatiquement après environ 20 échecs consécutifs.

Orchestration multiagent

L’orchestration multiagent est disponible en bêta publique depuis le 6 mai 2026. Un agent coordinateur peut déléguer des tâches à plusieurs sous-agents qui s’exécutent en parallèle dans leurs propres threads contextuellement isolés.

Principe de fonctionnement

Tous les agents partagent le même sandbox et les mêmes credentials vault, mais chaque agent tourne dans son propre session thread avec son propre historique de conversation. Le coordinateur opère dans le thread primaire ; les threads supplémentaires sont créés à l’exécution quand le coordinateur délègue.

Les patterns qui fonctionnent le mieux :

• Parallélisation : distribuer des sous-tâches indépendantes (recherche multi-sources, analyse de fichiers séparés) et synthétiser les résultats
• Spécialisation : router vers des agents avec des system prompts et outils dédiés (agent sécurité, agent documentation)
• Escalade : consulter un modèle plus puissant pour un sous-ensemble de tâches complexes

Configuration du coordinateur

coordinator = client.beta.agents.create(
    name="Engineering Lead",
    model="claude-opus-4-8",
    system="Coordinate engineering work. Delegate code review to the reviewer agent.",
    tools=[{"type": "agent_toolset_20260401"}],
    multiagent={
        "type": "coordinator",
        "agents": [
            {"type": "agent", "id": reviewer_agent.id},
            {"type": "agent", "id": test_writer_agent.id},
        ],
    },
)

Le roster du coordinateur est snapshotté à la création. Les agents référencés restent épinglés à la version résolue à ce moment-là — pour déléguer à une version plus récente, mettez à jour le coordinateur explicitement.

Limites à connaître : maximum 25 threads concurrents, 20 agents uniques dans le roster. Le coordinateur ne peut déléguer qu’à un seul niveau (pas de sous-coordinateurs).

Self-hosted sandboxes

Les self-hosted sandboxes sont disponibles en bêta publique depuis le 29 mai 2026. Ils permettent de garder l’exécution des outils dans votre propre infrastructure tout en laissant l’orchestration chez Anthropic.

Cloud vs self-hosted

C’est la bonne option quand l’agent doit opérer sur des données qui ne peuvent pas quitter votre périmètre réseau, accéder à des services internes non routables publiquement, ou fonctionner sous vos propres contrôles de conformité et d’audit.

Démarrer un worker

Créez un environnement self-hosted via l’API ou la Console, générez une clé d’environnement (sk-ant-oat01-...), puis lancez le worker sur votre hôte :

import asyncio
import os
from anthropic import AsyncAnthropic
from anthropic.lib.environments import EnvironmentWorker

async def main() -> None:
    async with AsyncAnthropic(
        auth_token=os.environ["ANTHROPIC_ENVIRONMENT_KEY"]
    ) as client:
        await EnvironmentWorker(
            client,
            environment_id=os.environ["ANTHROPIC_ENVIRONMENT_ID"],
            environment_key=os.environ["ANTHROPIC_ENVIRONMENT_KEY"],
            workdir="/workspace",
        ).run()

asyncio.run(main())

Le worker gère le polling, le téléchargement des skills et l’exécution des tool calls. Il s’arrête proprement sur SIGTERM en attendant la fin des appels en cours.

Note : la mémoire persistante n’est pas encore supportée avec les self-hosted sandboxes. Sur Claude Platform on AWS, l’endpoint de liste des work items (GET /v1/environments/{id}/work) n’est pas disponible ; les autres endpoints work (poll, ack, heartbeat, stop, résultats) fonctionnent normalement.

Disponibilité sur Claude Platform on AWS

Depuis le 11 mai 2026, Managed Agents est disponible sur Claude Platform on AWS. Cette intégration donne accès à l’ensemble des fonctionnalités de la plateforme Anthropic — y compris Managed Agents, les Messages API et les fonctionnalités bêta — via votre compte AWS.

La différence principale avec Amazon Bedrock : l’infrastructure d’inférence est opérée par Anthropic, pas par AWS. AWS fournit la couche d’authentification (SigV4 ou clé API), le contrôle d’accès IAM et la facturation via AWS Marketplace.

Pour les self-hosted sandboxes sur cette plateforme, le worker s’authentifie avec AWS IAM (SigV4) en attachant la managed policy AnthropicSelfHostedEnvironmentAccess à l’identité IAM du worker — les clés d’environnement générées dans la Console Claude ne fonctionnent pas avec cet endpoint.

Limites et points de vigilance

Managed Agents est en bêta publique. Voici les contraintes que j’ai identifiées et qui méritent votre attention avant un déploiement en production.

Rate limits : 60 requêtes par minute pour les endpoints de création, 600 par minute pour les endpoints de lecture. Les limites de dépenses et les rate limits par tier de votre organisation s’appliquent aussi.

Vendor lock-in : le service est exclusivement lié à Anthropic. Si votre architecture requiert du multi-modèle, comme Claude face à ChatGPT ou Gemini, Managed Agents ne couvre pas ce besoin.

Conformité : les environnements cloud ne proposent pas encore de VPC peering ni d’endpoints privés. Si votre entreprise exige l’isolation des données on-premise, les self-hosted sandboxes sont la voie à suivre. La Zero Data Retention (ZDR) est disponible sur demande via votre représentant Anthropic.

Memory stores et prompt injection : les stores en mode read_write acceptent les écritures de l’agent. Si celui-ci traite des entrées non filtrées (prompts utilisateur, contenu web tiers), une injection de prompt réussie pourrait corrompre la mémoire. Utilisez read_only pour les données de référence.

Mémoire et self-hosted sandboxes : la mémoire persistante n’est pas encore compatible avec les environnements self-hosted.

Coûts sur les tâches longues : le runtime à 0,08 $/h est négligeable pour des tâches ponctuelles, mais peut devenir significatif pour des workflows de 4 à 8 heures. Plusieurs retours de la communauté soulèvent ce point.

Bonnes pratiques pour vos premiers agents

Voici les pratiques qui m’ont le plus aidé lors de mes tests, complétées par les recommandations de la documentation officielle.

Rédigez des descriptions d’outils détaillées. C’est le facteur qui impacte le plus la performance de l’agent. Visez 3 à 4 phrases par description d’outil custom, en expliquant quand l’utiliser et quand l’éviter.

Consolidez les opérations liées. Plutôt que de créer create_pr, review_pr et merge_pr séparément, regroupez-les dans un seul outil avec un paramètre action. Moins d’outils signifie moins d’ambiguïté de sélection.

Utilisez le prompt engineering structuré pour vos system prompts d’agents. Les balises XML et le contract-style prompting améliorent la fiabilité des agents sur les tâches multi-étapes.

Commencez avec Sonnet 4.6. Son rapport performance/coût convient à 80 % des cas d’usage agents. Réservez Opus 4.8 aux tâches nécessitant un raisonnement profond ou une coordination multi-fichiers complexe — c’est le modèle par défaut pour les coordinateurs multiagent dans les exemples officiels depuis mai 2026.

Restreignez les outils au strict nécessaire. Désactivez web_fetch et web_search si votre agent n’en a pas besoin. Moins d’outils disponibles signifie des décisions plus rapides et un comportement plus prévisible.