Six annonces AWS en trois jours décrivent la même architecture sous six angles différents. Amazon Bedrock AgentCore est en disponibilité générale, et les pièces pour sortir un agent de la démo sont là : un MCP bridge qui connecte les agents dans le cloud aux outils locaux sur le laptop, une mémoire persistante entre les sessions, un nœud pour n8n qui construit des workflows agentiques sans coder, et une Web Search native dans Bedrock pour le grounding sans fournisseurs externes.

Pour qui essaie de faire fonctionner un agent sur des tâches réelles, le changement de perspective compte. La question centrale se déplace sur comment orchestrer qui fait quoi. Le choix du modèle passe au second plan. L’agent devient un processus avec état, outils, isolation et observabilité. AWS rassemble ces pièces sur une seule plateforme, et le fait la même semaine où Cloudflare construit son runtime pour agents. Deux fournisseurs avec des infrastructures différentes, même design.

Les cas d’usage publiés sont concrets. Mobileye a déployé un agent de support technique qui bridge les systèmes on-prem avec le cloud. LendingTree a trois agents coordonnés qui guident les clients sur les hypothèques en respectant la conformité financière. Ce sont des productions réelles, avec des chiffres et des contraintes réelles derrière.

En détail

L’agent que tu as essayé en chat, celui qui répond bien si tu lui donnes le bon prompt, a un problème structurel quand tu le mets en production : il perd l’état entre les appels, ne se souvient pas de ce qu’il a fait, n’a pas d’endroit sûr pour exécuter du code, et chaque outil que tu lui ajoutes est une intégration à écrire à la main. AgentCore essaie de résoudre ces problèmes au même endroit.

Mémoire persistante. L’agent sauvegarde l’état entre les sessions. Si hier il a analysé un document et aujourd’hui tu lui demandes une suite, il ne recommence pas de zéro. C’est la différence entre un assistant qui fonctionne et un qui redémarre à chaque fois.

MCP bridge pour les outils locaux. Le Model Context Protocol, dont nous avons raconté la mise à jour 2.0, est le standard pour connecter les agents aux outils. Le bridge d’AWS résout un problème concret : l’agent s’exécute dans le cloud, mais tes fichiers et tes outils sont sur le laptop. La solution est un tunnel WebSocket signé qui passe par une extension du navigateur, sans ouvrir de ports ou configurer de VPN.

n8n comme frontend visuel. Le nœud open source pour n8n transforme AgentCore en une étape dans un workflow visuel. Mémoire, outils réels, exécution de code et isolation VPC se configurent depuis l’éditeur, sans code d’infrastructure. Pour qui ne développe pas, cela signifie construire un agent en traînant des blocs.

Web Search native. Bedrock a maintenant une recherche web intégrée côté serveur. Le grounding du modèle sur des sources actuelles devient une capability de la plateforme, sans embarquer un tiers fournisseur ou gérer des API externes.

Ce que disent les cas réels. Mobileye bridge les systèmes on-prem avec AWS pour le support technique, en maintenant la gouvernance d’entreprise. LendingTree utilise trois agents coordonnés avec LangGraph et MCP pour les hypothèques, avec des guardrails intégrés pour la conformité financière. Le troisième cas, l’extraction automatique d’insights du web, combine AgentCore Browser, OpenSearch et Lambda pour surveiller les flux RSS et rendre les insights extraits recherchables.

Limites. Ceux-ci sont des posts du blog AWS : ils décrivent l’architecture dans ses meilleurs aspects. Le lock-in est réel, une fois construit sur AgentCore changer de fournisseur signifie réécrire l’orchestration. Le MCP bridge est élégant mais ajoute de la complexité (extension du navigateur, Chrome native messaging). Et la convergence avec Cloudflare confirme la direction sans valider les détails : deux fournisseurs qui convergent sur le même design est un signal fort, mais ne remplace pas l’expérience sur le terrain.