Spring AI et Bedrock AgentCore : un agent Java en production avec une seule annotation et deux endpoints

Dans une équipe enterprise qui travaille en Java, l'histoire des agents se déroule généralement ainsi : quelqu'un monte une démo en Python, elle plaît à tout le monde, puis on découvre qu'elle ne s'intègre ni à votre CI/CD, ni à votre supervision, ni à votre modèle d'accès. Dans une nouvelle analyse, AWS propose une autre voie : ne pas changer de stack, mais connecter les agents via Spring AI et Bedrock AgentCore.

En quoi un agent diffère d'un simple appel au modèle

Un chat completion classique génère du texte, mais ne décide pas de la suite à donner, n'accède pas aux systèmes externes et ne se souvient pas de la conversation de la veille. Un agent réunit trois éléments : la planification (découper un objectif en étapes et réviser le plan en cours de route), les outils (API, bases de données, interpréteur de code) et la mémoire (au sein d'une session et entre les sessions).

Une application RAG n'est pas un agent : elle fait de la recherche, mais n'a pas de boucle de planification. L'agent tourne en boucle jusqu'à ce qu'il ait accompli sa tâche ou conclu qu'il ne peut pas continuer.

À quoi cela ressemble dans le code

AgentCore est une plateforme managée d'AWS, indépendante du framework et du modèle. Le runtime n'exige de votre service que deux endpoints : POST /invocations pour les requêtes (JSON ou SSE en streaming) et GET /ping pour le contrôle de santé. Si la tâche est longue, le service doit répondre HealthyBusy, faute de quoi le runtime risque de le réduire (scale down).

Le SDK Spring AI AgentCore dissimule ce contrat derrière l'annotation @AgentCoreInvocation : elle crée elle-même les deux endpoints, sérialise le JSON et met en forme le SSE. Le même service peut exposer du REST pour une interface React, si bien qu'aucun backend distinct n'est nécessaire pour l'agent.

Les outils se branchent de façon tout aussi « spring ». Vous annotez une méthode avec @Tool et une description, vous l'enregistrez dans le ChatClient via defaultTools, et le modèle décide seul quand l'appeler. Pour une réponse structurée, on demande un record Java ; pour les documents, on joint le fichier au message de l'utilisateur. La mémoire se branche via des advisors : des intercepteurs qui ajoutent du contexte au prompt avant l'appel au modèle. Le passage sur la mémoire est tronqué dans le texte source ; pour les détails, reportez-vous à l'original.

D'un agent à plusieurs

Le second exemple est un système de traitement de documents avec cinq spécialistes : juriste, prêt immobilier, assurance, fiscalité et agent généraliste. Un classificateur détermine le type de document et le transmet au spécialiste approprié. Celui-ci renvoie un JSON structuré accompagné d'un score de confiance. Ensuite, des règles SpEL définies dans application.yml décident de la suite : envoyer une ALERT, bloquer ou orienter le document vers une vérification manuelle.

Trois patterns sont à l'œuvre : le routeur (simple dispatching, sans logique métier), l'évaluateur (règles métier appliquées aux réponses) et le fan-out parallèle. Ce dernier n'est pas implémenté dans la solution de base : le traitement par lots est séquentiel. Avec un fan-out, la durée d'analyse serait dictée par l'agent le plus lent, et non par la somme de tous les appels.

Limites

Premièrement : il s'agit d'un contenu AWS, taillé pour l'écosystème AWS. Bedrock Converse API, AgentCore, Graviton et modules Terraform forment un tout. La portabilité vers d'autres clouds n'est pas abordée dans l'article.

Deuxièmement : la sortie structurée dans un record Java a été testée sur Claude Sonnet 4.5. Spring AI ajoute le schéma au prompt et analyse la réponse, mais le modèle renvoie parfois des données non conformes au schéma. Pour plus de rigueur, il faut un fournisseur avec contrôle natif du schéma, ou une validation assortie d'une nouvelle requête.

Troisièmement : pour les appels d'outils à plusieurs arguments, les auteurs recommandent de recueillir la réponse via un call() bloquant, puis de la découper en chunks, afin que les arguments soient liés de façon fiable. Cela réduit l'intérêt d'un véritable streaming.

Que faire

Si vous avez un stack Java et que vous êtes déjà sur AWS, commencez par l'assistant de voyage : un agent, des outils et de la mémoire. Vérifiez le comportement de votre modèle sur la sortie structurée, puis seulement ajoutez le routeur et les règles. Les exigences sont strictes : JDK 21, Spring Boot 4.1 avec Spring AI 2.0, Terraform 1.5+ et Docker avec Buildx pour l'image ARM64. Assurez-vous au préalable que votre projet supportera une telle mise à niveau.