Spring AI y Bedrock AgentCore: un agente Java en producción con una anotación y dos endpoints

Si tienes un equipo enterprise en Java, la historia con los agentes suele ser así: alguien montó una demo en Python, a todos les gustó, y luego resulta que no encaja en tu CI/CD, tu monitorización ni tu modelo de acceso. En un nuevo análisis, AWS propone otro camino: no cambiar de stack, sino conectar agentes mediante Spring AI y Bedrock AgentCore.

En qué se diferencia un agente de una llamada a un modelo

Un chat completion normal genera texto, pero no decide qué hacer a continuación, no accede a sistemas externos y no recuerda la conversación de ayer. Un agente combina tres elementos: planificación (dividir el objetivo en pasos y revisar el plan sobre la marcha), herramientas (API, bases de datos, intérprete de código) y memoria (dentro de la sesión y entre sesiones).

Una aplicación RAG no es un agente: tiene búsqueda, pero no un ciclo de planificación. Un agente trabaja en un bucle hasta cumplir la tarea o decidir que no puede continuar.

Cómo se ve en el código

AgentCore es una plataforma gestionada de AWS que no está atada a un framework ni a un modelo. El runtime solo exige a tu servicio dos endpoints: POST /invocations para las solicitudes (JSON o SSE en streaming) y GET /ping para comprobar el estado. Si la tarea es larga, el servicio debe responder HealthyBusy; de lo contrario, el runtime puede reducir su escala.

El Spring AI AgentCore SDK oculta este contrato tras la anotación @AgentCoreInvocation: crea ambos endpoints por sí sola, serializa el JSON y da formato al SSE. El mismo servicio puede ofrecer REST para una interfaz React, de modo que no hace falta un backend aparte para el agente.

Las herramientas se conectan al estilo Spring. Marcas un método con @Tool y una descripción, lo registras en ChatClient mediante defaultTools, y el modelo decide por sí mismo cuándo invocarlo. Para una respuesta estructurada se pide un record de Java, y para documentos se adjunta un archivo al mensaje del usuario. La memoria se conecta mediante advisors: interceptores que añaden contexto al prompt antes de llamar al modelo. El fragmento sobre memoria en el texto original se corta, así que consulta el original para los detalles.

De un agente a varios

El segundo ejemplo es un sistema de procesamiento de documentos con cinco especialistas: abogado, hipotecas, seguros, impuestos y un agente general. Un clasificador determina el tipo de documento y lo pasa al especialista adecuado. Este devuelve un JSON estructurado con una puntuación de confianza. Después, reglas en SpEL de application.yml deciden qué hacer: enviar una ALERT, bloquear o mandar el documento a revisión manual.

Hay tres patrones: router (solo despacho, sin lógica de dominio), evaluador (reglas de negocio sobre las respuestas) y fan-out paralelo. Este último no está implementado en la solución base: el procesamiento por lotes es secuencial. Si se añade fan-out, el tiempo de análisis lo determinará el agente más lento, y no la suma de todas las llamadas.

Limitaciones

Primera: es un material de AWS y está pensado para el ecosistema de AWS. Bedrock Converse API, AgentCore, Graviton y módulos de Terraform: todo en un mismo paquete. El artículo no aborda la portabilidad a otras nubes.

Segunda: la salida estructurada en un record de Java se probó con Claude Sonnet 4.5. Spring AI añade el esquema al prompt y analiza la respuesta, pero a veces el modelo devuelve datos que no siguen el esquema. Para más rigor se necesita un proveedor con control nativo del esquema o validación con reintento de la solicitud.

Tercera: en llamadas a herramientas con varios argumentos, los autores aconsejan obtener la respuesta con un call() bloqueante y luego dividirla en chunks para que los argumentos se asocien de forma fiable. Esto reduce el beneficio del streaming real.

Qué hacer

Si tienes un stack Java y ya estás en AWS, empieza con el asistente de viajes: un agente, herramientas y memoria. Comprueba cómo se comporta tu modelo con la salida estructurada y solo después añade el router y las reglas. Los requisitos son estrictos: JDK 21, Spring Boot 4.1 con Spring AI 2.0, Terraform 1.5+ y Docker con Buildx para la imagen ARM64. Asegúrate de antemano de que tu proyecto soportará esa actualización.