Amazon Bedrock Agents contra el plano de control: una revisión arquitectónica

Para los ingenieros y arquitectos de DevOps que operan dentro del perímetro de AWS, Agentes de Amazon Bedrock—conocido arquitectónicamente como Tiempo de ejecución de AgentCore: es la ruta estándar para crear flujos de trabajo de agencia. Estandariza los complejos bucles recursivos necesarios para los agentes y gestiona el razonamiento, la memoria y la orquestación de las API que antes utilizaban los desarrolladores mediante bibliotecas como Cadena LANG.

Sin embargo, la adopción de un marco de agentes gestionados a menudo requiere un equilibrio entre la velocidad inicial y el control arquitectónico a largo plazo. Combina la lógica de las aplicaciones con la filosofía de orquestación de un proveedor de nube específico. Este informe analiza la arquitectura técnica de Amazon Bedrock Agents, evalúa la realidad operativa en relación con la observabilidad y la contrasta con un enfoque de plano de control independiente que utiliza el Plataforma TrueFoundry.

Anatomía del tiempo de ejecución de Amazon Bedrock Agent

Los agentes de Bedrock funcionan como un motor de orquestación diseñado para ejecutar tareas de varios pasos. A diferencia de una llamada a la API InvokeModel sin estado, un agente funciona como un bucle con estado.

Al definir un agente en Bedrock, los desarrolladores configuran tres primitivas distintas:

1. El grupo de acción: Un Esquema OpenAPI definir las capacidades del agente. Por lo general, se asignan a AWS Lambda funciones, que proporcionan la capa de procesamiento para la ejecución de la herramienta.
2. La base de conocimientos: Una integración de almacén vectorial (normalmente Amazon OpenSearch sin servidor) que proporciona capacidades RAG para conectar a tierra el modelo.
3. La plantilla de orquestación: La lógica de ingeniería rápida que indica al modelo cómo interpretar la entrada del usuario, seleccionar la Lambda correcta y analizar la salida.

El ciclo de razonamiento

La utilidad principal es automatizar los pasos de razonamiento. Cuando un usuario pide que «compruebes el artículo X en el inventario y actualices la base de datos», el motor de ejecución descompone esta solicitud:

• Paso 1: Determina que la lambda de CheckInventory es obligatoria.
• Paso 2: Construye la carga útil.
• Paso 3: Ejecuta la lambda y lee la respuesta.
• Paso 4: Determina que UpdateDatabase es el siguiente paso lógico en función del resultado anterior.

Figura 1: El bucle de orquestación recursiva administrado por AWS Bedrock Agents.

Compensaciones operativas

Los servicios gestionados aceleran la implementación inicial, pero las operaciones del segundo día (depuración, escalado y migración) suelen revelar el costo de la abstracción.

Consideraciones sobre la observabilidad

En un tiempo de ejecución totalmente gestionado, el bucle de mensajes es abstraído. AWS crea las instrucciones del sistema y las definiciones de las herramientas y las envía al LLM detrás del límite del servicio.

Si un agente alucina o llama a la herramienta equivocada, la depuración puede resultar compleja porque la ventana de contexto sin procesar y los pasos de razonamiento intermedios suelen gestionarse de forma implícita. Esto puede llevar a los equipos a centrarse en depurar la salida final en lugar de inspeccionar el proceso de razonamiento detallado.

Las arquitecturas que utilizan una puerta de enlace de IA como TrueFoundry mantienen la lógica de orquestación transparente. El «cerebro» del agente se ejecuta en su infraestructura, lo que garantiza que cada mensaje, señal y paso de razonamiento sea visible en herramientas de rastreo como Telemetría abierta o Arize.

La cadena de herramientas centrada en AWS

Los agentes de Bedrock están optimizados para el ecosistema de AWS. Llamar a una herramienta de forma nativa normalmente implica que la herramienta existe como una función de Lambda.

Si una empresa utiliza herramientas externas, como una base de datos Snowflake, una API de Salesforce o un servicio alojado en Azure, los desarrolladores suelen coordinarse mediante Lambdas contenedoras en AWS para cerrar la brecha. Esto puede suponer una latencia adicional y una sobrecarga de mantenimiento.

La industria se está uniendo actualmente en torno a la Protocolo de contexto modelo (MCP), un estándar abierto que permite a los agentes conectarse a fuentes de datos de forma universal. TrueFoundry está diseñado para ser Nativo de MCP, que actúa como un centro neutral en el que un agente puede conectarse simultáneamente a un servidor MCP de Google Drive, a una base de datos local de Postgres y a una función de AWS Lambda, sin contenedores de infraestructura personalizados.

TrueFoundry: La arquitectura del plano de control

TrueFoundry propone un Plano de control arquitectura. En lugar de agrupar el modelo, el tiempo de ejecución y las herramientas en un único servicio de nube vertical, este enfoque los desvincula.

En este caso, el proveedor de nube (AWS, Azure, GCP) funciona como un backend escalable para la computación y los modelos, mientras que TrueFoundry Gateway sigue siendo la interfaz gobernable para las aplicaciones.

Enrutamiento y eficiencia económica

Una característica que define a Bedrock Agents es la unión arquitectónica a los modelos de Bedrock (Titan, Claude, Llama on Bedrock). Los agentes complejos realizan muchos pasos y utilizan un modelo de alta gama como Claude 3.5 Soneto ya que cada paso de un bucle recursivo puede aumentar los costos.

TrueFoundry facilita enrutamiento semántico. El Gateway analiza la complejidad de un paso; si el agente solo necesita extraer una fecha de una cadena, la solicitud pasa a un modelo más rentable (como Meta Llama) hospedado en Instancias puntuales de AWS. Si el paso requiere un razonamiento complejo, se dirige a GPT-4o o Claude 3.5 Opus.

Figura 2: La lógica de enrutamiento de TrueFoundry optimiza la economía de las unidades al adaptar la complejidad de las tareas al proveedor más rentable.

Comparación de funciones: servicio gestionado frente a plano de control

En esta tabla se comparan las capacidades del servicio administrado de AWS con las del plano de control de TrueFoundry.

El argumento de la infraestructura híbrida

Para muchas empresas, el futuro no es «todo incluido en AWS» o «todo incluido en Azure», sino un estado híbrido dictado por la gravedad y el costo de los datos.

AgentCore se destaca cuando todo el ciclo de vida de los datos, desde la ingestión hasta la inferencia, reside en AWS. Sin embargo, a medida que los flujos de trabajo de las agencias se amplían, suelen requerir acceso a los datos de Microsoft SharePoint, a las plataformas de datos de clientes de Google Cloud o a los almacenes locales.

TrueFoundry facilita una patrón de enrutamiento entre nubes. La lógica del agente reside en el plano de control, lo que le permite acceder a las herramientas de diferentes nubes sin tener que atravesar complejas VPN ni configurar manualmente las puertas de enlace de API. Esto prepara la pila para el futuro; si Servicio Azure OpenAI lanza un nuevo modelo que supera a Claude, o si Llama 3 se vuelve viable para un caso de uso específico, cambiar el motor subyacente es un cambio de configuración más que una reescritura del código.

Figura 3: La arquitectura de enrutamiento de TrueFoundry que permite el acceso a los datos entre nubes.

Recomendación resumida

La elección entre el servicio administrado de AWS y el plano de control de TrueFoundry es, en efecto, una elección entre velocidad de integración y opcionalidad arquitectónica.

• Estandarice los agentes de AWS Bedrock si: Su equipo de ingeniería es pequeño, la lógica de las aplicaciones está compuesta en gran medida por funciones de AWS Lambda y no es necesario utilizar modelos ajenos a la cartera de Bedrock.
• Elige TrueFoundry si: Estás creando una plataforma que debe atender a varios equipos internos con necesidades diferentes. Necesita un gobierno centralizado para administrar los presupuestos y las políticas de seguridad en AWS y Azure, o tiene la intención de aprovechar los modelos de código abierto en las instancias puntuales para controlar la economía unitaria de las cargas de trabajo de los agentes de gran volumen.

‍