Amazon Bedrock AgentCore Harness: qué es, cómo funciona y características clave

Diseñado para la velocidad: ~ 10 ms de latencia, incluso bajo carga
¡Una forma increíblemente rápida de crear, rastrear e implementar sus modelos!
- Gestiona más de 350 RPS en solo 1 vCPU, sin necesidad de ajustes
- Listo para la producción con soporte empresarial completo
Crear un agente de AI que funcione en una demostración es relativamente fácil. Crear uno que pueda ejecutar tareas de forma fiable, utilizar herramientas, gestionar el contexto y operar en un entorno de producción es mucho más difícil. Ahí es donde entra en juego un agent harness.
Un agent harness se sitúa entre el modelo y los sistemas con los que este necesita interactuar. Gestiona el bucle del agente, la ejecución de herramientas, el contexto, la memoria, el aislamiento en sandbox y otras cuestiones del runtime necesarias para convertir un LLM en un agente funcional.
Amazon Bedrock AgentCore Harness es un servicio administrado y propietario de AWS que proporciona un bucle de agente preinstalado y se ejecuta dentro de AgentCore Runtime.
En esta guía, desglosaremos cómo funciona AgentCore Harness, en qué se diferencia de AgentCore Runtime y cómo se compara con TrueForge en términos de soporte de modelos, gestión del contexto, aislamiento en sandbox, extensibilidad, despliegue y control sobre el bucle del agente.
¿Qué es AgentCore Harness?

AgentCore Harness es un agent harness administrado dentro de Amazon Bedrock AgentCore. Entró en vista previa pública en abril de 2026 y ya está disponible para el público general. El bucle de orquestación se le proporciona listo para usar, impulsado por Strands Agents, y usted describe el agente en lugar de construirlo.
En la práctica, esto significa que declara un modelo, un system prompt, un conjunto de herramientas, ajustes de memoria y límites de ejecución como configuración. AWS ejecuta el bucle. La mayoría de los cambios que normalmente requerirían editar código y volver a desplegar se convierten en un único campo de configuración. Cambiar de un proveedor de modelos a otro es cuestión de un campo. Añadir una herramienta es cuestión de un campo.
Cada sesión del harness mantiene el estado por defecto y se ejecuta en una microVM aislada. El agente obtiene su propio sistema de archivos y shell, por lo que puede escribir un archivo, ejecutar código y conservar memorias y archivos entre sesiones en lugar de empezar desde cero cada vez.
Dos llamadas a la API le permiten empezar a operar. CreateHarness define el agente, InvokeHarness lo ejecuta. También existe una ruta mediante la CLI de AgentCore y una ruta desde la consola si prefiere hacer clic en lugar de ejecutar comandos curl.
¿Cómo funciona AgentCore Harness?
AgentCore Harness está construido en torno a un enfoque basado en configuración para la ejecución de agentes.
En lugar de escribir un bucle de agente como este:
usted define los componentes que el agente necesita y deja que el harness gestione el bucle.
A alto nivel, un AgentCore Harness consta de:
- Model: el modelo que el agente utiliza para el razonamiento y la generación
- Instructions: el comportamiento a nivel de sistema y las instrucciones para el agente
- Tools: capacidades que el agente puede invocar, incluidos servidores MCP y herramientas de AgentCore
- Memory: estado que se puede conservar a través de las interacciones
- Skills: capacidades e instrucciones adicionales que se pueden poner a disposición del agente
- Execution settings: controles sobre cómo opera el agente
A continuación, el harness coordina estos componentes durante la ejecución.
Por ejemplo, si un agente necesita investigar un tema, puede razonar sobre la tarea, llamar a una herramienta para recuperar información, incorporar el resultado a su contexto y continuar el bucle hasta alcanzar una respuesta final.
Esta abstracción significa que los desarrolladores no tienen que construir cada parte de la capa de orquestación por sí mismos.
Sin embargo, también significa que el modelo de ejecución viene determinado en gran medida por el harness. Si necesita cambiar el bucle subyacente o introducir una lógica de orquestación personalizada, tendrá menos flexibilidad que con un harness de código abierto donde el propio bucle es accesible.
Usted nunca ve el bucle. Ese es todo el propósito del producto y es también el origen de la mayoría de sus limitaciones.
¿Qué incluye el producto?
El harness administrado abarca un amplio abanico de funcionalidades sin necesidad de escribir código:
La selección de modelos incluye Bedrock, OpenAI, Gemini y LiteLLM, y puede cambiar de proveedor a mitad de la sesión. El shell integrado y las herramientas de file_operations vienen de serie, al igual que Agent Skills. La memoria se presenta en formato a corto y largo plazo; este último abarca memoria semántica, de resumen, de preferencias de usuario y episódica, con ámbito por usuario mediante actor ID.
Las demás primitivas de AgentCore se conectan mediante configuración en lugar de llamadas al SDK: Gateway, Browser, Code Interpreter y herramientas de servidores MCP remotos. Las opciones del sistema de archivos incluyen almacenamiento de sesión administrado por el servicio, un punto de acceso EFS o un punto de acceso S3 Files.
En cuanto a la seguridad, la autenticación entrante admite IAM SigV4 y OAuth, la autenticación saliente se gestiona a través del baúl de tokens de identidad para tokens OAuth y claves API, y las sesiones están aisladas con disponibilidad de red VPC. La observabilidad, las respuestas en streaming, el control de versiones y los endpoints funcionan sin necesidad de código personalizado.
Una excepción que conviene conocer: las herramientas integradas en línea y del lado del cliente siguen requiriendo que escriba y mantenga una implementación, incluso en el harness.
AgentCore Harness frente a AgentCore Runtime
Esta es la comparación que lleva a la mayoría de las personas a la documentación, por lo que merece la pena ser precisos. Ambos resuelven partes diferentes del mismo problema, y aws agentcore harness se superpone sobre el otro.
AgentCore Harness es una abstracción administrada que se ejecuta dentro de Runtime. CloudTrail incluso registra las operaciones del harness bajo AWS::BedrockAgentCore::Runtime, lo que revela dónde se sitúa realmente el límite.
AgentCore Runtime es un entorno de alojamiento serverless. Usted aporta el código del agente escrito en cualquier framework (o sin ninguno), lo envuelve con el punto de entrada BedrockAgentCoreApp del SDK de AgentCore, lo empaqueta en un contenedor ARM64, lo envía a Amazon ECR y lo despliega. Runtime gestiona el aislamiento, el escalado, las sesiones, el control de acceso de autenticación y la infraestructura de observabilidad. El bucle de orquestación es suyo.
El patrón en casi todas las características es el mismo. En el harness es configuración sin código. En Runtime está admitido, pero usted mantiene la implementación.
Lo que AgentCore Harness no puede hacer
AWS publica estas limitaciones en su propia tabla de características. Cuatro capacidades figuran como no admitidas en el harness:
Sin elección de framework de agente. El bucle está construido en torno a Strands Agents. Si su equipo ya ha desarrollado sobre LangGraph, CrewAI u otro framework, ese código no se podrá migrar.
Sin patrones ajenos al bucle de agente. Las aplicaciones con estructura de grafo o de workflow quedan fuera. Si solo un paso de su pipeline necesita un modelo y el resto es código determinista, el harness no tiene forma de expresar ese workflow.
Sin hooks. No puede inyectar su propia lógica en puntos específicos del bucle. Esto descarta casos de uso como una comprobación de cumplimiento o una regla de negocio que deba ejecutarse en un punto exacto del ciclo de ejecución, en lugar de cuando el modelo decida llamar a una herramienta.
Sin streaming bidireccional. El harness no admite streaming bidireccional, lo que limita las aplicaciones que necesitan comunicación continua en ambos sentidos entre el cliente y el agente.
Hay un quinto elemento que no es tanto una característica faltante sino una decisión de diseño, y afecta especialmente a los agentes de larga ejecución: la gestión del contexto utiliza truncamiento.
Cuando la ventana de contexto se llena, el contenido más antiguo se elimina. Esto mantiene al agente dentro de sus límites de contexto, pero también significa que la información anterior puede desaparecer.
Un enfoque alternativo es la compactación: resumir el historial más antiguo en un registro estructurado y conservar dicho resumen. En lugar de descartar simplemente las interacciones anteriores, el agente conserva una versión condensada de lo sucedido, lo que le ayuda a mantener la continuidad durante ejecuciones prolongadas.
Para un agente de soporte breve, el truncamiento puede ser perfectamente adecuado. Para una tarea de investigación o migración de varias horas, la diferencia puede ser mucho más notoria: el agente tiene que trabajar con menos contexto previo a medida que la ejecución se alarga.
TrueForge: una alternativa de código abierto a AgentCore Harness

TrueForge aborda el problema del agent harness desde un enfoque diferente. En lugar de proporcionar un bucle de orquestación fijo y administrado, TrueForge es un agent harness de código abierto con licencia MIT que puede ejecutar en su propia infraestructura.
El servidor central es de código abierto, de modo que los desarrolladores pueden inspeccionar y modificar el bucle de ejecución en lugar de tratarlo como una caja negra. Puede ejecutar TrueForge de forma local, con Docker Compose o desplegarlo mediante Helm.
Esto cambia considerablemente el balance técnico. Con AgentCore Harness, AWS administra el bucle y la infraestructura circundante por usted. Con TrueForge, obtiene mayor control sobre cómo se ejecuta realmente el agente.
Aporte su propio modelo y herramientas
TrueForge es neutral respecto al modelo y funciona con endpoints compatibles con OpenAI. Puede apuntar el harness al proveedor de modelos o endpoint que desee sin cambiar la implementación del agente subyacente.
Lo mismo se aplica a las herramientas que utiliza el agente. TrueForge admite servidores MCP y le permite aportar su propio sandbox en lugar de vincular el agente a un único entorno de ejecución administrado.
Esto hace que la capa de harness sea independiente del modelo y de la infraestructura subyacente:
Modelo → TrueForge → MCP / herramientas / sandbox
Puede cambiar el endpoint del modelo sin tener que reconstruir el agente en torno a un proveedor diferente.
Controle el bucle del agente
Una de las mayores diferencias respecto a AgentCore Harness es que el bucle de TrueForge es de código abierto.
Esto significa que los desarrolladores pueden inspeccionar cómo el harness gestiona la ejecución y modificarlo cuando necesiten un comportamiento que no esté disponible como opción de configuración.
Esto resulta útil cuando un agente requiere lógica personalizada en relación con:
- Ejecución de herramientas
- Aprobaciones
- Gestión del contexto
- Subagentes
- Aislamiento en sandbox
- Políticas de ejecución
- Orquestación personalizada
En lugar de esperar a que un harness administrado exponga un hook o una opción de configuración particular, la implementación subyacente está disponible para ser modificada.
Gestión del contexto
TrueForge también adopta un enfoque diferente para la gestión del contexto.
En lugar de depender únicamente del truncamiento cuando el contexto se vuelve demasiado grande, TrueForge utiliza compactación junto con técnicas como la carga diferida de herramientas, Code Mode y la descarga de respuestas.
El objetivo es reducir la cantidad de contexto que debe permanecer en la conversación activa mientras se conserva la información que el agente necesita para seguir trabajando.
Para los agentes de larga ejecución, esta distinción es relevante. Un agente que trabaja en un código base extenso o en una tarea de investigación de múltiples pasos puede acumular una cantidad sustancial de salidas de herramientas y contexto intermedio. Limitarse a eliminar mensajes antiguos puede hacer que esa información deje de estar disponible; la compactación ofrece una forma de conservar una representación condensada en su lugar.
Sandbox como herramienta
TrueForge también trata el sandbox de forma distinta.
Con AgentCore Harness, la sesión se ejecuta dentro de una microVM aislada. TrueForge, en cambio, trata el sandbox como una herramienta que se puede aprovisionar cuando el agente realmente necesita ejecutar código.
Esto significa que el sandbox no tiene por qué ser el entorno de toda la sesión del agente. Se convierte en una capacidad más que el agente puede invocar cuando sea necesario.
Dónde encaja TrueForge
En última instancia, la distinción se reduce al control.
AgentCore Harness está diseñado para ofrecer a los desarrolladores una ruta administrada para ejecutar agentes sin tener que construir el bucle de orquestación por sí mismos. TrueForge está diseñado para desarrolladores que desean que el propio harness siga siendo personalizable e independiente de un proveedor de nube o framework de agentes específico.
Esto hace que TrueForge sea especialmente relevante cuando necesita controlar el bucle del agente, cambiar la forma en que se gestiona el contexto, elegir su propio endpoint de modelo o ejecutar el harness en su propia infraestructura.
npx @truefoundry/trueforge le permite tener un agente en funcionamiento en aproximadamente un minuto, o vea cómo TrueForge gestiona el contexto en ejecuciones largas.
Preguntas frecuentes
P: ¿Qué es AgentCore Harness?
R: AgentCore Harness es el agent harness administrado de AWS dentro de Amazon Bedrock AgentCore, disponible de forma general a partir de 2026. El bucle de orquestación viene integrado y está impulsado por Strands Agents, por lo que usted declara el agente como configuración (cubriendo modelo, system prompt, herramientas, memoria y límites de ejecución) en lugar de escribir el bucle usted mismo. Las sesiones mantienen el estado por defecto y se ejecutan en una microVM aislada con su propio sistema de archivos y shell.
P: ¿Cuál es la diferencia entre AgentCore Harness y AgentCore Runtime?
R: Runtime es el alojamiento serverless y Harness es un bucle administrado que se ejecuta dentro de él. Con Runtime, usted aporta su propio código de agente en cualquier framework, lo empaqueta como un contenedor ARM64, lo envía a ECR y escribe la orquestación usted mismo. Con Harness no hay contenedor ni bucle que escribir. AWS registra las operaciones de Harness bajo AWS::BedrockAgentCore::Runtime, lo que muestra claramente cómo se relacionan ambos.
P: ¿Puedo usar LangGraph u otro framework con el agent harness que proporciona AgentCore?
R: No en el harness. AWS marca la elección de framework de agente como no admitida, porque el bucle utiliza Strands Agents. Puede ejecutar LangGraph, CrewAI o código personalizado en AgentCore Runtime, ya que Runtime es agnóstico respecto al framework por diseño, pero migrar al harness implica prescindir de ese código. Esta es la razón principal por la que los equipos comprometidos con un framework específico permanecen en Runtime.
P: ¿Puedo ejecutar un agent harness en mi propia VPC o en entorno on-premise?
R: Con un harness autohospedado, sí. TrueForge se ejecuta desde un único comando npx de forma local, o mediante Docker Compose y Helm para despliegues de equipo con Postgres, Redis, réplicas e inicio de sesión OIDC. La plataforma administrada de TrueFoundry también se ejecuta autohospedada, on-premise, en entornos aislados (air-gapped) o híbridos, por lo que ningún dato sale de su dominio. AgentCore Harness admite redes VPC, pero se ejecuta en AWS.
P: ¿Cómo puedo gobernar modelos y servidores MCP a través de múltiples agentes?
R: A través de una capa de gateway, una vez que las claves por equipo dejan de ser escalables. AI Gateway de TrueFoundry coloca más de 1000 LLM detrás de una única API compatible con OpenAI a aproximadamente 3 o 4 ms de latencia añadida y más de 350 RPS en una sola vCPU, con RBAC, presupuestos, guardrails y rotación de credenciales, además de trazas de OpenTelemetry hacia Grafana, Datadog o Prometheus. Los agentes en AgentCore, TrueForge o cualquier otra plataforma se gobiernan de la misma manera.
Lecturas relacionadas
- Agent Harness vs Agent Framework: ¿cuál es la diferencia real?: la distinción de categorías subyacente a esta publicación
- El mejor Agent Harness en 2026: comparación de las 5 opciones principales: cómo se sitúa el panorama actual
- El mejor Agent Harness de código abierto: las opciones abiertas, si descarta las soluciones administradas
- Alternativas a Claude Managed Agents: la misma decisión aplicada al harness administrado de Anthropic
- Amazon Bedrock Agents frente al plano de control: la cuestión arquitectónica más amplia en AWS
Conclusión
AgentCore Harness y TrueForge adoptan enfoques fundamentalmente diferentes para la creación de agentes de AI.
AgentCore Harness abstrae el bucle del agente. Usted define el modelo, las instrucciones, las herramientas, la memoria y el resto de la configuración, y AWS gestiona la ejecución. Esto puede simplificar la puesta en producción de un agente, especialmente si ya está desarrollando dentro del ecosistema de AWS y se siente cómodo con las limitaciones de un harness administrado.
TrueForge otorga más control al desarrollador. Es de código abierto, se puede ejecutar en su propia infraestructura y expone el bucle del agente subyacente para su modificación. Puede elegir su endpoint de modelo, servidores MCP y sandbox, y utilizar el harness como base en lugar de como una capa de orquestación fija.
Por lo tanto, la elección depende menos de qué harness tiene más características y más de cuánto control desea sobre el runtime del agente.
Si desea que AWS administre la orquestación y la infraestructura, AgentCore Harness le proporciona esa abstracción. Si desea inspeccionar, personalizar y ejecutar el harness usted mismo, TrueForge ofrece una alternativa de código abierto.
Para los equipos que evalúan la infraestructura de agentes, la pregunta importante no es simplemente ¿qué agent harness deberíamos usar? Sino ¿qué partes del stack del agente queremos que administre la plataforma y cuáles queremos controlar nosotros mismos?
npx @truefoundry/trueforge le permite tener un agente en funcionamiento en aproximadamente un minuto, o vea cómo TrueForge gestiona el contexto en ejecuciones largas.
TrueFoundry AI Gateway ofrece una latencia de entre 3 y 4 ms, gestiona más de 350 RPS en una vCPU, se escala horizontalmente con facilidad y está listo para la producción, mientras que LitellM presenta una latencia alta, tiene dificultades para superar un RPS moderado, carece de escalado integrado y es ideal para cargas de trabajo ligeras o de prototipos.














.webp)

.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.png)
.webp)
.webp)

.png)
.png)





