AWS lance AgentCore Runtime Instances — le compute persistant élimine le cold start des agents IA en production
Présenté au **AWS Summit New York** le **7 août 2026**, **AgentCore Runtime Instances** apporte un compute stateful et persistant aux agents **Bedrock**, supprimant le *cold start* qui pénalisait les déploiements temps réel. Si vos agents IA mettent plus de trois secondes à répondre, le problème vient probablement de votre infrastructure — et AWS vient de le résoudre.
7 août 2026, New York. Au AWS Summit, Amazon Bedrock AgentCore franchit un cap structurel. Jusqu’ici, chaque invocation d’un agent IA sur Bedrock passait par un cycle cold start : initialisation du modèle, rechargement du contexte, reconnexion aux outils. Résultat : une latence médiane de 2 à 8 secondes avant la première réponse utile, inacceptable pour un chatbot orienté client ou un agent de supervision en usine.
Runtime Instances change la donne. Le service maintient désormais une instance de compute stateful et persistante — chaude, prête à exécuter — entre deux appels. AWS annonce une latence first-token sous la seconde.
Ce que Runtime Instances résout concrètement
Le problème du cold start n’est pas nouveau. AWS Lambda l’a subi pendant des années avant l’introduction du Provisioned Concurrency en 2019. Cloudflare Workers a fait de l’élimination du cold start son argument commercial principal. Mais pour les agents IA, le cold start est plus douloureux : il ne s’agit pas seulement de charger un runtime, mais de reconstruire un état conversationnel, de réindexer des outils, et parfois de recharger des embeddings vectoriels.
Runtime Instances conserve tout cela en mémoire entre les appels :
- État de session persistant. Les conversations, les variables d’agent et les connexions aux outils survivent aux intervalles d’inactivité.
- Pas de rechargement du modèle. L’instance reste chaude, le modèle en mémoire — gain estimé de 60 à 80 % sur le temps jusqu’au premier token.
- Intégration native avec AgentCore. Pas de nouvelle API à apprendre ; une case à cocher dans la console ou un flag
runtimeInstancedans la définition CloudFormation/CDK. - Facturation à la seconde. L’instance est facturée tant qu’elle est provisionnée, avec une remise de 30 % par rapport au on-demand pour les réservations mensuelles.
Matt Wood, VP AI chez AWS, a déclaré sur scène : « Si votre agent met plus de temps à répondre qu’un humain, vous avez perdu l’utilisateur. Runtime Instances ramène ce temps sous la seconde. »
Ce que ça change pour les architectures serverless
Le serverless traditionnel — Lambda, Step Functions, EventBridge — repose sur un modèle invoke-and-forget. À chaque appel, un environnement frais est provisionné. Ce modèle est parfait pour les charges de travail asynchrones, mais devient un goulot d’étranglement pour les agents conversationnels qui doivent maintenir un contexte.
Runtime Instances introduit un hybride : du serverless stateful. L’infrastructure sous-jacente reste managée par AWS — pas de cluster à provisionner, pas de nœud à patcher — mais l’instance survit entre les appels.
Ce modèle a des implications architecturales majeures :
- Moins de dépendance aux caches externes. Avant Runtime Instances, une pratique courante consistait à sérialiser l’état de l’agent dans DynamoDB ou ElastiCache entre deux appels. Cette couche devient optionnelle.
- Réduction du coût des appels aux outils. Un agent qui appelle une API externe ou une base vectorielle à chaque cold start génère un trafic parasite. Runtime Instances réutilise les connexions établies.
- Agents multi-tours natifs. Les boucles de raisonnement (chain-of-thought, ReAct) deviennent viables en production sans orchestration externe complexe.
Petri Kallberg, architecte solutions chez AWS, précise dans la documentation publiée le 7 août : « Runtime Instances est conçu pour les agents qui traitent des flux conversationnels longs — support client, diagnostics industriels, assistants juridiques. Pour un agent de classification simple, le on-demand reste plus économique. »
Comparaison avec les alternatives
Le tableau ci-dessous positionne Runtime Instances face aux autres modes de déploiement d’agents IA sur le marché.
| Solution | Cold Start | État persistant | Managé | Coût |
|---|---|---|---|---|
| Bedrock AgentCore (on-demand) | 2-8 s | Non | Oui | Faible |
| Bedrock AgentCore Runtime Instances | <1 s | Oui | Oui | Moyen |
| Agents sur EC2/GKE auto-gérés | <0,5 s | Oui | Non | Élevé (ops) |
| LangGraph Cloud (LangChain) | 1-3 s | Partiel | Oui | Moyen |
| OpenAI Agents SDK (stateless) | 1-5 s | Non | Oui | Faible |
La proposition de valeur est claire : Runtime Instances cible le milieu de gamme — les déploiements où la latence est critique mais où l’équipe n’a pas la bande passante pour gérer un cluster Kubernetes. Pour une startup qui lance un agent de support client, c’est un raccourci opérationnel direct.
Le revers : vigilance sur la facture et la sécurité
Toute médaille a son revers. Runtime Instances introduit deux risques nouveaux :
1. Facturation continue. Une instance provisionnée 24 h/24 coûte ~720 $ par mois (prix annoncé pour une instance agent.runtime.medium en us-east-1). Si votre agent ne sert que 100 requêtes par jour, le on-demand reste 4× moins cher. AWS fournit un Simulateur de coûts dans la console AgentCore — utilisez-le avant de provisionner.
2. Surface d’attaque élargie. Un agent persistant qui maintient des connexions ouvertes vers des bases de données et des API externes est une cible plus intéressante qu’un agent éphémère. La persistance du contexte conversationnel signifie aussi qu’une injection de prompt réussie peut contaminer toute la session, pas un seul appel. AWS répond partiellement avec Guardrails (filtrage de contenu) et VPC Endpoints, mais la responsabilité de l’agentic security reste partagée.
Verdict
Passez à Runtime Instances si vous avez :
- Un agent orienté client avec un SLA de latence inférieur à 2 secondes.
- Des conversations longues (>5 tours) où le cold start casse l’expérience utilisateur.
- Une équipe ops réduite qui ne veut pas gérer Kubernetes ou ECS.
Restez en on-demand si :
- Votre agent effectue des tâches batch ou asynchrones (classification de documents, enrichissement de données).
- Votre volume d’appels est inférieur à 500 par jour — le cold start est moins pénalisant que la facture mensuelle.
- Vous prototypez. Le on-demand coûte zéro quand il n’est pas appelé.
AWS a comblé un trou béant dans son offre agentic AI. La question n’est plus « est-ce que Bedrock peut servir des agents en production ? » mais « est-ce que votre use case justifie le coût d’une instance persistante ? ». Pour les workloads orientés client, la réponse est de plus en plus souvent oui.
Références
- AWS Summit New York 2026 — Top Announcements, AWS News Blog, 7 août 2026
- Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore, AWS News Blog, 7 août 2026
- Amazon Bedrock AgentCore Documentation, AWS, consulté le 7 août 2026