Crear un agente de IA en 3 clics con Amazon Bedrock AgentCore Harness
Cómo usar AgentCore harness para crear un agente de IA en 3 clicks, qué limitaciones tiene, y qué otras opciones de configuración ofrece
Un agente de IA está formado por un modelo, al que puedes llamar a través de Amazon Bedrock , un prompt, un conjunto de herramientas que puedes exponer mediante AgentCore Gateway y un ciclo que gestiona las llamadas al modelo y a las herramientas. Ese ciclo puedes implementarlo con Strands SDK y ejecutarlo en AgentCore Runtime . Probablemente también quieras agregar autenticación con AgentCore Identity , memoria con AgentCore Memory y una buena observabilidad con AgentCore Observability , enviando logs y trazas a Amazon CloudWatch . Podría tirarte otras 10 palabras clave, pero creo que ya se entiende la idea: los agentes tienen muchas piezas que encajar, y AWS ofrece un montón de servicios y funcionalidades que necesitas combinar de la forma correcta. O puedes leer Simple AWS y conocer AgentCore harness 😁.
Amazon Bedrock AgentCore harness es una capacidad de AgentCore, lanzada el 17 de junio de 2026, que ofrece una forma de crear agentes de IA con decisiones de diseño ya tomadas para que el proceso sea lo más sencillo posible. Creas un recurso Harness y describes el agente mediante configuración: su modelo, instrucciones, herramientas, skills, memoria, entorno y límites de ejecución. AgentCore ejecuta el ciclo dentro de una sesión aislada de AgentCore Runtime y lo conecta con las capacidades configuradas, tal como lo harías si montaras todo manualmente.
Crear un agente con AgentCore Harness
Empecemos creando un agente. Vamos a construir un investigador de lanzamientos de AWS: podrás preguntarle por un servicio o una funcionalidad de AWS, y usará AgentCore Browser para consultar páginas oficiales de AWS antes de devolverte el estado del lanzamiento, una explicación breve y sus fuentes.
Abre la consola de Amazon Bedrock AgentCore, ve a Harnesses, haz clic en el desplegable Quick create harness y después en Advanced create harness. También puedes hacer clic en Quick create harness y tendrás un harness en 3 clics, como prometí en el título, pero vamos a tomar el camino largo.

Dale al Harness un nombre como
aws_release_researcher, elige un modelo como Sonnet 4.6 y agrega este system prompt:1
2
3
4
5
6
7
8
9
10
11
Eres un asistente de investigación de lanzamientos de AWS.
Usa el navegador para consultar la documentación oficial de AWS y sus blogs.
En cada respuesta:
1. Indica el estado actual del lanzamiento.
2. Explica qué cambió.
3. Incluye las URLs de las fuentes que usaste.
4. Aclara cuándo la evidencia disponible no respalda una afirmación.
No uses fuentes de terceros.Dentro de Tools, activa Browser tool y selecciona AgentCore Browser Tool. Deja todo lo demás como está; ya podrás jugar con esas opciones después (¡sé que lo harás!).
Nota de seguridad: AgentCore necesita un rol de ejecución para el Harness. Ese rol se asume dentro de la sesión de Runtime y necesita permisos para invocar el modelo que elegiste y usar las capacidades asociadas al Harness. La configuración predeterminada crea un rol nuevo para esto. Puedes cambiarlo en Permissions si quieres prestar más atención a la seguridad, o dejarlo como está para esta prueba.
Haz clic en Create Harness y espera a que esté listo. Una vez creado, haz clic en el botón amarillo Test Harness de la esquina superior derecha para ir a la interfaz del playground de Harness. Aquí puedes interactuar con tu agente. Prueba una pregunta que requiera información actual, como esta:
1
2
¿Cuándo alcanzó la disponibilidad general Amazon Bedrock AgentCore Harness,
y qué se agregó en GA?AgentCore inicia una sesión aislada de Runtime, envía al modelo el prompt y la definición de la herramienta Browser, ejecuta el navegador cuando el modelo lo solicita, devuelve los resultados al modelo y transmite la respuesta final en streaming a la consola. Fíjate en que no escribiste el ciclo de orquestación ni desplegaste un contenedor del agente: todo eso ya está resuelto por ti.

La consola es la forma más rápida de conocer la experiencia, pero también puedes crear e invocar el mismo agente a través del SDK. El siguiente ejemplo usa un rol de ejecución de IAM existente y un ID de modelo de Amazon Bedrock proporcionados mediante variables de entorno, y configura todo lo demás con Python y boto3:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
import os
import time
import uuid
import boto3
REGION = os.getenv("AWS_REGION", "us-west-2")
ROLE_ARN = os.environ["HARNESS_EXECUTION_ROLE_ARN"]
MODEL_ID = os.environ["BEDROCK_MODEL_ID"]
SYSTEM_PROMPT = """
You are an AWS release research assistant.
Use the browser to consult official AWS documentation and AWS blogs.
For every answer:
1. State the current launch status.
2. Explain what changed.
3. Include the source URLs you used.
4. Say when the available evidence does not support a claim.
Do not use third-party sources.
""".strip()
control = boto3.client(
"bedrock-agentcore-control",
region_name=REGION,
)
runtime = boto3.client(
"bedrock-agentcore",
region_name=REGION,
)
created = control.create_harness(
harnessName="aws_release_researcher",
executionRoleArn=ROLE_ARN,
model={
"bedrockModelConfig": {
"modelId": MODEL_ID,
}
},
systemPrompt=[
{
"text": SYSTEM_PROMPT,
}
],
tools=[
{
"type": "agentcore_browser",
"name": "browser",
}
],
maxIterations=12,
timeoutSeconds=300,
)
harness = created["harness"]
while harness["status"] == "CREATING":
time.sleep(3)
harness = control.get_harness(
harnessId=harness["harnessId"],
)["harness"]
if harness["status"] != "READY":
raise RuntimeError(
f"Harness creation failed: {harness.get('failureReason', 'unknown error')}"
)
response = runtime.invoke_harness(
harnessArn=harness["arn"],
runtimeSessionId=str(uuid.uuid4()),
messages=[
{
"role": "user",
"content": [
{
"text": (
"When did Amazon Bedrock AgentCore Harness become "
"generally available, and what was added at GA?"
)
}
],
}
],
)
for event in response["stream"]:
if "contentBlockDelta" in event:
delta = event["contentBlockDelta"].get("delta", {})
if "text" in delta:
print(delta["text"], end="", flush=True)
elif "runtimeClientError" in event:
raise RuntimeError(event["runtimeClientError"]["message"])Este fragmento crea el recurso, espera a que esté listo e imprime el stream de la respuesta. Fíjate en que no hay un
Agent de Strands, ni un componente que despache las llamadas a herramientas, ni un ciclo que lea bloques toolUse, ni un entrypoint de contenedor. Todo eso lo define el Harness, aunque puedes sobrescribir su configuración si quieres.El agente como configuración
Lo importante de harness no son tanto los valores predeterminados y los tres clics, sino la posibilidad de definir un agente mediante configuración. El modelo, el prompt, las herramientas, la memoria, el entorno y los límites son propiedades del Harness, que pasas como parámetros a una simple llamada a la función
create_harness, en lugar de tener constantes enterradas dentro de la aplicación del agente.Eso separa la definición del agente del mecanismo que usas para crearlo. Esta es una versión en CloudFormation del mismo investigador de lanzamientos:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
AWSTemplateFormatVersion: "2010-09-09"
Description: AWS release research agent built with AgentCore Harness
Parameters:
HarnessExecutionRoleArn:
Type: String
BedrockModelId:
Type: String
Resources:
ReleaseResearcherHarness:
Type: AWS::BedrockAgentCore::Harness
Properties:
HarnessName: aws_release_researcher
ExecutionRoleArn: !Ref HarnessExecutionRoleArn
Model:
BedrockModelConfig:
ModelId: !Ref BedrockModelId
Temperature: 0.2
SystemPrompt:
- Text: |
You are an AWS release research assistant.
Use the browser to consult official AWS documentation
and AWS blogs.
For every answer:
1. State the current launch status.
2. Explain what changed.
3. Include the source URLs you used.
4. Say when the available evidence does not support a claim.
Do not use third-party sources.
Tools:
- Type: agentcore_browser
Name: browser
Memory:
ManagedMemoryConfiguration:
Strategies:
- SEMANTIC
- SUMMARIZATION
EventExpiryDuration: 30
MaxIterations: 12
TimeoutSeconds: 300
Tags:
- Key: application
Value: aws-release-researcher
- Key: managed-by
Value: cloudformationEsta plantilla define el modelo, sus instrucciones, la herramienta que puede usar, cómo se gestiona la memoria y cuánto tiempo puede seguir trabajando el agente en una solicitud. CloudFormation crea el Harness, y AgentCore convierte esas propiedades en un Runtime, un ciclo administrado, un entorno de sesión aislado y las conexiones que necesitan las capacidades configuradas.
Puedes conectar AgentCore Browser, Code Interpreter, Gateway y herramientas MCP remotas al ciclo administrado. También puedes agregar skills con instrucciones reutilizables, scripts, referencias y archivos. La memoria puede quedar a cargo del Harness, provenir de un recurso de AgentCore Memory existente o estar deshabilitada. Un entorno personalizado te permite agregar dependencias y herramientas de línea de comandos mientras la orquestación sigue administrada. Todo eso se define mediante configuración, y Harness se encarga de traducirlo a los detalles de implementación.
También puedes cambiar la configuración para una invocación concreta. Supongamos que queremos una respuesta más breve del investigador de lanzamientos sin cambiar el Harness desplegado:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
response = runtime.invoke_harness(
harnessArn=HARNESS_ARN,
runtimeSessionId=str(uuid.uuid4()),
systemPrompt=[
{
"text": (
"You are an AWS release research assistant. "
"Use only official AWS sources. "
"Return at most three paragraphs and include the URLs."
)
}
],
maxIterations=6,
messages=[
{
"role": "user",
"content": [
{
"text": "Explain what AgentCore Harness manages."
}
],
}
],
)La sobrescritura se aplica a esa invocación. El recurso Harness usa su configuración existente para todas las demás llamadas. Puedes aprovecharlo para probar otro modelo compatible u otro conjunto de herramientas sin crear un segundo harness.
Nota de seguridad: esta flexibilidad también crea un límite de permisos. Quien pueda sobrescribir campos del modelo, herramientas, skills o instrucciones puede cambiar de forma importante a qué accede el agente y cómo se comporta. La API que expongas para invocar el harness debería eliminar los campos que el cliente nunca debería controlar y restringir los valores restantes mediante una lista de permitidos.
AgentCore Harness no tiene un cargo de servicio aparte. Pagas el precio habitual por la inferencia del modelo, el consumo de Runtime, la memoria administrada, Browser, Gateway, Code Interpreter, el almacenamiento, la transferencia de datos, CloudWatch y cualquier otra cosa que uses. La configuración también es el lugar adecuado para agregar tags y límites que te permitan atribuir y acotar esos costos. Para las llamadas a Bedrock, te conviene usar un inference profile con los tags que quieras, en lugar del ID de un modelo base. Los tags del Harness se propagan al Runtime administrado, al endpoint de Runtime y a la memoria administrada que crea. Necesitas etiquetar por separado los recursos creados de forma independiente, como Gateway, EFS, S3 y los recursos de Memory existentes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Inside your AWS::BedrockAgentCore::Harness resource
MaxIterations: 12
MaxTokens: 8000
TimeoutSeconds: 300
Tags:
- Key: application
Value: aws-release-researcher
- Key: environment
Value: production
- Key: owner
Value: platform-team
- Key: cost-center
Value: genaiPara usar esos tags en Cost Explorer y los informes de facturación, todavía necesitas activar sus claves como tags de asignación de costos definidos por el usuario en AWS Billing and Cost Management.
El ciclo de publicación de un Harness
Ya te mostré lo fácil que es crear el primer Harness. Pero después de cinco cambios de prompt, dos experimentos con modelos y una herramienta nueva, probablemente te cueste seguirle el rastro a lo que hace. Ahí es donde las versiones y los endpoints se vuelven útiles.
Supongamos que la versión 1 de nuestro investigador informa la fecha del lanzamiento y los enlaces a las fuentes, pero los usuarios también quieren conocer la disponibilidad regional y recibir una advertencia cuando una página de AWS todavía contiene referencias desactualizadas a una preview. Podemos probar esas instrucciones nuevas con una sobrescritura por invocación e iterar hasta encontrar el prompt adecuado. Después actualizamos la configuración del Harness.
Esa actualización crea una versión nueva e inmutable del Harness. La versión 1 sigue conteniendo el modelo, el prompt, las herramientas, la memoria, el entorno y los límites originales. La versión 2 contiene la definición actualizada con nuestros cambios.
Los endpoints de Harness determinan qué versión recibe las solicitudes. El endpoint
DEFAULT, que se crea automáticamente, siempre sigue la versión más reciente. También puedes crear endpoints con nombre y controlar a qué versión apuntan.Para producción, te recomiendo crear un endpoint con nombre en lugar de enviar el tráfico a través de
DEFAULT:1
2
3
4
5
aws bedrock-agentcore-control create-harness-endpoint \
--harness-id "$HARNESS_ID" \
--endpoint-name "production" \
--target-version "1" \
--description "Production release researcher"Puedes actualizar el Harness varias veces mientras
production sigue en la versión 1. Cuando la versión 2 pase tus pruebas, cambia el endpoint para que apunte a ella:1
2
3
4
5
aws bedrock-agentcore-control update-harness-endpoint \
--harness-id "$HARNESS_ID" \
--endpoint-name "production" \
--target-version "2" \
--description "Promote version 2"Si la nueva versión se comporta mal, puedes volver a apuntar el endpoint a la versión 1 y revertir el cambio. No necesitas conservar el prompt anterior ni recordar qué configuración del modelo usabas entonces: la versión 1 contiene todo eso.
Así es como deberías iterar sobre un Harness:
Sobrescribir un ajuste → inspeccionar la sesión → evaluar el resultado → actualizar el Harness → crear una nueva versión → cambiar la versión a la que apunta el endpoint
Deberías seguir este proceso con cada cambio. Recuerda que cualquier elemento de la configuración puede alterar de forma importante el comportamiento del agente. Un simple cambio de prompt puede hacer que el modelo elija otra herramienta. Una skill nueva puede cambiar el procedimiento que sigue. Elegir otro modelo puede afectar la calidad de la respuesta, la latencia y el costo. Es una ventaja que ninguno de esos cambios requiera reconstruir la aplicación, pero todos pueden cambiar lo que ven los usuarios y lo que reciben los sistemas posteriores. Por eso necesitas tratarlos como nuevas versiones de la aplicación.
Observabilidad y evaluaciones de Harness
Harness envía trazas, logs y métricas de las llamadas a modelos, las llamadas a herramientas, las operaciones de memoria y los comandos de shell a AgentCore Observability y CloudWatch. Necesitas habilitar CloudWatch Transaction Search para que esas trazas sean visibles y, después, decidir qué paneles, alertas, opciones de retención e informes de costos usará tu equipo.
Harness también te ofrece un panel de observabilidad donde puedes monitorear tus agentes. Muestra los mismos datos que CloudWatch e incluye enlaces para que puedas acceder fácilmente a información más detallada en CloudWatch.

AgentCore Evaluations puede puntuar las sesiones y comparar el comportamiento a medida que introduces cambios. Las evaluaciones por lotes permiten evaluar varias versiones con el mismo conjunto de datos. Además, las capacidades de optimización van más allá: pueden generar recomendaciones para los prompts o las descripciones de herramientas y probar variantes. El servicio puede ejecutar la evaluación, pero tú sigues necesitando aportar casos representativos y un umbral relevante para la aplicación.
Para el investigador de lanzamientos, ese conjunto de datos podría incluir preguntas sobre lanzamientos con documentación clara, lanzamientos cuyo estado pasó de preview a GA y servicios con páginas contradictorias o desactualizadas. Una evaluación que solo comprueba si la respuesta final es fluida y está bien escrita no detectará los errores que este agente busca evitar: información desactualizada presentada con seguridad como si siguiera vigente.
Los límites de AgentCore Harness
Harness es fácil de usar porque toma varias decisiones por ti. Ejecuta un ciclo del agente administrado por AWS y basado en Strands, con los puntos de configuración que expone AgentCore. Puedes seleccionar modelos, proporcionar instrucciones, conectar herramientas y skills, configurar la memoria y el entorno, y establecer límites de ejecución. La principal limitación es que no puedes reemplazar ese ciclo por cualquier flujo de control que quieras.
Si necesitas otro framework de agentes, orquestación mediante grafos o flujos de trabajo dentro del agente, hooks o middleware personalizados, streaming bidireccional o control directo sobre cómo avanza cada paso de razonamiento, tendrás que definir tu agente de la manera tradicional y ejecutarlo directamente en AgentCore Runtime. En esos casos, la orquestación forma parte de tu aplicación, en lugar de ser infraestructura reutilizable de soporte, así que las opciones predeterminadas razonables que ofrece Harness para implementarla dejan de servir para tu caso.
Tienes cierto margen entre un Harness completamente administrado y un agente completamente personalizado. Las funciones inline permiten que el cliente ejecute llamadas individuales a herramientas, o puedes usar AWS Step Functions para integrar un Harness en un flujo de trabajo determinista más amplio, con bifurcaciones, reintentos, aprobaciones y pasos que no dependen de agentes. Así, el ciclo de razonamiento sigue siendo administrado y fácil de construir, mientras que el proceso completo permanece explícito y muy configurable.
Nota de seguridad: Harness no puede decirte si el comportamiento que configuraste es seguro para tu aplicación. Al ejecutarse, el agente asume un rol de IAM que tú proporcionas, pero sigues necesitando limitar ese rol a los modelos, herramientas, credenciales y recursos que el agente requiere. Los repositorios de skills y las ubicaciones de S3 se tratan como contenido de confianza, aunque probablemente te convenga restringir ese alcance. Las sobrescrituras por invocación pueden cambiar la configuración del proveedor y las herramientas disponibles, y evitarlo es tu responsabilidad. Tanto quien hace la llamada como el Harness pueden estar autenticados y, aun así, la acción solicitada puede ser algo que tu aplicación deba rechazar. Puedes implementar controles muy sólidos con Autorización por capas para agentes de IA con Amazon Bedrock AgentCore .
La memoria necesita el mismo nivel de atención. La memoria administrada es práctica y puedes habilitarla fácilmente a través del Harness, pero los IDs de actor, la retención, la recuperación, la privacidad y la eliminación siguen siendo decisiones de la aplicación, es decir, tuyas. El servicio puede recordar que
user-123 prefiere resúmenes cortos, pero tu aplicación debe garantizar que quien inició una invocación del agente realmente tenga permiso para leer y escribir la memoria de user-123.Exportar un Harness
AgentCore puede convertir un Harness existente en código fuente Python editable que usa Strands. Esto te da una vía práctica para pasar de un agente administrado mediante configuración a uno basado en código que puede ejecutarse en AgentCore Runtime, sin tener que recrearlo todo a mano.
La exportación incorpora al agente generado la configuración del modelo, las herramientas, las skills, la memoria, los límites de ejecución, el truncamiento del contexto, los montajes del sistema de archivos y la configuración de autorización. Actualmente, el único destino de exportación disponible es Python con Strands, con un build de tipo
CodeZip o contenedor. AWS indica en su documentación que el soporte para otros frameworks llegará próximamente; por ahora no hay confirmación de una fecha de lanzamiento ni de soporte para otros lenguajes.Creamos nuestro investigador de lanzamientos en la consola, así que, para exportarlo mediante la CLI de AgentCore, necesitamos usar su ARN:
1
2
3
4
agentcore export harness \
--arn "$HARNESS_ARN" \
--target-agent-name "AWSReleaseResearcherRuntime" \
--build CodeZipSi creaste el Harness dentro del mismo proyecto de la CLI de AgentCore, puedes usar su nombre:
1
2
3
agentcore export harness \
--name "aws_release_researcher" \
--target-agent-name "AWSReleaseResearcherRuntime"Si quieres usar un Runtime basado en contenedores, puedes cambiar el tipo de build durante la exportación:
1
2
3
4
agentcore export harness \
--arn "$HARNESS_ARN" \
--target-agent-name "AWSReleaseResearcherRuntime" \
--build ContainerLa CLI guarda el agente generado en
app/ y lo añade al proyecto de AgentCore como cualquier otro Runtime. Antes de tocar el código, deberías leer el archivo EXPORT_NOTES.md generado. Ese archivo enumera la configuración que el exportador no pudo trasladar automáticamente, explica por qué necesita atención y te indica qué cambiar. Una vez resueltos esos puntos, puedes desplegar el agente generado en AgentCore Runtime ejecutando agentcore deploy.A partir de ese momento, el agente generado es código fuente como cualquier otro. Puedes cambiar el ciclo de Strands, añadir middleware, integrar otra biblioteca de Python, implementar un comportamiento personalizado para las herramientas o reestructurar cómo razona el agente. También pasan a ser responsabilidad tuya sus tests, dependencias, empaquetado, actualizaciones de seguridad, despliegue y mantenimiento futuro.
Ten en cuenta que no necesitas exportar un Harness simplemente porque haya llegado a producción. Las versiones, los endpoints con nombre, la observabilidad, las evaluaciones, la memoria administrada y el soporte de infraestructura como código siguen disponibles mientras el agente siga siendo un Harness. Deberías exportarlo cuando necesites configurar algo que Harness no admite.
Conclusión
AgentCore Harness y la consola de AWS te ofrecen el camino más rápido a un agente, con solo tres clics. La opción Advanced create harness te permite definir los valores de cada elemento de configuración. El SDK y CloudFormation exponen el mismo agente como un recurso que puedes automatizar y revisar. Las sobrescrituras por invocación te permiten probar cambios sin modificar ese recurso. Las versiones inmutables y los endpoints con nombre te permiten publicar esos cambios de forma controlada. La exportación te da el código fuente cuando necesitas cambiar algo que la configuración de Harness no admite.
Sigues necesitando construir las partes específicas de tu aplicación. El prompt debe definir una tarea clara. Las herramientas necesitan un comportamiento correcto y permisos acotados. La memoria necesita estar correctamente delimitada por usuario. Las evaluaciones necesitan casos representativos. La aplicación sigue necesitando una interfaz, controles de acceso, presupuestos y alguien que se haga responsable del resultado. Y el trabajo de seguridad sigue siendo responsabilidad tuya.
Harness te permite separar el qué del cómo. Defines mediante configuración cada elemento de tu agente, y Harness se encarga de cómo implementar cada uno y cómo conectarlos entre sí. Además, te da suficiente control para llevar un agente a producción y seguir administrándolo a través de Harness, con versiones, endpoints y sobrescrituras por invocación. No es exactamente que Harness se te quede pequeño, pero podrías llegar al límite de sus opciones de configuración. En ese punto puedes exportarlo y continuar en código.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article