¿Qué ocurrió?

Amazon Web Services (AWS), en su entrada de blog técnico del 14 de agosto de 2026, presentó una arquitectura multi-agente que combina Amazon Bedrock AgentCore con Amazon SageMaker AI. Este enfoque busca que los desarrolladores puedan usar modelos fundacionales gestionados junto con sus propios modelos optimizados en costo o específicos de dominio, sin tener que reescribir el marco de agentes.

En la arquitectura de ejemplo se combinaron tres rutas distintas de alojamiento de modelos dentro de un único contenedor de Bedrock AgentCore. El agente orquestador utiliza el modelo Claude Haiku 4.5, el agente de presupuesto usa Claude Sonnet 4.6 a través de Bedrock, mientras que el agente de análisis financiero llama al modelo Qwen 3.5 9B desplegado con vLLM en Amazon SageMaker AI mediante una API compatible con OpenAI.

¿Por qué es importante?

Los desarrolladores empresariales suelen tener que equilibrar requisitos de optimización de costos, residencia de datos y flexibilidad de modelos. La arquitectura mostrada por AWS busca satisfacer estos tres requisitos en una sola estructura, combinando distintos modelos para diferentes cargas de trabajo dentro del mismo pipeline de producción.

La entrada de blog también destaca una brecha técnica importante: el runtime de Bedrock AgentCore rastrea automáticamente los agentes con OpenTelemetry, pero este rastreo solo cubre las llamadas a modelos de Bedrock. El uso de tokens en los endpoints compatibles con OpenAI de SageMaker no es visible por defecto, lo que dificulta el seguimiento de costos y la depuración de latencia. AWS aborda este problema proponiendo la creación de un span personalizado gen_ai.chat que extrae manualmente el uso de tokens a partir de las métricas internas de Strands Agents.

Modelos utilizados en la arquitectura

AgenteModeloAlojamientoTarea
OrquestadorClaude Haiku 4.5Amazon BedrockClasificación y enrutamiento de la intención del usuario
Agente de presupuestoClaude Sonnet 4.6Amazon BedrockDistribución presupuestaria 50/30/20, salida estructurada
Agente de análisis financieroQwen 3.5 9BAmazon SageMaker AI (vLLM, ml.g6e.2xlarge)Análisis de acciones y construcción de cartera

Lo que se sabe

  • Qwen 3.5 9B se desplegó con un Deep Learning Container que incluye vLLM 0.22.1 en una única instancia ml.g6e.2xlarge con GPU L40S.
  • El sistema utiliza el patrón 'agentes como herramientas' (agents as tools) de la biblioteca Strands Agents.
  • El despliegue se realizó en la región ap-south-1 mediante bedrock-agentcore-starter-toolkit.
  • El código fuente completo se publicó en el repositorio de GitHub asociado de AWS.

¿Qué sigue?

AWS indica en la entrada de blog que esta arquitectura se presenta como una implementación de referencia, mostrando cómo los desarrolladores pueden llevar a producción combinaciones similares de modelos propios. La empresa recuerda que el acceso a los modelos de Bedrock varía según la región y que los desarrolladores deben verificar los modelos compatibles en la documentación de AWS.

La decisión real es la ocupación, no el modelo

Lo interesante de esta arquitectura no es la elección de modelos, sino la mezcla de formas de facturación. Bedrock cobra por token; la instancia GPU de SageMaker funciona por horas lleguen o no peticiones. Alojar un modelo propio no se decide preguntando si sale más barato por token, sino cuánto se puede mantener ocupada esa instancia.

Con poco tráfico, una L40S ociosa cuesta más que un modelo gestionado haciendo el mismo trabajo; con carga intensa y sostenida ocurre lo contrario. Si existe un requisito de residencia de datos, el cálculo se cierra antes de abrirse: ahí alojar no es una preferencia de coste sino una obligación.

Lo más valioso del artículo es que admite una carencia: el trazado automático de AgentCore solo ve las llamadas a Bedrock, y el uso de tokens en el extremo de SageMaker no se registra por defecto. Tapar ese hueco creando un span a mano deja ver el precio oculto del alojamiento mixto: un componente cuyo coste no se ve es un componente que no se puede optimizar.