Claude Managed Agents vs Claude Agent SDK

La semaine dernière, j’avais trois onglets ouverts : la documentation Managed Agents, le guide de démarrage rapide de l’Agent SDK, et la référence de l’API Messages. J’essayais de déterminer quelle voie utiliser pour un pipeline de traitement de documents asynchrone. Quarante minutes plus tard, j’ai réalisé que la confusion ne portait pas sur les fonctionnalités. Elle portait sur qui possède le runtime.

C’est le cœur de cette décision. Pas laquelle est « meilleure ». Quelle frontière d’infrastructure est logique pour ce que vous construisez en ce moment. Cet article documente comment les deux voies se comparent — et pourquoi une troisième option existe que la plupart des articles de comparaison ignorent.

Deux voies vers les agents propulsés par Claude

Agent SDK : vous possédez la boucle, vous gérez le runtime

Le Claude Agent SDK — renommé depuis le Claude Code SDK plus tôt cette année — vous donne les mêmes outils, la même boucle d’agent et la même gestion du contexte qui alimentent Claude Code, packagés sous forme de bibliothèque Python ou TypeScript. Vous l’installez, vous l’exécutez sur votre infrastructure, et vous gérez vous-même la mise à l’échelle, le sandboxing et l’orchestration.

Le SDK intègre automatiquement le Claude Code CLI. Votre agent accède aux opérations de fichiers, aux commandes bash, à la navigation web, à l’exécution de code — la boîte à outils complète de Claude Code — dès le départ. Vous définissez quels outils sont autorisés, configurez les modes de permission et implémentez des outils personnalisés en tant que serveurs MCP en cours de processus.

Ce que vous obtenez : un contrôle total sur l’environnement d’exécution. Ce que vous obtenez aussi : la responsabilité de maintenir cet environnement opérationnel, sécurisé et observable.

Managed Agents : Anthropic gère le harnais, vous définissez la tâche

Claude Managed Agents, lancé en version bêta publique le 8 avril 2026, inverse le modèle de propriété. Vous spécifiez l’agent — modèle, prompt système, outils, serveurs MCP, garde-fous — et Anthropic l’exécute. Le harnais gère l’exécution des outils, le sandboxing, la persistance des sessions, la compaction du contexte, la mise en cache des prompts et la récupération après crash.

L’équipe d’ingénierie d’Anthropic le décrit comme un « méta-harnais » — conçu pour accueillir les futurs harnais à mesure que les modèles s’améliorent plutôt que d’encoder des hypothèses fixes sur ce que Claude peut ou ne peut pas faire. Si un conteneur plante, la session survit. Un nouveau conteneur reprend à partir du journal de session.

Vous configurez, Anthropic opère.

Aucune n’est universellement meilleure

Le chevauchement des fonctionnalités est élevé. Les deux donnent à Claude accès à l’exécution de code, à la manipulation de fichiers, à bash, à la navigation web et aux intégrations MCP. La différence est opérationnelle : qui provisionne l’environnement, qui gère les pannes, qui met à l’échelle les conteneurs. C’est une décision d’infrastructure, pas une décision de fonctionnalités.

Comparaison fondamentale

Un point à noter sur la facturation : l’Agent SDK n’introduit pas de frais de runtime de session. Mais le qualifier de « moins cher » sans nuance est trompeur. Votre runtime auto-hébergé a de véritables coûts — serveurs, orchestration de conteneurs, surveillance, réponse aux incidents, les heures d’ingénierie pour maintenir tout cela. Les structures de coûts sont différentes, pas simplement ordonnées.

Quand choisir Managed Agents

Tâches longues ou asynchrones où la persistance des sessions est importante

Si votre agent s’exécute pendant 30 minutes à plusieurs heures — traitement de documents, recherche, exécution de workflows en plusieurs étapes — vous avez besoin d’un état de session qui survive aux déconnexions et aux pannes de conteneurs. Managed Agents stocke l’historique complet des événements côté serveur et le rend récupérable via API. Construire une durabilité équivalente vous-même est faisable. C’est aussi plusieurs semaines d’ingénierie qui n’appartiennent pas à votre produit principal.

Équipes sans capacité infra pour construire des sandboxes sécurisés

Le sandboxing de niveau production — isolation, gestion des identifiants, permissions délimitées, traçage d’exécution — est véritablement difficile. La plupart des équipes le sous-estiment. Si votre équipe n’a pas la capacité DevOps pour construire et maintenir un environnement d’exécution d’agents sécurisé, Managed Agents supprime toute cette surface de votre feuille de route.

Prototype vers production rapide : des jours plutôt que des mois

Le titre d’Anthropic est « atteindre la production 10 fois plus vite ». Je n’ai pas vérifié ce chiffre dans suffisamment de scénarios pour l’approuver. Mais la direction est précise : l’écart entre « l’agent fonctionne en test local » et « l’agent fonctionne de manière fiable en production » est important, et Managed Agents le réduit. Rakuten aurait déployé des agents spécialistes en moins d’une semaine chacun.

Quand la compaction et la mise en cache intégrées comptent plus que le contrôle personnalisé

Managed Agents gère automatiquement la mise en cache des prompts et la compaction du contexte. Si vous avez construit votre propre gestion du contexte pour des agents à longue durée d’exécution, vous savez combien d’essais et d’erreurs cela implique. L’approche intégrée ne sera pas optimale pour chaque charge de travail. Pour la plupart, c’est suffisant — et elle est disponible dès le premier jour.

Quand choisir Agent SDK

Logique d’orchestration personnalisée que Managed Agents n’expose pas

Le SDK vous donne des hooks, des outils personnalisés en tant que serveurs MCP en cours de processus, des callbacks de permission granulaires et un contrôle total sur la boucle d’agent. Si votre agent a besoin de stratégies de nouvelle tentative personnalisées, de routage conditionnel des outils ou de modification dynamique des prompts en cours de session — une logique que la surface de configuration de Managed Agents n’expose pas — vous avez besoin du SDK.

Intégrations d’outils spécialisés ou environnements d’exécution personnalisés

Si votre agent doit s’exécuter dans un environnement spécifique — accès à un GPU, un pilote de base de données particulier, une bibliothèque propriétaire — le SDK vous permet de contrôler complètement l’environnement d’exécution. Managed Agents vous donne un conteneur cloud avec des packages préinstallés. C’est suffisant pour la plupart des cas. Pas tous.

Exigences sur site ou en cloud privé

Managed Agents s’exécute exclusivement sur l’infrastructure d’Anthropic. Il n’y a pas d’option sur site, pas de déploiement sur votre propre cloud. Pour les organisations ayant des exigences strictes en matière de souveraineté des données ou des contraintes réglementaires qui interdisent l’envoi de données à une infrastructure tierce, le SDK est la seule voie. C’est une contrainte ferme, pas une préférence.

Structure des coûts à grande échelle

Les $0,08/heure de session sont négligeables pour la plupart des charges de travail — un agent 24/7 coûte environ $58/mois en runtime avant les tokens. Mais pour de grandes flottes d’agents à longue durée d’exécution concurrents, les frais de session s’accumulent. Une flotte de 500 agents s’exécutant simultanément génère $40/heure en frais de session seuls.

L’Agent SDK n’a pas cette surtaxe par session. Vos coûts sont les tokens plus ce que votre infrastructure vous coûte. À volume élevé, posséder le runtime peut être moins cher en termes marginaux — mais seulement si vous avez déjà absorbé le coût fixe de sa construction et de sa maintenance.

La troisième option : l’API Messages

Quand ni le SDK ni Managed Agents n’est nécessaire

C’est l’option que la plupart des articles de comparaison ignorent, et c’est la bonne réponse plus souvent que les gens ne le pensent.

L’API Messages vous donne un accès direct au modèle. Vous envoyez un prompt, vous obtenez une réponse. Pas de harnais, pas de boucle d’agent, pas de runtime géré. Vous construisez tout vous-même — y compris la boucle d’exécution des outils, si vous en avez besoin.

Schémas d’utilisation d’outils simples qui ne nécessitent pas un framework d’agent complet

Si votre cas d’usage est : appeler Claude, éventuellement le laisser utiliser un ou deux outils, retourner un résultat — vous n’avez pas du tout besoin d’un framework d’agent. L’API Messages avec l’utilisation d’outils gère cela proprement. Ajouter l’Agent SDK ou Managed Agents introduit une complexité qui ne se rentabilise pas dans des schémas simples de requête-réponse.

Les SDK clients Python et TypeScript d’Anthropic prennent en charge l’utilisation d’outils nativement. Vous implémentez vous-même la boucle d’outils — une boucle while qui vérifie stop_reason, exécute les outils, renvoie les résultats. Pour de nombreuses charges de travail en production, c’est tout ce dont vous avez besoin.

J’ai vu des équipes se tourner vers des frameworks d’agents alors qu’une boucle d’outils de 20 lignes aurait suffi. Vérifiez si votre tâche nécessite réellement de l’autonomie ou de la persistance de session avant de choisir une abstraction plus lourde.

Considérations de migration

Partir de Managed Agents, passer au SDK : ce qui change

La logique de l’agent — prompt système, définitions d’outils, structure des tâches — se transfère directement. Ce qui ne se transfère pas : la persistance des sessions, le sandboxing, la gestion du contexte et la récupération après crash. Vous devrez construire tout cela.

Passer de Managed Agents au SDK signifie passer de « Anthropic opère » à « vous opérez ». La capacité est équivalente. La charge opérationnelle se déplace entièrement vers votre équipe.

Partir du SDK, passer à Managed Agents : ce qui change

Plus facile à certains égards, plus difficile à d’autres. La logique principale de votre agent se porte. Les outils personnalisés implémentés en tant que serveurs MCP en cours de processus peuvent nécessiter d’être ré-exposés en tant que serveurs MCP distants. Les hooks personnalisés et les callbacks de permission doivent correspondre au modèle de configuration de Managed Agents.

Le gain : vous arrêtez de maintenir le runtime. Le coût : vous perdez le contrôle fin sur l’environnement d’exécution. Si ce compromis fonctionne dépend de la quantité de votre infrastructure personnalisée qui était réellement nécessaire par rapport à ce qui a été hérité des premières décisions de prototypage.

Il n’existe pas de guide de migration officiel entre les deux à partir d’avril 2026. Prévoyez des tests d’intégration, pas seulement du portage de code.

FAQ

Puis-je utiliser les deux dans le même produit ?

Oui. Le SDK et Managed Agents répondent à des besoins opérationnels différents. Un schéma courant : Agent SDK pour les interactions orientées utilisateur, sensibles à la latence, où vous avez besoin d’un contrôle total ; Managed Agents pour les tâches en arrière-plan, asynchrones, où la persistance des sessions et le fonctionnement sans intervention comptent davantage. Ils partagent les mêmes modèles Claude sous-jacents et la même structure de tarification pour les coûts de tokens.

Managed Agents me lie-t-il à l’infrastructure d’Anthropic ?

Oui. Le runtime est conçu spécifiquement pour Claude. Il ne fera pas tourner GPT, Gemini ou des modèles open source. La logique de votre agent — prompts, définitions d’outils, structure des tâches — est portable. Le runtime et le format de session ne le sont pas. Le SDK vous offre plus de flexibilité pour abstraire la couche modèle, bien qu’il soit également spécifique à Claude.

Lequel gère mieux les erreurs et les nouvelles tentatives ?

Managed Agents dispose d’une récupération après crash intégrée — le journal de session persiste, un nouveau conteneur reprend là où le précédent a échoué. Avec le SDK, vous construisez votre propre gestion des erreurs. Si vous avez déjà fait cela et avez de bons schémas, la gestion des erreurs du SDK peut être plus précisément adaptée à vos besoins. Sinon, les valeurs par défaut de Managed Agents constituent un bon point de départ.

Puis-je migrer un agent SDK existant vers Managed Agents ?

La logique principale de l’agent se transfère. Le prompt système, les définitions d’outils et la structure des tâches sont compatibles. Ce qui nécessite une refonte : les hooks personnalisés, les serveurs MCP en cours de processus (peuvent nécessiter des équivalents distants), la logique de permission personnalisée et tout ce qui dépend de votre environnement d’exécution spécifique. Aucun outil de migration officiel n’existe encore.

Lequel est plus rentable à volume élevé ?

Cela dépend de ce que vous comptez. Managed Agents ajoute $0,08/heure de session en plus des tokens. Le SDK n’ajoute aucune surtaxe par session — mais votre runtime auto-hébergé a sa propre ligne de coût : serveurs, orchestration, surveillance, maintenance d’ingénierie. À volume faible à modéré, Managed Agents est généralement moins cher en coût total de possession. À très volume élevé avec de nombreuses sessions longues concurrentes, le calcul peut s’inverser — mais seulement si vous avez déjà investi dans l’infrastructure.

C’est la comparaison. L’arbre de décision : besoin de contrôle de l’infrastructure ou impossibilité d’envoyer des données hors site → SDK. Vous voulez éviter l’infrastructure → Managed Agents. Pas besoin d’une boucle d’agent du tout → API Messages.

Lancez un pilote sur les deux si vous n’êtes pas sûr. Le coût de changement est plus faible au stade du prototype qu’après vous être engagé dans une architecture de déploiement.

Suite la semaine prochaine — je teste encore les schémas multi-agents sur Managed Agents.

Articles précédents :